1. Introduction (Einführung)

Das TCP-Protokoll [Postel81] wurde entwickelt, um zuverlässig über fast jedes Übertragungsmedium zu funktionieren, unabhängig von Übertragungsrate, Verzögerung, Beschädigung, Duplikation oder Neuordnung von Segmenten. Produktions-TCP-Implementierungen passen sich derzeit an Übertragungsraten im Bereich von 100 bps bis 10**7 bps und Round-Trip-Verzögerungen im Bereich von 1 ms bis 100 Sekunden an. Neuere Arbeiten zur TCP-Leistung haben gezeigt, dass TCP über eine Vielzahl von Internet-Pfaden gut funktionieren kann, von 800 Mbit/sec I/O-Kanälen bis hin zu 300 bit/sec Einwahlmodems [Jacobson88a].

Die Einführung von Glasfasern führt zu immer höheren Übertragungsgeschwindigkeiten, und die schnellsten Pfade verlassen den Bereich, für den TCP ursprünglich entwickelt wurde. Dieses Memo definiert eine Reihe bescheidener Erweiterungen von TCP, um den Anwendungsbereich an diese zunehmende Netzwerkkapazität anzupassen. Es basiert auf und ersetzt RFC-1072 [Jacobson88b] und RFC-1185 [Jacobson90b].

Es gibt keine einzeilige Antwort auf die Frage: "Wie schnell kann TCP sein?". Es gibt zwei getrennte Arten von Problemen, Leistung und Zuverlässigkeit, und jede hängt von unterschiedlichen Parametern ab. Wir diskutieren jede der Reihe nach.

1.1 TCP Performance (TCP-Leistung)

Die TCP-Leistung hängt nicht von der Übertragungsrate selbst ab, sondern vielmehr vom Produkt der Übertragungsrate und der Round-Trip-Verzögerung. Dieses "bandwidthdelay product (BandbreiteVerzögerungsprodukt)" misst die Datenmenge, die "die Pipeline füllen" würde; es ist der Pufferspeicher, der bei Sender und Empfänger erforderlich ist, um maximalen Durchsatz auf der TCP-Verbindung über den Pfad zu erhalten, d.h. die Menge unbestätigter Daten, die TCP handhaben muss, um die Pipeline voll zu halten. TCP-Leistungsprobleme treten auf, wenn das bandwidth*delay product groß ist. Wir bezeichnen einen Internet-Pfad, der in diesem Bereich arbeitet, als "long, fat pipe (lange, dicke Pipeline)", und ein Netzwerk, das diesen Pfad enthält, als "LFN" (ausgesprochen "elephan(t)").

Hochkapazitäts-Paketsatellitenkanäle (z.B. DARPAs Wideband Net) sind LFNs. Zum Beispiel hat ein Satellitenkanal mit DS1-Geschwindigkeit ein bandwidth*delay product von 106 Bits oder mehr; dies entspricht 100 ausstehenden TCP-Segmenten von jeweils 1200 Bytes. Terrestrische Glasfaserpfade fallen ebenfalls in die LFN-Klasse; zum Beispiel übersteigt eine transkontinentale Verzögerung von 30 ms bei einer DS3-Bandbreite (45Mbps) ebenfalls 106 Bits.

Es gibt drei grundlegende Leistungsprobleme mit dem aktuellen TCP über LFN-Pfade:

(1) Window Size Limit (Fenstergrößenbeschränkung)

Der TCP-Header verwendet ein 16-Bit-Feld, um die Empfangsfenstergröße an den Sender zu melden. Daher beträgt das größte Fenster, das verwendet werden kann, 2**16 = 65K Bytes.

Um dieses Problem zu umgehen, definiert Abschnitt 2 dieses Memos eine neue TCP-Option, "Window Scale (Fensterskalierung)", um Fenster größer als 2**16 zu ermöglichen. Diese Option definiert einen impliziten Skalierungsfaktor, der verwendet wird, um den in einem TCP-Header gefundenen Fenstergrößenwert zu multiplizieren, um die wahre Fenstergröße zu erhalten.

