Transmission Control Protocol (TCP)

(1)

Transmission Control Protocol (TCP)

SS 2014 Grundlagen der Rechnernetze ‐ Transportschicht 6

(2)

Übersicht

Anwendungsprozess A

TCP Sende‐

puffer

Anwendungsprozess B

TCP Empfangs‐

puffer

…

schreibe Bytes

lese

Bytes …

Segment Segment

… lese

Bytes

Empfangs‐

puffer

Sende‐

puffer

IP IP

Segment Segment Segment Segment

(3)

Übersicht

Anwendungsprozess A

TCP Sende‐

puffer

Anwendungsprozess B

TCP Empfangs‐

puffer

…

lese

Bytes …

Segment Segment

… lese

Bytes

Empfangs‐

puffer

Sende‐

puffer

IP IP

Segment Segment Segment Segment

Grundfunktion

• Zuverlässige Auslieferung

• eines Full‐Duplex

• Byte‐Streams in

• korrekter Reihenfolge Darüber hinaus:

• Flusskontrolle (vermeidet, dass Sender den Empfänger

überlastet)

• Lastkontrolle (vermeidet, dass Sender zu viel Last im Netz erzeugt)

Wie auch bei UDP:

• Port‐Mechanismus

(4)

Segmentnummerierung und ACKs

Initiale Sequenznummer: 1999 Byte‐Stream …

Segment 1 Bytes:

0…1023 Sequenz‐

nummer:

2000

Segment 2 Bytes:

1024…2047 Sequenz‐

nummer:

3024

Segment 3 Bytes:

2048…5000 Sequenz‐

nummer:

4048

Sender Empfänger Daten (SequenceNum)

Acknowledgment (SequenceNum+1) Bestätigt wird immer das

nächste erwartete Byte

(5)

Protokollablauf

Verbindungsaufbau

Datenübertragungsphase

Verbindungsabbau

Bildquelle: en.wikipedia.org/wiki/Transmission_Control_Protocol

(6)

Tafelanschrieb

(7)

Segmentstruktur

Octet 0 1 2 3

Bit 0 1 2 3 4 5 6 7 8 9 10111213141516171819202122232425262728293031

0 0 Source Port Destination Port

4 32 Sequence Number

8 64 Acknowledgement Number (if ACK set)

12 96 Data Offset

Rsrved 0 0 0

N S

C W

R E C E

U R G

A C K

P S H

R S T

S Y N

F I N

Window Size

16 128 Checksum Urgent Pointer (if URG set) 20

…

160

…

Options (if data Offset > 5)

(Padded at end with 0‐Bytes if necessary)

Data

(8)

Sliding‐Window

Sendende Anwendung

TCP

LastByteAcked

LastByteWritten

LastByteSent

… …

Sendepuffer

Empfangende Anwendung

TCP

NextByteExpected

LastByteRead

LastByteRcvd

… …

Empfangspuffer

MaxSendBuffer = Größe des Sendepuffers MaxRcvBuffer = Größe des Empfangspuffers TCP‐Acknowledgements sind kummulativ (Kummulative ACKs) – bestätigt wird die Nummer des ersten noch fehlenden Bytes. Alle vorigen Bytes wurden schon vollständig empfangen.

(9)

Flusskontrolle

Sender

TCP

v=LastByteAcked

l=LastByteWritten

w=LastByteSent

… …

Empfänger

TCP

NextByteExpected

x=LastByteRead

y=LastByteRcvd

… …

MSB = MaxSendBuffer MRB=MaxRcvBuffer

Zur Vermeidung eines Empfangs‐

pufferüberlaufes muss gelten:

Hierzu wird dem Sender das folgende

„AdvertisedWindow“ a mitgeteilt:

Auf Senderseite muss stets gelten:

Damit ist das Maximum an Daten, welches der Sender versenden darf (genannt „EffectiveWindow“ e):

Anwendung, die z Bytes schreibt wird blockiert, wenn:

(10)

Flusskontrolle

Sender

TCP

v=LastByteAcked

