Résumé

  • Le RFC 9959 permet de réemployer des paramètres de contrôle de congestion observés sur une connexion antérieure, mais seulement comme hypothèse à vérifier sur le chemin actuel.
  • Une même valeur saved_cwnd ne peut servir qu’à une connexion à la fois. Derrière un répartiteur de charge, cette règle exige une coordination qui dépasse le bon fonctionnement de chaque processus pris isolément.
  • Un bail d’usage de l’état sauvegardé peut relier version, durée de vie, acquéreur unique, contrôle du chemin, saut autorisé et invalidation. Il s’agit d’une proposition éditoriale de Daniel Kade, non d’une exigence de l’IETF.

Le cache ne contient pas de bande passante

Un cache restitue un objet. Un chemin réseau, lui, ne restitue pas la capacité qu’il offrait hier. Entre deux connexions, d’autres flux peuvent occuper le goulet, le routage peut changer, une adresse anycast peut conduire à un autre site et le délai peut prendre un autre sens. Pourtant, la mesure précédente garde une utilité : elle indique qu’un certain débit a réellement été utilisé dans un contexte récent.

Le RFC 9959, Careful Resume, organise cette utilité sans la confondre avec une réservation. Une connexion établie peut sauvegarder une fenêtre de congestion utilisée, un RTT minimal, une description du Remote Endpoint et une durée de vie. La connexion suivante commence normalement avec la fenêtre initiale. Elle observe d’abord le chemin, puis peut accélérer avec prudence.

La valeur sauvegardée n’est pas nécessairement la plus grande fenêtre vue. À la sortie du slow start, la fenêtre peut dépasser la capacité effectivement utilisée. Une application limitée par sa propre production peut également fournir une observation trompeuse. Le texte demande donc une mesure fondée sur la capacité utilisée et autorise à écarter les observations faibles ou inadéquates.

La notice officielle classe le document comme Proposed Standard de l’IETF. Elle ne dit pas qu’un opérateur précis l’a déployé, qu’un gain est garanti ou que l’historique devient une créance sur le réseau.

Le Remote Endpoint est un pari contrôlé

Le nom semble désigner une destination. En réalité, le Remote Endpoint du RFC 9959 représente la vue que l’émetteur se fait du chemin. Il associe une interface d’émission et une destination unicast ou anycast. L’implémentation peut ajouter le DSCP ou d’autres éléments.

Le compromis est immédiat. Une clé détaillée distingue mieux les chemins, mais produit moins de réemplois. Une clé large augmente les correspondances, mais rapproche des situations qui ne partagent peut-être pas le même goulet. Ce n’est pas un simple taux de succès de cache : chaque faux rapprochement peut injecter trop vite des données dans un chemin qui n’a jamais validé cette vitesse.

Le RFC répond par une phase de reconnaissance. Les premiers paquets utilisent le contrôle de congestion normal. Les acquittements et le RTT courant donnent une première confirmation. Une perte, une marque ECN-CE, une différence de chemin connue, une durée expirée ou un RTT très éloigné du RTT sauvegardé annulent l’essai. Un RTT courant supérieur à dix fois le minimum sauvegardé constitue notamment un indice de changement, sans que l’inverse garantisse l’identité du chemin.

ECMP, NAT, mobilité et anycast rappellent pourquoi la clé reste une hypothèse. Une même adresse peut mener ailleurs. Dans des configurations anycast où les capacités diffèrent fortement, le RFC déconseille le réemploi. La qualité de l’identifiant est donc une décision d’exploitation susceptible de changer avec le routage et l’architecture.

L’exclusivité est une propriété du système entier

Le RFC 9959 interdit l’usage simultané d’une même fenêtre sauvegardée par plusieurs connexions. Cette phrase transforme le stockage en problème de gouvernance.

Prenons une valeur historique de 40. Deux processus la lisent au même instant. Chacun respecte une progression limitée à la moitié et tente 20. Localement, les deux contrôleurs suivent la règle du demi-saut. Au goulet, l’augmentation cumulée vaut pourtant 40 avant validation. La limite mathématique ne protège pas contre la multiplication des décideurs.

Sur un serveur unique, une table avec acquisition atomique peut suffire. Dans une infrastructure distribuée, les connexions d’un même client peuvent être hachées vers des workers différents. Une copie retardée, une relance après expiration de requête ou un basculement peut donner deux propriétaires plausibles à la même génération d’état.

Il faut donc distinguer lecture et autorisation. Lire la valeur permet de connaître l’observation. L’utiliser exige de consommer une capacité logique à usage unique. Un processus qui échoue à l’acquérir doit revenir au contrôle normal, même si sa copie locale paraît fraîche.

C’est là que le Policy Mirror de Lu Heng éclaire la technique. La norme exprime une contrainte minimale ; l’architecture décide qui peut l’appliquer. La conformité d’un module ne démontre pas l’exclusivité de la flotte.

Une progression provisoire doit garder son statut

