• Transmission Control Protocol (TCP)

(1)

Grundlagen der Rechnernetze

Transportschicht

(2)

Übersicht

• Einfacher Demultiplexer (UDP)

• Transmission Control Protocol (TCP)

– Verbindungsauf‐ und abbau

– Flusskontrolle mittels Sliding‐Window‐Verfahren – Regulärer Duplexbetrieb inklusive Flusskontrolle – Adaptive Reübertragungen

– Erweiterungen – Überlastkontrolle

– Überlastvermeidung

– Implementationsvarianten

(3)

Einfacher Demultiplexer (UDP)

(4)

Demultiplexing aber sonst keine weitere Funktionalität über IP

UDP

Prozess 1 Prozess 2 Prozess 3

Ankommende Pakete Queues

Demultiplexing mittels

Portnummern Prozess

IP‐Paket

Quelle: 192.100.120.40 Ziel: 192.200.133.100 Daten: UDP‐Paket

Data

SrcPort DstPort Length Checksum

Sender‐Host Empfänger‐Host

Port‐Nummern sind 16 Bits lang.

Damit gibt es 2¹⁶ = 65536 unterschiedliche Ports.

Global eindeutige

Adresse eines Prozesses:

Prozess arbeitet blockierend die Queue per FiFo ab.

Nachrichten werden bei voller Queue verworfen.

(5)

und ggf. noch eine Checksumme

Fehlererkennung mittels Checksumme

[vgl. RFC 768 zu UDP und RFC 2460 zu IPv6]

• optional in IPv4 und verpflichtend in IPv6

• Gleicher Checksummenalgorithmus wie bei IP (Addition von 16‐Bit‐Worten mittels

Einerkomplementarithmetik)

• Eingabe ist der UDP‐Header und ein Pseudo‐Header Pseudo‐Header

• Source‐IP‐Adresse und Destination‐IP‐Adresse

• Protokollnummer (IPv4: protocol, IPv6: next header)

• plus UDP‐Längen‐Feld (UDP‐header und Daten) [damit wird UDP‐Längen‐Feld zwei mal addiert]

Pseudoheader ermöglicht einen einfachen Test, dass die Nachricht zwischen den richtigen End‐Punkten

ausgeliefert wurde.

[bei Änderung der IP‐Adresse währen der Auslieferung ist damit falsches Ziel ist erkennbar (sofern die

Checksumme nicht angepasst wurde)]

Data

source address destination address

zero protocol UDP length

source address

zero

destination address

Data

next h.

Pseudo Header unter IPv6 für Upper Layer Checksums Pseudo Header für UDP unter IPv4

upper layer packet length

(6)

Festlegung von Port‐Nummern

Gemäß RFC 6335 gibt es drei Kategorien von Portnummern

• 0 bis 1023 (System Ports) und 1024 bis 49151 (User Ports) – Zuweisung durch die Internet Assigned Numbers Authority (IANA, www.iana.org);

System und User Ports unterscheiden sich in der strenge der Registrierungsprozeduren

• 49152 bis 65 535 (Dynamic Ports) – können einfach von jedem Dienst ad hoc

verwendet werden. Ports werden zugewiesen, wenn eine Sitzung eingerichtet wird, und freigegeben, wenn die Sitzung endet.

Ports 0 bis 1023 (System Ports) umfassen die gängigen Protokolle und Diensten.

Zum Beispiel Port 21 für FTP File‐Server, Port 22 für SSH Remote Login, Port 25 für SMTP Mail‐Server, Port 53 für DNS Domain Name Server, Port 80 für HTTP Web‐Server, usw.

Ein bekannter Port aus der Kategorie 1024 bis 49151 (User Ports): Port 8080 WWW Caching Service.

Wo findet man vorab festgelegte Ports?

(7)

Festlegung von Port‐Nummern

Manchmal ist ein bekannter Port nur der Ausgangspunkt für die Kommunikation:

• Kontaktanfrage des Clients über bekannten Port

• nach dem ersten Kontakt wird ein privater Port für deren Session ausgemacht

• Der bekannte Port steht dann neuen Client‐Anfragen wieder zur Verfügung

Eine Frage bleibt noch: wo findest man im Falle von Dynamic Port den Port eines Dienstes?

Lösung: Port‐Mapper:

• ein festgelegter Port über den man den Port‐Mapper anspricht

