Résumé

  • FQ-PIE classe le cinq-tuple d’un paquet dans une file par hachage, applique PIE à cette file et la sert avec un ordonnanceur dérivé de DRR.
  • Deux flux distincts peuvent partager le même seau, tandis qu’un seul acteur peut occuper plusieurs seaux : l’adresse de file n’est pas une identité.
  • La preuve doit relier classification, état du contrôleur, décision de marquage ou de perte, service de l’ordonnanceur et résultat mesuré sans les confondre.

Une collision parfaitement valide

Deux communications qui n’ont ni propriétaire, ni application, ni destination en commun arrivent sur la même interface. Leurs cinq-tuples sont distincts. Le calcul de hachage les envoie pourtant vers le même seau. À partir de cet instant, elles partagent un arriéré, un état PIE et une occasion de service.

Rien n’a nécessairement dysfonctionné. Une table de files est finie, alors que l’espace des flux possibles ne l’est pas. Le projet draft-ietf-tsvwg-fq-pie-02 vise l’isolation des flux, mais reprend le principe de files hachées décrit pour FQ-CoDel. La collision est un résultat stochastique prévu, non la découverte que les deux communications forment un seul sujet.

Cette nuance change la valeur probante des métriques. Un tableau qui annonce « file 417 congestionnée » ne dit pas combien de flux y résident, qui ils représentent ni pourquoi ils ont été réunis. Pour l’expliquer plus tard, il faut conserver le cinq-tuple observé, la fonction ou l’époque de perturbation, le nombre de seaux et le résultat du hachage. Le numéro seul est une adresse d’exécution éphémère.

Le flux n’est pas l’unité naturelle de toute politique

RFC 8290 formule explicitement la limite : un fournisseur d’accès peut rechercher l’équité entre clients, tandis qu’un opérateur d’hébergement ou de transit peut la vouloir entre réseaux ou systèmes autonomes. Un ordonnanceur de flux répond à une autre question. Un client qui ouvre dix connexions présente dix objets à l’ordonnanceur ; un autre qui utilise une seule connexion n’en présente qu’un.

La symétrie entre files peut donc coexister avec une asymétrie entre clients. Elle peut aussi être souhaitable. FQ-PIE n’a pas pour fonction de résoudre seul une politique commerciale ou sociale. Le problème apparaît lorsque l’organisation rebaptise une propriété locale — l’isolation de flux visibles — en verdict global d’équité.

Le chiffrement ajoute une deuxième déformation. Plusieurs sessions intérieures peuvent être réunies dans un tunnel opaque que le classificateur ne voit que comme un flux extérieur. Elles partagent alors le même traitement. Ailleurs, une seule application peut multiplier les cinq-tuples. Le sens du mot « flux » dépend ainsi du point d’observation et des en-têtes accessibles.

Deux boucles de décision, deux temporalités

FQ-PIE combine la mise en file et PIE. À l’arrivée, le paquet est affecté à une file. PIE utilise une probabilité pour décider de l’admettre ou de le perdre. Cette probabilité est révisée périodiquement selon l’écart entre le délai de file et une cible, ainsi que selon la tendance du délai.

RFC 8033 donne comme valeurs usuelles une cible de 15 millisecondes et une période de mise à jour de 15 millisecondes. Ce sont des paramètres du contrôleur. Ils ne promettent pas que chaque paquet restera sous 15 millisecondes. PIE prévoit aussi une tolérance aux rafales : tant que le crédit de rafale demeure positif, un paquet peut être admis sans tirage de perte. Dépasser brièvement la cible peut donc être compatible avec le dessin du mécanisme.

Le projet FQ-PIE préfère une mesure directe par horodatage à l’estimation fondée sur la loi de Little. Il explique qu’un débit de sortie calculé dans la pile hôte peut mesurer le transfert vers l’anneau du pilote plutôt que l’émission réelle sur le lien. De plus, établir un débit de sortie exact pour chaque file est difficile.

La mesure directe ne supprime pas toute incertitude. La probabilité peut être calculée avec le délai du paquet le plus récemment sorti. Après une variation rapide du débit ou une nouvelle rafale, cet échantillon reste authentique mais peut ne plus décrire l’état actuel. L’heure, l’âge, la file, les points de mesure, la valeur précédente et l’instant de mise à jour doivent accompagner le nombre.

Marquer, perdre et servir

Un paquet compatible ECN peut être marqué plutôt que perdu. Cela prouve une décision locale prise avec un codepoint, un seuil et une probabilité déterminés. Cela ne prouve pas que le récepteur a renvoyé le signal, que l’émetteur a ralenti, ni que le délai applicatif s’est amélioré.

Lorsque la capacité totale en paquets est déjà saturée, FQ-PIE perd le nouvel arrivant sans autre traitement. Contrairement à la procédure de saturation de FQ-CoDel, il ne cherche pas la file contenant le plus grand nombre d’octets pour en supprimer la moitié. Le projet estime qu’une telle perte en masse pourrait sous-utiliser le lien, puisque PIE intervient déjà à l’entrée.

L’événement de saturation ne fournit donc pas un coupable. Il prouve que la capacité locale était pleine et qu’un paquet n’a pas été admis. Attribuer la faute à un client, une application ou un « gros flux » exigerait une autre analyse.

Au départ, un ordonnanceur dérivé de Deficit Round Robin visite les files et leur accorde un quantum d’octets. Une visite et des octets effectivement sortis prouvent le service de la file. Ils ne garantissent ni un débit égal par client, ni une fin de transfert simultanée, ni un résultat utilisable. Taille des paquets, RTT, contrôle de congestion, demande, nombre de flux et goulots ultérieurs restent actifs.

Code disponible, résultat non acquis

La révision 02 est datée du 6 juillet 2026 et expire le 7 janvier 2027. Datatracker la présente comme un Internet-Draft actif du groupe TSVWG, état WG Document et IESG I-D Exists. Le texte annonce un statut visé Experimental. Ce n’est pas un RFC.

Le document rapporte des implémentations dans Linux, FreeBSD et ns-3, ainsi que leur recours aux horodatages au moment de la rédaction. Cette disponibilité constitue une preuve de code, pas une preuve de configuration de production. Il faut encore identifier la version, l’interface, la discipline effectivement attachée, les paramètres, l’offload, le débit du lien et l’intervalle observé.

Le périmètre d’expérimentation conserve plusieurs questions ouvertes : interaction avec BBR, seuil entre marquage et perte, améliorations PIE adaptées, latence des flux courts, scénarios de RFC 7928 et mécanismes de hachage alternatifs. Une publication qui transformerait cette liste en résultats établis ferait disparaître précisément l’incertitude que le projet signale.

Sources