heinz nixdorf institut universität paderborn eim institut für informatik 1 algorithm. grundlagen...

HEINZ NIXDORF INSTITUTUniversität Paderborn

EIM ‒ Institut für Informatik

1Algorithm. Grundlagen des Internets26. Mai 2003

Christian Schindelhauer

Vorlesung Sommersemester 2003

Algorithmische Grundlagen des Internets

VChristian Schindelhauer

[email protected]


Fakultät für Elektrotechnik, Informatik und MathematikInstitut für Informatik

AG Theoretische InformatikAlgorithmen, Komplexitätstheorie, Paralleles Rechnen





Einordnung von TCP/IP

Anwendung

Transport

Netzwerk

Link

TCP, UDP

IP (+ICMP, +IGMP)

Gerätetreiber (z.B. Ethernet, Token Ring)

z.B. Telnet, FTP, HTTP, Email





Zusammenspiel von TCP und IP





Anwendungsschicht

o Anwendungen (z.B WWW, E-Mail, Telnet, FTP) erzeugen Kommunikationsverbindungen zwischen zwei Rechnern im Netzwerk

o Anforderungen an Kommunikation:

Verbindungen sind bidirektional (oftmals Client-Server)

Datenmenge kann variieren

Die gegenläufigen Datenströme sind meist abhängig

Fehlerfreie Übermittlung der Datenströme wird vorausgesetzt

Kein Abbruch bei Verbindungspausen

o Kommunikation wird auf Transportschicht delegiert





Transportschicht

o TCP (transmission control protocol) Erzeugt zuverlässigen Datenfluß zwischen zwei Rechnern Unterteilt Datenströme aus Anwendungsschicht in Pakete Gegenseite schickt Empfangsbestätigungen

(Acknowledgments)

o UDP (user datagram protocol) Einfacher unzuverlässiger Dienst zum Versand von

einzelnen Päckchen Wandelt Eingabe in ein Datagramm um Anwendungsschicht bestimmt Paketgröße

o Versand durch Netzwerkschicht

o Kein Routing: End-to-End-Protokolle





Netzwerkschicht (I)

o IP (Internet Protocol) + Hilfsprotokolle ICMP (Internet Control Management Protocol) IGMP (Internet Group Management Protocol) Ermöglicht Verbund von (lokalen) Netzwerken

IP ist ein unzuverlässiger verbindungsloser Datagrammauslieferungsdienst

o Datagramm besteht aus Anwendungsdaten und Header:

• Absender, Zieladresse

• TOS-Feld (type of service)

• TTL-Feld (time to live)

• ... (z.B. Paketlänge, Checksum für Header)





Netzwerkschicht (II)

o IP ist ein Datagrammauslieferungsdienst Soweit möglich direkte Übergabe von Sender zu Empfänger Sonst: Hop-Routing über Router

o IP ist unzuverlässig Fehlerbehandlung:

• Falls Problem beim Routing: - Lösche Datagramm- Schicke Fehlermeldung durch ICMP an Absender

• Falls Problem beim Routing von ICMP-Fehlermeldung- Lösche Fehlermeldungspaket

Keine Redundanz vorgesehen TTL-Feld begrenzt Anzahl der Hops eines Datagramms





TCP ist ..

… ein verbindungsorientierter, zuverlässiger Dienst für bidirektionale Byteströme

o Verbindungsorientiert Zwei Parteien identifiziert durch Socketpaar: IP-Adresse und Port Kein Broadcast oder Multicast Verbindungsaufbau und Ende notwendig, d.h. Verbindung aktiv, bis (ordentlich)

beendet

o Zuverlässig Jedes Datenpaket wird bestätigt (acknowledgment) Erneutes Senden von unbestätigten Datenpakete Checksum für TCP-Header und Daten TCP nummeriert Pakete und sortiert beim Empfänger

o Bidirektionale Byteströme Zwei gegenläufige Datenströme aus einzelnen Bytes Möglichst zeitnahe Auslieferung jedes einzelnen Datenbytes, aber Zeitverhalten

