- Le RFC 9330 définit l’architecture L4S destinée à réduire la latence de mise en file d’attente et les pertes dues à la congestion des applications Internet, et situe la cause première de la latence moins dans les files elles-mêmes que dans le contrôle de congestion des émetteurs, qui cherche à explorer la capacité disponible.
- L4S combine le Scalable congestion control côté hôte émetteur, l’AQM au point de goulot d’étranglement et des protocoles fondés sur ECN ; pour identifier les paquets L4S, il utilise le codepoint ECT(1) du champ IP-ECN.
- La latence de file d’attente visée est inférieure à 1 ms en moyenne et à environ 2 ms au 99e percentile ; dans l’exemple DCTCP avec Dual-Queue Coupled AQM, même en surcharge, la latence de file d’attente au 99e percentile reste de l’ordre de 1 à 2 ms.
- Pour coexister avec les contrôles de congestion Classic de type Reno/CUBIC existants, L4S sépare la latence du trafic Classic et celle du trafic L4S, tout en concevant la bande passante pour être partagée à long terme plutôt que découpée en parts fixes.
- L4S complète plutôt qu’il ne remplace Diffserv, FQ-CoDel, PIE ou BBR ; TCP a besoin d’un retour précis comme AccECN, tandis que QUIC et DCCP fournissent déjà le retour ECN nécessaire à L4S.
Le problème de latence que L4S cherche à résoudre
- Les situations où des trafics qui privilégient une faible latence remplissent un lien de goulot d’étranglement se multiplient : Web, voix, visioconférence, jeux, bureau à distance, applications cloud, AR/VR, contrôle à distance.
- Les caches et serveurs placés plus près des utilisateurs ont réduit la latence de propagation, mais la mise en file d’attente reste une composante majeure et intermittente de la latence.
- Même avec des AQM modernes, des pics de latence de plusieurs centaines de millisecondes ne sont pas rares.
- Les AQM Classic sont souvent configurés pour absorber les variations de file en dents de scie d’un flux long unique ; pendant des flux longs, les pics de latence réseau totale peuvent alors atteindre environ le double de la latence de base du chemin.
- L4S vise une latence de file d’attente très faible, des pertes très faibles et un débit extensible.
- Une latence de file d’attente très faible signifie moins de 1 ms en moyenne et environ moins de 2 ms au 99e percentile.
- Pour les applications interactives les plus exigeantes, une latence de bout en bout supérieure à 50 ms, voire 20 ms, commence à paraître non naturelle.
- Les pertes entraînant des délais de retransmission dans les applications interactives, des pertes faibles sont également un objectif central.
La cause de la latence : le contrôle de congestion Classic plutôt que la file
- L4S situe la cause première de la latence de file d’attente moins dans la file elle-même que dans le contrôle de congestion explorant la capacité côté émetteur.
- Les contrôles de congestion Classic comme Reno et CUBIC font varier l’occupation des files sous forme de grandes dents de scie.
- Si l’AQM maintient une file trop peu profonde, le contrôle de congestion Classic n’exploite pas correctement le lien à chaque point bas de la dent de scie.
- À mesure que le débit du flux augmente, le temps de récupération du contrôle de congestion Classic s’allonge, ce qui rend le contrôle de la file et de l’utilisation du lien plus lâche.
- Le Scalable congestion control maintient constant, même quand le débit du flux augmente, le temps moyen entre signaux de congestion, c’est-à-dire le temps de récupération.
- DCTCP en est un exemple largement utilisé dans des environnements contrôlés.
- Il est implémenté et déployé dans Windows Server Editions, Linux et FreeBSD.
- Prague over TCP/QUIC, SCReAM pour L4S et la partie L4S ECN de BBRv2 font également partie des exemples de Scalable congestion control.
Les trois composants de l’architecture L4S
- L4S se compose de trois éléments :
- le Scalable congestion control côté hôte émetteur ;
- l’AQM au goulot d’étranglement réseau ;
- un protocole fondé sur ECN chargé de l’identification des paquets et des signaux de congestion entre les deux.
- La faible latence n’est pas fournie directement par le réseau : elle provient du comportement prudent du Scalable congestion control de l’émetteur L4S.
- Le rôle principal du réseau est d’isoler la faible latence du trafic L4S de la latence de file d’attente plus importante dont le trafic Classic a besoin.
- Le réseau utilise ECN pour signaler immédiatement à la couche transport les tout premiers signes d’augmentation de la file.
- Il ne signale pas après avoir fortement lissé les variations de file comme le fait l’AQM Classic.
- La prise en charge d’ECN est indispensable à L4S.
- L’émetteur utilise le champ ECN afin que le réseau puisse distinguer les paquets L4S des paquets Classic.
ECN et codepoint ECT(1)
- L4S a besoin de signaux de congestion plus fins, qui s’affranchissent de la contrainte de l’ECN Classic selon laquelle « un signal ECN doit être traité comme équivalent à un drop ».
- Les signaux doivent pouvoir se produire plus fréquemment.
- Ils doivent pouvoir être envoyés immédiatement, sans forte latence destinée à lisser les variations de file.
- RFC8311 assouplit certaines exigences de RFC3168, ce qui rend possible l’expérimentation L4S.
- RFC9331 spécifie que ECT(1) doit être utilisé comme identifiant de paquet L4S.
- Le codepoint CE sert à indiquer Congestion Experienced dans le traitement L4S comme dans le traitement Classic.
- Si un AQM Classic en amont du chemin marque comme CE un paquet ECT(0), il existe un risque qu’il soit mal classé dans la file L4S.
- Selon l’annexe B du RFC9331, cinq conditions rares doivent toutes être réunies pour qu’un effet nuisible apparaisse, et même dans ce cas, la probabilité de retransmission erronée est extrêmement faible.
- Les opérateurs peuvent vouloir placer dans la file L4S du trafic non-L4S suffisamment faible et régulier pour ne pas créer de file.
- Les exemples incluent la VoIP, les datagrammes à faible débit pour la synchronisation des jeux en ligne, DNS, LDAP, etc.
- Dans ce cas, un marquage distinct est nécessaire, comme EF, NQB ou des identifiants propres à l’opérateur.
Dual-Queue Coupled AQM
- L4S vise à fournir une faible latence sans imposer aux composants réseau un traitement par flux.
- La conception représentative, Dual-Queue Coupled AQM, utilise deux files.
- La file L4S maintient une faible latence.
- La file Classic peut disposer d’une file plus grande, nécessaire au trafic Classic pour maintenir l’utilisation du lien.
- DualQ est conçu pour se comporter comme une membrane semi-perméable : les latences sont séparées, mais la bande passante n’est pas répartie en parts fixes.
- L’AQM Classic crée une probabilité de drop/marquage fondée sur la congestion de sa propre file et la couple aux signaux des files Classic et L4S.
- Le signal de congestion couplé pousse les flux L4S à réduire leur débit afin de laisser la capacité nécessaire aux flux Classic.
- Le planificateur peut donner la priorité à la file L4S.
- À courte échelle de temps, il évacue rapidement les rafales L4S pour protéger la faible latence.
- À des échelles de temps longues, au moins égales au temps aller-retour, le couplage des signaux de congestion de la file Classic compense la priorité de bande passante et produit une équité approximative par flux.
- Lorsqu’il n’y a que du trafic L4S, l’AQM de la file L4S commence le marquage de congestion sur une file très peu profonde afin de maintenir une faible latence de mise en file.
Différences entre files par flux et DualQ
- Les files par flux comme FQ-CoDel et FQ-PIE peuvent aussi être utilisées avec L4S.
- Sous Linux, elles ont été modifiées pour pouvoir appliquer un seuil de marquage ECN peu profond uniquement aux paquets ECT(1).
- Les flux Not-ECT ou ECT(0) se voient appliquer un AQM Classic, tandis que les flux ECT(1) se voient généralement appliquer un seuil peu profond, inférieur à la milliseconde.
- L’approche par flux sépare les files de chaque flux, mais ne supprime pas la mise en file créée par le flux lui-même.
- Avec DualQ, l’identifiant L4S se trouvant dans le champ IP-ECN, aucune inspection plus profonde que la couche IP n’est requise.
- Il peut être utilisé même lorsque les identifiants de couche transport sont chiffrés, comme avec IPsec ou des tunnels VPN chiffrés.
- L’approche par flux confie au réseau le contrôle des débits relatifs entre flux applicatifs.
- DualQ sépare la fourniture d’une faible latence du problème de contrôle du débit des flux, et un policing distinct du débit des flux peut être ajouté si nécessaire.
Exigences côté hôte
- L’émetteur doit implémenter le Scalable congestion control.
- DCTCP est l’exemple le plus largement utilisé, mais il nécessite des améliorations de sécurité et de performances pour être employé sur l’Internet public.
- Les parties des exigences Prague L4S liées au risque de nuire à autrui sont incluses dans les exigences normatives du RFC9331.
- TCP Prague est implémenté comme implémentation de référence sous Linux.
- Les protocoles de transport autres que TCP doivent aussi implémenter une réponse scalable à la congestion et l’indiquer avec le codepoint ECT(1) pour utiliser le service L4S.
- Une variante scalable pour QUIC est à l’étude.
- La partie L4S ECN de BBRv2 est présentée comme un Scalable congestion control pour TCP, QUIC, etc.
- Une variante L4S de SCReAM pour les médias RTP a également été implémentée.
- L’état du retour ECN varie selon les protocoles.
- DCCP et QUIC fournissent un retour ECN suffisamment fin pour L4S.
- Le retour ECN existant de TCP repose sur l’hypothèse que les marques ECN sont équivalentes à des drops, et ne peut donc pas être utilisé avec Scalable TCP.
- Les récepteurs TCP doivent prendre en charge AccECN, un retour ECN plus précis.
- SCTP doit implémenter et déployer une nouvelle conception ECN pour prendre en charge L4S.
- Pour RTP, un retour ECN suffisant est défini dans les RFC6679 et RFC8888.
Pourquoi un signal de congestion explicite est nécessaire
- L4S utilise les signaux de congestion explicites comme moyen central, plutôt que les pertes.
- Un drop étant à la fois une dégradation de performance et un signal, il crée une tension entre « moins il y en a, mieux c’est pour limiter les dégâts » et « plus il y en a, mieux c’est pour le signal ».
- Les signaux explicites fondés sur ECN peuvent être utilisés plusieurs fois par temps aller-retour sans dégradation, ce qui aide à maintenir les files courtes.
- L4S déplace le lissage du réseau vers les hôtes.
- Le réseau ne connaissant pas le RTT de chaque flux, l’approche Classic doit supposer le pire RTT.
- Les signaux de congestion Classic peuvent donc être retardés de 100 à 200 ms.
- Chaque hôte connaissant son propre RTT, il peut lisser juste ce qu’il faut, généralement à l’échelle de quelques millisecondes.
- La file L4S utilise une nouvelle variante L4S ECN qui n’est pas équivalente à un drop, tandis que la file Classic utilise l’ECN Classic ou les drops.
Fondements de l’extensibilité du débit
- Le contrôle de congestion Reno Classic voit son temps de récupération s’allonger à mesure que le produit bande passante-latence augmente.
- L’exemple suppose un RTT maximal de 30 ms au pic de la dent de scie.
- Si le taux de paquets Reno augmente de 1 250 packet/s à 10 000 packet/s, soit un facteur 8, il passe d’environ 15 Mb/s à 120 Mb/s avec des paquets de 1 500 B, et le temps de récupération passe de 422 ms à 3,38 s.
- À 120 Mb/s, CUBIC fonctionne en mode Reno-friendly et met environ 4,3 s à récupérer.
- À 960 Mb/s, il passe en mode true CUBIC et le temps de récupération atteint 12,2 s.
- À 7,68 Gb/s, le temps de récupération monte jusqu’à 24,3 s.
- Les Scalable congestion controls comme DCTCP ou Prague induisent en moyenne 2 signaux de congestion par RTT, et cette propriété reste indépendante du débit du flux.
- En 2020, la capacité moyenne mondiale des accès fixes était de 103 Mb/s, et en 2019 le RTT de base moyen jusqu’aux CDN était de 25 à 34 ms.
- Après une réduction de fenêtre de congestion, un flux de téléchargement CUBIC unique peut mettre, même dans le meilleur des cas, environ 200 RTT, soit 5 secondes, à récupérer.
Relation avec les technologies existantes
- Diffserv traite l’allocation de bande passante du trafic important et la latence de file d’attente du trafic sensible à la latence, tandis que L4S ne traite que le problème de latence de file d’attente.
- Diffserv est efficace lorsque seule une partie du trafic au goulot d’étranglement exige une faible latence.
- Si tout le trafic du goulot d’étranglement souhaite une faible latence, l’avantage de différenciation de Diffserv disparaît.
- L’identifiant L4S n’indique pas une exigence de qualité, mais un engagement de comportement : une réponse scalable à la congestion.
- Les AQM Classic comme PIE et FQ-CoDel réduisent fortement la latence de file d’attente par rapport à l’absence totale d’AQM.
- L4S les complète et ne remplace pas la nécessité d’un déploiement large.
- Avec l’AQM seul, les grandes dents de scie du contrôle de congestion Classic rendent difficile l’élimination de la tension entre latence et utilisation du lien.
- ABE modifie la réaction des hôtes au marquage ECN pour augmenter l’utilisation du lien et le débit des flux ECN, mais suppose que le réseau traite toujours ECN et les drops de la même manière.
- BBR contrôle la latence de mise en file de bout en bout sans logique réseau spéciale.
- BBR maintient la latence de file d’attente à un niveau raisonnablement bas, mais pas aussi bas que L4S.
- BBRv2 peut utiliser, lorsque c’est possible, L4S ECN et le comportement de Scalable L4S congestion control.
Applications concernées
- L4S peut améliorer fortement la qualité des applications existantes en situation de charge.
- Jeux et cloud gaming
- VoIP
- Visioconférence
- Navigation Web
- Streaming vidéo adaptatif
- Messagerie instantanée
- Une latence de file d’attente plus faible rend possibles des usages comme la vidéo interactive dans le cloud et la VR/AR dans le cloud.
- Dans une démonstration L4S, de la vidéo interactive et de la VR dans le cloud fonctionnaient ensemble sur un lien d’accès haut débit de 40 Mb/s, dans une situation où plusieurs applications sensibles à la latence et des téléchargements partageaient la même file de goulot d’étranglement.
- Avec une latence de base de bout en bout de 7 ms, la latence supplémentaire de mise en file était d’environ 1 ms.
- Avec un AQM alternatif, la vidéo suivait visiblement en retard les gestes des doigts et les mouvements de tête.
- Le panoramique vidéo par balayage du doigt ou mouvement de tête a des exigences de latence bien plus strictes que la VoIP.
- La téléprésence interactive et le contrôle à distance assisté par vidéo de machines ou de procédés industriels sont difficiles à rendre fiables sans une latence de file d’attente très faible.
Modèle de déploiement et introduction progressive
- L’AQM L4S n’a pas besoin d’être déployé sur tout Internet pour être efficace.
- Les réseaux d’accès à l’Internet public sont généralement conçus de façon à ce que le goulot d’étranglement d’un site apparaisse sur un lien logique connu.
- Un site peut être un foyer, un appareil mobile, un campus ou un réseau d’entreprise de petite ou moyenne taille.
- Il s’agit d’une généralisation applicable à diverses technologies d’accès : xDSL, câble, PON, cellulaire, radio, satellite, etc.
- En aval, déployer un AQM L4S à l’entrée du lien goulot d’étranglement permet d’obtenir la plupart des bénéfices ; en amont, le même principe s’applique en le déployant à l’entrée du lien montant.
- Pour qu’un flux L4S bénéficie du service, trois éléments sont généralement nécessaires :
- le contrôle de congestion de l’émetteur ;
- l’AQM au goulot d’étranglement ;
- pour les transports anciens comme TCP, un retour récepteur mis à niveau.
- L’ordre de déploiement peut varier.
- Le DCTCP déjà existant peut être utilisé dans des environnements de test contrôlés.
- Déployer TCP Prague et AccECN permet d’utiliser L4S sur l’Internet public.
- QUIC prenant en charge dès le départ le retour ECN nécessaire à L4S, le déploiement du contrôle de congestion Prague côté émetteur est plus simple.
Contraintes selon les technologies de lien
- Wi-Fi, PON et câble agrègent plusieurs paquets de données en rafales et mettent en mémoire tampon les paquets arrivant pendant la constitution de ces rafales.
- Ethernet et DSL ne réalisent pas ce type d’agrégation de paquets.
- Cette mise en tampon liée à l’agrégation ne peut pas être réduite par l’émetteur et ne doit donc pas être comptée comme une file contrôlée par l’AQM.
- Les liens radio comme le cellulaire, le Wi-Fi ou le satellite peuvent voir leur capacité varier fortement et rapidement ; une file résidente est donc considérée comme souhaitable pour exploiter les augmentations soudaines de capacité.
- Les réseaux cellulaires sont plus complexes du fait des besoins de mise en mémoire tampon destinés à rendre les handovers imperceptibles.
- L4S ne supprime pas tous ces besoins de buffering.
- Supprimer le « plus grand poteau », c’est-à-dire le buffering destiné aux grandes dents de scie du contrôle de congestion Classic, crée une incitation à réduire aussi d’autres facteurs de buffering, comme la taille des rafales d’agrégation de paquets ou l’intervalle d’ordonnancement MAC.
Goulots non-L4S et traitement des pertes
- Même si L4S est activé entre deux hôtes, si le goulot d’étranglement ne prend pas ECN en charge, l’émetteur L4S doit coexister de manière sûre avec Reno face aux drops.
- Cette règle protège le trafic Classic, mais dégrade le service L4S en présence de pertes.
- Pertes temporaires au goulot d’étranglement dues à des rafales dans une file peu profonde
- Erreurs de transmission comme des interférences électriques
- Policing de débit
- Trois approches pour traiter ce problème relèvent actuellement de la recherche.
- Ignorer dans le contrôle de congestion Prague certaines pertes peu susceptibles d’être dues à la congestion
- Récupérer les erreurs de transmission au moyen de la combinaison RACK, L4S et retransmissions de lien sans réordonnancement
- Policer hybride ECN/drop du débit
- Les scénarios de déploiement où ces problèmes sont rares, comme les réseaux filaires, peuvent avancer en parallèle de ces recherches.
Sécurité et policing du trafic
- Aujourd’hui, Internet sépare généralement la capacité des liens partagés entre sites au moyen de planificateurs, et ne police pas de manière généralisée le débit de chaque flux applicatif.
- L4S est conçu pour ne pas rompre cet état de fait.
- DualQ est conçu pour ne pas accorder aux flux non réactifs un avantage de débit supérieur à celui qu’ils auraient avec un AQM à file unique.
- Si un policing de débit par flux est nécessaire, il peut être ajouté indépendamment de la distinction L4S/Classic.
- L4S est conçu pour réduire la latence sans nuire à la latence ni au débit du trafic Classic ; il n’est donc pas nécessaire de policer l’accès au service L4S uniquement pour protéger Classic.
- Certains opérateurs peuvent ne fournir le service L4S qu’à un groupe limité, par exemple des clients premium.
- Dans ce cas, ils peuvent utiliser des identifiants locaux, comme des plages d’adresses source, en plus du champ ECN.
- Si l’identifiant local ne correspond pas, le trafic peut être envoyé vers la file Classic même s’il porte ECT(1).
- Le service L4S exige de la retenue non seulement sur le débit, mais aussi sur le caractère bursty.
- La fonction de protection de file à faible latence pour DOCSIS redirige partiellement vers la file Classic les flux qui créent de la file, afin de préserver la faible latence.
- Une fonction de protection à file unique n’est pas un élément indispensable de l’architecture L4S ; une partie de l’expérimentation L4S consiste à déterminer si une telle fonction est nécessaire.
Tunnels et confidentialité
- Comme l’AQM L4S signale la congestion via le champ ECN, lorsque le trafic traverse un tunnel ou fonctionne à une couche inférieure, le champ ECN doit être propagé entre couches conformément aux standards.
- L’architecture L4S n’exclut pas les méthodes qui inspectent les identifiants de couche transport.
- L’exemple en est FQ-CoDel avec prise en charge L4S ajoutée.
- L’innovation centrale, DualQ AQM, ne requiert aucune inspection plus profonde que l’en-tête IP le plus externe.
- Même si l’utilisateur chiffre les identifiants de flux applicatifs avec IPsec ou un tunnel VPN chiffré, il n’a pas besoin de renoncer à une faible latence.
- L4S pouvant fournir une faible latence à un large ensemble d’applications, il réduit la nécessité de distinguer les applications individuelles ou les classes détaillées pendant leur traversée du réseau.
1 commentaires
Avis sur Hacker News
C’est vraiment génial. J’ai vu une démo en direct le mois dernier à IETF 118, et ça semblait excellent pour le chat vidéo, car cela éliminait complètement le bufferbloat
Il semble qu’il faille ajouter un bit supplémentaire aux paquets IP pour y mettre des informations comme le fait que le buffer est plein, mais ça fonctionnait réellement, et ça donnait l’impression de « je ne pensais pas que c’était possible »
Pour ceux chez qui le lien temporel ne fonctionne pas, c’est à 1 h 21. Édition : en fait non, c’était un récapitulatif du hackathon, et la présentation est difficile à retrouver
Je me demandais comment le récepteur informe l’émetteur de la congestion, alors j’ai cherché, mais ce n’était pas aussi facile à trouver que je l’imaginais. L’essentiel est documenté dans https://www.rfc-editor.org/info/rfc3168
En simplifiant, il n’y a pas un seul drapeau, mais environ trois. Il y a un drapeau par lequel l’émetteur indique au routeur qu’il prend en charge ECN, un drapeau par lequel le routeur signale la congestion au récepteur, et un drapeau que le récepteur positionne lorsqu’il envoie un paquet ACK
L’émetteur indique la prise en charge d’ECN avec le codepoint ECT, et un routeur compatible ECN, au lieu de jeter le paquet, le transmet en définissant le codepoint CE dans l’en-tête IP. Le récepteur positionne alors ECN-Echo dans le prochain ACK TCP, et l’émetteur réagit à la congestion comme à une perte de paquet, puis positionne le drapeau CWR dans l’en-tête TCP du paquet suivant
Bob Briscoe réfléchit dans cette direction depuis longtemps. En classiques connexes, je recommande les textes ci-dessous
http://www.sigcomm.org/sites/default/files/ccr/papers/2007/A...
https://dl.acm.org/doi/pdf/10.1145/1080091.1080124
Des tests ont été menés sur une partie du réseau câble de Comcast, et les slides ci-dessous l’expliquent
https://datatracker.ietf.org/meeting/118/materials/slides-11...
Je ne sais pas où cela mènera, mais je me dis que les FAI pourraient commencer à faire payer un péage pour une voie rapide
Avis personnel, mais je travaille chez Comcast
Si vous voulez en savoir plus sur L4S, une série de webinaires commence aujourd’hui sur understandinglatency.com. Certains auteurs de L4S, le responsable des essais terrain L4S chez Comcast, ainsi que des voix critiques, y interviennent
J’ai trouvé une courte démo d’usage réel avec un flux vidéo de voiture RC : https://www.youtube.com/watch?v=RZmS10djDEg
C’est un progrès dans la bonne direction, mais le problème reste que s’il y a ne serait-ce qu’un participant malveillant qui ignore le retour de congestion et veut simplement une plus grande part de bande passante, cela pose problème. Les autres participants reculeront alors, et la partie déloyale obtiendra ce qu’elle veut
Il est difficile pour les bons participants de savoir si les autres respectent les règles, et ils doivent savoir qu’il existe une fair queueing pour croire que L4S les traitera équitablement
Ce problème peut être résolu en complétant L4S par une fair queueing comme fq_codel, et en permettant au contrôle de congestion de détecter la présence d’une fair queueing : https://github.com/muxamilian/fair-queuing-aware-congestion-...
Le débat sur la fair queueing fait partie d’un débat plus large. Sans fair queueing, l’équité est déjà mise en œuvre par les hôtes terminaux, indépendamment de L4S, et des hôtes terminaux comme des serveurs peuvent ignorer la réaction à la congestion et prendre plus que leur part équitable. Ce n’est pas un problème créé par L4S, même si certains estiment que L4S facilite l’obtention d’une part plus grande
Les partisans de la fair queueing considèrent que le réseau doit garantir un partage équitable, mais tout le monde n’est pas d’accord avec la mesure de l’équité qu’ils ont choisie. En particulier, l’un des principaux soutiens de L4S n’est pas d’accord, comme on peut le voir dans l’article lié ici : https://news.ycombinator.com/item?id=38598023
Je me demande ce qui change réellement du point de vue de l’utilisateur. Par exemple, est-ce que les appels vidéo se rapprochent davantage du temps réel ? Il y a généralement environ 0,5 à 1 seconde de délai, ce qui provoque beaucoup de coupures et d’interruptions quand on parle en même temps. Quelles autres applications s’amélioreraient fortement ?
Pour tenir sous les 3 Mbps de débit binaire, il faut faire des compromis difficiles entre qualité, débit binaire, temps CPU et latence. Les ordinateurs portables ordinaires ont un CPU lent, ou bien, même avec un CPU 6 cœurs, gardent une fréquence basse sur batterie. L’encodage vidéo accéléré matériellement n’est pas non plus universel, ce qui nuit à la qualité et à la latence
Le Wi-Fi ajoute aussi de la latence, surtout quand l’ordinateur portable fonctionne sur batterie. Pour gérer le NAT, de nombreux services de chat vidéo utilisent des serveurs cloud comme relais, ce qui ajoute encore de la latence
https://hpbn.co/wifi/#measuring-and-optimizing-wifi-performa...
Les fonctions très interactives comme le jeu et la visioconférence s’améliorent aussi énormément sans latence. Aujourd’hui, afficher une page web, streamer une vidéo ou gérer les interactions avec un assistant IA comme Alexa nécessite beaucoup d’allers-retours ; presque tout ce qui implique une interaction entre l’utilisateur et un appareil pourrait donc s’améliorer
Essentiellement, L4S est une technologie qui réduit la boucle de rétroaction de la latence. La seconde moitié de cette vidéo l’explique assez bien : https://youtu.be/tAVwmUG21OY?si=lydbqfNL80Y8Uxvp