Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 11te Vorlesung Lehrstuhl für...

Lehrstuhl für Kommunikationssysteme - Systeme II 1

Systeme II – 11te Vorlesung

Lehrstuhl für KommunikationssystemeInstitut für Informatik / Technische Fakultät

Universität Freiburg2009


Letzte Vorlesung

‣Einstieg in die Transportschicht•Bereitstellung von Diensten für Netzwerkapplikationen

•Realisiert eine Reihe von Aufgaben, wie beispielsweise das Multiplexing oder die Datenfluss-Steuerung


Letzte Vorlesung

‣TCP/IP kennt zwei wesentliche (neben anderen) Protokolle der Transportschicht‣ UDP (User Datagram Protocol)

•Einfacher unzuverlässiger Dienst zum Versand von einzelnen Päckchen

•Wandelt Eingabe in ein Datagramm um

•Anwendungsschicht bestimmt Paketgröße

‣In TCP (Transmission Control Protocol)•Erzeugt zuverlässigen Datenfluß zwischen zwei Rechnern

•Unterteilt Datenströme aus Anwendungsschicht in Pakete

•Gegenseite schickt Empfangsbestätigungen (Acknowledgments)


Letzte Vorlesung

‣Transport Protokolle sind nicht in Netzwerk Routing Aufgaben einbezogen – realisieren lediglich End-to-end-Connections‣TCP und UDP hängen nicht von IP(v4) als Protokoll der Vermittlungsschicht ab und könnten (theoretisch) auf der Basis anderer Netzwerkschichtprotokolle arbeiten

5 | 52

Eine andere schwierige Herrausforderung sind Häufungen von PaketenDiese können einen Stau verursachen und damit spontan die Übermittlungszeit stark erhöhen.

Die Gesamtzeit um eine Nachricht zu senden und das ack zu empfangen kann in wenigen Millisekunden um mehrere Größenordnungen schwanken.

Vor TCP wurde ein fester Wert für das Timeout vor einem Neuversand eingesetzt. Für ein Internet würde das offensichtlich nicht gut funktionieren. TCP wurde darauf ausgelegt, adaptiv zu handeln. Für jede aktive Verbindung wird ein eigener Timeout geschätzt.

Protokoll – Herausforderungen

6 | 52

Obwohl sich das Protokoll einfach anhört, gibt es doch ein paar SchwierigkeitenDa Pakete fragmentiert werden können, ist es möglich, dass nur ein Teil der Segemente ankommen.

Die Segmente müssen nicht in der richtigen Reihenfolge ankommen, so dass die Byte 4123-5300 nicht bestätigt werden können, so lange die Byte 2947-4122 noch nicht angekommen sind.

Segmente können so lange verzögert werden, dass der Neuversandt ausgelöst wird.

Wenn das neue Segment schneller übermittelt wird, können das Original und das Duplikat gleichzeitig ankommen.

Protokoll – Herausforderungen

TCP VerbindungenWerden duplex betrieben (auf einer virtuellen Ebene, unabhängig von der Netzwerkschicht)

Arbeiten Punkt-zu-Punkt – jede Verbindung hat genau zwei Endpunkte

Unterstützen weder multi- noch broadcast (dafür kann aber UDP eingesetzt werden)

Kein Nachrichten- sondern ein ByteStrom

TCP kann Daten puffern oder sofort senden (push flag)

Besondere Behandlung für dringende Daten (urgent pointer)

Dienste-Modell


Dienste-Modell

