Recherche et brouillons

Recherche TCP

Un argument pour augmenter la fenêtre de congestion initiale de TCP

Les flux TCP commencent par une fenêtre de congestion initiale de quatre segments maximum ou environ 4 Ko de données. Comme la plupart des transactions Web ont une courte durée de vie, la fenêtre de congestion initiale est un paramètre TCP essentiel pour déterminer la vitesse à laquelle les flux peuvent s'achever. Alors que les vitesses d'accès réseau mondiales ont considérablement augmenté en moyenne au cours de la dernière décennie, la valeur standard de la fenêtre de congestion initiale de TCP est restée la même. Dans ce document, nous proposons d’augmenter la fenêtre de congestion initiale de TCP à au moins dix segments (environ 15 Ko). Grâce à des expériences Internet à grande échelle, nous quantifions les avantages et les coûts en termes de latence liés à l'utilisation d'une fenêtre plus étendue, en fonction de la bande passante réseau, du délai aller-retour (DAR), du produit délai-bande passante (BDP) et de la nature des applications. Nous montrons que la latence moyenne des réponses HTTP s'est améliorée d'environ 10 %, les avantages les plus importants étant démontrés sur les réseaux à DAR élevé et BDP. Nos tests ont également permis d'améliorer considérablement la latence des réseaux à faible bande passante. Le taux de retransmission moyen a légèrement augmenté de 0,5%, la majeure partie de l'augmentation étant due aux applications qui contournent efficacement l'algorithme de démarrage lent de TCP en utilisant plusieurs connexions simultanées. D'après les résultats de nos tests, nous pensons que la fenêtre de congestion initiale doit être d'au moins dix segments et qu'il doit également faire l'objet d'une enquête de normalisation par l'IETF.

TCP Fast Open

Les services Web actuels sont dominés par les flux TCP si courts qu'ils arrêtent plusieurs allers-retours après un handshake. Ce handshake est une source importante de latence pour de tels flux. Dans ce document, nous décrivons la conception, l'implémentation et le déploiement du protocole TCP Fast Open, un nouveau mécanisme qui permet l'échange de données lors du handshake initial de TCP. Ainsi, TCP Fast Open réduit la latence du réseau des applications d'une durée d'un aller-retour complet, ce qui diminue le délai subi par de tels transferts TCP courts. Nous résolvons les problèmes de sécurité inhérents à l'autorisation de l'échange de données lors du three-way handshake, afin de limiter les risques à l'aide d'un jeton de sécurité qui vérifie la propriété de l'adresse IP. Nous présentons en détail d'autres mécanismes de défense de remplacement et remédions aux problèmes que nous avons rencontrés avec les boîtiers intermédiaires, la rétrocompatibilité pour les piles réseau existantes et le déploiement incrémentiel. D'après l'analyse du trafic et l'émulation du réseau, nous montrons que TCP Fast Open réduirait la latence réseau des transactions HTTP de 15%et le temps de chargement de la page entière de plus de 10% en moyenne, voire jusqu'à 40 % dans certains cas.

Réduction proportionnelle du taux pour TCP

Les pertes de paquets augmentent la latence pour les internautes. La récupération rapide est un mécanisme clé permettant à TCP de récupérer après une perte de paquets. Dans cet article, nous explorons certaines des faiblesses de l'algorithme standard décrit dans le document RFC 3517, ainsi que les algorithmes non standards implémentés sous Linux. Nous constatons que ces algorithmes s'écartent de leur comportement prévu dans le monde réel en raison de l'effet combiné des flux courts, des blocages d'applications, des pertes d'utilisation intensive, de la perte et de la réorganisation de la reconnaissance (ACK) et des ACKs d'extension. Linux souffre de réductions excessives des fenêtres d'encombrement, tandis que le document RFC 3517 transmet des pics importants en cas de pertes importantes, ce qui nuit au reste du flux et augmente la latence Web. Notre principale contribution est une nouvelle conception qui permet de contrôler la transmission lors d'une récupération rapide appelée réduction proportionnelle (PRR). Le taux de réponse positive récupère rapidement, en douceur et de manière précise les retransmissions entre les ACK reçus. En plus du PRR, nous évaluons l'algorithme de retransmission précoce (ER) TCP, qui abaisse le seuil de confirmation en double pour les transferts courts. Il montre que le fait de retarder les retransmissions anticipées sur un court intervalle permet d'éviter les fausses retransmissions en présence d'un faible degré de réorganisation. Les rapports PRR et ER réduisent la latence TCP des connexions subissant des pertes de 3 à 10% en fonction de la taille de la réponse. Sur la base de l'analyse effectuée sur les serveurs Web et YouTube de Google aux États-Unis et en Inde, nous présentons également des statistiques clés sur la nature des retransmissions TCP.

Laminar TCP

Laminar est un nouveau framework de contrôle de congestion TCP qui sépare la planification de la transmission, qui détermine avec précision quand 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. Laminar devrait permettre à de nouveaux algorithmes avancés de réguler plus précisément le trafic TCP.

Brouillons SSL et TLS

Faux démarrage du protocole TLS (Transport Layer Security)

Le faux démarrage est un comportement facultatif des implémentations TLS. Elle n'affecte que la durée du protocole, pas les données sur le protocole filaire, et peut être implémenté de manière unilatérale. La fonctionnalité de faux démarrage TLS permet de réduire la latence d'un aller-retour pour certains handshakes.

Extension de négociation du protocole TLS (Transport Layer Security)

Extension TLS (Transport Layer Security) pour la négociation du protocole de la couche d'application Cela permet à la couche application de négocier le protocole à exécuter sur la connexion sécurisée de manière à éviter les allers-retours supplémentaires et ce qui est indépendant des protocoles de la couche d'application.

Brouillon DNS

Sous-réseau client dans les requêtes DNS

Ce brouillon définit une extension EDNS0 pour transmettre des informations sur le réseau à l'origine d'une requête DNS et sur le réseau pour lequel une réponse peut être mise en cache.