• Client fragt erst den Port‐Mapper nach dem richtigen Port für einen bestimmten Dienst

• Der rückgegebene Port wird dann für die Kontaktierung des eigentlichen Services verwendet

Client Port‐Mapper

Server

Host 1 Host 2

(8)

Ergänzung : NAPT als Lösung für IPv4

Erinnerung: Network‐Address‐Translation (NAT): Lokalen Hosts werden temporär globale Adressen zugeordnet.

Problem: NAT‐Box braucht aber immer so viele IP‐Adressen, wie viele interne Hosts simultan auf das Internet zugreifen wollen.

Bessere Lösung: Network Address Port Translation (NAPT)

Lokales Netz

NAT‐Box

Verfügbare eindeutige globale Adressen:

171.69.210.246, ..., 171.69.210.252 Lokal eindeutige

Adresse:

10.0.1.5 H

IP‐Paket:

Quelle: 10.0.1.5

IP‐Paket:

Quelle: 171.69.210.246 Ins Internet

(9)

Ergänzung : NAPT als Lösung für IPv4

Damit: verwende nur eine globale IP‐Adresse (hier z.B. 203.0.113.1) und unterscheide die simultanen Zugriffe interner Hosts auf das Internet durch übergangsweisen Austausch der der Source‐Port‐Nummern.

Src IP: 192.168.1.2

Beispiel aus Fall/Stevens, TCP/IP Illustrated, Volume 1, Second Edition, The Protocols, S.305 Src Port: 23479

Src IP: 192.168.1.35 Src Port: 23479

Src IP: 192.168.17.4 Src Port: 34011

Src IP: 203.0.113.1 Src Port: 23479

Src IP: 203.0.113.2 Src Port: 23479

Src IP: 203.0.113.3 Src Port: 34011

NAT

Src IP: 203.0.113.1 Src Port: 23479

Src IP: 203.0.113.1 Src Port: 3000

Src IP: 203.0.113.1 Src Port: 34011

NAPT

Src IP: 192.168.1.2 Src Port: 23479

Src IP: 192.168.1.35 Src Port: 23479

Src IP: 192.168.17.4 Src Port: 34011

(10)

Transmission Control Protocol (TCP)

(11)

Ü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

(12)

Übersicht

Anwendungsprozess A

TCP Sende‐

puffer

Anwendungsprozess B

TCP Empfangs‐

puffer

…

lese

Bytes …

Segment Segment

… lese

Bytes

Empfangs‐

puffer

Sende‐

puffer

IP IP

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

(gleiche Diskussion wie bei UDP)

(13)

Segmentnummerierung und ACKs

Initiale Sequenznummer im Beispiel: 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:

4028

Sender Empfänger Daten (SequenceNum)

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

nächste erwartete Byte

• Sequenznummern zeigen (modulo maximale Sequenznummer 2³²) auf Byte‐Positionen im Byte‐Stream

• In der Regel ist das Acknowledgement Teil eines TCP‐Segmentes in die Rückrichtung

(14)

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 HdrLen 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

Advertised Window 16 128 Checksum Urgent Pointer (if URG set) 20

…

160

…

Options (if HdrLen > 5)

(Padded at end with 0‐Bytes if necessary)

Data

(15)

Transmission Control Protocol (TCP)

Verbindungsaufbau und ‐abbau

(16)

Übersicht

Herstellen eine TCP‐Verbindung

• Client (Anrufer) führ ein Active‐Open für einen Server durch

• Der Server muss zuvor ein passives Öffnen durchgeführt haben

• Die Verbindung wird dann über einen Dreiwege‐Handshake hergestellt

• (Bemerkung: das ist der Regelfall. TCP ermöglicht aber auch gleichzeitiges aktives Öffnen von beiden Seiten)

Erst nach erfolgreichem Ablauf des Verbindungsaufbau beginnen beide Seiten mit dem Senden von Daten.

Abbau einer TCP‐Verbindung

• Sobald ein Teilnehmer mit dem Senden von Daten fertig ist, schließt er eine Richtung der Verbindung

• TCP initiier damit eine Sequenz von Control‐Nachrichten

Der Verbindungsaufbau ist zwar (in der Regel) asymmetrisch, der Verbindungsabbau ist jedoch symmetrisch (jede Seite muss die Verbindung unabhängig schließen).

Es ist möglich, dass eine Seite die Verbindung schon beendet , was bedeutet, dass sie keine Daten mehr senden kann, während die andere Seite die andere Hälfte der

