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 ;-)
Réponses:
Lire les articles sur HFSC et ses cousins n’est pas un bon moyen de le comprendre. L'objectif principal du document HFSC est de fournir une preuve mathématique rigoureuse de ses affirmations, sans expliquer son fonctionnement. En effet, vous ne pouvez pas comprendre comment cela fonctionne à partir du document HFSC seul, vous devez également lire les documents auxquels il fait référence. Si vous avez un problème avec la revendication ou ses preuves, contacter les auteurs des articles peut être une bonne idée, sinon je doute qu'ils soient intéressés à recevoir de vos nouvelles.
J'ai écrit un tutoriel pour HFSC . Lisez-le si mes explications ci-dessous ne sont pas claires.
La courbe en temps réel et la courbe de partage de lien sont évaluées de différentes manières. La courbe en temps réel prend en compte ce que la classe a fait tout au long de son histoire. Il doit le faire pour fournir une allocation de bande passante et de latence précise. L'inconvénient n'est pas ce que la plupart des gens pensent intuitivement comme juste . En temps réel, si une classe emprunte de la bande passante lorsque personne d'autre ne la veut, elle est pénalisée si quelqu'un d'autre la souhaite plus tard. Cela signifie qu’en temps réel, une classe ne peut obtenir de la bande passante pendant une longue période, car elle l’a utilisée plus tôt, quand personne ne la voulait.
Le partage de liens est juste, en ce sens qu'il ne pénalise pas une classe d'utilisation de bande passante disponible. Cependant, cela signifie qu'il ne peut pas fournir de garanties de latence élevées.
La séparation entre le partage des liens et la fourniture de garanties de latence est la nouveauté apportée par HFSC, ainsi que le dit le texte dans sa phrase d'introduction: Dans cet article, nous étudions des modèles et des algorithmes de gestion hiérarchique des ressources prenant en charge à la fois le partage de liens et la garantie. services en temps réel avec délai découplé (priorité) et allocation de la bande passante. Le mot clé dans cette phrase est découplé. Traduit, cela signifie que vous êtes censé indiquer comment la bande passante inutilisée doit être partagée avec ls, et spécifier quelles garanties en temps réel (comme les garanties de latence) sont nécessaires avec rt. Les deux sont orthogonaux.
Oui. Dans le document HFSC, ils définissent la bande passante en fonction de ce que la classe a envoyé depuis que la classe est en retard de traitement (c'est-à-dire que des paquets sont en attente d'envoi). La seule différence entre rt et ls est que rt attend avec impatience chaque fois que la classe est en retard de traitement et calcule la bande passante garantie la plus basse à partir de cet ensemble, alors que le partage de liens ne semble à partir de la dernière fois que la classe est en retard de traitement. Ainsi, rt prend plus en considération que ls, mais chaque octet que ls considère est également pris en compte par rt.
La limite supérieure n'empêche pas l'envoi de paquets pour satisfaire à la condition de temps réel. Les paquets envoyés dans la condition de temps réel comptent toujours dans la limite supérieure et risquent donc de retarder l'envoi d'un paquet dans la condition de partage de liaison à l'avenir. C'est une autre différence entre le temps réel et le partage de liens.
Oui, cela fait une différence. Comme expliqué ci-dessus, si vous utilisez le temps réel, les latences sont garanties mais le lien n'est pas partagé équitablement (et la classe risque en particulier de manquer de bande passante) et les limites supérieures ne sont pas appliquées. Si vous utilisez le partage de lien, la latence n'est pas garantie, mais le partage de lien est juste, il n'y a aucun risque d'inanition et la limite supérieure est appliquée. Le temps réel est toujours vérifié avant le partage de lien, mais cela ne signifie pas nécessairement que le partage de lien sera ignoré. C'est parce que les paquets sont comptés différemment. Étant donné que l'historique est considéré en temps réel, un paquet peut ne pas avoir besoin de respecter la garantie en temps réel (en raison du décompte inclus de l'historique), mais il est nécessaire pour satisfaire le partage de lien car il ignore le paquet historique.
La courbe des contrôles en temps réel vous permet d'échanger une latence étroite pour une classe de trafic particulière (par exemple, VoIP) contre une latence médiocre pour d'autres classes de trafic (par exemple, la messagerie électronique). Lorsque vous décidez quel paquet envoyer en respectant la contrainte de temps réel, HFSC choisit celui qui effectuera le premier envoi. Cependant, il n'utilise pas la bande passante du lien pour calculer cela, il utilise la bande passante allouée par la courbe en temps réel. Ainsi, si nous avons des paquets VOIP et de courrier électronique de la même longueur et que le paquet VOIP a une courbe convexe qui donne un gain de 10 fois sur la courbe concave pour le courrier électronique, 10 paquets VOIP seront envoyés avant le premier paquet de courrier électronique. Mais cela ne se produit que pour le temps de rafale, qui devrait être au maximum le temps nécessaire pour envoyer quelques paquets, c'est-à-dire quelques millisecondes. Ensuite, la courbe VOIP devrait s’aplatir, et la VOIP n’obtiendra pas d’augmentation future sauf si elle recule un peu (ce qui devrait être le cas, étant donné que VOIP est une application à faible bande passante). Le résultat net de tout cela est de garantir que les deux premiers paquets VOIP soient envoyés plus rapidement que toute autre chose, donnant ainsi à la VOIP une faible latence au détriment de la latence élevée des e-mails.
Comme je l’ai dit plus tôt, comme le partage de lien ne regarde pas l’historique, il ne peut pas donner de garantie de latence. Une garantie à toute épreuve est nécessaire pour un trafic en temps réel tel que la VOIP. Cependant, en moyenne, une courbe convexe partagée de liaison fournira toujours une augmentation de latence à son trafic. Ce n'est simplement pas garanti. C'est bien pour la plupart des choses, comme le trafic Web par courrier électronique.
La documentation est correcte. La hiérarchie (et donc les nœuds internes) n’a aucun effet sur le calcul du temps réel. Je ne peux pas vous dire pourquoi ALTQ pense évidemment que oui.
Les deux ont tort. Si 70% ou 80% de votre trafic a des exigences de latence strictes qui doivent être spécifiées en temps réel, le fait est que vous ne pourrez certainement pas les satisfaire avec le lien que vous utilisez. Vous avez besoin d'un lien plus rapide.
La seule façon pour quelqu'un de penser spécifier 80% du trafic devrait être en temps réel, c'est si elle utilisait la priorité en temps réel. Oui, afin de garantir la latence, vous augmentez en fait la priorité de certains paquets. Mais cela ne devrait durer que quelques millisecondes. C’est tout ce qu’un lien peut gérer et toujours fournir les garanties de latence.
Il existe très peu de trafic nécessitant des garanties de latence. La VOIP en est une, le NTP un autre. Le reste devrait être fait avec le partage de liens. Si vous voulez que le Web soit rapide, vous le faites rapidement en lui attribuant l'essentiel de la capacité des liens. Cette part est garantie à long terme. Si vous voulez que la latence soit faible (en moyenne), donnez-lui une courbe convexe sous le partage de liens.
C'est une bonne description limite supérieure. Bien que la description du partage de lien soit strictement exacte, elle est trompeuse. Bien que le partage de liens véritable ne donne pas les garanties de latence strictes comme le fait le temps réel, il offre un meilleur travail de dotation en bande passante à la classe que ses concurrents, comme CBQ et HTB. Donc, en disant que le partage de lien "ne fournit pas de garanties", il le maintient à un niveau supérieur à celui que tout autre planificateur peut fournir.
La description en temps réel parvient à être à la fois précise, mais tellement trompeuse que je dirais que c'est faux. Comme son nom l'indique, le but en temps réel n'est pas de fournir une bande passante garantie. Il s'agit de fournir une latence garantie - c'est-à-dire que le paquet est envoyé MAINTENANT, et non une durée aléatoire en fonction de l'utilisation du lien. La plupart du trafic n'a pas besoin de latence garantie.
Cela dit, le temps réel ne donne pas non plus de garantie de latence parfaite. Cela pourrait se produire si le lien n'était pas géré par partage de lien également, mais la plupart des utilisateurs souhaitent bénéficier de la souplesse supplémentaire associée à la présence des deux et cela n'est pas gratuit. Le temps réel peut manquer l’échéance de latence avant d’envoyer un paquet MTU. (Si cela se produit, ce sera probablement parce qu'il s'agissait d'un partage de liaison de paquets MTU enfermé tout en maintenant en temps réel le lien inactif, au cas où il recevrait un paquet avec un délai court qu'il devait envoyer immédiatement. C'est une autre différence entre le partage de liens. Afin de fournir ses garanties, le temps réel peut délibérément garder la ligne inactive même s’il ya des paquets à envoyer, fournissant ainsi moins de 100% d’utilisation des liens. Le partage de liens utilise toujours 100% de la capacité disponible des liens. ,
On peut dire que le temps réel offre des garanties de latence strictes parce que le délai est limité. Donc, si vous essayez d’offrir une garantie de latence de 20 ms sur un lien de 1 Mbit / s et que le partage de lien envoie des paquets de taille MTU (1 500 octets), vous savez qu’un de ces paquets prendra 12 ms à envoyer. Ainsi, si vous indiquez en temps réel que vous souhaitez une latence de 8 ms, vous pouvez toujours respecter le délai de 20 ms - avec une garantie absolue.
Il n'y a pas de modèle de priorisation. Sérieusement. Si vous souhaitez attribuer des priorités absolues au trafic, utilisez pfifo. C'est ce que c'est pour. Mais méfiez - vous aussi que si vous donnez le trafic web une priorité absolue sur le trafic e - mail, cela signifie laisser le trafic web sature le lien et donc pas de paquets de courrier électronique passer à travers, tout . Toutes vos connexions par courrier électronique meurent alors.
En réalité, personne ne veut ce genre de priorisation. Ce qu'ils veulent, c'est ce que fournit HFSC. Si vous avez réellement du trafic en temps réel, HFSC vous le fournira. Mais ce sera tout. Pour le reste, HFSC vous permet de dire "sur un lien encombré, allouez 90% au Web, laissez les courriels filer à 10%, et oh envoyez rapidement le paquet DNS impair, mais ne laissez pas quelqu'un me Dos avec."
la source
Vous pouvez définir les courbes avec des noms différents:
Lorsque vous définissez une définition avec des taux uniquement dans HFSC, elle définit automatiquement «dmax» sur 0. Cela signifie en gros que le délai n’est pas pris en compte. Une bonne configuration HFSC doit inclure à la fois la bande passante ET les limites de retard que vous souhaitez utiliser pour votre classe, sinon l'algorithme ne peut pas déterminer exactement quelle priorité une classe devrait avoir.
Chaque fois que vous accordez la priorité aux paquets, vous devrez réduire la priorité des autres paquets. Sur la base des valeurs 'dmax' et 'rate', toutes les classes seront multiplexées à l'aide de minuteries virtuelles. Reportez-vous à tc-hfsc (7) pour plus d'informations.
Si le flux ne dépasse pas les limites de la définition de partage de liens de la classe, la courbe en temps réel n'est jamais utilisée. Définir une courbe en temps réel dans ce cas vous permet par exemple: de garantir un certain «dmax».
Si vos définitions de partage de liens sont sans faille, vous n’auriez pas besoin de courbes en temps réel. Vous pouvez simplement définir des courbes de service (sc), mais cela rendrait votre configuration plus difficile.
La courbe de limite supérieure de votre classe s'applique uniquement au partage de lien. Lorsque vous définissez une courbe de limite supérieure, vous DEVEZ définir une courbe de partage de lien. Cependant, la courbe de limite supérieure des classes parentes est toujours appliquée.
Il existe une légère différence, par exemple A2 = 0 kbits / s et B2 = 256 kbits / s. Ensuite, le temps virtuel pour A2 sera à son maximum. Chaque fois que les paquets sont classés en A2, ils sont traités instantanément. Cependant, la courbe en temps réel de B2 permettra toujours de pouvoir transmettre au moins 64 kbit / s.
Les courbes en temps réel ne partagent pas le trafic entre les feuilles voisines, contrairement aux courbes de partage de liens.
Il est vrai que les courbes en temps réel sont ignorées pour les classes internes, elles ne sont appliquées qu'aux classes feuille. Toutefois, les courbes en temps réel définies sur ces classes internes sont prises en compte pour les calculs sur les classes feuille.
Ce qu'ils veulent dire, c'est: vous ne pouvez pas hiérarchiser tout le trafic ... Chaque fois que vous accordez la priorité aux paquets, vous devrez réduire la priorité des autres paquets. Si vous sur-garantissez, l'algorithme devient inutile. Définissez les classes gagnantes en priorités et définissez les classes susceptibles de souffrir.
C'est correct.
La différence entre, par exemple, HFSC et HTB est que HFSC vous permettra de définir exactement le degré de priorité que vous souhaitez lui donner. Vous faites cela en définissant des limites minimum et maximum avec la valeur 'dmax'.
la source
Enfin, un guide qui semble expliquer la plupart des incohérences et explique en quoi la mise en œuvre actuelle est différente de celle du document original:
http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html
Selon ce guide, de nombreux autres guides et messages sur le forum sur le HFSC sont totalement insensés. cela montre simplement à quel point les HFSC sont complexes, car beaucoup de personnes qui semblent être des experts et prétendent les comprendre parfaitement n'ont en fait qu'une connaissance partielle et font de fausses déclarations basées sur une incompréhension du concept et de la manière dont tous ces paramètres fonctionnent ensemble.
Je pense que je vais enfin renoncer à HFSC. Si vous parvenez à configurer correctement votre système HFSC, il se peut que vous obteniez la meilleure qualité de service, mais les chances de vous perdre complètement sont bien plus grandes que les chances de succès.
la source
Si vous ne parvenez pas à mettre la main sur les auteurs originaux, j'essaierai ensuite:
Essayez également de vérifier d'autres documents plus récents qui citent celui-ci. Il se peut que de nouveaux articles poursuivent la recherche dans ce domaine et qu'ils incluent davantage d'informations sur les questions que vous posez.
la source