der Datenfolgen kann verändert werden Versucht Übertragungsmedium effizient und fair zu nutzen durch Anpassung der

Datenrate





TCP-Header

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Source Port | Destination Port |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Sequence Number |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Acknowledgment Number |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Data | |U|A|P|R|S|F| || Offset| Reserved |R|C|S|S|Y|I| Window || | |G|K|H|T|N|N| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Checksum | Urgent Pointer |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Options | Padding |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

o Absender-Port + Ziel-Port-Nr. IP-Adresse in IP-Header

o Sequenznummer

= Nummer des ersten Bytes im Segment

o Bestätigungsnummer

Aktiviert durch ACK-Flag

Nummer des nächsten noch nicht bearbeiteten Datenbytes

= letzte Sequenznummer + letzte Datenmenge





Bestätigungen

o Huckepack-Technik Bestätigungen „reiten“ auf den

Datenpaket der Gegenrichtung

o Eine Bestätigungssegment kann viele Segmente bestätigen Liegen keine Daten an, werden

Acks verzögert „Das“ Seq.nr. 154

„ist“ Seq.nr. 157

„es“ Seq.nr. 160

ACK: 162

„World“ Seq.nr. 23

„bla bla“ Seq.nr. 91

ACK: 91+7=98

„Hello!“ Seq.nr. 17

ACK: 17+6=23

Algorithmus von NagleKleine Pakete werden nicht versendet, solange Bestätigungen noch

aussteheno Selbsttaktend: Schnelle Verbindung = viele kleine Paketeo Paket ist klein, wenn Datenlänge < Maximale Segmentgröße





Exponentielles Zurückweichen

o Retransmission Timout (RTO) regelt Zeitraum zwischen Senden von Datenduplikaten, falls Bestätigung ausbleibt

o Wann wird ein TCP-Paket nicht bestätigt? Wenn die Bestätigung wesentlich länger

benötigt, als die durchschnittliche Umlaufzeit (RTT/round trip time)

• 1. Problem: Messung der RTT

• 2. Problem: Bestätigung kommt, nur spät Sender

• Wartet Zeitraum gemäß RTO

• Sendet Paket nochmal und setzt

RTO ← 2 RTO (bis RTO = 64 Sek.)

o Neuberechnung von RTO, wenn Pakete bestätigt werden


„Hello!“ Seq.nr. 17

ACK: 17+6=23

Sen

der

Em

pfän

ger





1s2s

4s8s

?

?

?

?





Schätzung der Umlaufzeit(RTT/Round Trip Time)

o TCP-Paket gilt als nicht bestätigt, wenn Bestätigung „wesentlich“ länger dauert als RTO

o RTT nicht on-line berechenbar (nur rückblickend)

o RTT schwankt stark

o Daher: Retransmission Timeout Value aus großzügiger Schätzung: RFC 793: (M := letzte gemessene RTT)

R ← α R + (1- α) M, wobei α = 0,9

RTO ← β R, wobei β = 2 Jacobson 88: Schätzung nicht robust genug, daher

A ← A + g (M - A) , wobei g = 1/8

D ← D + h (|M - A| - D) , wobei h = 1/4

RTO ← A + 4D

o Aktualisierung nicht bei mehrfach versandten Pakete





Gleitende Fenster (sliding windows)

o Datenratenanpassung durch Fenster Empfänger bestimmt Fenstergröße (wnd) im TCP-Header der ACK-

Segmente Ist Empfangspuffer des Empfängers voll, sendet er wnd=0 Andernfalls sendet Empfänger wnd>0

o Sender beachtet: Anzahl unbestätigter gesender Daten ≤ Fenstergröße





Slow StartCongestion Fenster

o Sender darf vom Empfänger angebotene Fenstergröße nicht von Anfang wahrnehmen

