Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 11te Vorlesung Lehrstuhl für Kommunikationssysteme Institut für Informatik / Technische.

Präsentation zum Thema: "Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 11te Vorlesung Lehrstuhl für Kommunikationssysteme Institut für Informatik / Technische."—  Präsentation transkript:

1 Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 11te Vorlesung Lehrstuhl für Kommunikationssysteme Institut für Informatik / Technische Fakultät Universität Freiburg 2009

2 Lehrstuhl für Kommunikationssysteme - Systeme II2 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

3 Lehrstuhl für Kommunikationssysteme - Systeme II3 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)

4 Lehrstuhl für Kommunikationssysteme - Systeme II4 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 5 | 52 Eine andere schwierige Herrausforderung sind Häufungen von Paketen Diese 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 6 | 52 Obwohl sich das Protokoll einfach anhört, gibt es doch ein paar Schwierigkeiten Da 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

7 TCP Verbindungen Werden 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

8 Lehrstuhl für Kommunikationssysteme - Systeme II8 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)

9 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 beiden Sockets vom Sender und Empfänger identifiziert. Dienste-Modell

10 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

11 Lehrstuhl für Kommunikationssysteme - Systeme II11 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

12 Lehrstuhl für Kommunikationssysteme - Systeme II12 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 13 World Seq.nr. 23 Hello! Seq.nr. 17 ACK: 17+6=23 Sender Empfänger World Seq.nr. 23 1s 2s 4s 8s ? ? ? ? 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

14 Lehrstuhl für Kommunikationssysteme - Systeme II14 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

15 Lehrstuhl für Kommunikationssysteme - Systeme II15 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 Algorithmus Eigentlich 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

16 Lehrstuhl für Kommunikationssysteme - Systeme II16 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-Wort Frü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 :-))

17 Lehrstuhl für Kommunikationssysteme - Systeme II17 TCP Timer Festlegung der RTX Timer: Slow-start wird als Reaktion auf einen abgelaufenen Timer aufgerufen Zur 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 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 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

20 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 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 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 23 Segment 8 Segment 9 Segment 10 Segment 1 ACK: Segment 1 Sender Empfänger 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

24 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

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

26 26 Jacobson 88: Parameter: cwnd und Slow-Start-Schwellwert (ssthresh=slow start threshold) S = Datensegmentgröße = maximale Segmentgröße Verbindungsaufbau: cwnd Sssthresh 65535 Bei Paketverlust, d.h. Bestätigungsdauer > RTO, multiplicatively decreasing cwnd Sssthresh Werden Segmente bestätigt und cwnd ssthresh, dann slow start: cwnd cwnd + S x 1 y max y x/2 x 1 x 2 x, bis x = y x: Anzahl Pakete pro RTT Stauvermeidung in TCP Tahoe

27 Lehrstuhl für Kommunikationssysteme - Systeme II27 Verbindungssteuerung von TCP Werden Segmente bestätigt und cwnd > ssthresh, dann additively increasing cwnd cwnd + S x x +1

28 Lehrstuhl für Kommunikationssysteme - Systeme II28 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 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

30 Lehrstuhl für Kommunikationssysteme - Systeme II30 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

31 Lehrstuhl für Kommunikationssysteme - Systeme II31 Stauvermeidungsprinzip: AIMD x 1 x x +1 x x/2

32 32 Beispiel: TCP Reno in Aktion Slow Start Additively Increase Fast Recovery Fast Retransmit Multiplicatively Decrease

33 33 Durchsatz und Antwortzeit Klippe: Hohe Last Geringer Durchsatz Praktisch alle Daten gehen verloren Knie: Hohe Last Hoher Durchsatz Einzelne Daten gehen verloren

34 34 Einfaches Datenratenmodell

35 35 Lineare Datenratenanpassung Interessante Spezialfälle: AIAD: Additive Increase Additive Decrease MIMD: Multiplicative Increase/Multiplicative Decrease AIMD: Additive Increase Multiplicative Decrease

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

37 37 Vektordarstellung (I)

38 38 Vektordarstellung (II)

39 39 AIAD Additive Increase/ Additive Decrease

40 40 MIMD: Multiplicative Increase/Decrease

41 41 AIMD: Additively Increase/ Multiplicatively Decrease

42 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)

43 Lehrstuhl für Kommunikationssysteme - Systeme II43 Ende der siebten Vorlesung Ende der elften Vorlesung Erneuter Wechsel der Schichten – ein Layer abwärts: Vermittlungs-schicht re-visited Weiter geht es am Montag, den 22.6. mit der nächsten Vorlesung, selbe Zeit&Ort Alle relevanten Informationen auf der Webseite zur Vorlesung: http://www.ks.uni-freiburg.de/php_veranstaltungsdetail.php?id=28 http://www.ks.uni-freiburg.de/php_veranstaltungsdetail.php?id=28 Vorbereitung: Lesen des Kapitels 3 im Kurose&Ross und zu IPv6 & Multicast, Broadcast und zu entsprechenden Aspekten in der angegebenen Literatur!