(2) Recovery from Losses (Wiederherstellung nach Verlusten)

Paketverluste in einem LFN können katastrophale Auswirkungen auf den Durchsatz haben. Bis vor kurzem würden ordnungsgemäß funktionierende TCP-Implementierungen dazu führen, dass die Datenpipeline bei jedem Paketverlust entleert wird, und eine Slow-Start-Aktion zur Wiederherstellung erfordern. Kürzlich wurden die Fast Retransmit und Fast Recovery Algorithmen [Jacobson90c] eingeführt. Ihr kombinierter Effekt besteht darin, sich von einem Paketverlust pro Fenster zu erholen, ohne die Pipeline zu entleeren. Mehr als ein Paketverlust pro Fenster führt jedoch typischerweise zu einer Retransmission-Timeout und der resultierenden Pipeline-Entleerung und Slow Start.

Die Erweiterung der Fenstergröße, um der Kapazität eines LFN zu entsprechen, führt zu einer entsprechenden Erhöhung der Wahrscheinlichkeit, dass mehr als ein Paket pro Fenster verworfen wird. Dies könnte verheerende Auswirkungen auf den Durchsatz von TCP über einen LFN haben. Zusätzlich würden, wenn ein Congestion-Control-Mechanismus, der auf irgendeiner Form zufälliger Verwerfung basiert, in Gateways eingeführt würde, zufällig verteilte Paketverwerfungen üblich werden, was möglicherweise die Wahrscheinlichkeit erhöht, mehr als ein Paket pro Fenster zu verwerfen.

Um den Fast Retransmit/Fast Recovery Mechanismus zu verallgemeinern, um mehrere pro Fenster verworfene Pakete zu handhaben, sind selektive Bestätigungen erforderlich. Im Gegensatz zu den normalen kumulativen Bestätigungen von TCP geben selektive Bestätigungen dem Sender ein vollständiges Bild davon, welche Segmente beim Empfänger in der Warteschlange stehen und welche noch nicht angekommen sind. Einige Beweise zugunsten selektiver Bestätigungen wurden veröffentlicht [NBS85], und selektive Bestätigungen wurden in eine Reihe experimenteller Internet-Protokolle aufgenommen -- VMTP [Cheriton88], NETBLT [Clark87] und RDP [Velten84], und für OSI TP4 vorgeschlagen [NBS85]. Im nicht-LFN-Bereich reduzieren selektive Bestätigungen jedoch die Anzahl der erneut übertragenen Pakete, verbessern aber ansonsten nicht die Leistung, wodurch ihre Komplexität von fragwürdigem Wert ist. Selektive Bestätigungen werden jedoch im LFN-Bereich voraussichtlich viel wichtiger werden.

RFC-1072 definierte eine neue TCP-"SACK"-Option zum Senden einer selektiven Bestätigung. Es gibt jedoch wichtige technische Probleme, die sowohl das Format als auch die Semantik der SACK-Option betreffen, die ausgearbeitet werden müssen. Daher wurde SACK aus diesem Erweiterungspaket weggelassen. Es wird gehofft, dass SACK während des Standardisierungsprozesses "aufholen" kann.

(3) Round-Trip Measurement (Round-Trip-Messung)

TCP implementiert zuverlässige Datenübertragung, indem Segmente erneut übertragen werden, die nicht innerhalb eines bestimmten Retransmission-Timeout-Intervalls (RTO) bestätigt werden. Die genaue dynamische Bestimmung eines geeigneten RTO ist für die TCP-Leistung wesentlich. RTO wird bestimmt, indem der Mittelwert und die Varianz der gemessenen Round-Trip-Zeit (RTT) geschätzt werden, d.h. das Zeitintervall zwischen dem Senden eines Segments und dem Empfang einer Bestätigung dafür [Jacobson88a].

Abschnitt 4 führt eine neue TCP-Option, "Timestamps (Zeitstempel)", ein und definiert dann einen Mechanismus, der diese Option verwendet, der es ermöglicht, nahezu jedes Segment, einschließlich Neuübertragungen, mit vernachlässigbaren Rechenkosten zu messen. Wir verwenden das Mnemonic RTTM (Round Trip Time Measurement, Round-Trip-Zeitmessung) für diesen Mechanismus, um ihn von anderen Verwendungen der Timestamps-Option zu unterscheiden.

