J'ai lu le document original SIGCOMM '97 PostScript sur HFSC, très technique, mais je comprends le concept de base. Au lieu de donner une courbe de service linéaire (comme avec pratiquement tous les autres algorithmes de planification), vous pouvez spécifier une courbe de service convexe ou concave et ainsi il est possible de découpler la bande passante et le retard. Cependant, même si cet article mentionne le type d'algorithme de planification utilisé (temps réel et partage de liens), il ne mentionne toujours qu'une courbe par classe de planification (le découplage est effectué en spécifiant cette courbe, une seule courbe suffit pour cela. )
Maintenant, HFSC a été implémenté pour BSD (OpenBSD, FreeBSD, etc.) en utilisant le cadre de planification ALTQ et a été mis en œuvre sous Linux en utilisant le cadre de planification de TC (qui fait partie de iproute2). Les deux implémentations ont ajouté deux courbes de service supplémentaires, qui n'étaient PAS dans le document d'origine! Une courbe de service en temps réel et une courbe de service limite supérieure. Encore une fois, veuillez noter que le document d'origine mentionne deux algorithmes de planification (temps réel et partage de liens), mais que, dans ce document, les deux fonctionnent avec une seule courbe de service. Il n’ya jamais eu deux courbes de service indépendantes pour l’une ou l’autre, comme on en trouve actuellement dans BSD et Linux.
Pire encore, certaines versions d’ALTQ semblent ajouter une priorité de file d’attente supplémentaire à la FMCC (la priorité n’existe pas non plus dans le document original). J'ai trouvé plusieurs BSD HowTo mentionnant ce paramètre de priorité (même si la page de manuel de la dernière version d'ALTQ ne contient aucun paramètre de ce type pour HSFC, donc officiellement, il n'existe même pas).
Tout cela rend l'ordonnancement HFSC encore plus complexe que l'algorithme décrit dans le document d'origine et il existe sur Internet de nombreux tutoriels qui se contredisent souvent, l'un prétendant le contraire. C'est probablement la raison principale pour laquelle personne ne semble vraiment comprendre comment fonctionne la planification HFSC. Avant de pouvoir poser mes questions, nous avons besoin d’un exemple de configuration. J'en utiliserai une très simple, comme le montre l'image ci-dessous:
alt text http://f.imagehost.org/0177/hfsc-test-setup.png
Voici quelques questions auxquelles je ne peux pas répondre car les tutoriels se contredisent:
Pourquoi ai-je besoin d'une courbe en temps réel? En supposant que A1, A2, B1, B2 correspondent à un partage des liens à 128 kbit / s (pas de courbe en temps réel pour l’un ou l’autre), chacun d’entre eux obtiendra 128 kbit / s si la racine a 512 kbit / s à distribuer (et A et B sont tous deux à 256 kbit / s bien sûr), non? Pourquoi devrais-je également donner à A1 et B1 une courbe en temps réel à 128 kbit / s? Qu'est-ce que ce serait bon? Pour donner à ces deux une priorité plus élevée? Selon le document original, je peux leur donner une priorité plus élevée en utilisant une courbe , c'est ce qu'est le HFSC après tout. En donnant aux deux classes une courbe de [256kbit / s 20ms 128kbit / s], les deux priorités ont deux fois plus de priorité que A2 et B2 automatiquement (n'obtenant que 128 kbit / s en moyenne)
La bande passante en temps réel compte-t-elle dans la bande passante en partage de liens? Par exemple, si A1 et B1 ne disposent que de la bande passante en partage de liens en temps réel à 64 kbit / s et à 64 kbit / s, cela signifie-t-il que dès qu’ils sont servis à 64 kbit / s en temps réel, leurs besoins en partage de liens sont également satisfaits ( excès de bande passante, mais ignorons cela pendant une seconde) ou cela signifie-t-il qu'ils obtiennent un autre débit de 64 kbit / s via le partage de liens? Ainsi, chaque classe a-t-elle une "exigence" de bande passante de partage en temps réel plus? Ou bien une classe a-t-elle une exigence plus élevée que la courbe en temps réel si la courbe de partage de lien est supérieure à la courbe en temps réel (l'exigence actuelle de partage de lien est égale à l'exigence de partage de lien spécifiée moins la bande passante en temps réel déjà fournie à cette classe)?
La courbe limite supérieure est-elle appliquée également au temps réel, uniquement au partage de lien, ou peut-être aux deux? Certains tutoriels disent d'une manière, d'autres disent de l'autre. Certains prétendent même que la limite supérieure est la limite maximale pour la bande passante en temps réel + la bande passante en partage de lien? Quelle est la vérité?
En supposant que A2 et B2 sont tous deux à 128 kbit / s, est-ce que cela fait une différence si A1 et B1 sont uniquement à partage de liens à 128 kbit / s ou à 64 kbit / s en temps réel et à 128 kbit / s en partage de liens, et si oui , quelle différence?
Si j'utilise la courbe en temps réel séparée pour augmenter les priorités des classes, pourquoi aurais-je besoin de "courbes"? Pourquoi le temps réel n'est-il pas une valeur fixe et le partage de liens n'est-il pas non plus une valeur fixe? Pourquoi les deux courbes? Le besoin de courbes est clair dans le document d'origine, car il n'y a qu'un seul attribut de ce type par classe. Mais maintenant, ayant trois attributs (temps réel, partage de lien et limite supérieure), pour quoi ai-je encore besoin de courbes? Pourquoi voudrais-je que la forme des courbes (pas la bande passante moyenne, mais leurs pentes) soit différente pour le trafic en temps réel et en partage de liens?
Selon le peu de documentation disponible, les valeurs de courbe en temps réel sont totalement ignorées pour les classes internes (classes A et B), elles ne sont appliquées qu'aux classes feuilles (A1, A2, B1, B2). Si cela est vrai, pourquoi l' exemple de configuration d'ALTQ HFSC (recherche de la configuration de l'échantillon 3.3 ) définit-il des courbes en temps réel sur les classes internes et prétend-il que celles-ci définissent le taux garanti de ces classes internes? N'est-ce pas complètement inutile? (Remarque: pshare définit la courbe de partage de liens dans ALTQ et grille la courbe en temps réel; vous pouvez le voir dans le paragraphe situé au-dessus de l'exemple de configuration).
Certains tutoriels indiquent que la somme de toutes les courbes en temps réel peut ne pas dépasser 80% de la vitesse de la ligne, tandis que d'autres indiquent qu'elle ne doit pas être supérieure à 70% de la vitesse de la ligne. Lequel a raison ou ont-ils peut-être tort tous les deux?
Un tutoriel a dit que vous allez oublier toute la théorie. Quelle que soit la manière dont les choses fonctionnent réellement (ordonnanceurs et distribution de la bande passante), imaginez les trois courbes selon le "modèle mental simplifié" suivant: le temps réel est la bande passante garantie que cette classe obtiendra toujours. Le partage de liens est la bande passante que cette classe veut devenir pleinement satisfaite, mais la satisfaction ne peut être garantie. En cas d'excès de bande passante, la classe peut même se voir proposer plus de bande passante que nécessaire pour être satisfaite, mais elle ne peut jamais utiliser plus que la limite supérieure. Pour que tout cela fonctionne, la somme de toutes les largeurs de bande en temps réel ne doit pas dépasser xx% de la vitesse de la ligne (voir la question ci-dessus, le pourcentage varie). Question: Est-ce plus ou moins exact ou une incompréhension totale de la FMCC?
Et si l'hypothèse ci-dessus est vraiment exacte, où est la hiérarchisation dans ce modèle? Par exemple, chaque classe peut avoir une bande passante en temps réel (garantie), une bande passante en partage de lien (non garantie) et peut-être une limite supérieure, mais certaines classes ont des besoins de priorité supérieurs à ceux des autres classes. Dans ce cas, je dois quand même prioriser, même parmi le trafic en temps réel de ces classes. Aurais-je prioriser par la pente des courbes? Et si oui, quelle courbe? La courbe en temps réel? La courbe de partage des liens? La courbe limite supérieure? Tous? Est-ce que je leur donnerais tous la même pente ou une autre et comment trouver la bonne pente?
Je n'ai toujours pas perdu espoir qu'il existe au moins une poignée de personnes dans ce monde qui comprennent vraiment HFSC et sont capables de répondre à toutes ces questions avec précision. Et le faire sans se contredire dans les réponses serait vraiment sympa ;-)