Grundlagen der Rechnernetze

(1)

Grundlagen der Rechnernetze

Transportschicht

(2)

Übersicht

• Einfacher Demultiplexer (UDP)

• Zuverlässiger Byte‐Stream (TCP) Zuverlässiger Byte Stream (TCP)

• TCP‐Überlastkontrolle

• TCP‐Überlastvermeidung

• TCP Varianten

• TCP‐Varianten

2 Grundlagen der Rechnernetze ‐Transportschicht

SS 2012

(3)

Einfacher Demultiplexer (UDP)

(4)

Demultiplexing aber sonst keine weitere Funktionalität über IP

S d H t E fä H t

Prozess 1 Prozess 2 Prozess 3 Prozess

Sender‐Host Empfänger‐Host

Queues IP Paket

Demultiplexing itt l

IP‐Paket

Quelle: 192.100.120.40 Ziel: 192.200.133.100 D t UDP P k t

UDP

Ankommende mittels

Portnummern Daten: UDP‐Paket

SrcPort DstPort Length Checksum

Port‐Nummern sind 16 Bits lang.

Damit gibt es 2¹⁶ = 65536 t hi dli h P t Ankommende

Pakete Data

unterschiedliche Ports.

Global eindeutige

Adresse eines Prozesses:

SS 2012 Grundlagen der Rechnernetze ‐Transportschicht 4

<Port,Host>

(5)

Woher erfährt der Sender die Port‐Nummer des Empfängers?

Möglichkeit 1: vorab festgelegte Port Nummern Möglichkeit 1: vorab festgelegte Port‐Nummern.

• Zum Beispiel Port 53 für DNS, Port 25 für Mail‐Server oder Port 517 für Unix‐

Talk‐Programm

l d i i i di h k li i

• Festgelegte Portnummern werden in einem RFC periodisch aktualisiert

• Unter vielen Unix‐Systemen findet man die festen Portnummern auch unter /etc/services

Möglichkeit 2: Port‐Mapper

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

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

• 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

S i d t

Services verwendet

Bemerkung: häufig werden nach dem ersten Kontakt zwischen Client und Server ein privater Port für deren Session ausgemacht.

ein privater Port für deren Session ausgemacht.

Client Port‐Mapper

Host 1 Client Host 2

Host 1

(6)

Zuverlässiger Byte‐Stream (TCP)

(7)

TCP‐Features

Im Gegensatz zu UDP:

• Zuverlässige Auslieferung

• eines Full‐Duplex

• Byte‐Streams in

• korrekter Reihenfolge

• korrekter Reihenfolge Darüber hinaus:

• Flusskontrolle (vermeidet, dass Sender den Empfänger überlastet)

• Lastkontrolle (Vermeidet, dass Sender zuviel Last im Netz erzeugt)

Das einzige identische zu UDP:

• Port‐Mechanismus

(8)

TCP‐Segmente

Prozess Prozess SrcPort DstPort

SequenceNum

0 4 10 16 31

…schreibe Bytes

lese Bytes

… Acknowledgment

HdrLen

Checksum

0 Flags AdvertisedWindow

UrgPtr TCP

Sendepuffer

TCP

Empfangspuffer

Options (variable)

Segment … Segment sende Segmente

Data

g

Daten (SequenceNum)

Fl

Sender Empfänger

Flags:

SYN, FIN, RESET, PUSH, URG, ACK

Acknowledgment + AdvertisedWindow

(9)

TCP Verbindungsherstellung und ‐terminierung

CLOSED CLOSED CLOSED

Passive open Close

Close

Active open/SYN CLOSED

Passive open Close

Close

Active open/SYN

LISTEN

Send/SYN SYN/SYN + ACK

LISTEN

SYN_RCVD SYN_SENT

SYN + ACK/ACK SYN/SYN + ACK

ACK

SYN_RCVD SYN_SENT

SYN + ACK/ACK SYN/SYN + ACK

ACK

ESTABLISHED Close/FIN ESTABLISHED Close/FIN

CLOSE_WAIT FIN_WAIT_1

FIN/ACK Close/FIN

FIN/ACK ACK

ACK + Close/FIN

CLOSE_WAIT FIN_WAIT_1

FIN/ACK Close/FIN

FIN/ACK ACK

ACK + Close/FIN

LAST_ACK CLOSING

FIN_WAIT_2

+ FIN /ACK

Timeout after two segment lifetimes FIN/ACK

ACK ACK

LAST_ACK CLOSING

FIN_WAIT_2

+ FIN /ACK

Timeout after two segment lifetimes FIN/ACK

ACK ACK

(10)

Tafelanschrieb

(11)

TCP Sliding‐Window‐Protokoll

Sendende Empfangende

Sendende Anwendung

Empfangende Anwendung

LastByteWritten TCP TCP

LastByteRead

… … … …

LastByteAcked LastByteSent

Sendepuffer

NextByteExpected LastByteRcvd

Empfangspuffer

p p g p

MaxSendBuffer = Größe des Sendepuffers MaxRcvBuffer = Größe des Empfangspuffers

(12)

Tafelanschrieb

(13)