1.2 TCP Reliability (TCP-Zuverlässigkeit)

Nun wenden wir uns von der Leistung zur Zuverlässigkeit. Eine hohe Übertragungsrate beeinflusst die TCP-Leistung durch das bandwidth*delay product. Eine hohe Übertragungsrate allein kann jedoch die TCP-Zuverlässigkeit bedrohen, indem sie die Annahmen hinter dem TCP-Mechanismus zur Duplikaterkennung und Sequenzierung verletzt.

Eine besonders schwerwiegende Art von Fehler kann aus einer versehentlichen Wiederverwendung von TCP-Sequenznummern in Datensegmenten resultieren. Angenommen, ein "old duplicate segment (altes dupliziertes Segment)", z.B. ein dupliziertes Datensegment, das in Internet-Warteschlangen verzögert wurde, wird dem Empfänger zum falschen Zeitpunkt zugestellt, sodass seine Sequenznummern irgendwo innerhalb des aktuellen Fensters fallen. Es gäbe keinen Prüfsummenfehler, um vor dem Fehler zu warnen, und das Ergebnis könnte eine unentdeckte Datenbeschädigung sein. Der Empfang eines alten duplizierten ACK-Segments beim Sender könnte nur geringfügig weniger schwerwiegend sein: Es würde wahrscheinlich die Verbindung blockieren, sodass kein weiterer Fortschritt gemacht werden kann, was ein RST auf der Verbindung erzwingt.

Die TCP-Zuverlässigkeit hängt von der Existenz einer Grenze für die Lebensdauer eines Segments ab: das "Maximum Segment Lifetime (Maximale Segmentlebensdauer)" oder MSL. Ein MSL wird im Allgemeinen von jedem zuverlässigen Transportprotokoll benötigt, da jedes Sequenznummernfeld endlich sein muss und daher jede Sequenznummer schließlich wiederverwendet werden kann. In der Internet-Protokollsuite wird die MSL-Grenze durch einen IP-Layer-Mechanismus erzwungen, das "Time-to-Live (Lebenszeit)"-Feld oder TTL.

Die Duplizierung von Sequenznummern kann auf zwei Arten geschehen:

(1) Sequence number wrap-around on the current connection (Sequenznummern-Wrap-Around bei der aktuellen Verbindung)

Eine TCP-Sequenznummer enthält 32 Bits. Bei einer ausreichend hohen Übertragungsrate kann der 32-Bit-Sequenzraum innerhalb der Zeit, die ein Segment in Warteschlangen verzögert wird, "gewickelt" (zyklisiert) werden.

(2) Earlier incarnation of the connection (Frühere Inkarnation der Verbindung)

Angenommen, eine Verbindung wird beendet, entweder durch eine ordnungsgemäße Schließsequenz oder aufgrund eines Host-Absturzes, und dieselbe Verbindung (d.h. unter Verwendung desselben Socket-Paares) wird sofort wiedereröffnet. Ein verzögertes Segment aus der beendeten Verbindung könnte innerhalb des aktuellen Fensters für die neue Inkarnation fallen und als gültig akzeptiert werden.

Duplikate aus früheren Inkarnationen, Fall (2), werden durch Durchsetzung des aktuellen festen MSL der TCP-Spezifikation vermieden, wie in Abschnitt 5.3 und Anhang B erläutert. Fall (1), die Vermeidung der Wiederverwendung von Sequenznummern innerhalb derselben Verbindung, erfordert jedoch eine MSL-Grenze, die von der Übertragungsrate abhängt, und bei ausreichend hohen Raten ist ein neuer Mechanismus erforderlich.

Genauer gesagt, wenn die maximale effektive Bandbreite, bei der TCP über einen bestimmten Pfad übertragen kann, B Bytes pro Sekunde beträgt, dann muss die folgende Einschränkung für fehlerfreien Betrieb erfüllt sein:

