Résumé

  • Avec CCID 2, DCCP transmet de manière fiable les informations de réception nécessaires au contrôle de congestion, sans assurer la retransmission des données applicatives perdues.
  • L'accusé de réception d'un compte rendu permet au récepteur de libérer un historique. Une information apprise après l'envoi de ce compte rendu ne doit pas disparaître avant d'avoir été communiquée.
  • La seconde confirmation peut elle-même se perdre : l'ancien état reste alors conservé plus longtemps. Cette conséquence limitée évite une chaîne infinie de confirmations et ne s'applique pas uniformément à tous les profils de congestion.

Une ancienne réponse à une situation nouvelle

L'annexe A.3 du RFC 4340 décrit une difficulté discrète de la gestion des accusés de réception. Un récepteur envoie un Ack Vector indiquant qu'un paquet manque. Celui-ci arrive ensuite, avant que l'émetteur n'accuse réception du vecteur déjà parti.

La confirmation tardive porte donc sur une ancienne description : le paquet était encore absent. Elle ne prouve pas que l'émetteur connaît sa réception ultérieure. Si le récepteur efface sans précaution toutes les informations couvertes par cette confirmation, il peut détruire une nouvelle qu'il n'a pas encore annoncée.

L'annexe propose de limiter la frontière de libération pour éviter ce résultat. Il s'agit d'un exemple d'implémentation, non d'une obligation d'adopter ce tampon précis. Le problème, lui, est général : confirmer un message n'équivaut pas à confirmer tout ce que son auteur a appris depuis.

Ce détail éclaire un choix essentiel de DCCP. Dans un transport qui ne retransmet pas les données applicatives perdues, il existe néanmoins des informations qu'on ne peut pas abandonner au hasard. Le protocole doit organiser la fin de leur conservation aussi soigneusement que leur transmission.

La fiabilité n'était plus un bloc indivisible

Publié en mars 2006, le RFC 4336 expose la demande à laquelle DCCP cherchait à répondre. Une application de téléphonie ou de jeu peut préférer une information récente à la récupération obstinée d'une information périmée. Une tranche audio arrivée après son instant de lecture ou une ancienne position ne retrouve pas nécessairement son utilité en étant enfin livrée.

Cela ne dispense pas l'application de tenir compte de la congestion. Le contrôle de congestion détermine quand et combien elle peut envoyer ; elle souhaite garder le choix du contenu pertinent à cet instant. DCCP sépare donc cette discipline de l'obligation de reconstruire un flux de données intégral. Une application peut ajouter sa propre récupération sélective, mais le transport ne lui impose pas de réexpédier chaque ancien datagramme.

L'émetteur doit pourtant apprendre les pertes et les marques de congestion observées par le récepteur. Dans CCID 2, ces informations sont transmises de façon fiable par les Ack Vectors. L'absence de garantie sur les données n'est pas une licence pour faire disparaître les faits dont dépend le réglage du débit.

Un historique qui tient dans des suites de nombres

Les numéros de séquence de DCCP comptent les paquets, y compris les accusés de réception sans données. Ils ne comptent pas les octets. Un accusé possède ainsi sa propre identité, que le correspondant peut citer à son tour.

Le champ Acknowledgement Number indique le plus grand numéro reçu. Ce n'est pas une promesse que tous les précédents sont arrivés. Les options décrivent les trous et les autres états de réception. Confondre ce champ avec la frontière cumulative d'un flux TCP supprimerait précisément les distinctions que le protocole a besoin de communiquer.

Ack Vector représente l'histoire en remontant vers les paquets plus anciens. Deux bits décrivent l'état, six la longueur d'une suite de paquets dans cet état. Une longueur codée à zéro désigne un paquet ; 63 en désigne 64. Les états distinguent réception, réception avec marque ECN, valeur réservée et absence encore constatée.

Cette compression économise des octets, pas des obligations. Tant que le récepteur ne sait pas que son correspondant a reçu les informations, il peut devoir les répéter. Un historique compact peut encore être un historique dont personne n'a autorisé la disparition.

Le mot « reçu » possède lui aussi un périmètre. Les options du paquet ont été traitées par DCCP ; les données n'ont pas nécessairement été remises à l'application. Une suppression dans le tampon applicatif ne transforme pas rétroactivement le paquet en perte sur le réseau. L'option Data Dropped apporte une information distincte.

La numérotation des paquets de contrôle crée une autre précaution. Un trou peut ne contenir aucune donnée applicative. Lorsque la fonction correspondante est activée, NDP Count rapporte la série de paquets sans données immédiatement précédente et aide à interpréter ce trou. Il ne donne pas un décompte général des octets applicatifs perdus.

Le coût d'une histoire sans point final