(17)

Dreiwege‐Handshake

Client (active open)

Server (passive open)

Data Checksum

HdrLen 0 Flags

Options (variabel)

UrgPtr

AdvertisedWindow Acknowledgement

SequenceNum

SrcPort DstPort

U R G

A C K

P S H

R S T

S Y N

F I N 0 4 10 16 31

Dreiwege‐Handshake generell: zwei Parteien wollen sich auf eine Reihe von Parametern einigen. Speziell bei TCP:

• Festlegen einer initialen zufälligen Sequenznummer für beide Kommunikationsrichtungen

• Diese wird jeweils bestätigt (Server‐>Client: SYN+ACK, Client‐>Server: ACK)

• Bestätigt wird das erste erwartete Byte an der Stelle Sequenznummer+1

• Bei Ausbleiben einer Bestätigung findet eine Reübertragung statt

(18)

Dreiwege‐Handshake

Client (active open)

Server (passive open)

Data Checksum

HdrLen 0 Flags

Options (variabel)

UrgPtr

AdvertisedWindow Acknowledgement

SequenceNum

SrcPort DstPort

U R G

A C K

P S H

R S T

S Y N

F I N 0 4 10 16 31

Warum nicht einfach am Anfang auf 0 setzen?

Der Grund dafür ist der Schutz vor verzögert eintreffenden Nachrichten einer alten Inkarnationen derselben Verbindung (SrcPort, SrcIPAddr, DstPort, DstIPAddr)

(19)

TCP‐Zustandsübergangsdiagramm

Verbindungsaufbau

Datenübertragungsphase

Verbindungsabbau

Bildquelle: en.wikipedia.org/wiki/Transmission_Control_Protocol

(20)

Typischer Ablauf

• Server im Listen‐State

• Client führt Active‐Open aus Darstellung als MSC:

Verbindungsaufbau im Detail

(21)

Drei mögliche Fälle:

1. Diese Seite beendet zuerst

2. Die andere Seite beendet zuerst 3. Beide Seiten beenden gleichzeitig Darstellung von Fall 1 als MSC:

Verbindungsabbau im Detail

(22)

Transmission Control Protocol (TCP)

Flusskontrolle mittels Sliding‐Window‐Verfahren

(23)

Sliding‐Window

Das Herzstück von TCP ist ein Sliding‐Window‐Verfahren.

Entscheidender Unterschied zu Sliding‐Window‐Verfahren auf der

Verbindungsebene: bei TCP läuft dieses Ende‐zu‐Ende über das Internet und nicht über eine physische Punkt‐zu‐Punkt‐Verbindung. Hieraus ergeben sich die folgenden Konsequenzen:

•

Es braucht einen expliziten Mechanismus zum Verbindungsaufbau

•

Round‐Trip Zeiten sind sehr variabel (z.B. im Spektrum von wenigen ms bis mehrere 100 ms)

•

Pakete können in unterschiedlicher Reihenfolge am Empfänger ankommen;

d.h. wesentlich ältere Pakete können plötzlich auftauchen (konservative Schätzung maximale Lebenszeit (maximum segment lifetime MSL) eines IP‐

Paketes: 120 Sekunden)

•

das Verfahren muss ein breites Spektrum an Rechen‐ und Speicherkapazitäten erlauben

•

das Delay‐Bandbreitenprodukt ist sehr variabel

•

die verfügbaren Ressourcen im Netz sind nicht bekannt

(24)

Sende‐ und Empfangspuffer

Sendende Anwendung

TCP

LastByteAcked

LastByteWritten

LastByteSent

… …

Empfangende Anwendung

TCP

NextByteExpected

LastByteRead

LastByteRcvd

… …

Sendepuffer

noch nicht bestätigte gesendete Daten und neue zu sendende Daten der darüber

liegenden Schicht

Empfangspuffer

schon empfangene Daten (unter Umständen mit fehlenden Datenabschnitten), die noch nicht von der darüber liegenden Schicht gelesen wurden

(25)

Zusammenhang der einzelnen Pointer

Sendende Anwendung

TCP

LastByteAcked

LastByteWritten

LastByteSent

… …

TCP

NextByteExpected

LastByteRead

LastByteRcvd

… …

Sendepuffer

• LastByteAcked <= LastByteSent

• LastByteSent <= LastByteWritten