l=LastByteWritten

w=LastByteSent

… …

Empfänger

TCP

NextByteExpected

x=LastByteRead

y=LastByteRcvd

… …

MSB = MaxSendBuffer MRB=MaxRcvBuffer

Zur Vermeidung eines Empfangs‐

pufferüberlaufes muss gelten:

y – x ≤ MRB

Hierzu wird dem Sender das folgende

„AdvertisedWindow“ a mitgeteilt:

a = MRB – ( y – x )

Auf Senderseite muss stets gelten:

w – v ≤ a

Damit ist das Maximum an Daten, welches der Sender versenden darf (genannt „EffectiveWindow“ e):

e = a – ( w – v )

Anwendung, die z Bytes schreibt wird blockiert, wenn:

( l – w ) + z > MSB

(11)

Regulärer Duplexbetrieb

AdvWnd=1024, AckedSeqNr=3463

Gerät 1 Gerät 2

(12)

AdvertisedWindow = 0  Deadlock?

AdvertisedWindow=0

Empfangspuffer wird geleert und Empfänger sendet nichts an den Sender zurück.

Empfänger Sender

Annahme: Sender sendet ab hier nicht weiter

Woher weis der Sender, dass wieder Platz im Empfängerpuffer ist?!?

AdvertisedWindow=0

Empfangspuffer wird geleert und Empfänger sendet nichts an den Sender zurück.

Empfänger Sender

Segment der Länge 1

AdvertisedWindow=0

Segment der Länge 1

AdvertisedWindow=1200

Probing mit Segment der Länge 1

Persist timer

(13)

Wann soll ein Segment versendet werden?

TCP verwaltet eine Variable Maximum‐Segment‐Size (MSS)

MSS = MTU des lokalen Netzes minus TCP‐ und IP‐Headergröße Versende Segment auf jeden Fall sobald

• mindestens MSS viele neue Bytes vorliegen oder

• der sendende Prozess explizit darum bittet (push)

Was sonst? Warum nicht aggressiv immer sofort senden?

(14)

Sofortiges Senden bedeutet unnötiger Overhead

Sender Empfänger

Sendepuffer leer

…

2 Bytes erzeugt 7 Bytes erzeugt 3 Bytes erzeugt

Segment mit ein paar wenigen Bytes bedeutet unnötiger Overhead. Versendet werden muss: Daten + IP‐Header + TCP‐Header.

Effekte wie diesen, in denen unnötig kleine Pakete versendet werden, nennt man auch Silly‐Window‐Syndrom.

Besser wäre es doch zu warten, bis der Puffer wieder gut gefüllt ist. Wie lange sollte man warten?

(15)

Nagle‘s Algorithmus

Routine, die von TCP ausgeführt wird, wenn die sendende Applikation neue Daten produziert hat:

if verfügbare Daten und Window >= MSS then sende volles Segment

else

if nicht-Acked Data unterwegs then

puffere die Daten bis Ack ankommt else

sende alle neuen Daten jetzt endif

endif

(Die Vorgehensweise von Nagle‘s Lösung nennt man auch self‐

clocking.)

(16)

Reübertragung bei TCP der ersten Stunde

TCP‐Sender TCP‐Empfänger

Segment

*

Wie lange warten, bis das Segment

reübertragen wird?

Erste TCP‐

Implementierungen

verwenden das zweifache der RTT.

Woher kennt man die RTT?

(17)

Ermitteln der RTT

Ein Sample RTT(i) bei gegebener Segment‐Sendezeit s und Acknowledgement‐Zeit a für das ite versendete Segment:

Ein simpler Ansatz wäre das Stichprobenmittel darüber, also:

Die gesamte Summation muss dabei nicht jedes mal neu berechnet werden:

(18)

Ermitteln der RTT

Nachteil des einfachen Stichprobenmittels:

• jede Messung auch die in der weiten Vergangenheit haben dasselbe Gewicht

• Besser wäre es doch den aktuellen Messungen das meiste Gewicht zu geben

