4. Changements par rapport à RFC 6937 (Changes Relative to RFC 6937)

Le plus grand changement depuis [RFC6937] est l'introduction d'une nouvelle heuristique qui utilise une bonne progression de récupération (pour TCP, lorsque le dernier ACK fait avancer SND.UNA et n'indique pas qu'une retransmission rapide précédente a été perdue) pour sélectionner la limite de réduction (PRR-CRB ou PRR-SSRB).

[RFC6937] laissait le choix de la limite de réduction à la discrétion de l'implémenteur, mais recommandait d'utiliser PRR-SSRB par défaut. Pour tous les environnements explorés dans la recherche PRR antérieure, la nouvelle heuristique est cohérente avec l'ancienne recommandation.

Introduction de l'heuristique SafeACK

L'article « Analyse à l'échelle d'Internet du policing du trafic » [Flach2016policing] a découvert un cas critique précédemment inexploré où les deux limites de réduction fonctionnent mal, mais pour des raisons différentes.

Défi des policers à jetons

Dans de nombreuses configurations, les policers de trafic à jetons peuvent brusquement commencer à abandonner la plupart du trafic lorsque les jetons sont épuisés, sans avertissement aux systèmes terminaux. Le contrôle de congestion du transport n'a aucune opportunité de mesurer le taux de jetons et de définir ssthresh en fonction des performances de chemin précédemment observées. Cette valeur de ssthresh peut conduire à un débit de données bien supérieur au taux de réapprovisionnement des jetons, entraînant des taux de perte de paquets élevés.

Dans ces conditions, les deux limites de réduction fonctionnent mal :

• PRR-CRB est trop conservateur - résultant parfois en une récupération très longue avec une fenêtre beaucoup plus petite que nécessaire
• PRR-SSRB est trop agressif - résultant souvent en plusieurs tours de retransmissions perdues, les deux cas entraînant des temps de récupération prolongés qui impactent sévèrement la latence et/ou le débit de l'application

Solution SafeACK

L'investigation de ces environnements a conduit au développement de l'heuristique « SafeACK » pour commuter dynamiquement la limite de réduction :

• Par défaut PRR-CRB - commencer la récupération de manière conservatrice
• Condition de basculement vers PRR-SSRB - seulement lorsqu'un ACK indique que la récupération progresse bien (SND.UNA avance et aucune nouvelle perte de paquet détectée)

L'heuristique SafeACK a été expérimentée sur le réseau de distribution de contenu (CDN) de Google [Flach2016policing] et est implémentée dans Linux TCP depuis 2015.

Scénarios d'application

L'heuristique SafeACK n'est invoquée que lorsque :

• La perte de paquets, un comportement limité par l'application ou d'autres événements font que l'estimation actuelle des données en vol tombe en dessous de ssthresh
• Des taux de perte de paquets élevés rendent l'heuristique critique, ce qui n'est courant qu'en présence de perte de paquets sévère, comme les policers de trafic [Flach2016policing]
• Dans ces environnements, l'heuristique surpasse l'utilisation de l'une ou l'autre limite seule