Empfangspuffer

• LastByteRead < NextByteExpected

• NextByteExpected <= LastByteRcvd+1 NextByteExpected zeigt auf das erste noch nicht empfange Byte. Alle vorigen Bytes wurden vollständig empfangen.

Achtung: wir ignorieren hier Wraparound der Pointer aufgrund von endlicher Bitanzahl zur Speicherung von Segmentnummern (32 Bit).

(26)

Größe des Sende‐ und Empfangspuffer

Sendende Anwendung

TCP

LastByteAcked

LastByteWritten

LastByteSent

… …

TCP

NextByteExpected

LastByteRead

LastByteRcvd

… …

Sendepuffer

verwendeter Pufferspeicher =

LastByteWritten ‐ LastByteAcked Diese Größe muss immer kleiner gleich MaxSendBuffer sein.

Empfangspuffer

verwendeter Pufferspeicher = LastByteRcvd ‐ LastByteRead

Diese Größe muss immer kleiner gleich MaxRcvBuffer sein.

(27)

Definition des AdvertisedWindow

Sendende Anwendung

TCP

LastByteAcked

LastByteWritten

LastByteSent

… …

TCP

NextByteExpected

LastByteRead

LastByteRcvd

… …

Empfänger teilt dem Sender seine festgelegte Größe des Empfangspuffers durch das AdvertisedWindow mit. Dies legt die maximale erlaubte Anzahl weiteren noch

versendbaren noch nicht bestätigten Bytes fest.

Auf Empfängerseite muss immer gelten: LastByteRcvd ‐ LastByteRead <= MaxRcvBuffer Das AdvertisedWindow wird demnach wie folgt festgelegt:

AdvertisedWindow = MaxRcvBuffer ‐ ((NextByteExpected ‐ 1) ‐ LastByteRead)

(28)

Definition des EffectiveWindow

Sendende Anwendung

TCP

LastByteAcked

LastByteWritten

LastByteSent

… …

TCP

NextByteExpected

LastByteRead

LastByteRcvd

… …

Auf der Senderseite muss immer sicher gestellt sein:

LastByteSent ‐ LastByteAcked <= AdvertisedWindow

Das EffectiveWindow, d.h. die Anzahl an noch versebaren Bytes, ist dann wir folgt:

EffectiveWindow = AdvertisedWindow ‐ (LastByteSent ‐ LastByteAcked)

(29)

Data

Mitteilen des AdvertisedWindow

Ist Bestandteil eines TCP‐Segments des Empfängers an den Sender.

Beachte: TCP ist duplex.

TCP verfolgt den Ansatz Smart Sender / Dumb Receiver

Empfänger sendet kein dediziertes Segment, um die aktuelle Größe des AdvertisedWindow mitzuteilen.

Checksum

HdrLen 0 Flags

Options (variabel)

UrgPtr

AdvertisedWindow Acknowledgement

SequenceNum

SrcPort DstPort

0 4 10 16 31

(30)

Vermeiden eines Deadlocks

AdvertisedWindow=0

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

Empfänger Sender

Sender sendet ab hier nicht weiter

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

AdvertisedWindow=0

Empfangspuffer wird geleert und Annahme der 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 (ca. alle 5 bis 60 sekunden)

(31)

Transmission Control Protocol (TCP)

Regulärer Duplexbetrieb inklusive Flusskontrolle

(32)

Regulärer Duplexbetrieb

AdvWnd=1024, AckedSeqNr=3463

Gerät 1 Gerät 2

AdvWnd=4020, AckedSeqNr=42783

usw.

(33)

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?

(34)

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.

Noch schlimmer: ohne weitere Vorkehrungen verweilen solche einmal eingeführten kleinen Segmente beliebig lang im Nachrichtenfluss der Fluss‐Kontrolle; das sogenannte Silly‐Window‐Syndrom.

(35)

Silly‐Window‐Syndrom

Angenommen der Sender versendet mit jedem bestätigten Segment unmittelbar wieder ein Segment.

So gesehen kann man den Nachrichtenfluss wie ein Förderband sehen. Segmente sind volle Container vom Sender zum Empfänger. Acknowledgements sind die leeren Container vom Empfänger zurück.

(a) Wenn immer maximale MSS gesendet werden kann und der Empfänger immer die volle MSS bestätigen kann, dann sind immer Container maximaler Größe einer MSS unterwegs (ist Effizient).