2**31 / B  > MSL (secs)                     [1]

Die folgende Tabelle zeigt den Wert für Twrap = 2**31/B in Sekunden für einige wichtige Werte der Bandbreite B:

Network	B*8 bits/sec	B bytes/sec	Twrap secs
ARPANET	56kbps	7KBps	310*5 (~3.6 days)
DS1	1.5Mbps	190KBps	10**4 (~3 hours)
Ethernet	10Mbps	1.25MBps	1700 (~30 mins)
DS3	45Mbps	5.6MBps	380
FDDI	100Mbps	12.5MBps	170
Gigabit	1Gbps	125MBps	17

Es ist klar, dass Wrap-Around des Sequenzraums kein Problem für 56kbps-Paketvermittlung oder sogar 10Mbps-Ethernets ist. Andererseits ist Twrap bei DS3- und FDDI-Geschwindigkeiten vergleichbar mit dem 2-Minuten-MSL, das von der TCP-Spezifikation angenommen wird [Postel81]. In Richtung Gigabit-Geschwindigkeiten wird Twrap zu klein für eine zuverlässige Durchsetzung durch den Internet-TTL-Mechanismus.

Das 16-Bit-Fensterfeld von TCP begrenzt die effektive Bandbreite B auf 2**16/RTT, wobei RTT die Round-Trip-Zeit in Sekunden ist [McKenzie89]. Wenn die RTT groß genug ist, begrenzt dies B auf einen Wert, der die Einschränkung [1] für einen großen MSL-Wert erfüllt. Betrachten Sie zum Beispiel ein transkontinentales Backbone mit einer RTT von 60ms (festgelegt durch die Gesetze der Physik). Mit dem auf 64KB durch die TCP-Fenstergröße begrenzten bandwidth*delay product ist B dann auf 1.1MBps begrenzt, egal wie hoch die theoretische Übertragungsrate des Pfades ist. Dies entspricht dem Zyklus des Sequenznummernraums in Twrap= 2000 Sekunden, was im heutigen Internet sicher ist.

Es ist wichtig zu verstehen, dass nicht das größere Fenster, sondern die hohe Bandbreite der Schuldige ist. Betrachten Sie zum Beispiel ein (sehr großes) FDDI-LAN mit einem Durchmesser von 10km. Mit der Lichtgeschwindigkeit können wir die RTT über den Ring als (210**4)/(310**8) = 67 Mikrosekunden berechnen, und das delay*bandwidth product beträgt dann 833 Bytes. Eine TCP-Verbindung über dieses LAN mit einem Fenster von nur 833 Bytes läuft mit vollen 100mbps und kann den Sequenzraum in etwa 3 Minuten umwickeln, sehr nahe am MSL von TCP. Somit kann hohe Geschwindigkeit allein ein Zuverlässigkeitsproblem mit Sequenznummern-Wrap-Around verursachen, auch ohne erweiterte Fenster.

Watsons Delta-T-Protokoll [Watson81] umfasst Netzwerkschicht-Mechanismen zur präzisen Durchsetzung eines MSL. Im Gegensatz dazu ist der IP-Mechanismus zur MSL-Durchsetzung locker definiert und im Internet noch lockerer implementiert. Daher ist es unklug, sich auf aktive Durchsetzung von MSL für TCP-Verbindungen zu verlassen, und es ist unrealistisch, sich vorzustellen, MSLs kleiner als die aktuellen Werte festzulegen (z.B. 120 Sekunden für TCP spezifiziert).

Eine mögliche Lösung für das Problem des Zyklus des Sequenzraums wäre, die Größe des TCP-Sequenznummernfeldes zu erhöhen. Zum Beispiel könnte das Sequenznummernfeld (und auch das Bestätigungsfeld) auf 64 Bits erweitert werden. Dies könnte entweder durch Änderung des TCP-Headers oder mittels einer zusätzlichen Option erfolgen.

