Résumé

  • Une voie de retour étroite peut dilater, perdre ou comprimer les ACK et commander ainsi un flux TCP circulant sur une voie descendante bien plus large.
  • Libérer plusieurs ACK à la fois ne restitue pas leur chronologie d’origine : cela peut déclencher une rafale, déplacer la perte et masquer la cause réelle du débit.

L’upload occupait la file. Chaque gros paquet montant prenait son tour, tandis que les petits ACK d’un téléchargement s’accumulaient derrière lui. Quand la file leur rendit enfin le passage, ils arrivèrent chez l’émetteur presque ensemble.

Le récepteur n’avait pourtant jamais parlé de cette façon. Ses ACK avaient été produits au rythme des données reçues. Le réseau avait transformé une cadence régulière en silence, puis en impulsion. C’est l’ACK compression décrite par RFC 3449, publié en décembre 2002 comme BCP 69.

Les exemples d’accès et les chiffres du document sont historiques. Le mécanisme reste une leçon de mesure : la capacité d’un sens n’est pas la capacité d’une boucle de contrôle.

Le retour porte l’horloge

Un ACK cumulatif affirme que le TCP récepteur a avancé jusqu’à un numéro de séquence. Il rouvre la fenêtre d’envoi, participe à la croissance de la fenêtre de congestion et fournit des indices pour la reprise après perte. Il ne prouve pas que l’application a conservé ou traité les données.

Dans un chemin bien cadencé, le goulot descendant espace les paquets ; le récepteur transforme cet espacement en ACK ; leur retour autorise de nouveaux envois. Une file inverse peut altérer ce signal sans modifier sa valeur cumulative.

Il faut donc observer quatre horloges : émission par le récepteur, arrivée avant le goulot, départ après le goulot et réception par l’émetteur. Une seule capture ne peut pas dire où la cadence a changé.

Une file profonde dilate les ACK

Si le tampon montant est profond, les ACK attendent au lieu de tomber. Ils ressortent plus lentement que le récepteur ne les avait émis. L’émetteur se cadence alors sur le retour étroit ; la liaison descendante peut rester vide sans aucune perte descendante.

La file augmente aussi le RTT et ralentit les algorithmes dont la progression dépend du nombre d’ACK reçus. Les variations de délai compliquent la temporisation de retransmission. Un graphique d’utilisation descendante montre le symptôme, un RTT agrégé montre une conséquence, mais aucun ne prouve seul la file causale.

RFC 3449 normalise l’asymétrie par la taille des paquets. Son exemple de 10 Mbps en aval, 50 Kbps en amont, 1 000 octets de données et 40 octets d’ACK donne k = 8. C’est une démonstration, pas la mesure d’un service actuel.

Une file courte perd l’histoire sans perdre tous les octets

Avec peu de tampon, certains ACK disparaissent. Le caractère cumulatif permet à un ACK ultérieur de confirmer plusieurs segments. Le bilan des octets peut donc être correct alors que la suite des preuves ne l’est plus.

Moins d’ACK signifie parfois une croissance de fenêtre plus lente. En cas de perte descendante, moins de duplicata ou d’informations SACK peuvent retarder Fast Retransmit et Fast Recovery. À l’inverse, un ACK couvrant beaucoup de données peut libérer une grande quantité de paquets d’un seul coup.

« Tous les octets ont finalement été acquittés » et « la reprise a perdu ses indices temporels » sont deux propositions compatibles. Un audit doit conserver les deux.

La compression transforme l’attente en rafale

Quand les ACK retenus derrière l’upload sortent groupés, l’émetteur croit voir une progression concentrée. Il injecte une rafale sur la voie descendante. Une file aval peut déborder alors que la moyenne de cette voie semblait faible.

La compression des ACK n’est donc pas seulement du délai. Le goulot inverse a modifié l’action de l’émetteur. La dilation écarte les ACK ; la compression les rapproche. Dans les deux cas, la chronologie reçue ne copie plus celle du récepteur.