(b) Sobald einmal ein Container mit Größe s < MSS eingeführt ist, wird dieser das AdvertisedWindow bei seinem Acknowledgement um s weiter rücken und damit (vorausgesetzt der Sender hat alle bisher versendbaren Bytes gesendet) den Sender wieder zum versenden eines Container mit Größe s veranlassen.

Bildquelle: Peterson/Davie, Computer Networks: A Systems Approach, 2019, Online Version 6.2‐dev, Figure 133

(36)

Behandlung auf der Empfängerseite?

Silly‐Window‐Syndrom ist nur dann ein Problem, wenn entweder der Sender ein kleines Segment sendet oder der Empfänger das Fenster um einen kleinen Betrag öffnet.

Wenn beides nicht passiert, wird ein kleiner Container niemals in den Stream eingeführt.

Es ist nicht möglich, das Senden kleiner Segmente zu verbieten. Beispielsweise kann die Anwendung nach dem Senden eines einzelnen Bytes einen Push ausführen.

Es ist jedoch möglich, den Empfänger daran zu hindern, einen kleinen Container wieder zurückzusenden.

Die Regel ist, dass der Empfänger nach seinem AdvertisedWindow=0 ein neues AdvertisedWindow erst dann mitteilet, wenn dieses mindestens MSS groß ist.

Jedoch sind kleine Container im Strom nicht ausgeschlossen. Es benötigt einen

Mechanismus, um diese zusammenzuführen. Der Empfänger kann dies tun, indem er ACKs verzögert (d.h. ein kombiniertes ACK anstelle mehrerer kleinerer).

Dies ist jedoch nur eine Teillösung, da der Empfänger nicht wissen kann, wie lange es für die Anwendung sinnvoll ist, zu warten bis ein weiteres Segment eintrifft oder bis die Anwendung Daten konsumiert und damit das Sendefenster wieder weiter öffnet.

(37)

Behandlung auf der Senderseite!

Wenn Daten gesendet werden müssen, das Fenster jedoch weniger als MSS geöffnet ist, möchten wir möglicherweise einige Zeit warten, bevor wir die verfügbaren Daten senden.

Die Frage ist jedoch, wie lange?

Wenn wir zu lange warten, verletzen wir interaktive Anwendungen wie Telnet. Wenn wir nicht lange genug warten, riskieren wir, ein paar winzige Pakete zu verschicken und

triggern damit das Silly‐Window‐Syndrom.

Die Antwort besteht darin, einen Timer einzuführen und zu senden, wenn der Timer abläuft.

Dies ist bei TCP kein Timer im Sinne einer festen Zeit, sondern ACK wird als Trigger genutzt.

Diese Vorgehensweise nennt man Self‐Clocking.

(38)

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

Bemerkung: Für besonders zeitkritische Anwendungen lässt sich aber Nagel‘s Algoritmus abschalten (setze TCP_NODELAY). Dann wird immer sofort gesendet.

(39)

Transmission Control Protocol (TCP)

Adaptive Reübertragungen

(40)

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? RFC 675: Specification of Internet Transmission

(41)

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:

(42)

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.

(43)

Ermitteln der RTT

Warum lautet dieser gleitende Mittelwert eigentlich exponentiell gewichtet?

Expandieren liefert:

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

(44)

Problem: Zuordnung von ACKs

Sender Empfänger Sender Empfänger

SampleRTT

zu lang SampleRTT

zu kurz

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

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

Timeout = 2*Timeout (Exponential Backoff)

(45)

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. Ein Teil des Jacobson/Karels‐Algorithmus (Änderung von TCP 1988 hinsichtlich Überlast im Netz; Diskussion folgt; hier nur der

Timeoutmechanismus): schätze die folgende mittlere Abweichung:

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

(46)

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.

(47)

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)

(48)

Transmission Control Protocol (TCP)

Erweiterungen

(49)

Diskussion/Motivation

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 OC‐192 (10 Gbps) 3 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 OC‐192 (10 Gbps) 118,4 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...

(50)

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

(51)

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

… …

(52)

Transmission Control Protocol (TCP)

Überlastkontrolle

(53)

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: ...

(54)

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:

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

(55)

Additive‐Increase‐Beispiel

Source Destination

RTT

Erhöhe um eine MSS

...

... ...

Inkrement pro RTT:

Inkrement pro ACK?

