Qu'est-ce que laminaire ?
Laminar est un nouveau framework de contrôle de la congestion TCP qui sépare la planification de la transmission, qui détermine avec précision le moment où les données sont envoyées, du contrôle de congestion pur, qui détermine la quantité totale de données envoyées lors de chaque DAR.
L'algorithme par défaut pour la planification de la transmission est une implémentation stricte du principe de conservation des paquets de Van Jacobson [Jacobson88]. Les données arrivant au destinataire provoquent des ACK, qui à leur tour entraînent l'émetteur à transmettre une quantité équivalente de données au réseau. La variable d'état principale est implicite dans la quantité de données et les ACK qui circulent sur le réseau. Cet état est observé via un Estimator tcp_packets_in_flight() amélioré (également appelé "total_pipe"). Le "total_pipe" est basé sur le "pipe" (comme décrit dans le document RFC 3517), mais il inclut également la quantité de données signalées par l'indicateur ACK actuel et les transmissions en attente qui ont passé le contrôle de congestion, mais attendent d'autres événements tels que TSO.
Une nouvelle variable, CCwin, est la variable d'état principale du contrôle de congestion. Les algorithmes de contrôle de congestion ajustent CCwin pour réguler le niveau global de congestion tout au long du chemin. Bien que CCwin ressemble à "cwnd", cwnd est surchargé et utilisé par plusieurs algorithmes (comme la suppression en rafale) avec des objectifs différents et parfois contradictoires.
Chaque fois que total_pipe est différent de CCwin, l'algorithme de planification de transmission ajuste légèrement le nombre de segments envoyés en réponse à chaque ACK. Le démarrage lent et la réduction proportionnelle du taux (qui remplacent la réduction de moitié) sont tous deux intégrés à l'algorithme de planification de la transmission.
Le principal avantage du framework Laminar est qu'en partitionnant le contrôle de congestion et la planification de la transmission dans des sous-systèmes distincts, chacun est soumis à des contraintes de conception beaucoup plus simples, ce qui facilite le développement de nombreux nouveaux algorithmes qui ne seraient pas réalisables avec l'organisation précédente du code.
Le framework Laminar modifie la philosophie de conception sous-jacente du contrôle de la congestion TCP et a potentiellement des implications générales, au-delà du correctif lui-même. Ce correctif est destiné à permettre aux utilisateurs de tester le code, de commenter et de détecter les cas particuliers qui auraient pu être négligés. De plus, le correctif est incomplet dans le sens où il manque encore un certain nombre d'algorithmes, en particulier: les algorithmes de contrôle de la congestion autres que CUBIC et Reno, la validation partagée, les métriques de destination, etc. Il serait très bien que des personnes puissent nous aider à refactoriser certains de ces autres algorithmes.
Le framework Laminar et sa motivation sont décrits plus en détail dans une version préliminaire sur Internet, draft-mathis-tcpm-tcp-laminar.
Veuillez envoyer vos commentaires et suggestions à l'adresse mattmathis@google.com.
Ce projet s'inscrit dans le cadre des efforts de Google visant à accélérer le Web grâce à des améliorations du protocole.
Notes d'implémentation
Laminar est principalement implémenté dans trois fonctions (tcp_input.c):
Tcp_cong_avoid() et tcp_mult_decr() effectuent le contrôle de congestion AIMD à l'aide de la variable d'état CCwin. À l'exception de l'annulation, ces deux fonctions sont les seuls endroits où CCwin change. (Les deux fonctions appellent des gestionnaires spécifiques aux modules de congestion.)
Tcp_laminar_schedule() détermine la quantité de données à envoyer en réponse à chaque ACK. Il implémente la conservation des paquets de Van Jacobson, légèrement ajustée à la hausse ou à la baisse pour que tcp_packets_in_flight() converge vers CCwin.
Des modifications importantes ont été apportées à l'estimateur tcp_packets_in_flight() qui le rend invariant pour la plupart des événements de protocole. Les applications se bloquent, les ajustements dans tcp_laminar_schedule() et les pertes réelles de paquets modifient tcp_packets_in_flight(), le cas échéant. comme le traitement ACK, l'entraînement TSO et la plupart des autres événements. Notez qu'en cas de pertes, le nombre réel de paquets en cours de transfert change immédiatement, mais n'est pas reflété dans l'estimateur tcp_packets_in_flight() tant que le système de retransmission ne les marque pas comme perdus et augmente le nombre de paquets perdus_out.
Obtenir le correctif
Ce correctif s'applique au net-next de Dave Miller et à la version 3.5-rc2.
Remarque: Les autres modules de contrôle de la congestion, autres que Reno et CUBIC, n'ont pas été mis à jour et ne seront pas compilés. Si votre configuration crée d'autres modules de contrôle de la congestion, tels que Vegas, évolutifs, haut débit, etc., vous devez d'abord les désactiver.