Après reconnaissance, le saut ne peut dépasser ni max_jump ni la moitié de saved_cwnd. L’envoi doit être cadencé avec le RTT courant pour éviter une rafale à la vitesse de ligne. Le contrôleur distingue ensuite les paquets non validés, la validation par les acquittements et le retour au fonctionnement normal.

La même valeur de fenêtre ne signifie donc pas la même chose selon la phase. Avant l’acquittement actuel, elle représente une extrapolation historique. Après validation, elle incorpore une observation du chemin présent. Un tableau de bord qui conserve le nombre sans la phase détruit cette différence de qualité probante.

Le projet qlog pour Careful Resume décrit des événements pour reconnaissance, non-validé, validation, normal et retrait sûr. Il peut enregistrer la transition, son déclencheur, la fenêtre sauvegardée et le RTT. C’est une base utile, mais la révision 02 reste un Internet-Draft. Surtout, un événement émis par un worker ne prouve pas qu’un second worker n’a pas utilisé la même génération.

Le retrait sûr doit invalider toutes les copies

Si des pertes, ECN ou un changement de chemin apparaissent pendant l’essai, la prémisse est démentie. Le RFC impose alors Safe Retreat : les paramètres utilisés deviennent invalides et sont supprimés, tandis que la fenêtre diminue fortement.

La réaction est plus sévère qu’une réduction ordinaire car le saut peut avoir déplacé des paquets appartenant à des connexions déjà établies. Le but n’est pas seulement de sauver le nouveau transfert ; c’est d’éviter que son pari raté ne fasse payer les autres flux. Le texte précise que l’essai et son échec ne doivent pas défavoriser indûment les connexions qui partagent déjà le goulet.

Une suppression locale n’est toutefois pas une révocation distribuée. Si la génération existe dans trois répliques et qu’une seule apprend l’échec, une autre peut la proposer de nouveau. La trace opérationnelle doit donc relier le motif d’invalidation à sa propagation dans tout le périmètre qui avait le droit de consommer l’état.

La durée de vie répond à une autre forme de péremption. Le RFC envisage des minutes pour les chemins dynamiques et éventuellement des heures pour des chemins plus stables et peu partagés. Ce ne sont pas des valeurs universelles. Une modification de configuration doit aussi permettre de purger les paramètres. L’âge, la topologie et la version de politique participent ensemble à la validité.

Un bail minimal de réemploi

Le mot « bail » désigne ici un mécanisme informatique d’exclusivité temporaire. Il ne crée ni propriété, ni contrat, ni réservation de débit.

Le reçu du bail devrait contenir :

  1. une identité de périmètre tournée ou hachée, avec la version de la règle Remote Endpoint ;
  2. le condensat et la génération des paramètres, l’heure d’observation, saved_cwnd, saved_rtt et leur Lifetime ;
  3. le worker ou la connexion candidate, l’acquisition atomique, son résultat et son échéance ;
  4. la preuve de démarrage normal, le RTT courant et le motif de correspondance du chemin ;
  5. l’algorithme de base, max_jump, la borne de moitié, le cadencement et l’augmentation réellement tentée ;
  6. les changements de phase et leurs déclencheurs ;
  7. la libération, le remplacement, l’expiration, la purge de configuration ou le retrait sûr, avec l’état de révocation des répliques ;
  8. des mesures agrégées de perte, ECN, conflit d’acquisition et effet sur les flux établis.

Ni contenu, ni URL, ni compte, ni cookie, ni identifiant client durable n’est nécessaire. Les détails restent à accès contrôlé et à courte rétention. La publication peut se limiter aux taux de conflits, tentatives périmées, discordances de chemin, retraits sûrs et délais de révocation, ventilés par version et cohorte.

Minimum Initial Specification ne réclame pas un stockage central unique. Un opérateur peut sérialiser les acquisitions ; un autre peut attribuer chaque clé à un propriétaire ; un troisième peut désactiver la fonction sur les chemins indiscernables. Le noyau commun est la preuve qu’une génération n’a soutenu qu’un seul essai à un instant donné.

Limites

Les sources ne mesurent aucun déploiement actuel et ne documentent aucun incident nommé. Elles ne prouvent ni amélioration de performance, ni défaut d’un fournisseur, ni échec d’un système distribué. Le choix de ne pas sauvegarder une petite fenêtre ou de ne jamais utiliser Careful Resume peut être parfaitement rationnel.

Le RFC 2914 rappelle la responsabilité collective du contrôle de congestion. Le RFC 7661 traite une fenêtre non validée dans une connexion TCP limitée par l’application. Le RFC 9002 fournit le contexte QUIC, et le RFC 9040 étudie le partage d’informations entre blocs de contrôle TCP. Aucun ne réserve la capacité future.

La conclusion est plus modeste : le passé peut accélérer une mesure présente, mais ne peut pas la remplacer. Là où le système distribue la mémoire, il doit aussi distribuer correctement son autorité d’usage et sa révocation.

Sources