Lösung exponentiell gewichteter gleitender Mittelwert (so ist es auch in der Original‐TCP‐Spezifikation in RFC 793) realisiert:

Einfluss von ? TCP verwendet  zwischen 0,8 und 0,9.

(19)

Ermitteln der RTT

Warum lautet dieser gleitende Mittelwert eigentlich exponentiell gewichtet? Expandieren liefert:

Also z.B. für alpha=0,8:

(20)

Problem: Zuordnung von ACKs

Sender Empfänger Sender Empfänger

SampleRTT

zu lang SampleRTT

zu kurz

Karn/Patridge‐Algorithmus: Ignoriere einfach die Segmente, die reübertragen wurden.

Darüber hinaus: wann immer ein Segment reübertragen werden musste:

Timeout = 2*Timeout (Exponential Backoff)

(21)

Einbeziehen der Varianz

Warum eigentlich Timeout für Reübertragung = 2*EstimatedRTT?

RTT ist variabel, d.h. man sollte einen Sicherheitsabstand (hier eine zusätzliche RTT) einhalten.

Aber wieso ist genau eine zusätzliche RTT gut? Besser:

berücksichtige die Varianz der RTT‐Messungen. Jacobson/Karels‐

Algorithmus: schätze die folgende mittlere Abweichung:

Hierbei ist E[X] der Erwartungswert von Zufallsvariable X.

(22)

Einbeziehen der Varianz

Einfache Stichprobenvarianz lässt sich wie folgt berechnen:

1 1

1 | |

1

1| 1 |

Analog zur mittleren RTT lassen sich hierbei ebenfalls durch exponentiell gleitenden Mittelwert neuere Varianzwerte höher gewichten als ältere.

(23)

Einbeziehen der Varianz

Die komplette Berechnung nach Jacobson/Karels‐Algorithmus ist dann wie folgt:

1 1 · · 1

1 1

1 1 · · 1

0 1 1 · 1

Hierbei ist nach der Originalveröffentlichung von Jacobson:

g = 1/8 = 0,125 h = 1/4 = 0,25

f = 2 (bzw. später auf f=4 korrigiert)

(24)

Diskussion

Bandbreite Zeit bis Sequenz‐

nummern verbraucht sind

T1 (1,5 Mbps) 6,4 Stunden Ethernet (10 Mbps) 57 Minuten

T3 (45 Mbps) 13 Minuten

Fast Ethernet (100 Mbps) 6 Minuten OC‐3 (155 Mbps) 4 Minuten OC‐12 (622 Mbps) 55 Sekunden OC‐48 (2,5 Gbps) 14 Sekunden

Bandbreite Delay‐Bandbreiten‐

Produkt für

beispielsweise 100 ms RTT

T1 (1,5 Mbps) 18 KB

Ethernet (10 Mbps) 122 KB

T3 (45 Mbps) 549 KB

Fast Ethernet (100 Mbps) 1,2 MB OC‐3 (155 Mbps) 1,8 MB OC‐12 (622 Mbps) 7,4 MB OC‐48 (2,5 Gbps) 29,6 MB

Kurze „Wraparound‐Zeit“ kann

problematisch werden, wenn der Delay und Bandbreite groß sind. Alte Segmente interferieren mit aktuellen.

Das Sendefenster erlaubt mit 16‐Bit‐

AdvertisedWindow‐Werten, dass maximal 64KB Daten unterwegs sind. Somit wird bei großem Delay eine große verfügbare

Bandbreite kaum genutzt.

Lösungen? TCP‐Erweiterungen...

(25)

TCP‐Erweiterungen

32‐Bit‐Timestamp

• Speichere Sendezeit in Segment

• Wiederhole die Zeit im ACK

• Berechne RTT bei ACK‐Empfang Sender braucht keine Timestamps zu

verwalten. Die sind „im Netz gespeichert“.

32‐Bit‐Sequenznummern: Lösung der vorhin beschriebenen kurzen Wrap‐

around‐Zeiten

• Verwende oben beschriebenen Timestamp

• Segmente mit gleichen