‣Sendende und empfangende TCP Entitäten tauschen Daten in Form von Segmenten aus. Ein Paket besteht aus einem 20byte Header (möglicherweise noch mit einem optionalen Teil), gefolgt von so vielen Daten, wie in die MTU passen. (# Daten = MTU – IP Header – TCP Header) Jedes Segment hat seine eigene Segmentnummer (32bit)Die Segmentnummern werden für die acks und den Fenstermechanismus eingesetzt, die eigene 32bit Header Felder haben. Die Nummern fangen später wieder von vorne an(rund alle 5 Minuten in einem 100Mbit/s LAN)

Um TCP nutzen zu können, müssen Sender und Empfänger Endpunkte, sogenannte Sockets, erstellen – der Dienst muss explizit gestartet werden.Jedes Socket wird durch ein Tuppel aus IP Adresse und Portnummer (16bit) festgelegt. Ein Socket kann mehrere Verbindungen verwalten, wie kann man also die Verbindungen unterscheiden?Verbindungen werden über ein Tuppel aus den beidenSockets vom Sender und Empfänger identifiziert.

Dienste-Modell

Betrachte zwei Hosts, von denen einer einen Webserver betreibt und der andere als Client einen Browser benutzt. Drei Werte des Tuppels sind fest: die beiden IP Adressen und der Port des Servers.Der Client könnte also 64k Verbindungem zum Server aufbauen (jede mit einer anderen Portnummer bis keine mehr frei sind.)Der Server könnte mehr als diese 64k Verbindungen verwalten, wenn sich mehrere Clients wie oben beschrieben verbinden. (Die Höchstanzahl der offenen Verbindungen hängt von der Anwendung und dem OS ab und kann auch sonst beschränkt sein)

Dienste-Modell


Verbindungsaufbau von TCP

‣TCP verwendet einen 3-Wege-Handshake zum Aufbau der Verbindung und entsprechendes zum Abbau‣Besonders interessant ist die Fluss-Steuerung, die ja nicht von IP realisiert wird, TCP bietet viel Raum für Theorie, Forschung und Optimierung


Verbindungssteuerung von TCP

‣Ein Problem ist die Geschwindigkeit des Sendens und Setzens der Timeouts•Adaptives Neu-Senden hilft den Durchsatz auf verschiedenen Verbindungen zu optimieren – man betrachte Fall von zwei Verbindungen mit unterschiedlichen Round-Trip-Times (RTT, Umlaufzeit)

13

„World“ Seq.nr. 23

„Hello!“ Seq.nr. 17

ACK: 17+6=23

Sen

der

Em

pfä

ng

er„World“ Seq.nr. 23




1s2s

4s8s

?

?

?

?

Exponentielles Zurückweichen

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

‣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


Exponentielles Zurückweichen

•Sender

-Wartet Zeitraum gemäß RTO-Sendet Paket nochmal und setzt-RTO ← 2 RTO (bis RTO = 64 Sek.)•Neuberechnung von RTO, wenn Pakete bestätigt werden

‣Problem: TCP-Paket gilt als nicht bestätigt, wenn Bestätigung „wesentlich“ länger dauert als RTO•RTT nicht on-line berechenbar (nur rückblickend)•RTT schwankt stark


RTT Messung

‣Problem:In TCP gibt es keine Möglichkeit zu entscheiden, ob ein ACK für das Original oder das neu versandte Paket gemeint war.

Das wird als "acknowledgement ambiguity" bezeichnet.

Karn's AlgorithmusEigentlich zwei Teile ... um die Mehrdeutigkeit aufzulösen:Messe nicht die RTT für Segmente, die neu versandt wurden (einfach)

Bei einem Timeout:Das Netzwerk sagt dir, dass es Probleme hat

Also: verdopple den TRX Timer (bis zu 64x) bei jedem folgenden Timeout (64s max)s


RTT Messung

‣Um die RTT der Verbindung zu messen, verwendet TCP einen exponentiell gewichtenden gleitenden Durchschnitt (wie RED):Auch Tiefpassfilter genannt

Benötigt nur ein Speichert-WortFrühe TCPs haben einfach die durchschnittliche RTT geschätzt und das Timeout auf das Doppelte gesetzt, um etwas die Varianz zu berücksichtigen.In Netzwerken mit einer großen Varianz könnte dies jedoch nicht genug sein. Wie kann man also die Schwankung der RTT auch noch messen?Vielleicht die Standardabweichung? (ein bischen komplexer :-))


TCP Timer

‣Festlegung der RTX Timer:Slow-start wird als Reaktion auf einen abgelaufenen Timer aufgerufenZur Erinnerung: Der Timer muss irgendwie so gesetzt werden, dass TCP sowohl in lokalen Netzwerken, als auch in Netzen mit großen Verzögerungen arbeiten kann. Man braucht also einen Weg, den Timer in Abhängigkeit von der RTT der Verbindung zu setzen.Wie kann man die RTT messen?

Wie setzt man danac den RTX Timer?

Einfacher Ansatz:Merke die die Sendezeit eines Pakets

Wenn das ACK kommt, benutze die Zeitdifferenz als RTT

18

Schätzung der Umlaufzeit

‣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

‣Aktualisierung nicht bei mehrfach versandten Pakete

‣Weiteres Problem: Wie kann man sicherstellen, •dass kleine Pakete zeitnah ausgeliefert werden•und bei vielen Daten große Pakete bevorzugt werden?