Le récepteur distingue notamment les informations déjà confirmées par l'émetteur, celles qu'il a annoncées sans savoir si elles ont été reçues, et celles qu'il n'a pas encore annoncées. Les deux dernières catégories alimentent la fenêtre d'acquittement. Les nouvelles réceptions l'étendent ; les confirmations de comptes rendus permettent de retirer sa partie ancienne.

Sans ce mouvement de sortie, explique le RFC 4340, un récepteur CCID 2 pourrait répéter des informations remontant au début de la connexion. Le problème n'est pas qu'il ne sait pas produire un rapport. Il ne sait pas quand il peut cesser de le produire.

En communication bidirectionnelle, les confirmations nécessaires se trouvent normalement dans les échanges ordinaires. Quand l'application d'un côté cesse d'envoyer, ce côté continue pourtant à recevoir des données et à les acquitter. L'autre extrémité doit alors confirmer de temps à autre ces purs accusés de réception, par exemple en envoyant un DCCP-DataAck plutôt qu'un DCCP-Data.

Le RFC 4341 rend cette obligation explicite pour l'émetteur actif. Il recommande de confirmer les accusés du récepteur au moins une fois par fenêtre de congestion. Il ne commande pas un paquet supplémentaire après chaque accusé. Si les deux applications deviennent silencieuses, l'émetteur peut attendre arbitrairement longtemps.

Le trafic applicatif rendait une tâche presque invisible ; son arrêt ne rend pas nécessairement cette tâche inutile. C'est ce changement de support, plutôt qu'une simple opposition entre connexion active et inactive, qui explique le besoin de règles particulières.

Pourquoi la troisième confirmation n'est pas nécessaire

La fiabilité des Ack Vectors semble ouvrir une régression : si leur réception doit être confirmée, faudra-t-il confirmer cette nouvelle confirmation ? DCCP arrête la chaîne en donnant à sa perte une conséquence différente.

Si la seconde confirmation disparaît, le récepteur conserve et retransmet son ancien état un peu plus longtemps. Il ne conclut pas à tort qu'il peut l'effacer. Il n'est donc pas nécessaire de rendre cette seconde confirmation elle-même fiable, ni de créer un troisième étage.

La solution ne rend pas les pertes gratuites. Mémoire, taille des futurs comptes rendus et circulation sur le chemin retour peuvent en souffrir. Elle évite en revanche de transformer chaque échec en une nouvelle obligation absolue de livraison. Une incertitude prolonge une charge existante au lieu d'engendrer une chaîne d'engagements.

La détection du silence respecte la même prudence. Pour CCID 2, le délai est le maximum de 0,2 seconde et de deux temps aller-retour. Il faut en outre que l'émetteur ait confirmé les vecteurs couvrant toutes les données reçues. Le délai seul ne tranche pas. Avec un RTT inconnu, la valeur par défaut de 0,2 seconde donne 0,4 seconde pour le terme de deux RTT.

D'autres profils, d'autres corrections

Le RFC 4342 décrit CCID 3 et son contrôle TFRC : des variations de débit plus douces, au prix d'une réaction plus lente aux changements de capacité. Selon le RFC de base, son état d'acquittement est généralement borné. Il n'a pas besoin du même mécanisme de confirmation des confirmations. Cela ne signifie ni absence de mémoire ni absence de retour sur la congestion.

Ses errata techniques vérifiés apportent une autre leçon sur la fraîcheur d'un rapport. Le débit reçu se mesure sur le dernier RTT, et non sur toute la durée depuis le précédent retour. Un second Receive Rate peut être ignoré dans le cas prévu où l'intervalle ne contient aucune donnée ; le temporisateur d'absence de retour ne doit alors pas être réarmé. Le simple passage d'un paquet de contrôle ne renouvelle pas toutes les preuves nécessaires.

Les errata du RFC 4340 corrigent notamment un exemple erroné sur la valeur zéro d'Ack Ratio et des détails éditoriaux de l'annexe. Le RFC 8311, en 2018, retire la discussion d'ECN Nonce de trois profils DCCP. Il serait imprudent de transformer les phrases de 2006 en prescriptions actuelles sans leurs corrections.

Le RFC 6773, publié en 2012, avait ajouté l'encapsulation UDP pour franchir certaines limites d'équipements ne prenant pas en charge DCCP nativement. Cette adaptation de transport n'ajoute pas la livraison fiable des données. Le registre IANA identifie les profils ; il ne mesure pas leur adoption.

Ces textes n'établissent donc ni la part actuelle de DCCP ni le comportement d'un produit particulier. Ils montrent quelque chose de plus précis : une histoire de réception peut être fiable sans rendre les données fiables, et elle ne devient effaçable qu'à la bonne frontière de connaissance.