SequenceNum‐Werten sind anhand des Timestamp unterscheidbar

SrcPort DstPort

SequenceNum Acknowledgment

HdrLen

Checksum

Options (variable)

0 Flags AdvertisedWindow

UrgPtr

Data

0 4 10 16 31

Erinnerung: TCP‐Header

(26)

TCP‐Erweiterungen

Scaling‐Factor für das 16‐Bit‐Advertised‐

Window

• Lösung der vorhin beschriebenen Ineffizienz bei hohem Delay‐

Bandbreitenprodukt

• AdvertisedWindow‐Wert wird mit dem Scaling‐Factor multipliziert Selective‐ACK (SACK)

• Verbesserung des kummulativen ACK von TCP.

• Neben dem gewöhnlichen

Acknowledgement speichert das Optionale Feld zusätzliche

Acknowledgements für die nicht aufeinander folgenden Segmente

• Sender braucht nur noch die Lücken zu reübertragen

SrcPort DstPort

SequenceNum Acknowledgment

HdrLen

Checksum

Options (variable)

0 Flags AdvertisedWindow

UrgPtr

Data

0 4 10 16 31

NextByteExpected LastByteRead

LastByteRcvd

… …

(27)

TCP‐Überlastkontrolle

(28)

Motivation

Bisher haben wir die Flusskontrolle besprochen:

Regulieren der Senderate, um eine Überlastung des Empfängers zu vermeiden.

Wir interessieren uns nun für die Überlastkontrolle:

Regulieren der Senderate, um eine Überlastung des ganzen Netzes zu vermeiden.

Die TCP‐Flusskontrolle verwendet (wie schon gezeigt) das

EffectiveWindow: es dürfen nur EffectiveWindow viele weitere Bytes versendet werden.

• Versenden von weiteren Bytes verkleinert das EffectiveWindow

• Empfang von Acknowledgements vergrößert das Window wieder

Das EffectiveWindow kann auch für die Überlastkontrolle verwendet werden: ...

(29)

EffectiveWindow für Fluss‐ und Überlastkontrolle

Annahme in der Variable CongestionWindow steht, wie viel Bytes das Netz im Transit erlaubt.

Setze das EffectiveWindow wie folgt:

min ,

Aber woher lernt TCP das CongestionWindow?

Additive Increase / Multiplicative Decrease (AIMD):

• Sender halbiert das Fenster, wenn er Überlast vermutet

• Sonst vergrößere das Fenster um eine MSS pro RTT Das Fenster darf aber nie kleiner als eine MSS werden

Wie kann man Überlast vermuten? Wann immer ein Timeout für ein ausstehendes ACK stattfindet.

(30)

Additive‐Increase‐Beispiel

Source Destination

RTT

Erhöhe um eine MSS

...

... ...

Inkrement pro RTT:

CongestionWindow += MSS

Inkrement pro ACK?

Inc in one RTT:

inc = MSS/CongestionWindow Per ACK:

CongestionWindow += inc

Sei c die alte Länge des CongestionWindow. Nach einem RTT‐Durchlauf ist:

CongestionWindow += inc*c

= MSS

(31)

Ein typisches AIMD‐Muster

CongestionWindow‐Größe

Zeit

(32)

Slow‐Start

RTT

... ...

Source Destination

Starte mit einem CongestionWindow der Länge MSS.

Erhöhe CongestionWindow um eine MSS pro ACK.

Somit wird das CongestionWindow pro RTT wie weit erhöht?

CongestionWindow *= 2

Warum heißt das eigentlich Slow‐Start?

Historischer Grund: In TCP‐Anfängen wurde zum Starten direkt mit einem großen

CongestionWindow gestartet.

(33)

Wann beginnt und endet der Slow‐Start?

Wenn eine Verbindung neu hergestellt wurde.

• Setze CongestionWindow auf eine MSS

• Beginne Slow‐Start

• Wechsele in AdditiveIncrease sobald ein bestimmter

Schwellwert (CongestionThreshold) überschritten wurde Wenn ein Timeout stattgefunden hat