Der Fall AdvertisedWindow = 0

AdvertisedWindow=0

Empfänger Sender

AdvertisedWindow=0

Empfänger Sender

AdvertisedWindow=0

Empfangspuffer

i d l Annahme: Sender

AdvertisedWindow=0

Empfangspuffer

i d l Segment der Länge 1

wird geleert und Empfänger sendet nichts an den Sender

sendet ab hier nicht weiter

wird geleert und Empfänger sendet nichts an den Sender

Segment der Länge 1

Ad ti dWi d 0 Probing mit

zurück. zurück. AdvertisedWindow=0

Probing mit Segment der Länge 1

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

Empfängerpuffer

ist?!? AdvertisedWindow=1200

(14)

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

Versende Segment auf jeden Fall sobald

• mindestens MSS viele neue Bytes vorliegen oder

• der sendende Prozess explizit darum bittet (push)p (p )

Was sonst? Warum nicht aggressiv immer sofort senden?

(15)

Sofortiges Senden bedeutet unnötiger Overhead

Sender Empfänger

Sendepuffer leer 2 Bytes erzeugty g 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 Besser wäre es doch zu warten, bis der Puffer wieder gut gefüllt ist. Wie lange

(16)

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

sende volles Segment else

if nicht-Acked Data unterwegs theng

puffere die Daten bis Ack ankommt else

sende alle neuen Daten jetzt endif

endif endif

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

( g g g

clocking.)

(17)

Reübertragung bei TCP der ersten Stunde

TCP‐Sender TCP‐Empfänger

S t

Segment

*

Wie lange warten, bis das Segment

reübertragen wird?

Erste TCP‐

Implementierungen

verwenden das zweifache der RTT.

Woher kennt man die RTT?

(18)

Ermitteln der RTT

Wie misst man die RTT (hier bezeichnet als SampleRTT)?

Verwendeter RTT ergibt sich als gleitender Mittelwert über die einzelnen Samples:p

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

(19)

Problem: Zuordnung von ACKs

Sender Empfänger Sender Empfänger

SampleRTT

zu lang SampleRTT

zu kurz

K /P t id Al ith I i i f h di S t di üb t d

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)

(20)

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: Betrachte SampleRTT wie vorhin und berechne:go t us et ac te Sa p e e o u d be ec e

 ist hierbei zwischen 0 und 1, =1 und  = 4 typischerweise

(21)

Diskussion

Bandbreite Zeit bis Sequenz‐

nummern verbraucht sind

Bandbreite Delay‐Bandbreiten‐

Produkt für

beispielsweise 100 T1 (1,5 Mbps) 6,4 Stunden

Ethernet (10 Mbps) 57 Minuten

ms RTT T1 (1,5 Mbps) 18 KB Ethernet (10 Mbps) 122 KB T3 (45 Mbps) 13 Minuten

Fast Ethernet (100 Mbps) 6 Minuten OC‐3 (155 Mbps) 4 Minuten

Ethernet (10 Mbps) 122 KB

T3 (45 Mbps) 549 KB

Fast Ethernet (100 Mbps) 1,2 MB OC 3 (155 Mbps) 4 Minuten

OC‐12 (622 Mbps) 55 Sekunden OC‐48 (2,5 Gbps) 14 Sekunden

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

Das Sendefenster erlaubt mit 16‐Bit‐

AdvertisedWindow Werten dass maximal problematisch werden, wenn der Delay

und Bandbreite groß sind. Alte Segmente interferieren mit aktuellen.

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

Bandbreite kaum genutzt Bandbreite kaum genutzt.

(22)

TCP‐Erweiterungen

32‐Bit‐Timestamp

• Speichere Sendezeit in Segment

• Wiederhole die Zeit im ACK ^SrcPort ^DstPort

0 4 10 16 31

• Wiederhole die Zeit im ACK

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

lt Di i d i N t i h t“

SequenceNum Acknowledgment

HdrLen

h k

verwalten. Die sind „im Netz gespeichert“.

32‐Bit‐Sequenznummern: Lösung der

Checksum

Options (variable)

UrgPtr

vorhin beschriebenen kurzen Wrap‐

around‐Zeiten

• Verwende oben beschriebenen

Data

Timestamp

• Segmente mit gleichen

SequenceNum‐Werten sind anhand

Erinnerung: TCP‐Header q

des Timestamp unterscheidbar

(23)

TCP‐Erweiterungen

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

Window

• Lösung der vorhin beschriebenen

SrcPort DstPort

SequenceNum

0 4 10 16 31

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

Bandbreitenprodukt

Ad ti dWi d W t i d it

SequenceNum Acknowledgment

HdrLen

Checksum

UrgPtr

• AdvertisedWindow‐Wert wird mit dem Scaling‐Factor multipliziert

Checksum

Options (variable)

UrgPtr

Selective‐ACK (SACK)

• Verbesserung des kummulativen ACK von TCP.

Data

• Neben dem gewöhnlichen

Acknowledgement speichert das

Optionale Feld zusätzliche p LastByteRead Acknowledgements für die nicht

aufeinander folgenden Segmente

