Résumé

  • RFC 3337 fit passer une même session PPP sur plusieurs Channel Identifiers AAL2, chacun représentant une classe de préemption. Les fragments SSSAR de 64 octets permettaient d’insérer un fragment urgent entre deux fragments d’un gros paquet.
  • Le CID ne choisissait ni l’ordonnanceur ni la capacité du circuit. Classification, mapping, service de file, contrat ATM, réassemblage et résultat applicatif devaient être prouvés séparément ; les cent millisecondes et la borne de l’exemple équitable restaient conditionnelles.

Cent millisecondes naissaient avant toute congestion complexe

Le problème de départ n’exigeait pas une panne spectaculaire. Un paquet de 1 500 octets transmis à 128 kbit/s occupait la liaison pendant environ 100 ms. Une petite trame vocale arrivée juste après devait attendre la fin de la sérialisation. Pour de nombreuses interactions, ce seul délai suffisait à dégrader la conversation.

Une priorité logique attribuée après le début du paquet ne pouvait interrompre les bits déjà engagés. Il fallait réduire l’unité de préemption. RFC 3337 réutilisa SSSAR, déjà présent dans PPP sur AAL2, pour couper les paquets en fragments de 64 octets. Le temps d’indisponibilité pouvait alors être borné par un fragment, sous réserve que le scheduler choisisse réellement l’autre classe.

Le chiffre de 100 ms n’était ni une mesure universelle ni une promesse. Il liait un paquet, un débit et une opération de sérialisation. Sa valeur historique est de montrer que le délai peut être fabriqué par la taille de l’unité non interruptible avant même les files du reste du réseau.

Le CID rendait la classe visible à celui qui pouvait agir

Une session PPP pouvait recevoir plusieurs CID CPS. RFC 3337 exigeait des CID différents pour des classes de préemption différentes et au moins autant de CID que de classes préemptibles. Après classification, chaque paquet entrait dans l’instance SSSAR et la file CID correspondant à sa classe.

Cette disposition transformait une intention abstraite en choix exploitable. Le scheduler CPS voyait plusieurs files au lieu d’un flux unique. Il pouvait placer un fragment prioritaire entre des fragments ordinaires.

Mais l’exactitude du mapping restait à prouver. Un paquet bien classé pouvait être envoyé vers le mauvais CID. Deux classes pouvaient être fusionnées après une reconfiguration. L’étiquette d’entrée et le CID transmis sont deux reçus, non une seule vérité.

Le classificateur lui-même n’était pas fixé

Le RFC autorisait plusieurs méthodes de classification. Son exemple voix séparait petits et grands paquets, avec un seuil dépendant de l’application et du débit du circuit. Ce choix était simple à mettre en œuvre, pas une définition de la voix.

Un petit paquet peut être une opération de maintenance sans urgence ; un objet média plus grand peut avoir une échéance. Une règle ancienne peut continuer à fonctionner exactement tout en servant un produit différent de celui décrit par la politique. Il faut donc conserver version, champs inspectés, seuil, résultat et autorité d’approbation.

Cette liberté empêchait le format de devenir un contrat de service autonome. Deux équipements conformes pouvaient classer différemment, ou recevoir une classification externe différente, tout en utilisant les mêmes CID.

L’ordonnanceur donnait enfin un verbe à la classe

AAL2 CPS ne prescrivait pas l’algorithme entre CID. RFC 3337 évoquait priorité stricte, équité et équité pondérée selon les besoins. Chacun crée une relation différente entre délai, débit et risque de famine.

Dans l’exemple à deux classes, un scheduler équitable faisait attendre un fragment temps réel au plus pendant la transmission d’un fragment non temps réel. La borne dépendait des fragments de 64 octets, de deux files distinctes et d’une équité appliquée à cette granularité. Elle ne signifiait ni attente nulle ni résultat de bout en bout.

Une priorité stricte pouvait réduire davantage ce délai mais affamer les données. Un quantum plus grand pouvait casser la borne. Ajouter des classes changeait le cycle. Le nom de la classe ne décrivait donc pas l’algorithme actif ; il fallait enregistrer celui-ci et ses paramètres.

Le circuit devait encore fournir le service

L’exemple vocal ajoutait une exigence : pour garantir faible latence et pertes, le circuit virtuel ATM devait être provisionné avec une classe temps réel appropriée telle que VBRnrt ou VBRrt. L’ordonnanceur local ne pouvait créer de capacité.

Sans admission, contrat de trafic et file disponible en aval, la préférence déplaçait seulement l’attente. En surcharge, le scheduler choisit le perdant ; il ne satisfait pas toutes les demandes. Le policing pouvait aussi supprimer un paquet correctement classé.

Il existe ainsi trois autorités : le classificateur exprime le traitement souhaité, l’ordonnanceur choisit le prochain fragment, et le provisionnement fournit ou refuse les ressources. Une capture de configuration de la première ne prouve pas les deux autres.

Le récepteur avait le dernier mot factuel

SSSAR utilisait les règles de base de RFC 3336, avec état UUI pour les fragments intermédiaires et finaux. Le départ rapide d’un fragment ne prouvait pas que tous les suivants arrivent, que le réassemblage et le CRC réussissent, que PPP accepte le paquet ou que le tampon vocal respecte son échéance.

La chaîne probante sépare entrée du classificateur, résultat, mapping CID, séquence de fragments, temps dans chaque file, décision du scheduler, contrat du circuit, cellules transportées, réassemblage, CRC, LCP et événement applicatif. Les horloges doivent être corrélées sans être confondues.

La qualité vocale dépend encore de la gigue, du codec, du playout et de la dissimulation des pertes. Une borne locale peut être nécessaire sans être suffisante. Seul le terminal observe l’utilité finale.

Les RFC voisins ne constituent pas un registre de déploiement

RFC 3336 fournit la base PPP/AAL2. RFC 2689 décrit les services intégrés sur liaisons à faible débit. RFC 2686 définit l’extension multiclasse de Multilink PPP et RFC 1990 le protocole multilink. RFC 2508 traite la compression IP/UDP/RTP.

RFC 2474 et RFC 3246 offrent un contexte DiffServ et Expedited Forwarding. Un marquage DS ou un PHB ailleurs ne prouve pas le mapping CID de RFC 3337. RFC 2119 explique les mots normatifs, pas leur installation.

Pour affirmer l’adoption, il faudrait version d’équipement, règles, CID, scheduler, contrat, trafic et mesures. La famille documentaire explique les options. Elle ne remplace pas les reçus d’un réseau réel.

La promesse commence là où se trouve l’exécuteur

RFC 3337 donna aux classes une séparation exploitable. C’était indispensable : sans files distinctes, aucune décision fine ne pouvait s’exercer entre fragments. Pourtant, la séparation restait un substantif tant qu’un scheduler ne lui donnait pas d’action.

Une garantie sérieuse nomme tous ses verbes : classer, mapper, fragmenter, ordonnancer, admettre, transmettre, réassembler et jouer. Elle dit qui les contrôle et où ils sont mesurés. Une simple couleur de classe ne possède aucune de ces autorités.

La leçon durable est de chercher l’exécuteur. Le protocole rend une préférence représentable. Le résultat n’existe que lorsqu’un mécanisme la lit, qu’une ressource la soutient et qu’un récepteur confirme son effet.

Sources