• CongestionThreshold = CongestionWindow/2 (man merkt sich also den CongestionWindow nach dem durch den Timeout ausgelösten MultiplicativeDecrease)

• Setze CongestionWindow auf eine MSS

• Beginne Slow‐Start

• Wechsele in AdditiveIncrease sobald der Schwellwert CongestionThreshold überschritten wurde

(34)

Ein Beispiel

(35)

Fast‐Retransmit

Sender Empfänger

Paket 1 Paket 2

* ^ACK 1

ACK 2 ACK 2

ACK 6 Paket 4

Paket 5 Paket 6

Paket 3

(retransmit) Paket 3

Erinnerung: ACKS sind kummulativ (d.h. bestätigen die bisher voll‐

ständig zusammenhängende Se‐

quenz von Segmenten)

Verlorene Sequenz führt zu

„duplicate ACKs“.

Fast‐Retransmit: Warte nicht auf Timeout, sondern reübertrage ein Segment, nach drei aufeinander folgenden Duplicate‐ACKs.

(36)

Die TCP‐Variante mit Fast‐Recovery

• Slow‐Start, wenn die TCP‐Verbindung neu aufgebaut wurde.

• Bei Reübertragung wegen duplicate ACK lediglich CongestionWindow wie üblich halbieren.

• Aber keinen Slow‐Start, sondern gewöhnlichen AdditiveIncrease.

(37)

TCP‐Überlastvermeidung

(38)

Motivation

TCP implementiert Überlastkontrolle, d.h. erst wenn Segmente auf den Routern verworfen werden, wird an den Quellen die in das Netz gesendete Last reduziert.

Die Idee von Überlastvermeidung: reduziere die an den Quellen erzeugte Last schon bevor die ersten Segmente (Pakete) an den Routern wegen voll gelaufener Queues verworfen werden.

TCP hat an den Quellknoten keine Mechanismen eingebaut, die eine solche Strategie unmittelbar ermöglicht. Man müsste hierzu TCP

erweitern oder durch ein neues Protokoll ersetzen.

Idee: Router „gaukeln“ vorzeitig übergelaufene Queues vor, sodass die TCP‐Quellknoten auch vorzeitig die Last reduzieren und somit keine Überlast an den Routern auftreten kann.

(39)

Random‐Early‐Detection (RED)

Router berechnet regelmäßig die mittlere Queuelänge AvgLen anhand von gemessenen Queuelängensamples SampleLen:

1 · ·

Jeder Router hat ein MinThreshold und ein MaxThreshold. Bei Ankunft eines Paketes wird folgender Algorithmus ausgeführt:

if AvgLen <= MinThreshold

speichere Paket in der Queue else if AvgLen < MaxThreshold

berechne Wahrscheinlichkeit p

verwerfe das Paket mit der Wahrscheinlichkeit p else

verwerfe das Paket immer

In Abhängigkeit der Queue‐

Länge und bisher

abgelaufenen Zeit in Überlast

(40)

Berechnung der Drop‐Wahrscheinlichkeit

Bestimme die Wahrscheinlichkeit TempP zunächst in Abhängigkeit von AvgLen wie folgt:

D.h. zwischen MinThresh und MaxThresh als Formel:

·

Zähle die Anzahl count der nicht verworfenen Pakete während AvgLen zwischen MinThresh und MaxThresh war und berechne:

1 ·

TempP 1.0

MaxP

MinThresh MaxThresh

AvgLen

(41)

TCP‐Varianten

(42)

TCP erlaubt Implementationsvarianten

• Send‐Policy

– Keine Festlegung wie lange und wieviel gepuffert wird, bevor ein Segment gesendet wird

– Abzuwägen ist: Response‐Zeit versus Overhead wegen Nachrichten‐Header

• Deliver‐Policy

– Keine Festlegung wie lange Segmente auf der Empfängerseite gepuffert werden, bevor diese an die Anwendung weiter gegeben werden

– Abzuwägen ist: Response‐Zeit versus Overhead wegen Processing in TCP‐

