Résumé

  • Le désordre décrit une arrivée différente de l’ordre d’émission ; le réordonnancement est la décision d’attendre afin de reconstruire cet ordre.
  • La couche 2 connaît le trou de séquence et la durée d’attente, mais généralement pas le contexte TCP, QUIC ou applicatif des paquets retenus.
  • RACK, QUIC, ROHC et ESP ont des tolérances propres et bornées. Un nom de protocole ne remplace pas la preuve de la version, de la configuration et du comportement observé.
  • draft-ietf-intarea-reordering-00 propose de n’utiliser le réordonnancement du sous-réseau que si des éléments clairs montrent que son bénéfice dépasse la latence et la gigue ajoutées.
  • Il s’agit d’un Internet-Draft informationnel actif, non d’un RFC, d’une modification déjà adoptée ou d’un résultat de déploiement.

Une victoire arrivée hors délai

Le paquet manquant finit par revenir. Le tampon libère alors une suite parfaite : 41, 42, 43, 44. Pour son compteur interne, l’opération est réussie. Mais 43 portait une réponse interactive dont la valeur expirait avant ce déblocage. L’ordre a été sauvé ; le service, non.

Ce décalage est le sujet véritable du projet. Le lien voit des numéros et des absences. Il ne voit pas nécessairement que 42 appartient à un téléchargement, 43 à une résolution de nom et 44 à une autre connexion. Retenir les trois derrière 41 transforme une propriété locale en taxe collective.

Il faut donc résister à un indicateur trompeur : « remis dans l’ordre » n’est pas synonyme de « amélioré ». La première affirmation se vérifie sur la séquence. La seconde exige un contrefactuel crédible : que se serait-il passé si les paquets disponibles avaient été transmis immédiatement ?

L’ancien compromis n’a pas disparu, il a changé de centre

RFC 3819 recommandait déjà d’éviter le désordre sans sacrifier efficacité, fiabilité ou délai moyen. Ses avertissements reflétaient cependant un TCP plus sensible aux accusés dupliqués et des mécanismes de compression qui supposaient davantage l’ordre.

RACK, défini par RFC 8985, tire l’inférence de perte du temps et des accusés plutôt que d'un simple compte de duplications. QUIC, dans RFC 9002, dispose également de seuils temporels et de paquets. Le terminal est ainsi mieux placé pour décider si un paquet est réellement perdu.

Cela ne crée pas une immunité universelle. Une pile peut ne pas activer l’algorithme attendu, conserver des seuils étroits ou traverser un équipement ancien. La preuve utile n’est pas « QUIC est moderne », mais « ce terminal, dans cette version et cette configuration, a reçu cette forme de désordre et l’a interprétée ainsi ».

L’attente est une action de contrôle

Le réordonnancement possède au moins quatre paramètres implicites : l’identité du contexte, la capacité du tampon, la condition de perte et la durée maximale d’attente. Chacun peut changer le résultat.

Dans le cellulaire, des processus HARQ parallèles, une retransmission RLC ou deux chemins de Dual Connectivity peuvent produire des arrivées décalées. Dans le Wi-Fi décrit par le projet, un tampon distinct existe par identifiant de trafic. Dans DOCSIS, les canaux agrégés et leurs délais différents imposent une logique encore différente.

Ces mécanismes n'offrent pas une preuve commune. Ils montrent surtout que le « même ordre » est reconstruit dans des domaines distincts, avec des unités, des temporisations et des conséquences différentes.

La sécurité ne peut pas être retirée avec le tampon

Le Wi-Fi utilise aussi les numéros de paquet contre la répétition. Si une retransmission ancienne mais légitime arrive après qu’un numéro plus élevé a été accepté, une règle naïve peut la rejeter comme replay. Autoriser le désordre suppose donc d’adapter la fenêtre et la logique de preuve, pas simplement d’abaisser une temporisation.

ESP a sa propre fenêtre anti-rejeu. RFC 4303 accepte un certain désordre, borné par la fenêtre retenue. ROHC et ROHCv2 ont eux aussi des contrats de contexte. Dire que ces protocoles « tolèrent le désordre » sans conserver la taille de fenêtre, le profil et l’état revient à effacer la donnée qui décide du verdict.

Une réforme saine ne remplace pas le dogme de l’ordre par celui du désordre. Elle demande quelle contrainte est réellement active et qui peut la démontrer.

Ce que le texte propose, et ce qu’il ne prouve pas

Le projet conseille d’éviter le désordre inutile. Lorsque le désordre accompagne inévitablement un gain de capacité ou de fiabilité—répartition sur plusieurs liens, retransmission de couche 2—il devrait en général être exposé au terminal. Le sous-réseau ne devrait réordonner que si des preuves claires montrent un bénéfice supérieur à la latence et à la gigue ajoutées.

Le mot décisif est « preuves ». Une moyenne globale ne suffit pas. Il faut rapprocher séquence d’émission, chemin, arrivée, entrée en tampon, cause de libération, état du terminal, récupération transport et délai applicatif. La queue de distribution compte souvent davantage que la moyenne.

Le chiffre Wi-Fi cité dans le projet—plus de 75 ms au P90 et 400 ms au P99 dans un scénario avec sept autres stations en concurrence—reste le résultat de ce scénario cité. Il ne devient ni une constante Wi-Fi ni une mesure de BTW.

Un document encore en mouvement

La révision 00 date du 27 août 2026, expire le 28 février 2027 et vise un statut informationnel. Elle remplacerait le texte de la section 15 de RFC 3819 si elle était approuvée. Elle ne modifie encore aucun standard IEEE, 3GPP ou CableLabs et ne demande aucune action IANA.

Il s’agit d’un Internet-Draft actif. Ce n’est pas un RFC.

Aucun équipement ni réseau nommé n’a été vérifié ici. Le texte peut changer, être remplacé ou expirer. L’analyse porte sur la frontière de preuve exposée par la proposition, pas sur une adoption qui n’a pas été démontrée.