Résumé

  • La RFC 3006 conservait le TSpec original du flux et ajoutait un indice de compressibilité que chaque routeur n’utilisait que si son propre lien savait appliquer la compression annoncée.
  • Le routeur qui accordait une réduction de ressources devait ensuite contrôler le flux selon ce TSpec comprimé, afin que l’erreur ou l’exagération ne dégrade pas les autres réservations.

Le nombre le plus important de la RFC 3006 n’était pas une vitesse de ligne, mais l’écart entre deux descriptions valides du même flux. L’émetteur annonçait 48 kbit/s. Un routeur doté d’une compression IP/UDP/RTP sur son interface pouvait n’en réserver que 33,6. En amont ou en aval, un équipement sans ce mécanisme devait encore raisonner sur 48. La même circulation avait donc un coût différent selon le code réellement exécuté sur chaque saut.

Les spécifications RSVP ne savaient pas bien représenter cette situation. Avec le TSpec non comprimé, un routeur pouvait refuser une demande qui tenait pourtant sur son lien après compression. L’émetteur ne pouvait pas réduire lui-même sa déclaration, car il ignorait quels sauts compresseraient. La solution de la RFC 3006 fut de ne jamais modifier le Sender TSpec transmis. Elle lui ajouta un indice : une information disponible pour le calcul local, non une nouvelle vérité de bout en bout.

Ce choix respectait la répartition de RFC 2205 et de RFC 2210. L’émetteur connaît la forme probable de ses paquets. Le routeur connaît la fonction de son interface et ses ressources. RSVP transporte ; le contrôle de trafic décide. Placer l’indice dans le TSpec permettait aussi à une architecture de réservation autre que RSVP de livrer la même donnée au composant qui en avait besoin.

L’exemple rendait le contrat vérifiable. Pour des paquets de 120 octets, comprimer quarante octets d’en-têtes IP/UDP/RTP en quatre enlève 36 octets. Le facteur devient 70 %. Le débit r de 48 kbit/s devient 33,6 ; la profondeur b et la taille maximale M, toutes deux égales à 120 octets, deviennent 84. L’unité minimale m, initialement 64, n’est pas simplement multipliée : elle devient 28 après soustraction des mêmes 36 octets.

La généralisation gardait le débit de pointe inchangé, multipliait r et b par f/100, et soustrayait une économie fixe N à M et m lorsque l’algorithme s’y prêtait. La RFC avertissait que tous les compresseurs n’avaient pas cette propriété. Somme de contrôle UDP, évolution des horodatages RTP et distribution des tailles pouvaient diminuer le gain. Le routeur pouvait donc effectuer son propre calcul prudent. La valeur zéro laissait expressément le facteur à sa discrétion ; 100 annonçait qu’aucune réduction n’était attendue.

Le cas de plusieurs émetteurs révélait un autre piège. Chaque TSpec devait être réduit selon son facteur avant l’agrégation. Pour le service garanti de RFC 2212, le taux demandé était ajusté selon une moyenne pondérée par les tailles de rafale, pas selon une moyenne commode. Et parce qu’un taux R plus petit pourrait augmenter le terme de délai C/R, le saut devait gonfler son terme C inversement. L’économie de bande passante ne devait pas dégrader silencieusement la garantie temporelle choisie par le récepteur.

Puis venait la question que l’arithmétique favorable ne réglait pas : que se passe-t-il si le flux se comprime moins bien ? Si le routeur a admis 33,6 kbit/s mais en observe 35, les 1,4 kbit/s supplémentaires n’ont jamais été réservés. Ils deviennent du trafic excédentaire traité selon le service. Une estimation avantageuse ne se transforme pas après coup en créance sur les ressources des voisins.

L’émetteur pouvait aussi exagérer délibérément. Un faux indice risquait de faire admettre un flux et de sous-allouer le lien, au détriment des réservations déjà installées. La réponse de la RFC 3006 était locale et symétrique : tout routeur ayant utilisé l’indice devait contrôler le flux comme s’il se trouvait à la frontière du réseau. Le contrôle effectué à la véritable entrée sur le TSpec de 48 kbit/s ne prouvait pas le respect du budget comprimé de 33,6 sur ce lien précis.

La taille maximale conservait pourtant sa valeur non comprimée pour les services qui l’utilisaient dans le contrôle. Certains paquets pouvaient ne pas se comprimer. La RFC séparait ainsi le coût récurrent attendu du cas individuel maximal, au lieu d’effacer le pire cas au nom de la moyenne.

La compatibilité suivait la même discipline. Un ancien routeur devait idéalement ignorer l’indice inconnu, le transmettre intact et agir comme s’il n’existait pas. Il réservait alors le coût complet, tandis qu’un saut ultérieur pouvait encore appliquer la réduction. Certains logiciels pouvaient cependant rejeter le PATH ; un PathErr permettait à l’émetteur de recommencer sans indice. L’échec revenait à un contrat plus cher mais compris, non à une remise implicite.

Les travaux voisins fixent la limite éditoriale. RFC 2688 comptabilisait l’expansion PPP, la fragmentation et le bourrage ; RFC 2689 assemblait l’architecture des liens à bas débit ; RFC 2508 décrivait la compression IP/UDP/RTP elle-même. La RFC 3006 étudiait le point où une information sémantique devenait une réduction de réservation, puis une obligation de contrôle.

La réutilisation ultérieure par RFC 3241 pour ROHC sur PPP montre que l’espace d’indices pouvait accueillir d’autres profils. Elle ne prouve ni diffusion générale ni succès commercial. L’héritage certain est plus étroit : une économie promise n’avait d’autorité que là où une capacité locale, un calcul explicite et une conséquence en cas d’écart la rendaient réelle.

Avec la grille de Lu Heng, le standard distingue clairement couche commune et décision localisée. Le paquet de signalisation décrit une possibilité ; le code du routeur l’adopte ou la refuse ; l’observation ultérieure confirme ou invalide le budget. La stabilité n’est donc pas le calme apparent d’une réservation installée, mais la continuité mesurable entre hypothèse de compression, ressources promises et trafic réellement transporté.

Sources