Résumé

  • Le RFC 1016 proposait que le module IP de la source conserve, par destination récente, un délai D entre les datagrammes. La valeur ordinaire était zéro ; les destinations ralenties seules occupaient la liste active.
  • Les paramètres illustratifs fixaient un premier délai d'au moins 75 ms, ajoutaient 20 ms par événement d'avertissement, regroupaient les avertissements reçus en deux secondes et retranchaient 1 ms après chaque seconde pertinente avec des données à envoyer. Les auteurs ont étudié le dispositif dans une simulation écrite en C.

Un message ICMP Source Quench pouvait partir d'une passerelle à court de place dans sa file de sortie. Un datagramme était perdu, ou la passerelle voyait venir le trop-plein, et l'expéditeur recevait une invitation à ralentir vers la destination concernée. L'ordre avait la netteté d'un coup de sifflet et la précision d'un conseil de circulation un jour de pluie. Dans leur RFC 1016 de juillet 1987, W. Prue et Jon Postel ont cherché à transformer cette plainte en attente mesurable.

Le goulot d'étranglement pouvait tenir dans un chiffre cruel. Avec un mégaoctet en attente sur une ligne de 56 kb/s, calculaient-ils, le dernier datagramme patienterait plus de deux minutes avant son départ. Une liaison locale rapide avait largement le temps d'encombrer une liaison longue distance lente. À l'autre bout, TCP n'entendait pas forcément le signal : le RFC relevait qu'IP et ICMP ne lui fournissaient pas d'événement Source Quench bien défini dans de nombreuses implémentations. Les auteurs placèrent donc la réponse dans IP, près de la file d'émission.

Ils nommèrent cette réponse SQuID, Source Quench Introduced Delay. Pour chaque destination touchée, le module IP de la source attribuait un délai D entre datagrammes. D valait normalement zéro. L'hôte ne conservait des entrées que pour les destinations dont le délai était positif, dans un cache de correspondants récents. Un paquet pour une autre destination pouvait partir pendant que celui-ci attendait. La punition ne s'étendait pas à tout le carnet d'adresses parce qu'une seule route avait fait grincer les dents à la passerelle.

L'algorithme avançait vite dans un sens et lentement dans l'autre. Au premier événement Source Quench, D atteignait au moins 75 millisecondes ; si D était déjà positif, l'événement y ajoutait 20 millisecondes, avec ce plancher de 75. Plusieurs avertissements pendant une période de deux secondes comptaient pour un seul événement. Sans ce regroupement, une rafale de messages pouvait produire un délai excessif. Après une seconde admissible avec des données à envoyer, D diminuait d'une milliseconde, sans passer sous zéro.

Une destination silencieuse ne récupérait pas automatiquement sa vitesse pendant qu'aucun paquet ne demandait à partir.

Ces valeurs dessinaient le tempérament de la proposition. Un signal de congestion provoquait une réaction énergique. Le retour à la vitesse normale était prudent et progressif. Soixante-quinze millisecondes semblent peu sur une montre ordinaire ; répétées entre chaque datagramme vers la même destination, elles changent la forme d'une rafale. Le message vague de la passerelle devenait un geste local que l'on pouvait tester et régler.

Les passerelles recevaient aussi un scénario plus subtil que « jeter puis se plaindre ». Dans les seuils illustratifs du RFC, la file à 70 % déclenchait l'avertissement tout en laissant passer le datagramme. À 95 %, la passerelle commençait à jeter des données. Elle continuait d'avertir jusqu'à la descente sous une marque basse de 50 %. La passerelle détenait l'information sur sa file ; l'IP de l'hôte détenait la capacité d'espacer les prochains envois. Le partage des responsabilités était plus précis que le seul nom Source Quench.

Pour le mettre à l'épreuve, Prue et Postel ont écrit un modèle d'Internet en C. Leur exemple reliait deux réseaux locaux de 10 Mb/s par une liaison à 56 kb/s. Les files, des datagrammes de 512 octets et un routage fixe permettaient de comparer plusieurs réactions au signal. La simulation laissait de côté la fragmentation et le mécanisme TTL. Ses résultats montraient des oscillations pour tous les algorithmes étudiés. Augmenter le délai trop doucement puis l'abaisser trop vite entretenait l'excès d'envois et les pertes. Une hausse plus marquée et une baisse lente donnaient une piste plus convaincante dans ce modèle.

Un passage du RFC montre une rafale de vingt datagrammes fonçant depuis le réseau local vers la liaison lente. Avec les tailles de file choisies, ils atteignaient la passerelle en 81 ms ; une seule unité pouvait franchir l'étape suivante en environ 73 ms. Les quatre derniers datagrammes de la rafale étaient perdus dans ce scénario. La source avait rempli sa fenêtre TCP ; la passerelle n'avait pas élargi son tuyau pour lui faire plaisir. Le chronomètre placé avant l'envoi visait cette différence de cadence.

Le texte se présente comme une idée provocatrice et sollicite la discussion. Il montre un modèle, des paramètres, des limites et des résultats observés dans ce modèle. Son intérêt historique tient à la traduction d'un signal : la passerelle pouvait crier « ralentis », mais seul l'hôte expéditeur pouvait décider de l'intervalle entre ses prochains datagrammes. SQuID prenait cette décision destination par destination, avec un chronomètre plutôt qu'un sermon.