19

TCP - Algorithmus von Nagle

‣Algorithmus von Nagle:•Kleine Pakete werden nicht versendet, solange Bestätigungen noch ausstehen.-Paket ist klein, wenn Datenlänge < MSS•Trifft die Bestätigung des zuvor gesendeten Pakets ein, so wird das nächste verschickt.

‣Beispiel: •Telnet/SSH versus ftp

‣Eigenschaften•Selbst-taktend: Schnelle Verbindung = viele kleine Pakete

Ein anderer wichtiger Aspekt von TCP ist die Staukontrolle (congestion control)Die Congestion control könnte auch in tieferen Schichten implementiert werden. (was häufiger nur in Subnetzen der Fall und auch nicht garantiert ist)Im modernen Internet ist der Verlust (oder eine sehr lange Verzögerung) eines Pakets wahrscheinlicher als ein Fehler in der Hardware. Transportprotokolle, die neu versenden, könnten das Stauproblem noch verstärken, in dem die zusätzliche Kopien einer Nachricht senden. Das könnte dann bis zum vollständigen Zusammenbruch des gesamten Systems führen.

Stauvermeidung und Fluss-Steuerung

21

Buffer, Flusskontrolle und Fenster

‣Wenn die empfangende Anwendung die Daten so schnell verarbeiten kann, wie sie ankommen, wird sie eine positive Window Advert senden

Wenn die sendende Seite schneller ist als der Empfänger, wird sie, wenn Puffer voll ist, ein Zero Window Advert senden

Dann darf der Sender nichts mehr schicken, bis er wieder ein positives Fenster bekommt

22

Gleitende Fenster (sliding windows)

‣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

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

23

Segment 8

Segment 9

Segment 10

Segment 1

ACK: Segment 1

Se

nd

er

Em

pfä

ng

er

Segment 2

Segment 3

ACK: Segment 3

Segment 4

Segment 5

ACK: Segment 7

Segment 6

Segment 7

ACK: Segment 5

…

Slow Start – Congestion Fenster

‣Sender darf vom Empfänger angebotene Fenstergröße nicht von Anfang wahrnehmen‣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:-cwnd ← cwnd + S•Solange bis einmal Bestätigung ausbleibt

‣„Slow Start“ = Exponentielles Wachstum

Warum wird es dann “slow-start” genannt?Hauptsächlich, weil es bedeutend langsamer ist, als was davor eingesetzt wurde ( Start nur in Abhängigkeit von dem vom Empfänger angebotenen Fenster )Für jedes empfangene ACK wird das Congestion Window um eins erhöht Resultierende Folge für cwnd: 1, 2, 4, 8, 16, 32, ...n braucht Zeit proportional zu log W um die Größe von W zu erreichen, [noch länger falls ACKs verzögert]Zwei Algorithmen:Slow-Start: Suche nach dem Gleichgewicht

Stauvermeidung: Suche nach neuer Bandbreite auf dem Weg ( und Reaktion auf den Stau )

Slow Start – Congestion Fenster

Die beiden Ideen können nicht gleichzeitig verfolgt werden, TCP aber implementiert beide:Es wird eine Grenze festgelegt, um zwischen den beiden Algorithmen umzuschaltenDaher muss ein Kriterium festgesetzt werden, das entscheidet, ob slow-start oder Stauvermeidung ausgeführt werden soll - Neue Variable: sstreshWenn cwnd <= sstresh führe slow-start aus, ansonsten Stauvermeidungsstresh wird mit einem großen Wert initialisiert, nach einem Stausignal wird cwnd halbiert und sstresh auf cwnd gesetzt.

Stauvermeidung – Slow Start

26

‣Jacobson 88: •Parameter: cwnd und Slow-Start-Schwellwert (ssthresh=slow start threshold)•S = Datensegmentgröße = maximale Segmentgröße

‣Verbindungsaufbau:•cwnd ← S ssthresh ← 65535

‣Bei Paketverlust, d.h. Bestätigungsdauer > RTO, •multiplicatively decreasingcwnd ← S ssthresh ←

‣Werden Segmente bestätigt und cwnd ≤ ssthresh, dann •slow start: cwnd ← cwnd + S

x ← 1 y ← max

y ← x/2x ← 1

x ← 2⋅x, bis x = y

x: Anzahl Pakete pro RTT

Stauvermeidung in TCP Tahoe


Verbindungssteuerung von TCP

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

cwnd ← cwnd + S x ← x +1


