Tafelanschrieb
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
Regulärer Duplexbetrieb
AdvWnd=1024, AckedSeqNr=3463
Gerät 1 Gerät 2
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
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?
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?
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.)
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?
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:
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.
Ermitteln der RTT
Warum lautet dieser gleitende Mittelwert eigentlich exponentiell gewichtet? Expandieren liefert:
Also z.B. für alpha=0,8:
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)
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.
Einbeziehen der Varianz
Einfache Stichprobenvarianz lässt sich wie folgt berechnen:
Analog zur mittleren RTT lassen sich hierbei ebenfalls durch exponentiell gleitenden Mittelwert neuere Varianzwerte höher gewichten als ältere.
Einbeziehen der Varianz
Die komplette Berechnung nach Jacobson/Karels‐Algorithmus ist dann wie folgt:
Hierbei ist nach der Originalveröffentlichung von Jacobson:
g = 1/8 = 0,125 h = 1/4 = 0,25
f = 2 (bzw. später auch f=4 korrigiert)
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...
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
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
… …