und User‐Software, sowie unnötige OS‐Interrupts

• Accept‐Policy

– Keine Festlegung, wie mit Out‐of‐Order Segmenten umzugehen ist – Zwei Optionen

• Verwerfe Out‐of‐Order‐Segmente

• Behalte alle Segmente, die in das Receive‐Fenster passen

– Abzuwägen ist: Aufwand für Puffer‐Verwaltung versus Netzlast

(43)

TCP erlaubt Implementationsvarianten

• Retransmit‐Policy

– Keine Festlegung, wann ein gepuffertes und noch nicht bestätigtes Segment nochmals übertragen wird

– Mögliche Strategien:

• First‐only: Ein Retransmit‐Timeout für das Segment am Anfang der Sende‐Queue (wenn Timeout stattfindet sende das erste Segment und setze den Timer erneut)

• Batch: Sende alle Segmente erneut sobald der Retransmit‐Timeout stattfindet

• Individuell: Ein Timer für jedes Segment in der Queue

– Abzuwägen ist:

• First‐only: geringe Netzlast aber größere Verzögerung

• Batch und Individuell: geringere Verzögerung bei höherer Netzlast

• Acknowledge‐Policy

– Keine Festlegung, wann genau ein einkommendes Segment bestätigt werden muss – Mögliche Strategien:

• Immediate: sende leeres Segment (d.h. ohne Daten) mit Acknowledgement

• Cummulative: Sammele Daten auf der Empfangsseite und sende Acknowledgement erst dann (allerdings: Persit‐Timer, um Acknowledgement nicht zu lange zu verzögern)

– Abzuwägen ist: Netzlast versus Verzögerung

• Zusammengefasst: im Rahmen der genannten Policies können TCP‐Varianten realisiert werden, die untereinander interoperabel sind.

(44)

Beispiele von TCP‐Varianten

TCP existiert/existierte in verschiedenen Varianten TCP Tahoe

Ursprüngliche TCP‐Implementierung des beschriebenen Congestion‐Control‐Mechanismus; mit Ausnahme des diskutierten Fast‐Recovery

TCP Reno

Unter anderem wurde Fast‐Recovery hinzugefügt TCP Vegas

Beobachtung der RTT auf den sendenden Knoten und proaktive Anpassung des CongestionWindows, um Congestion vorab zu vermeiden

(45)

Zusammenfassung und Literatur

Grundlagen der Rechnernetze ‐ Transportschicht 50

SS 2014

(46)

Zusammenfassung

• Die wichtigsten Internet‐Transportprotokolle

– UDP (keine Aufwertung des IP Best‐Effort‐Dienstes) – TCP (zuverlässiger Byte‐Strom über IP)

• Flusskontrolle und Überlastkontrolle

– Flusskontrolle findet Ende‐zu‐Ende statt – Überlastkontrolle betrifft das ganze Netz

• Eine weitere TCP‐Stärke: TCP erlaubt Erweiterungen; Hosts müssen sich einigen welche Erweiterungen genutzt werden sollen; Neue TCP‐Erweiterung erfordert damit nicht im

ganzen Internet TCP komplett neu zu installieren

• Die Unterscheidung zwischen Überlastkontrolle und

Überlastvermeidung

(47)

Literatur

[PetersonDavie2007] Larry L. Peterson and Bruce S. Davie, „Computer Networks: A Systems Approach“, Edition 4, 2007.

5.1 Simple Demultiplexer (UDP) 5.2.2 Segment Format

5.2.3 Connection Establishement and Termination 5.2.4 Sliding Window Revisited

5.2.5 Triggering Transmission 5.2.6 Adaptive Retransmission 5.2.7 Record Boundaries

5.2.8 TCP Extensions

6.3.1 Additive Increase/Multiplicative Decrease 6.3.2 Slow Start

6.3.3 Fast Retransmit and Fast Recovery 6.4.2 Random Early Detection (RED)

Grundlagen der Rechnernetze ‐ Transportschicht 52

SS 2014