Sei c die alte Länge des

CongestionWindow. Nach

einem RTT‐Durchlauf ist:

(56)

Ein typisches AIMD‐Muster

CongestionWindow‐Größe

Zeit

(57)

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?

Warum heißt das eigentlich Slow‐Start?

Historischer Grund: In TCP‐Anfängen wurde zum Starten direkt mit dem gesamten Flow‐Control‐

Window (d.h. beliebig großem

CongestionWindow) gestartet.

(58)

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

•

CongestionThreshold ist erst mal auf das Flow‐Control‐Window gesetzt Wenn ein Timeout stattgefunden hat

•

CongestionThreshold = CongestionWindow/2 (man merkt sich also das 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

(59)

Ein Beispiel

Bildquelle: Andrew S. Tanenbaum, „Computer Networks“, Fourth Edition, 2003

(60)

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 kumulativ (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.

(61)

Die TCP‐Variante mit Fast‐Recovery

• Slow‐Start, wenn die TCP‐Verbindung neu aufgebaut wurde oder ein gewöhnlicher Timeout stattgefunden hat.

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

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

(62)

Transmission Control Protocol (TCP)

Überlastvermeidung

(63)

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.

Mögliche Optionen

•

Aktives Queue‐Management auf den Routern (active queue management AQM): erfordert Anpassung von Routern

•

Ohne notwendige Veränderung einer TCP‐Implementation

•

Erweiterung von TCP mit einem Signalisierungsmechanismus

•

Quellbasierte Lösung: erfordert keine Anpassung von Routern aber erfordert

bestimmte TCP Variante

Beispiel zur quellbasierten Lösung:

•

TCP Vegas: beobachten der Varianz der RTT als Hinweis auf Überlast

(64)

AQM mittels RED (Random‐Early‐Detection)

Beispiel für Aktives Queue‐Management auf den Routern Ohne notwendige

Veränderung einer TCP‐Implementation

Idee:

Router „gaukeln“ durch zufällig verworfene IP‐Pakete vorzeitig

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

(65)

RED: Zufälliges Verwerfen von Paketen

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

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

(66)

RED: 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:

TempP 1.0

MaxP

MinThresh MaxThresh

AvgLen

(67)

AQM mittels DECbit bzw. ECE

Beispiel für aktives Queue‐Management inklusive Erweiterung von TCP mit einem Signalisierungsmechanismus

DECbit: Zusammenspiel von IP und TCP; Router setzen bei mittlerer Queue‐Länge größer 1 ein Bit im Paket‐Header. Dieses Bit wird dem Sender über ACK des Empfängers übermittelt.

Wenn mehr als die Hälfte eines Congestion‐Windows an Paketen dieses Flag gesetzt haben, reduziere das Window exponentiell, ansonsten erhöhe linear.

ECE (Explicit Congestion Notification):

• vergleichbares Prinzip wie mit DECbit; definiert den Rahmen, wie Hosts und Router kommunizieren.

• Zwei Bits im TOS‐Feld von IP‐Header:

ECT = ECN‐Capable‐Transport (gesetzt durch Quelle), CE = Congestion Encountered (gesetzt durch Router)

• Zwei weitere optionale Flags im TCP‐Header:

ECE = ECN‐Echo (Empfänger signalisiert Quelle, dass Paket mit CE‐Flag empfangen wurde)

CWR = Congestion Window Reduced (Quelle signalisiert Empfänger, dass dieser sein Congestion‐Window verkleinert hat)

(68)

Transmission Control Protocol (TCP)

TCP Varianten

(69)

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

(70)

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

(71)

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

(72)

Zusammenfassung und Literatur

(73)

Zusammenfassung

• Die wichtigsten Internet‐Transportprotokolle

–

UDP (keine Aufwertung des IP Best‐Effort‐Dienstes)

–

TCP (zuverlässiger Byte‐Strom über IP)

• Adressierung auf dieser Ebene: Port‐Mechanismus

• Flusskontrolle und Überlastkontrolle

–

Flusskontrolle findet Ende‐zu‐Ende statt

–

Überlastkontrolle betrifft das ganze Netz

• Design‐Merkmale

–

Ende‐zu‐Ende‐Argument: realisiere Funktion auf der Schicht, in der diese komplett implementierbar ist

–

TCP funktioniert nach dem Smart‐Sender/Dumb‐Receiver‐Prinzip

• 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

(74)