o 2. Fenster: Congestion-Fenster (cwnd/Congestion window) Von Sender gewählt (FSK) Sendefenster: min {wnd,cwnd} S: Segmentgröße Am Anfang: cwnd ← S Für jede empfangene Bestätigung,

setze

cwnd ← cwnd + S Solange bis einmal Bestätigung

ausbleibt

o „Slow Start“ = Exponentielles Wachstum

Segment 8

Segment 9

Segment 10

Segment 1

ACK: Segment 1

Sen

der

Em

pfän

ger

Segment 2

Segment 3ACK: Segment 3

Segment 4

Segment 5

ACK: Segment 7

Segment 6Segment 7

ACK: Segment 5

…





Stauvermeidung(congestion avoidance)

o Jacobson 88:

Parameter: cwnd und Slow-Start-Schwellwert (ssthresh=slow start threshold)

S = Datensegmentgröße = maximale Segmentgröße

1. Verbindungsaufbau:cwnd ← S ssthresh ← 65535

2. Bei Paketverlust, d.h. Bestätigungsdauer > RTO, multiplicatively decreasing

cwnd ← S ssthresh ←

3. Werden Segmente bestätigt und cwnd ≤ ssthresh, dann slow startcwnd ← cwnd + S

4. Werden Segmente bestätigt und cwnd > ssthresh, dann additively increasing

cwnd ← cwnd +

2

},min{,2max

wndcwndS

x 1

x x +1

y max

y x/2x 1

x 2x, bis x = y

x: Anzahl Pakete proRTT

cwnd

S





Fast Retransmit und Fast Recovery

o Jacobson 90: Geht nur ein Paket verloren, dann• Wiederversand Paket + Restfenster• Und gleichzeitig Slow Start

o Fast Retransmit: Nach drei Bestätigungen desselben Pakets (triple duplicate ACK), sende Paket nochmal

o Fast Recovery: Erhöhe Paketrate mit jeder weiteren Bestätigung

1. Fast retransmit: Nach triple duplicate ack von P, sende Paket P nochmalssthresh ← min(wnd,cwnd)/2 cwnd ← ssthresh + 3 S

2. Fast recovery: Bei weiterer Bestätigung von P:cwnd ← cwnd + S

3. Congestion avoidance: Trifft Bestätigung von P+x ein:

cwnd ← ssthresh

x y (= x/2)





Stauvermeidungsprinzip: AIMD

o Kombination von TCP und Fast Recovery verhält sich im wesentlichen wie folgt:

1. Verbindungsaufbau:

2. Bei Paketverlust, MD:multiplicative decreasing

3. Werden Segmente bestätigt, AD: additive increasing

x 1

x x +1

x x/2





Durchsatz und Antwortzeit





Ein einfaches Datenratenmodell

o n Teilnehmer, Rundenmodell

o Teilnehmer i hat Datenrate xi(t)

o Anfangsdatenrate x1(0), …, xn(0) gegeben

o Feedback nach Runde t: y(t) = 0, falls

y(t) = 1, falls

o Jeder Teilnehmer aktualisiert in Runde t+1:

xi(t+1) = f(xi(t),y(t))

Increase-Strategie f0(x) = f(x,0)

Decrease-Strategie f1(x) = f(x,1)

o Wir betrachten lineare Funktionen:





Lineare Datenratenanpassung

o Wir betrachten lineare Funktionen:

o Interessante Spezialfälle: AIAD: Additive Increase

Additive Decrease

MIMD: Multiplicative Increase/Multiplicative Decrease

AIMD: Additive IncreaseMultiplicative Decrease





Fairness und Effizienz

o Effizienz Last:

Maß

o Fairness: Für x=(x1, …, xn):

1/n ≤ F(x) ≤ 1 F(x) = 1 ↔ absolute Fairness, d.h. xi = xj, für alle i,j

Skalierungsunabhängig Kontinuierlich, stetig, differenzierbar Falls k von n fair, Rest 0, dann F(x) = k/n

heinz nixdorf institut universität paderborn eim institut für informatik 1 algorithm. grundlagen...

Documents