Recherchen und Entwürfe

TCP-Forschung

Ein Argument zum Verlängern des anfänglichen Überlastungsfensters von TCP

TCP-Datenflüsse beginnen mit einem anfänglichen Überlastungsfenster von höchstens vier Segmenten oder etwa 4 KB Daten. Da die meisten Webtransaktionen von kurzer Dauer sind, ist das anfängliche Überlastungsfenster ein entscheidender TCP-Parameter dafür, wie schnell Datenflüsse beendet werden können. Während die globalen Netzwerkzugriffsgeschwindigkeiten in den letzten zehn Jahren durchschnittlich stark angestiegen sind, blieb der Standardwert für das anfängliche Überlastungsfenster von TCP unverändert. In diesem Artikel schlagen wir vor, das anfängliche Überlastungsfenster von TCP auf mindestens zehn Segmente (etwa 15 KB) zu erhöhen. Durch umfangreiche Internetexperimente quantifizieren wir den Latenznutzen und die Kosten bei der Verwendung eines größeren Fensters als Funktionen der Netzwerkbandbreite, der Umlaufzeit (Round Trip Time, RTT), des Bandbreiten-Verzögerungs-Produkts (BDP) und der Art der Anwendungen. Wir haben gezeigt, dass sich die durchschnittliche Latenz von HTTP-Antworten um etwa 10% verbesserte. Die größten Vorteile wurden in Netzwerken mit hoher RTT- und BDP-Rate deutlich. In unseren Tests hat sich auch die Latenz von Netzwerken mit niedriger Bandbreite erheblich verbessert. Die durchschnittliche Rate erneuter Übertragungen stieg um bescheiden um 0,5 %. Der größte Anteil stammt von Anwendungen, die den Slow-Start-Algorithmus von TCP effektiv durch die Verwendung mehrerer gleichzeitiger Verbindungen umgehen. Basierend auf den Ergebnissen unserer Experimente gehen wir davon aus, dass das anfängliche Überlastungsfenster mindestens zehn Segmente betragen und von der IETF für die Standardisierung untersucht werden sollte.

TCP – Fast Open

Heutige Webdienste werden von TCP-Datenflüssen dominiert, die so kurz sind, dass sie nach dem Handshake einige Umläufe beenden. Dieser Handshake ist eine wichtige Latenzquelle für solche Datenflüsse. In diesem Artikel beschreiben wir den Entwurf, die Implementierung und die Implementierung des TCP Fast Open-Protokolls, eines neuen Mechanismus, der den Datenaustausch während des ersten Handshake von TCP ermöglicht. Auf diese Weise reduziert TCP Fast Open die Latenz des Anwendungsnetzwerks um eine volle Umlaufzeit und verringert so die Verzögerung, die durch solche kurzen TCP-Übertragungen entsteht. Wir befassen uns mit den Sicherheitsproblemen, die durch den Datenaustausch während des Drei-Wege-Handshakes entstehen. Dies lässt sich durch die Verwendung eines Sicherheitstokens minimieren, das die Inhaberschaft der IP-Adresse bestätigt. Wir erläutern weitere Mechanismen zur Abwehr von Fallbacks und behandeln Probleme, die mit Middleboxes aufgetreten sind, sowie die Abwärtskompatibilität für vorhandene Netzwerk-Stacks und die inkrementelle Bereitstellung. Basierend auf der Traffic-Analyse und der Netzwerkemulation zeigen wir, dass TCP Fast Open die Netzwerklatenz von HTTP-Transaktionen im Durchschnitt um 15%und die Ladezeit der gesamten Seite um mehr als 10% und in einigen Fällen um bis zu 40 % verringern würde.

Proportionale Ratenreduzierung für TCP

Paketverluste erhöhen die Latenz für Webnutzer. Eine schnelle Wiederherstellung ist ein wichtiger Mechanismus für TCP, um Paketverluste wiederherzustellen. In diesem Artikel werden einige der Schwächen des in RFC 3517 beschriebenen Standardalgorithmus sowie der unter Linux implementierten Nicht-Standardalgorithmen erläutert. Wir stellen fest, dass diese Algorithmen aufgrund der kombinierten Auswirkungen von kurzen Datenflüssen, Anwendungsstürzen, Burst-Verlusten, Bestätigungsverlust (ACK), Neuanordnung und Stretch ACKs von ihrem beabsichtigten Verhalten in der realen Welt abweichen. Linux leidet an einer übermäßigen Reduzierung der Überlastungsfenster, während RFC 3517 unter hohen Verlusten große Bursts überträgt, was beide den Rest des Datenflusses beschädigen und die Weblatenz erhöhen. Unser Hauptbeitrag ist ein neues Design zur Steuerung der Übertragung bei schneller Wiederherstellung, das sogenannte proportionale Reduktion (PRR) genannt wird. PRR gleicht Verluste schnell, reibungslos und genau ab, indem erneute Übertragungen über empfangene ACKs beschleunigt werden. Zusätzlich zum PRR evaluieren wir auch den ER-Algorithmus (Early Retransmit) von TCP, der den Grenzwert für doppelte Bestätigungen für kurze Übertragungen senkt. Außerdem zeigen wir, dass eine Verzögerung früherer Übertragungen um ein kurzes Intervall effektiv dazu beiträgt, fehlerhafte erneute Übertragungen bei einem geringen Grad der Neuanordnung zu vermeiden. PRR und ER reduzieren die TCP-Latenz von Verbindungen, bei denen Verluste auftreten, je nach Antwortgröße um 3–10 %. Basierend auf unserer Nutzung der Web- und YouTube-Server von Google in den USA und Indien stellen wir außerdem wichtige Statistiken zur Art der TCP-Übertragungen bereit.

Laminar TCP

Laminar ist ein neues Framework für die TCP-Überlastungssteuerung. Es trennt die Übertragungsplanung, die genau bestimmt, wann Daten gesendet werden, von der reinen Überlastungskontrolle, die die Gesamtmenge der Daten bestimmt, die während jeder RTT gesendet werden. Laminar soll neue fortschrittliche Algorithmen ermöglichen, um TCP-Traffic präziser zu regulieren.

SSL- und TLS-Entwürfe

Falscher Start für Transport Layer Security (TLS)

„Falscher Start“ ist ein optionales Verhalten bei TLS-Implementierungen. Sie wirkt sich nur auf das Protokolltiming, nicht auf Daten, die über das Wireprotokoll übertragen werden, aus und kann einseitig implementiert werden. Die TLS-Funktion Falscher Start führt zu einer Latenzreduzierung von einem Umlauf bei bestimmten Handshakes.

Next Protocol Negotiation Extension (Transport Layer Security (TLS))

TLS-Erweiterung (Transport Layer Security) zum Aushandeln von Protokollen auf Anwendungsebene Auf diese Weise kann die Anwendungsebene auf eine Weise verhandeln, welches Protokoll über die sichere Verbindung ausgeführt werden soll, und zwar so, dass zusätzliche Umläufe vermieden werden und welches Protokoll unabhängig von den Protokollen der Anwendungsebene ist.

DNS-Entwurf

Clientsubnetz in DNS-Anfragen

In diesem Entwurf ist eine EDNS0-Erweiterung definiert, die Informationen über das Netzwerk enthält, von dem eine DNS-Abfrage stammt, und das Netzwerk, für das eine Antwort im Cache gespeichert werden kann.