Le diagnostic doit corréler trafic montant, occupation de file, inter-ACK aux différents points, taille des rafales descendantes et pertes qui suivent. Sans cette chaîne, la perte paraît naître du réseau aval alors que son déclencheur est en amont.

Réduire les ACK déplace les contraintes

ACK Filtering retire des acquittements cumulatifs devenus redondants avant le goulot. RFC 3449 le classe expérimental et le conditionne à une limitation des rafales. Le débit montant économisé a pour contrepartie des stretch ACK plus puissants.

ACK Decimation utilise des règles de file et de rejet plus grossières. Elle peut fonctionner sans lire chaque en-tête, mais elle choisit moins finement les preuves conservées. Le document préfère le filtrage lorsqu’il est possible et demande encore une protection contre les rafales.

Allonger sans discernement le délai d’ACK au récepteur n’était pas recommandé. Le récepteur ne connaît généralement pas assez bien le retour pour choisir un facteur sûr. Augmenter le MSS sans fragmentation routeur est recommandé lorsque le PMTU le permet ; fabriquer de gros segments destinés à être fragmentés ne l’est pas.

Lisser l’action n’ajoute pas une observation

Le pacing côté émetteur répartit dans le temps les paquets qu’un stretch ACK vient d’autoriser. Il traite la rafale, pas la perte d’information. RFC 3449 le considérait expérimental, notamment parce qu’il faut estimer un taux.

Le byte counting modifie lui aussi la réaction à un ACK cumulatif. Sans borne, un ACK couvrant beaucoup d’octets peut ouvrir excessivement la fenêtre. Appropriate Byte Counting encadre cette croissance ; il ne transforme pas l’ACK en preuve d’un résultat applicatif.

Une file plus calme après pacing prouve un changement d’action. Elle ne prouve ni que le chemin retour ne perd plus d’ACK, ni que la reprise sous perte s’est améliorée.

Priorité, équité et en-têtes protégés

Servir les ACK en priorité peut réduire leur attente. Sans contrôle de leur volume, cette règle peut affamer les données montantes ; RFC 3449 ne recommande donc pas ACKs-first comme règle générale de l’Internet. Le fair queuing sépare mieux les intérêts, à condition d’être évalué sous charge bidirectionnelle.

Plusieurs mécanismes transparents supposent que l’intermédiaire voie ou modifie l’en-tête TCP. Le chiffrement ou la protection d’intégrité peut supprimer ce pouvoir. Ce n’est pas un défaut de la protection : c’est une limite d’autorité que l’architecture doit déclarer.

Une chaîne de reçus, pas un chiffre vert

Le dossier commence par les deux routes, leur capacité, le coût MAC par paquet, les trafics croisés, la politique de file et la profondeur des tampons. Il conserve ensuite la politique d’ACK du récepteur et sa cadence réelle.

Toute perte, filtration, décimation, compression, reconstruction ou priorité doit avoir une provenance. Chez l’émetteur, il faut l’espacement des ACK, la progression cumulative, les duplicata/SACK, la fenêtre, le pacing et la distribution des rafales.

La perte descendante, la reprise, le goodput, la charge offerte et l’équité ont leurs propres reçus. L’achèvement applicatif authentifié et le résultat visible viennent après. Un rollback et un chemin alternatif ferment la preuve causale.

Limite de preuve

RFC 3449 ne démontre le comportement actuel d’aucun opérateur, satellite, réseau radio, modem, pile TCP ou contrôleur de congestion nommé. Son exemple k = 8 est pédagogique. Les travaux TCP ultérieurs changent certaines dynamiques sans abolir le rôle des ACK.

Les principes de Heng Lu sur la spécification initiale minimale et la primauté du code en fonctionnement sont ici une grille éditoriale déclarée. Ils favorisent des mesures locales, des changements bornés et des reçus observables ; ils n’apportent aucune donnée de déploiement.

Sources