Fast Retransmit und Fast Recovery

‣TCP Tahoe [Jacobson 1988]: •Geht nur ein Paket verloren, dann-Wiederversand Paket + Restfenster-Und gleichzeitig Slow Start•Fast retransmit-Nach drei Bestätigungen desselben Pakets (triple duplicate ACK),-sende Paket nochmal, starte mit Slow Start

29

x ← y + 3

y ← x/2


‣TCP Reno [Stevens 1994]•Nach Fast retransmit:-ssthresh ← min(wnd,cwnd)/2-cwnd ← ssthresh + 3 S•Fast recovery nach Fast retransmit-Erhöhe Paketrate mit jeder weiteren Bestätigung-cwnd ← cwnd + S•Congestion avoidance: Trifft Bestätigung von P+x ein:-cwnd ← ssthresh-Wann wird überhaupt Slow-Start nach dem Aufbau einer Verbindung ausgeführt?TCP hat einen Verlust festgestellt

TCP nutzt verlorene Pakete als Indikatoren für einen Stau

timer expiring & fast retransmit



‣Fast Retransmit

Durch die kummulativen Acks können Pakete, die beim Empfänger in der falschen Reihenfolge ankommen, duplizierte acks erzeugen (“dupacks”)

Heuristisch beim Sender um den Neuversandt auch ohne Timeouts auszulösen

Um einen Neuversand wegen wenigen Vertauschungen auszuschließen, wird auf drei DUPACKS gewartet

Nach dem dritten DUPACK für Packet n wird Paket n+1 neu gesendet (Und auch mehr, wenn es das Sendefenster zulässt )Wenn nur ein Paket verloren wurde, wird die Lücke beim Empfänger geschlossen


Stauvermeidungsprinzip: AIMD

x ← 1

x ← x +1

x ← x/2

32

Beispiel: TCP Reno in Aktion

Slow Start

Additively Increase

Fast RecoveryFast Retransmit

Multiplicatively Decrease

33

Durchsatz und Antwortzeit

‣Klippe:•Hohe Last•Geringer Durchsatz•Praktisch alle Daten gehen verloren

‣Knie:•Hohe Last•Hoher Durchsatz•Einzelne Daten gehen verloren

34

Einfaches Datenratenmodell

35

Lineare Datenratenanpassung

‣Interessante Spezialfälle:•AIAD: Additive IncreaseAdditive Decrease

•MIMD: Multiplicative Increase/Multiplicative Decrease

•AIMD: Additive IncreaseMultiplicative Decrease

36

Konvergenz

‣Konvergenz unmöglich‣Bestenfalls Oszillation um Optimalwert•Oszillationsamplitude A•Einschwingzeit T

37

Vektordarstellung (I)

38

Vektordarstellung (II)

39

AIAD Additive Increase/ Additive Decrease

40

MIMD: Multiplicative Increase/Decrease

41

AIMD: Additively Increase/Multiplicatively Decrease

42

TCP fairness & TCP friendliness

‣TCP reagiert dynamisch auf die zur Verfügung stehende Bandweite•Faire Aufteilung der Bandbreite-Im Idealfall: n TCP-Verbindungen erhalten einen Anteil von 1/n

‣Zusammenspiel mit anderen Protokollen•Reaktion hängt von der Last anderer Transportprotokolle ab-z.B. UDP hat keine Congestion Control•Andere Protokolle können jeder Zeit eingesetzt werden•UDP und andere Protokoll können TCP Verbindungen unterdrücken

‣Schlussfolgerung•Transport-Protokolle müssen TCP-kompatibel sein (TCP friendly)


Ende der siebten VorlesungEnde der elften Vorlesung

Erneuter Wechsel der Schichten – ein Layer abwärts: Vermittlungs-schicht re-visitedWeiter geht es am Montag, den 22.6. mit der nächsten Vorlesung, selbe Zeit&OrtAlle relevanten Informationen auf der Webseite zur Vorlesung: http://www.ks.uni-freiburg.de/php_veranstaltungsdetail.php?id=28Vorbereitung: Lesen des Kapitels 3 im Kurose&Ross und zu IPv6 & Multicast, Broadcast und zu entsprechenden Aspekten in der angegebenen Literatur!

http://www.ks.uni-freiburg.de/php_veranstaltungsdetail.php?id=28

Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 11te Vorlesung Lehrstuhl für...

Documents

Transcript of Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 11te Vorlesung Lehrstuhl für...