• Sender braucht nur noch die Lücken

… …

Sender braucht nur noch die Lücken

(24)

TCP‐Überlastkontrolle

(25)

Motivation

Bisher haben wir die Flusskontrolle besprochen:

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

zu vermeiden.

Wir interessieren uns nun für die Überlastkontrolle:

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

Die TCP Flusskontrolle verwendet (wie schon gezeigt) das Die TCP‐Flusskontrolle verwendet (wie schon gezeigt) das

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

• Versenden von weiteren Bytes verkleinert das EffectiveWindow

• Empfang von Acknowledgements vergrößert das Window wieder

Das EffectiveWindow kann auch für die Überlastkontrolle

(26)

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):/ p ( )

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

(27)

Additive‐Increase‐Beispiel

Source Destination

Inkrement pro RTT:

RTT Erhöhe um

eine MSS

Inkrement pro ACK?

RTT Erhöhe um

eine MSS

RTT Erhöhe um

eine MSS

Sei c die alte Länge des CongestionWindow Nach

...

... ...

CongestionWindow. Nach

einem RTT‐Durchlauf ist:

(28)

Ein typisches AIMD‐Muster

‐GrößenWindow‐ongestionCo

Zeit

(29)

Slow‐Start

S D ti ti

RTT

Source Destination

Starte mit einem CongestionWindow der Länge MSS.

RTT

Erhöhe CongestionWindow um eine MSS pro ACK.

Somit wird das CongestionWindow pro RTT RTT

wie weit erhöht?

RTT

.. ..

Warum heißt das eigentlich Slow‐Start?

.. ..

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

C ti Wi d t t t

CongestionWindow gestartet.

(30)

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 Schwellwert (CongestionThreshold) überschritten wurde Wenn ein Timeout stattgefunden hatg

• 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

• Beginne Slow‐Start

• Wechsele in AdditiveIncrease sobald der Schwellwert CongestionThreshold überschritten wurde

g

(31)

Ein Beispiel

(32)

Fast‐Retransmit

S d E fä

Sender Empfänger

Paket 1 Paket 2 Paket 3

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

* ^ACK 1

ACK 2 ACK 2 Paket 4

ständig zusammenhängende Se‐

quenz von Segmenten)

ACK 2 Paket 5

Paket 6

Verlorene Sequenz führt zu

„duplicate ACKs“.

ACK 2 ACK 2

„ p

Fast‐Recovery: Warte nicht auf

Paket 3

(retransmit)

Timeout, sondern reübertrage ein Segment, nach drei aufeinander folgenden Duplicate ACKs

ACK 6

folgenden Duplicate‐ACKs.

(33)

Die TCP‐Variante mit Fast‐Recovery

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

• Bei Timeout lediglich CongestionWindoe wie üblich halbieren.

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

(34)

TCP‐Überlastvermeidung

(35)

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 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.g g Q

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

durch ein neues Protokoll ersetzen.

Idee: Router „gaukeln“ vorzeitig übergelaufene Queues vor, sodass die TCP‐Quellknoten auch vorzeitig die Last reduzieren und somit Q g

(36)

Random‐Early‐Detection (RED)

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

if AvgLen <= MinThreshold

speichere Paket in der Q e e speichere Paket in der Queue else if AvgLen < MaxThreshold

berechne Wahrscheinlichkeit p

verwerfe das Paket mit der Wahrscheinlichkeit p else

verwerfe das Paket immer

(37)

Berechnung der Drop‐Wahrscheinlichkeit

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

1.0 MaxP

MinThresh MaxThresh

AvgLen

D.h. zwischen MinThresh und MaxThresh als Formel:

MinThresh MaxThresh

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

(38)

TCP‐Varianten

(39)

TCP‐Varianten

TCP existiert/existierte in verschiedenen Varianten TCP Tahoe

Ursprüngliche TCP‐Implementierung des beschriebenen Congestion Control Mechanismus; mit Ausnahme des 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 Beobachtung der RTT auf den sendenden Knoten und proaktive Anpassung des CongestionWindows, um Congestion vorab zu vermeiden

(40)

Zusammenfassung und Literatur

Grundlagen der Rechnernetze ‐Transportschicht 40

SS 2012

(41)

Zusammenfassung

i i h i k ll

• Die wichtigsten Internet‐Transportprotokolle

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

• 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 – Ende‐zu‐Ende‐Argument: realisiere Funktion auf der Schicht, in der

diese komplett implementierbar ist

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

Ei i TCP S ä k TCP l b E i H

• 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 g g Internet TCP komplett neu zu installieren

• Die Unterscheidung zwischen Überlastkontrolle und Überlastvermeidung

Überlastvermeidung

(42)

Literatur

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

5 1 Si l D lti l (UDP) 5.1 Simple Demultiplexer (UDP) 5.2.2 Segment Format

5.2.3 Connection Establishement and Termination 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 E t i 5.2.8 TCP Extensions

6.3.1 Additive Increase/Multiplicative Decrease 6.3.2 Slow Start

6.3.2 Slow Start

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

Grundlagen der Rechnernetze ‐Transportschicht 42

SS 2012