lehrstuhl für kommunikationssysteme - systeme ii1 systeme ii – 11te vorlesung lehrstuhl für...
TRANSCRIPT
Lehrstuhl für Kommunikationssysteme - Systeme II 1
Systeme II – 11te Vorlesung
Lehrstuhl für KommunikationssystemeInstitut für Informatik / Technische Fakultät
Universität Freiburg2009
Lehrstuhl für Kommunikationssysteme - Systeme II 2
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
Lehrstuhl für Kommunikationssysteme - Systeme II 3
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)
Lehrstuhl für Kommunikationssysteme - Systeme II 4
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
Lehrstuhl für Kommunikationssysteme - Systeme II 8
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
Lehrstuhl für Kommunikationssysteme - Systeme II 11
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
Lehrstuhl für Kommunikationssysteme - Systeme II 12
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
„World“ Seq.nr. 23
„World“ Seq.nr. 23
„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
Lehrstuhl für Kommunikationssysteme - Systeme II 14
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
Lehrstuhl für Kommunikationssysteme - Systeme II 15
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
Lehrstuhl für Kommunikationssysteme - Systeme II 16
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 :-))
Lehrstuhl für Kommunikationssysteme - Systeme II 17
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
Lehrstuhl für Kommunikationssysteme - Systeme II 27
Verbindungssteuerung von TCP
‣Werden Segmente bestätigt und cwnd > ssthresh, dann additively increasing
cwnd ← cwnd + S x ← x +1
Lehrstuhl für Kommunikationssysteme - Systeme II 28
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
Fast Retransmit und Fast Recovery
‣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
Lehrstuhl für Kommunikationssysteme - Systeme II 30
Fast Retransmit und Fast Recovery
‣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
Lehrstuhl für Kommunikationssysteme - Systeme II 31
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)
Lehrstuhl für Kommunikationssysteme - Systeme II 43
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!