Abschnitt 5 präsentiert einen anderen Mechanismus, den wir PAWS (Protect Against Wrapped Sequence numbers, Schutz vor umwickelten Sequenznummern) nennen, um die TCP-Zuverlässigkeit auf Übertragungsraten weit über die vorhersehbare Obergrenze der Netzwerkbandbreiten hinaus zu erweitern. PAWS verwendet die in Abschnitt 4 definierte TCP-Timestamps-Option, um vor alten Duplikaten aus derselben Verbindung zu schützen.

1.3 Using TCP options (Verwendung von TCP-Optionen)

Die in diesem Memo definierten Erweiterungen verwenden alle neue TCP-Optionen. Wir müssen zwei mögliche Probleme hinsichtlich der Verwendung von TCP-Optionen ansprechen: (1) Kompatibilität und (2) Overhead.

Wir müssen auf Kompatibilität, d.h. auf Interoperabilität mit bestehenden Implementierungen, besonders achten. Die einzige zuvor definierte TCP-Option, MSS, darf nur in einem SYN-Segment erscheinen. Jede Implementierung sollte (und wir erwarten, dass die meisten es tun werden) unbekannte Optionen in SYN-Segmenten ignorieren. Einige fehlerhafte TCP-Implementierungen könnten jedoch durch das erste Auftreten einer Option in einem Nicht-SYN-Segment abstürzen. Daher werden für jede der unten definierten Erweiterungen TCP-Optionen nur dann in Nicht-SYN-Segmenten gesendet, wenn ein Austausch von Optionen in den SYN-Segmenten angezeigt hat, dass beide Seiten die Erweiterung verstehen. Außerdem wird eine Erweiterungsoption nur dann in einem <SYN,ACK>-Segment gesendet, wenn die entsprechende Option im ursprünglichen <SYN>-Segment empfangen wurde.

Eine Frage kann bezüglich des Bandbreiten- und Verarbeitungs-Overheads für TCP-Optionen aufgeworfen werden. Diese Optionen, die in SYN-Segmenten auftreten, werden wahrscheinlich kein Leistungsproblem verursachen. Das Öffnen einer TCP-Verbindung erfordert die Ausführung von signifikantem Sonderfallcode, und die Verarbeitung von Optionen wird diese Kosten wahrscheinlich nicht signifikant erhöhen.

Andererseits kann eine Timestamps-Option in jedem Daten- oder ACK-Segment erscheinen und fügt dem 20-Byte-TCP-Header 12 Bytes hinzu. Wir glauben, dass die durch Reduzierung unnötiger Neuübertragungen eingesparte Bandbreite die zusätzliche Header-Bandbreite mehr als ausgleicht.

Es gibt auch ein Problem bezüglich des Verarbeitungs-Overheads für das Parsing des variablen byte-ausgerichteten Formats von Optionen, insbesondere bei einer RISC-Architektur-CPU. Um diesem Anliegen zu begegnen, enthält Anhang A ein empfohlenes Layout der Optionen in TCP-Headern, um eine vernünftige Datenfeldausrichtung zu erreichen. Im Geiste von Header Prediction kann ein TCP schnell auf dieses Layout testen, und wenn es verifiziert wird, dann einen schnellen Pfad verwenden. Hosts, die dieses kanonische Layout verwenden, werden die Optionen effektiv als einen Satz fester Formatfelder verwenden, die an den TCP-Header angehängt sind. Um jedoch den philosophischen und Protokoll-Rahmen von TCP-Optionen beizubehalten, muss ein TCP darauf vorbereitet sein, ein beliebiges Optionsfeld zu parsen, wenn auch mit geringerer Effizienz.

Schließlich beobachten wir, dass die meisten der in diesem Memo definierten Mechanismen für LFNs und/oder sehr Hochgeschwindigkeitsnetzwerke wichtig sind. Für Low-Speed-Netzwerke könnte es eine Leistungsoptimierung sein, diese Mechanismen NICHT zu verwenden. Ein TCP-Anbieter, der sich um optimale Leistung über Low-Speed-Pfade kümmert, könnte in Betracht ziehen, diese Erweiterungen für Low-Speed-Pfade zu deaktivieren oder einem Benutzer oder Installationsmanager zu erlauben, sie zu deaktivieren.