Service Internet L4S : faible latence, faibles pertes et débit évolutif : RFC 9330

Aperçu de l’architecture de service Internet L4S

• Objectif de l’architecture L4S : atteindre une faible latence, de faibles pertes dues à la congestion et un contrôle du débit évolutif pour les applications Internet
• Insight clé : la cause fondamentale de la latence n’est pas la file d’attente elle-même, mais le contrôleur de congestion de l’émetteur chargé de sonder la capacité
• Nouvel algorithme de contrôle de congestion : il devient possible d’adopter de nouveaux algorithmes de contrôle de congestion qui, contrairement aux algorithmes existants générant une forte latence, peuvent sonder la capacité avec très peu de délai
• Forme modifiée d’ECN : prise en charge via une forme modifiée de la notification explicite de congestion (ECN) dans le réseau, permettant d’atteindre simultanément une faible latence et un débit élevé
• Accent sur un déploiement progressif : définition de mécanismes permettant à une nouvelle classe de contrôle de congestion et au contrôle de congestion « classique » de coexister sur un réseau partagé

Composants de l’architecture L4S

• Hôtes : des algorithmes de contrôle de congestion évolutifs existent déjà et, contrairement aux algorithmes classiques existants, le temps de récupération reste constant même lorsque le débit du flux augmente
• Réseau : il isole le trafic L4S de la latence du trafic classique et utilise deux files d’attente pour séparer la latence, sans toutefois séparer la bande passante
• Protocole : il utilise des identifiants pour permettre aux hôtes de distinguer les paquets L4S des paquets classiques, afin que le réseau puisse traiter chaque type de paquet séparément

Avis de GN⁺

Le point le plus important de cet article est que l’architecture L4S propose une nouvelle approche pour fournir aux services Internet une faible latence, de faibles pertes et un débit évolutif. Cette architecture surmonte les limites des algorithmes de contrôle de congestion existants et permet une communication efficace en exploitant ECN. C’est un sujet susceptible d’intéresser les concepteurs de réseaux, les opérateurs et les utilisateurs, et il pourrait avoir une influence importante sur l’évolution future d’Internet.

[GN⁺]

Commentaires sur Hacker News

• Interrogation sur la manière dont le destinataire informe l’émetteur de la congestion du réseau

  • Des informations détaillées sont disponibles dans le document RFC 3168
  • Il existe trois drapeaux prenant en charge l’ECN (Efficient Congestion Notification)
    • Le drapeau ECT (Echo Congestion Experienced), qui indique que l’émetteur peut prendre en charge l’ECN
    • Le drapeau CE (Congestion Experienced), par lequel le routeur informe le destinataire qu’il y a congestion
    • Le drapeau ECN-Echo, défini par le destinataire lorsqu’il envoie un paquet ACK à l’émetteur
    • L’émetteur reçoit le drapeau ECN-Echo, suppose qu’il y a eu une perte de paquets et réagit à la congestion
    • L’émetteur définit le drapeau CWR (Congestion Window Reduced) pour informer le destinataire qu’il a bien pris en compte le drapeau ECN-Echo et qu’il a réagi

• Retour d’expérience après avoir vu une démonstration réelle de la technologie ECN

  • Démonstration en direct de la technologie ECN observée à l’IETF 118
  • Le buffer bloat y était complètement éliminé, ce qui est très utile pour la visioconférence
  • Une technologie qui donne l’impression d’être futuriste, en ajoutant des bits supplémentaires aux paquets IP pour signaler que le tampon est plein

• Recommandation des travaux de recherche de Bob Briscoe

  • Recommandation des articles classiques de Bob Briscoe, qui a consacré beaucoup de temps à la recherche sur l’ECN

• Tests de L4S sur le réseau Comcast

  • Partage d’un jeu de slides présentant les résultats de tests L4S sur l’infrastructure câble
  • Spéculation sur la possibilité qu’un FAI facture une voie rapide

• Découverte d’une démo de flux vidéo de voiture RC utilisant la technologie L4S

  • Partage d’un lien vers une vidéo de démonstration utilisant la technologie L4S pour le flux vidéo d’une voiture RC

• Présentation d’une série de webinaires sur L4S

  • Pour en apprendre davantage sur L4S, présentation d’une série de webinaires commençant sur understandinglatency.com
  • Parmi les intervenants figurent les auteurs de L4S, le responsable des essais terrain L4S chez Comcast, ainsi que des voix critiques

• Suggestion pleine d’esprit sur la prononciation de L4S

  • Un commentaire dit espérer que L4S se prononce « L-Force »

• Problèmes d’équité de L4S et pistes de solution

  • Un problème se pose s’il existe des acteurs « malveillants » qui ignorent le retour de congestion pour s’approprier une plus grande part de bande passante
  • La solution consiste à compléter L4S par du fair queuing et à permettre au contrôle de congestion de détecter le fair queuing
  • Partage d’un lien GitHub sur un contrôle de congestion tenant compte du fair queuing

• Partage d’une vidéo expliquant la réduction de la boucle de rétroaction de latence par L4S

  • Partage d’un lien vidéo expliquant comment L4S réduit la boucle de rétroaction de latence

• Confusion sur les améliorations apportées à la visioconférence et au streaming

  • Expression d’une incompréhension sur la manière dont L4S, basé sur TCP, peut améliorer la visioconférence et le streaming alors que ceux-ci utilisent UDP