Résumé

  • NQB n’est pas un ticket coupe-file. La RFC 9956 réserve une file courte en meilleur effort aux microflux réguliers et peu volumineux, car leur comportement est observable et vérifiable.
  • La protection peut reclasser ou supprimer le trafic qui remplit la file protégée ; L4S exige séparément un contrôle de congestion extensible, le signal ECT(1) et un marquage réseau compatible.
  • La vraie mesure du produit est la latence chargée de bout en bout — émetteur, accès, passerelle et Wi-Fi — avec la preuve du marquage, du repli et des reclassements.

Prenons une ligne vendue à 1 Gbit/s. Un ordinateur lance une sauvegarde. L’application interactive consomme peu et le forfait n’est pas en cause, mais ses petits paquets patientent derrière une rafale dans la file la plus étroite. Le test de débit à vide reste parfait. L’utilisateur, lui, voit le retard.

Le nouveau traitement Non-Queue-Building de l’IETF vise cette différence. Publiée comme Proposed Standard en mai 2026, la RFC 9956 définit un service en meilleur effort à tampon court pour les microflux réguliers, à faible débit et limités par l’application. La voix, les messages de synchronisation de jeu, le DNS et certaines communications machine-à-machine peuvent convenir ; un transfert cherchant toute la capacité ne le devrait pas.

NQB ne veut pas dire « application importante ». Le flux affirme qu’il ne contribue pas matériellement à la file, et cette affirmation peut être contrôlée. Un émetteur dépassant la limite de comportement ne doit pas appliquer le DSCP NQB. Un nœud compatible doit séparer NQB et trafic par défaut, et devrait protéger la file courte contre les flux qui ne tiennent pas leur promesse.

C’est du meilleur effort assorti d’une charge de preuve, non une voie prioritaire payante. La file reste rapide précisément parce qu’elle ne peut pas devenir une seconde file profonde.

Le comportement peut annuler le marquage

La RFC 9956 recommande d’identifier les arrivées incompatibles avec NQB et de remettre le trafic fautif dans la file ordinaire, ou de le supprimer. Le jugement doit porter sur les paquets, non sur le nom de l’application, le port ou l’adresse. Le goulet est l’observateur pertinent : c’est là que la file se forme réellement.

La RFC 9957, également publiée en mai 2026, explique un algorithme DOCSIS Queue Protection. Elle est informative et ne relève pas de l’Internet Standards Track. L’algorithme mesure le délai de la file à faible latence, maintient un score de contribution par flux et sanctionne lorsque le délai et la contribution dépassent leurs seuils. L’action normale est le reclassement vers la file Classic.

La conséquence commerciale est nette. L’application choisit le marquage ; l’équipement d’accès décide si le comportement observé mérite encore le traitement. Logiciel, seuils, compteurs et durée de support deviennent des composantes du service. Deux offres au même débit peuvent traiter différemment le même paquet marqué.

L4S est un contrat voisin, pas un synonyme

NQB peut partager une file à faible latence avec L4S, mais les obligations diffèrent. L’architecture L4S réunit un contrôle de congestion extensible chez l’émetteur, un marquage fin au goulet et le protocole qui les relie. La RFC 9331 emploie ECT(1) dans le champ ECN pour identifier le trafic qui revendique cette réponse. La RFC 9332 décrit un Dual-Queue Coupled AQM : il isole l’attente tout en couplant les signaux de congestion afin que Classic et L4S partagent la capacité.

Une priorité stricte inciterait toute application à demander la première place. DualQ isole le délai sans accorder une préférence de bande passante illimitée. NQB dépend d’un profil limité par l’application ; L4S d’une réaction fréquente et proportionnelle aux marques. Dans les deux cas, conserver le label sans conserver le comportement casse le contrat.

La RFC 9331 prévoit donc le retour en arrière. L’émetteur doit surveiller la coexistence avec l’ECN classique et, si un problème persiste sans correction du réseau, revenir à un contrôle de congestion Classic. « L4S activé » n’est pas un droit permanent sur tout chemin.

Le chemin ne s’arrête pas au modem

Une file correcte dans l’accès peut perdre son effet dans le domicile. CableLabs relève que le Wi-Fi est souvent le goulet de bout en bout : délai d’accès au média, distance, concurrence radio, implémentation du point d’accès et diversité des clients s’ajoutent au tampon. CableLabs publie un modèle expérimental NS-3 et décrit des simulations ainsi que des essais avec un point d’accès Nokia. Ce sont des essais reproductibles et bornés, pas une référence mondiale.

Le sens de l’en-tête IP peut aussi disparaître. La documentation Apple avertit qu’effacer le DSCP ne doit pas effacer l’ECN, les deux partageant l’octet de classe de trafic. Apple indique une prise en charge L4S pour certains utilisateurs depuis iOS 17 et iPadOS 17 dans QUIC et TCP. Cela prouve une capacité de plateforme, non la continuité sur l’accès, la passerelle et le Wi-Fi.

Comcast déclarait en janvier 2025 déployer Low Latency DOCSIS/L4S avec des partenaires applicatifs, avec marquage volontaire, sans coût spécial ni API propriétaire. C’est la preuve d’une conception et d’une offre chez un opérateur, pas d’une couverture universelle ni d’un gain fixe pour chaque foyer.

Comment réfuter la thèse

Il faut charger le chemin. Comparer p50, p95 et p99 du RTT et les pertes avec et sans traitement, ajouter un flux volumineux volontairement mal marqué, puis répéter en filaire et en Wi-Fi, avec ECN conservé ou effacé et plusieurs logiciels de passerelle.

La thèse s’affaiblit si les files séparées ne changent pas la latence chargée, si un gros flux mal marqué ne nuit pas à la file courte même sans protection, si la préservation ECN/Wi-Fi ne change rien et si les choix d’implémentation n’affectent ni reclassement ni repli. Les sources ne donnent ni part mondiale NQB, ni taux normal de sanction, ni gain universel. Elles donnent un mécanisme réfutable.