Algorithmen des Internets

Transkript

1 Algorithmen des Internets Vorlesungsskript Sommersemester 2005 Christian Schindelhauer Heinz Nixdorf Institut Fakultät EIM, Institut für Informatik Universität Paderborn Sommersemester 2005

2

3 Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis III V 1 TCP: Das Transport-Protokoll des Internets VII 1.1 Transportschicht VII 1.2 Eigenschaften von TCP VII Verbindungsorientiert VII Zuverlässig VII Bidirektional VIII 2 TCP IX TCP-Header IX Verbindungsaufbau XI Verbindungsende XII Bestätigungen XII 2.1 Datenflusskontrolle durch TCP XIII Exponentielles Rückweichen (exponential backoff) XIII Round Trip Time XIII Gleitende Fenster (sliding windows) XIV Slow Start XV Stauvermeidung (Congestion Avoidance) XVI Fast Retransmit und Fast Recovery XVII 2.2 Fairness und Effizienz von AIMD XVIII Das Modell XVIII Bewertungskriterien XIX Faire und effiziente Datenratenwahl XXI I

4 II INHALTSVERZEICHNIS

5 Abbildungsverzeichnis 2.1 TCP-Header-Definition aus RFC 793 [?] X 2.2 Verbindungsaufbau von TCP XI 2.3 half-close XII 2.4 schließen einer TCP-Verbindung XII 2.5 gleitendes Fenster XIV 2.6 Knie und Klippe des Durchsatz und der Antwortzeit XVIII 2.7 Oszillation XX 2.8 Vektordarstellung XXI 2.9 AIAD XXII 2.10 MIMD XXIII 2.11 AIMD XXIV III

6 IV ABBILDUNGSVERZEICHNIS

7 Tabellenverzeichnis V

8 VI TABELLENVERZEICHNIS

9 Kapitel 1 TCP: Das Transport-Protokoll des Internets In diesem Kapitel soll eine Einführung in das TCP Protokoll geben werden. Dazu wird im folgenden eine kurze Einführung in die Transportschicht gegeben. Im Anschluss daran werden die Eigenschaften von TCP beschrieben. In Kap. 2 wird das TCP Protokoll dann im Detail beschrieben. 1.1 Transportschicht Die Aufgabe der Transportschicht ist es Daten über das Netzwerk zu transportieren. Anwendungsprogramme verwenden die Transportschicht um eine mit anderen Anwendungsprogrammen auf entfernten Computern über ein Netzwerk zu kommunizieren. Dabei arbeitet die Transportschicht unabhängig von den physikalischen Eigenschaften der Netzwerke und unabhängig der Routing-Protokolle. Im Internet gibt es zwei Protokolltypen auf der Transportschicht. Diese sind das verbindungslose UDP und das verbindungsorientierte TCP Protokoll. Das UDP Protokoll ist im Prinzip nur ein kleiner Aufsatz auf dem IP Protokoll. Es werden sog. UPD Datagramme verschickt. Die Datagrame besitzten fast die gleichen Eigenschaften wie IP Packete (unzuverlässig, verbindungslos, ohne Reihenfolge usw.). Die einzigen zusätlichen Mechanismen die UPD bereitstellt ist es den Packeten Ports zuzuordnen. Außerdem enthält das UDP Protokoll noch die möglichkeit Fehlerhafte Packete zu erkennen. Dazu ist im Header des UPD-Header eine Prüfsumme vorgesehen. Das TCP Protokoll hingegen ermöglicht eine weitaus bessere Verbindung. Dabei wird von Packeten abstrahiert und die Anwendungen können über sog. Ströme (engl. Streams) kommunizieren. Im folgenden werden die Eingenschaften von TCP genauer beschrieben. 4. Vorlesung Autor1 (wickert(at)upb.de) Autor2 (betra(at)upb.de) 1.2 Eigenschaften von TCP Verbindungsorientiert Bei TCP identifizieren sich zwei Parteien durch Sockets. Ein Socket besteht aus einer IP-Adresse und einem Port. Somit ist die TCP-Verbindung eindeutig durch das Socketpaar identifiziert. Um eine Verbindung mit Hilfe von Sokets zu etablieren, ist es notwendig erst die Verbindung aufzubauen und dann zu beenden. Es existiert solange eine Verbindung bis diese nicht (ordentlich) beendet wurde. Bei dieser Verbindungsart funktioniert kein Broad- oder Multicast Zuverlässig Unter TCP erhält jeder Sender eine Bestätigung (acknowledgment) zu jedem versendeten Datenpaket. Somit kann der Sender festellen, welche Pakete nicht angekommen sind und diese nocheinmal verschicken. Es VII

10 VIII KAPITEL 1. TCP: DAS TRANSPORT-PROTOKOLL DES INTERNETS werden des weitern noch Checksummen für den TCP-Header und die Daten hinzugefügt, um eine bessere Fehlerkennung zu gewährleisten. Des weiteren werden die Pakete von TCP nummeriert und dann versandt. Somit kann es geschehen, dass die Pakete über unterschiedliche Routen zum Empfänger gelangen. Da die Pakete nummeriert sind, kann der Empfänger diese wieder in die richtige Reihenfolge bringen. Hiermit kann auch das Problem der doppleten Pakete gelöst werden, da diese nun beim Empfänger gelöscht werden können Bidirektional Bei TCP wird der Inhalt der Daten nicht interpretiert sondern nur ausgeliefert. Da die Pakete über unterschiedliche Routen zum Empfänger gelangen, kann sich auch das Zeitverhalten der Datenfolgen ändern. Dies ist aber kein Problem, da die einzelnen Pakete durchnummeriert sind und beim Empfänger sortiert werden. TCP versucht eine zeitnahe Auslieferung jedes einzelnen Datenbytes zu gewährleisten. Es wird auch weiter versucht das Übertragungsmedium effizient zu nutzten. Dies kann man erreichen, indem man wenig Pakete verschickt.

11 Kapitel 2 TCP In Kapitel 1 haben wir bereits eine Einführung in TCP begonnen. Wir setzen nun diese Diskussion fort. 4. Vorlesung TCP-Header Der (mind.) 20-Byte-Header eines TCP-Pakets (Segments) besteht, wie in Abbildung 2.1 gezeigt, aus folgenden Teilen. 16 Bit Absender-Port-Nummer (source port) Diese Port-Nummern sind notwendig, um über eine IP-Adresse gleichzeitig verschiedene TCP- Verbindungen aufrecht zu halten. Entsprechend dieser Portnummmer werden die IP-Datagrammen den Anwendungen auf einem Rechner zugeordnet. Die eigentliche Absender-IP-Adresse findet sich im IP-Header. Die Kombination aus Port und IP- Adresses wird Socket genannt. 16 Bit Ziel-Port-Nummer (destination port) Deren Aufgabe entspricht der Absender-Port-Nummer. Ziel- und Quell-Socket bilden zusammen das Socket-Paar. Dieses Paar beschreibt eindeutig die TCP-Verbindung. 32 Bit Sequenznummer (sequence number) Anhand dieser Zahl wird die Reihenfolge der TCP-Pakete wiederhergestellt. In jeder Kommunikationsrichtung wird jedes Byte durchnummeriert (mit Umbruch bei auf 0) und das erste Byte des Segments bestimmt die Sequenznummer des gesamten TCP-Pakets. 32 Bit Bestätigungsnummer (acknowledgement number) Hier wird dem Sender einer Flussrichtung die Nummer des als nächstes erwarteten Datenbytes vom Empfänger mitgeteilt. In anderen Worten ist es die Sequenznummer des letzten Bytes des zuletzt erhaltenen Pakets plus eins. Dieses Feld wird erst mit gesetzten Acknowledgment-Flag gültig. Wird eine Bestätigungsnummer eines TCP-Pakets (d.h. Sequenznummer+Paketlänge) empfangen, so belegt das auch, dass alle Datenbytes mit kleinerer Sequenznummer ordentlich empfangen worden sind. Durch diesen Mechanismus ist es insbesondere nicht (unmittelbar) möglich, einzelne Pakete zu bestätigen, die nach einem fehlenden Paket empfangen worden sind. Erscheint also ein Paket in einem Strom nicht, so müssten eigentlich alle Pakete die danach noch übermittelt worden sind, mit dem fehlenden Paket (das durch die Bestätigungsnummer beschrieben wird) erneut verschickt werden (Der fast retransmit-algorithmus umgeht dieses Problem). 6 Flag-Bits Die folgenden 6 Flag-Bits können (weitestgehend 1 ) unabhängig voneinander gesetzt werden. 1 Alle Flags zu setzen, ist zum Beispiel unsinnig. So ein so beflaggtes Segment wird laut [Pos87] kamikaze packet genannt. Weitere Spitznamen dafür sind nastygram, christmas tree packet und lamp test. IX

12 X KAPITEL 2. TCP TCP Header Format 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 data TCP Header Format Note that one tick mark represents one bit position. Abbildung 2.1: TCP-Header-Definition aus RFC 793 [Pos81] URG: urgent pointer Dieses Flag aktiviert den urgent pointer. Mit diesem Mechanismus wird der Empfänger über Dringlichkeit von Daten informiert. Dies wird zumeist in Telnet und Rlogin-Verbindungen benutzt 2. ACK: acknowledgement number Dieses Flag aktiviert die Bestätigungsnummer. PSH: push Ein gesetztes Push-Flag zeigt dem Empfänger an, dass die Daten so schnell als möglich an die Anwendungsschicht weitergeben soll. RST: reset Das Reset-Flag wird gesendet, um anzuzeigen, dass ein empfangenes Segment nicht einer TCP- Verbindung korrekt zugeordnet werden kann. Dies geschieht beispielsweise, wenn ein UDP- Paket an einem TCP-Port ankommt oder ein Port an einem Rechner nicht verwendet wird. SYN: synchronize Damit werden Sequenznummern beim Verbindungsaufbau synchronisiert. FIN: finished Damit wird angezeigt, dass der Sender einer Flussrichtung aufhört, Daten zu senden. In der Gegenrichtung kann weiter übertragen werden. 4 Bit Headerlänge Durch ein Optionsfeld ist die Länge des Headers variabel. Deswegen ist es notwendig, die Headerlänge mitzuteilen. 2 Dieses Flag kann beschleunigt nicht etwa den Datenfluss. Es spielt eine Rolle im interaktiven Zusammenspiel der gegenläufigen Datenflüsse.

13 XI 16 Bit Prüfsumme (checksum) Diese Prüfsumme bezieht sich auf TCP-Header und TCP-Daten. 16 Bit Fenstergröße (window) Diese Zahl gibt an, wieviel Bytes mit noch nicht eingegangener Bestätigung maximal in einer Flussrichtung noch versandt werden dürfen. Die variierende Fenstergröße ist die Methode von TCP der Datenratenanpassung. Es ist klar, dass eine geringe Fenstergröße ein geringe Datenrate verursacht und eine große Fenster hohen Datendurchsatz erst ermöglichen kann. 16 Bit urgent pointer wird hier nur der Vollständigkeit halber erwähnt und nicht weiter vorgestellt. Variables Optionsfeld Die am häufigsten verwendete Option ist die der maximalen Segmentgröße. Hier teilt der Empfänger dem Sender die gewünschte maximale Segmentlänge (MSS: Maximum Segment Size) bei Verbindungsaufbau mit. Variables Datenfeld Hier stehen die Anwendungsdaten. Dieses Feld ist optional und tatsächlich gibt es bei Verbindungsaufbau, Beendigung und gelegentlich bei Bestätigung TCP-Pakete ohne dieses Datenfeld (Die Länge dieses Datenfelds ergibt sich aus der Gesamtlänge des Segments, das im Header des umgebenden IP- Datagramms mitgeteilt wird) Verbindungsaufbau Zumeist handelt es sich bei TCP-Verbindungen um eine Client-Server-Beziehung. In diesem Fall wird eine TCP-Verbindung durch drei Segmente aufgebaut, wie in Abbildung 2.2 gezeigt. Abbildung 2.2: Verbindungsaufbau von TCP 1. Im ersten Segment sendet der Client ein SYN-Segment mit der initialen Sequenznummer (und natürlich mit dem gewünschten Ziel-Port). 2. Der Server antworte mit einem SYN-Segment mit seiner initialen Sequenznummer und bestätigt mit diesem Segment durch ACK-Flag und Bestätigungsnummer (Sequenznummer des Client +1) das erste Segment des Client. 3. Der Client bestätigt das SYN-Segment des Servers durch ein ACK-Segment mit Bestätigungsnummer (= Sequenznummer des Servers +1). TCP legt hierbei auch mit dem SYN-Segment die maximale Segmentgröße (MSS) fest. Dies geschieht dadurch, dass jeder Empfänger dem Sender die Segmentgröße, die er empfangen möchte, mitteilt. Problematisch bei diesem einfachen Protokoll ist, dass nicht getestet wird, ob diese Paketgröße auch tatsächlich

14 XII KAPITEL 2. TCP übermittelt werden kann (Beispielsweise kann ein Router oder eine dazwischen genutztes Netzwerk hierbei gewissen Einschränkungen unterliegen). Es sei hier erwähnt, dass IP Datagramme deren Länge die maximale Übertragungseinheit einer Rechner zu Rechnerverbindung (MTU: Maximum Transmission Unit) überschreiten, zerlegt (fragmentiert) und am Zielrechner wieder zusammensetzt. So ein Vorgang verringert natürlich den Datendurchsatz und erhöht die Fehleranfälligkeit. Neben dieser Art des Client-Server-Verbindungsaufbaus erlaubt TCP auch andere Varianten des Verbindungsaufbaus [Ste95] Verbindungsende TCP erlaubt einen so genannten half-close, d.h. die gegenläufigen Datenströme können unabhängig voneinander beendet werden. Ist ein Datenstrom beendet durch ein half-close, können noch Daten in der Gegenrichtung übermittelt werden. Abbildung 2.3: half-close Für ein half-close werden zwei Segmente benötigt (Abbildung 2.3): 1. Der Sender (einer Datenrichtung) verschickt ein FIN-Segment. 2. Der Empfänger bestätigt dies durch ein ACK-Segment. Für das vollständige Schließen einer TCP-Verbindung werden daher 4 Segmente benötigt wegen zweier Half-Close-Operationen (Abbildung 2.4). Abbildung 2.4: schließen einer TCP-Verbindung Bestätigungen Wie schon bei der Beschreibung des TCP-Headers erwähnt wurde, werden die Anwendungsdaten durch die Sequenznummern durchnummeriert. Jedes TCP-Paket mit Daten muss bestätigt werden. Pakete, die keine Daten tragen und nur aus Bestätigungen bestehen, werden nicht bestätigt. Diese verursachen natürlich auch keine Erhöhung der Sequenznummer. TCP nutzt nun die gegenläufigen Datenströme, um Bestätigungen in einer Richtung per Huckepack mit Daten aus der Gegenrichtung zu befördern. Ferner müssen Segmente nicht einzeln bestätigt werden. Sind alle Segmente bis zum Datenbyte mit Sequenznummer i korrekt eingetroffen, wird lediglich eine Bestätigungsnummer i+1 zurückgeschickt, unabhängig davon, wie viele Pakete seit der letzten Bestätigung

15 2.1. DATENFLUSSKONTROLLE DURCH TCP XIII eingetroffen sind. Tatsächlich wird bei jedem Segment (außer bei Verbindungsaufbau und Ende) das ACK- Flag gesetzt und mit der Bestätigungsnummer das als nächstes erwartete Datenbyte mitgeteilt. Um weiter Segmente einzusparen, arbeitet TCP mit verzögerten Bestätigungen (delayed acknowledgements). Hat die eine Seite keine Daten zu senden, wartet sie zwischen den reinen Bestätigungspaketen eine Mindestzeit (z.b. 200 ms), um einkommende Segmente zu sammeln. Eine weitere Technik, um die Paketanzahl auf Verbindungen mit geringen Datenfluss (wie z.b. in Telnet-Sitzungen) zu verringern, ist der Algorithmus von Nagle. Der Algorithmus verhindet den Versand von zu kleinen TCP-Paketen (kleiner als die Segmentgröße), solange noch Bestätigungen von verschickten TCP-Paketen ausstehen. Diese Daten werden gesammelt bis sie die vereinbarte Segmentgröße erreichen oder bis die ausstehenden Bestätigungen eingetroffen sind. Der Vorteil von Nagles Algorithmus ist die Selbsttaktung. Für schnelle Verbindungen werden mehr kleinere TCP-Pakete verschickt, während für langsame Verbindungen die Paketanzahl verringert wird. Nagles Algorithmus lässt sich deaktiveren, was in bestimmten Situationen Sinn ergibt (wenn z.b. ein X Windows Client die Bewegungen einer Maus übertragen muss). 2.1 Datenflusskontrolle durch TCP Das Routing-Protokoll IP kümmert sich nicht um eine faire und effiziente Ausnutzung der Verbindungsressourcen. Diese Aufgabe muss die Transportschicht übernehmen. Wir stellen nun die verschiedenen Mechanismen hierfür vor Exponentielles Rückweichen (exponential backoff) TCP unterhält unter anderen eine retransmission timout (RTO) Variable, die den minimalen Zeitraum (von z.b. 1 Sekunde) vorgibt, nach dem ein verlorenes Segment als solches erkannt wird und es erneut verschickt werden darf. Bleibt also die Bestätigung für ein Paket aus, wartet TCP mindestens den Zeitraum der in dieser Variablen beschrieben wird und sendet dann das Paket nochmal. Das Besondere hierbei ist, dass nach jedem erfolglosen Senden eines Pakets dieser Wert verdoppelt wird, bis er eine obere Grenze von 64 Sekunden erreicht hat und dort verbleibt. Erreicht den Sender die Bestätigung des Segments, wird der RTO-Timer auf seinen Anfangswert zurückgesetzt Round Trip Time Ein Paketverlust lässt in mehr als 99% aller Fälle den Schluss zu, dass es zu einem Datenstau (congestion) auf einem Router gekommen ist [Jac88]. Woher weiß man aber, dass ein Paket verloren ist und nicht etwa nur das ACK-Segment verzögert worden ist? Es gibt keine sichere Methode letzteres auszuschließen. TCP unterhält hierfür eine Stoppuhr, welche die Zeitdauer zwischen Paket und Bestätigung überprüft. Ist diese Zeitdauer größer als die RTT, gilt das Paket als verloren. Die Umlaufzeit (RTT) unterliegt gewissen Schwankungen, um daher nicht häufiger als nötig tatsächlich angekommene Pakete als verloren abzuschreiben. Ursprünglich (in RFC793) wurde daher der Retransmission Timeout Value (RTO) folgendermaßen bestimmt. Zuerst wird, sobald ein neuer Meßwert M für RTT verfügbar ist, ein geglätteter Schätzwert von RTT berechnet: R αr + (1 α)m, wobei α = 0,9 gewählt wird. Mit Hilfe von R bestimmt sich RTO als RTO = βr, wobei β als Varianzfaktor mit β = 2 empfohlen wird. In [Jac88] wird beschrieben, dass dieser Mechanismus nicht in der Lage ist, mit den enormen Umlaufzeitschwankungen fertig zu werden, was unnötigen Wiederversand von Daten erfordert. Daher wird

16 XIV KAPITEL 2. TCP in [Jac88] folgende Methode vorgeschlagen. Wie eben wird mit jeder neuen Messung der Umlaufzeit M folgende Berechnung durchgeführt (bei geeigneter Initialisierung von A und D beim ersten Meßwert): A A + g (M A), D D + h ( M A D), RTO A + 4D. Herbei werden die Werte g = 1/8 und h = 1/4 verwendet. In A wird eine geglättete Abschätzung für RTT gespeichert, während D die durchschnittliche Abweichung der Umlaufzeit RTT vom Schätzwert geglättet darstellt 3. Diese Aktualisierung darf nicht angewendet werden, wenn Pakete mehrfach übertragen worden sind, weil möglicherweise zwei Bestätigungen für ein Paket existieren und ein falscher Zeitraum M der Berechnung zugrundeliegen würde [KP87]. Dann wird der durch evtl. exponentielles Zurückweichen gewählte Wert von RTO für das nächste Paket noch einmal zugrunde gelegt Gleitende Fenster (sliding windows) Die Datenratenanpassung von TCP basiert auf der Methode der gleitenden Fenster (sliding windows). Ein Parameter hierfür ist die Fenstergröße (window size/wnd), mit welcher der Empfänger die Datenmenge des Sender steuern kann, wie in Abbildung 2.5 gezeigt wird. Abbildung 2.5: gleitendes Fenster Wenn zum Beispiel die Eingangswarteschlange eines Empfängers überfüllt ist, (weil der Empfänger langsamer arbeitet als der Sender) dann wird mit dem nächsten Bestätigungspaket die Fenstergröße auf 0 gesetzt. Der Sender ist dann nicht mehr in der Lage, ein weiteres Datenpaket zu senden, weil noch die Bestätigungen für die versandten TCP-Pakete ausstehen. Hat der Empfänger seine Warteschlange entsprechend abgearbeitet, wird er eine weitere Bestätigung schicken, die sich von der ersten nur durch die erhöhte (Anfangs-) Fenstergröße unterscheidet. Wie in Abbildung 2.5 zu sehen, bezeichnen wir nun als Fenster die Menge der nicht bestätigten Daten in einer Flussrichtung. Die Fenstergröße wird vom Empfänger gesteuert und kann folgendermaßen verändert werden: Das Fenster schliesst sich, wenn das linke Ende nach rechts wandert. Dies passiert, wenn Daten bestätigt werden. Das Fenster öffnet sich, wenn das rechte Ende nach rechts weiterläuft. Damit können mehr Daten gesendet werden. Dies geschieht insbesondere, wenn der Empfänger TCP-Pakete bestätigt und damit Platz in seinem Eingangspuffer schafft. 3 Bei der Beschreibung dieser Berechnung haben eine Menge praktischer Fragestellung im Vordergrund gestanden. Zum Beispiel sind alle Konstanten Zweier-Potenzen. Die Standardabweichung wurde nicht verwendet, weil sonst eine Quadratwurzel berechnet werden muss.

17 2.1. DATENFLUSSKONTROLLE DURCH TCP XV Eine absolute Ausnahme gemäß der Host Requirement RFC sollte der folgende Vorgang sein: Das Fenster schrumpft, wenn das rechte Ende sich nach links bewegt. Der Empfänger verringert mit einer Bestätigung die Fenstergröße um mehr als die damit bestätigte Datenmenge. Von dieser Art der Fensterveränderung wird abgeraten. Dennoch müssen TCP-Protokollen sie unterstützen Slow Start Tatsächlich darf der Sender die angebotene Fenstergröße einer TCP-Verbindung nicht von Anfang an voll nutzen. In lokalen Netzwerken wäre dies in der Regel kein Problem, in größeren Netzwerken kann das jedoch auf den Routern zu Netzwerkstauungen und damit Datenverlust kommen. Damit kommt ein weiterer Fenstermechanismus ins Spiel, nämlich das Congestion-Fenster (cwnd), welches in Vielfachen der Segmentgröße verwaltet wird. Im Gegensatz zum Fenster, wird das Congestion- Fenster vom Sender verwaltet. Auch das Congestion-Fenster beschränkt die Anzahl der gesendeten unbestätigten Daten. Damit kann der Sender maximal min{cwnd, wnd} an unbestätigten Daten versenden oder versandt haben. Der Slow-Start-Mechanismus arbeitet wie folgt: Wird eine Verbindung aufgebaut, wird das Congestions-Fenster auf die Paketgröße (gegeben durch die maximale Segmentgröße MSS) gesetzt. cwnd 1 MSS Damit kann anfangs nur ein (volles) TCP-Paket verschickt werden. Wird ein Paket bestätigt (durch Erhalten eines ACK-Segments), wird das Congestion-Fenster um die maximale Segmentgröße vergrößert: cwnd cwnd + MSS. Die maximal mögliche Fenstergröße ergibt sich aus der Kapazität, dem Produkt aus Bandweite (Bytes/Sek.) und der Umlaufzeit (Sek.) (round trip time/rtt): Maximale Fenstergröße wnd(bytes) = Bandweite (Bytes/Sek.) Umlaufzeit (Sek.). Letzteres ist die Zeit, die zwischen Senden eines Pakets und Empfang der Bestätigung vergeht. Leider steht TCP diese Information nicht zur Verfügung und TCP muss daher auf eine Probing-Strategie zurückgreifen, wie im letzten Abschnitt besprochen. Zur Veranschaulichung dieses Algorithmus bezeichnen wir mit x die Anzahl der Pakete, die innerhalb einer Umlaufzeit versandt werden dürfen unter Berücksichtigung von cwnd, d.h. Demnach gliedert sich slow start in zwei Teile. x = cwnd MSS. 1. Zu Beginn setzen wir x Mit jedem Paket wetzen wir x x + 1. Da dies maximal x-mal geschehen kann während der Umlaufzeit setzen wir im besten Fall: x 2x. Damit realisiert Slow-Start im optimalen Fall (wenn alle Pakete bestätigt werden und wenn wnd ausreichend groß ist) exponentielles Wachstum der Bandbreite.

18 XVI KAPITEL 2. TCP Stauvermeidung (Congestion Avoidance) Der AIMD-Mechanismus, den wir in einer vereinfachten Version schon vorgestellt haben, wird bei TCP folgendermaßen umgesetzt [Jac88]. Die entscheidenden Parameter sind die Congestion-Fenstergröße cwnd, und ein Slow-Start-Schwellwert ssthresh (Slow Start Threshold Size). Wir bezeichnen mit y = ssthresh/mss. 1. Beim Verbindungsaufbau wird das Congestion-Fenster auf die maximale Segmentgröße (MSS) gesetzt cwnd MSS und der Slow-Start-Schwellwert auf die maximale Fenstergröße: In der Notation mit x und y bedeutet dies: ssthresh = x 1, y max. 2. Kommt es zu einem Paketverlust, d.h. eine Bestätigung eines Pakets erreicht den Sender nicht innerhalb des aktuell berechneten Zeitraums RTO oder eine Reihe von Acknowledgements des selben Pakets treffen ein, dann wird ein Datenstau (congestion) angenommen. Nun werden folgende Aktualisierungen durchgeführt: { ssthresh max 2 MSS, cwnd MSS. } min{cwnd, wnd}, 2 Wenn wir wieder annehmen, dass wnd ausreichend groß ist und dass cwnd mindestens 4MSS ist, bedeutet das: x 1, y x Werden Daten bestätigt und ist cwnd ssthresh, wird Slow Start durchgeführt. Wird also ein Paket bestätigt, erhalten wir cwnd cwnd + MSS. Werden alle Pakete innerhalb der Zeit RTO bestätigt, verdoppelt sich das Fenster innerhalb der Umlaufzeit (RTT). Setzen wir x = cwnd/mss, stellt sich also nach O(log x) Umlaufzeiteinheiten (Vielfachen von RTT) x x 2 ein. 4. Werden Daten bestätigt und ist cwnd > ssthresh, befindet der Algorithmus sich in der Congestion Avoidance-Phase. Hier wird die Congestion-Fenstergröße langsamer erhöht: cwnd cwnd + MSS cwnd. Hierbei handelt es sich um eine lineare Zunahme der Datenmenge, wie folgende Überlegung zeigt. Die Gesamtmenge an Daten, die innerhalb der Umlaufzeit RTT übertragen wird, ist cwnd. Die Datenrate ist damit w = cwnd/rtt. Diese Menge wird nun für jedes der cwnd TCP-Pakete innerhalb der Umlaufzeit RTT um MSS cwnd = MSS cwnd

19 2.1. DATENFLUSSKONTROLLE DURCH TCP XVII Bytes erhöht 4. Damit erhöht sich sich die Datenrate um d = MSS /RTT, d.h. pro Umlaufzeit nur um ein Paket. Wir erhalten also x x + 1. Der AIMD-Algorithmus aus dem vorhergehenden Abschnitt beschreibt also diesen Prozeß (bis auf den Slow-Start-Mechanismus) recht genau. In Abschnitt 2.2 werden wir die Motivation für dieses Verfahren kennenlernen Fast Retransmit und Fast Recovery Geht nun nur ein einziges TCP-Paket verloren, so hat das drastische Auswirkungen auf das Übertragungsverhalten einer TCP-Verbindung. So wird nicht nur die Datenrate auf den kleinstmöglichen Wert gesetzt, sondern auch noch alle TCP-Pakete, die nach dem Paket verschickt worden sind, müssen wegen des Bestätigungsmechanismus als verloren angesehen werden. Deswegen wurde 1990 in [Jac90] das Fast Retransmit and Fast Recovery Verfahren vorgeschlagen. Der Fast-Retransmit-Mechanismus tritt in Aktion, wenn drei Bestätigungen der selben Bestätigungsnummer (triple duplicate ACK) beim Sender eingegangen sind. Dies signalisiert dem Sender, dass nach einem fehlenden TCP-Pakete weitere TCP-Pakete empfangen wurden. Der Sender schickt daher als nächstes Paket nochmal jenes, das der dreimal wiederholten Bestätigungsnummer entspricht. Ansonsten verschickt der Sender keine weiteren Kopien, sondern schickt neue TCP-Pakete, sofern die Fenstergröße dies noch zulässt. Der Fast-Recovery-Mechanismus verhindert nun nach dem Empfangen eines Triple-Duplicate-Ack einen Slow-Start. Vielmehr wird die Congestion-Fenstergöße direkt auf die Hälfte der ursprünglichen Fenstergröße gesetzt. Außerdem wird jede weitere Kopie einer Bestätigung als Bestätigung eines späteren Pakets interpretiert und damit das Congestion-Fenster um ein Segment erweitert. Im einzelnen wird fast retransmit und fast recovery wie folgt implementiert. Hierbei finden die folgende Schritte statt der Punkte des Congestion-Avoidance-Algorithmus Anwendung, sofern eine dreifache Bestätigung des selben Pakets festgestellt wird. 1. Wird eine dritte Bestätigung des selben Segments erhalten, setze ssthresh min{cwnd, wnd} 2 und sende das fehlende Segment ein zweites Mal. Außerdem wird die Congestion-Fenstergröße, wie folgt, gesetzt. cwnd ssthresh + 3 MSS. 2. Trifft danach eine weitere Bestätigung des selben Segments ein, setzt der Sender cwnd cwnd + MSS und versucht, falls es die Fenstergrößen erlauben, ein weiteres Segment zu verschicken. 3. Erscheint nach der Folge der Bestätigungen des selben Segments eine Bestätigung eines anderen Segments, bestätigt dies den Erhalt des verlorenen Pakets. Nun wird das Congestion-Fenster wie folgt gesetzt. cwnd ssthresh. Damit befinden wir uns wieder im congestion-avoidance-mechanismus, da wir ab jetzt nur die Hälfte der ursprünglichen Datenrate verwenden. 4 Natürlich müsste man eigentlich hier verschiedene Werte für cwnd zugrunde legen. Hiermit würde sich das Ergebnis aber nur um einen konstanten Faktor ändern.

20 XVIII KAPITEL 2. TCP 2.2 Fairness und Effizienz von AIMD In diesem Abschnitt motivieren wir den AIMD-Mechanismus (additively increasing/multiplicatively decreasing) zur Stauvermeidung (congestion avoidance) gemäß [CJ89]. In Abbildung 2.6 wird gezeigt, wie typischerweise in einem Netzwerk Datenlast (load) mit Antwortzeit und Datendurchsatz interagieren. Der Datendurchsatz ist maximal, wenn die Last die Netzwerkkapazität fast erreicht. Wird die Last weiter erhöht, nimmt der Datendurchsatz ab, da Datenpuffer überlaufen und Pakete verloren gehen und mehrfach versendet werden müssen. Dadurch steigt auch die Antwortzeit extrem an. Diese Situation einer Datenstauung wird congestion genannt. Abbildung 2.6: Knie und Klippe des Durchsatz und der Antwortzeit Statt ein Netzwerk mit dieser extremen Lastanforderung zu betreiben, empfiehlt es sich, die Last auf das so genannte Knie einzustellen. Beim Knie steigt die Antwortzeit erstmals an, während der Datendurchsatz schon nahe der Netzwerkkapazität ist. Eine gute Stauvermeindungsstrategie (congestion avoidance) versucht die Datenlast des Netzwerks bei diesem Knie zu halten. Neben dem Datendurchsatz ist es aber auch wichtig, dass die Datenraten aller Teilnehmer gleich sind, also fair gewählt werden Das Modell Im Netzwerk nehmen n Nutzer teil. Das System wird in Runden modelliert. Zu Beginn (in Runde 0) hat Teilnehmer i [1..n] Datenrate x i (0) [0,B]. In jeder weiteren Runde t kann der Teilnehmer seine Datenrate auf x i (t) [0,B] setzen. Als Information steht ihm in Runde t + 1 neben seiner alten Datenrate nur zur Verfügung, ob in der Runde t die Summe der Datenraten das Ziel K [0,B] überschritten hat, d.h. ob x i (t) K. wobei K für die Datenlast an der oben beschreibenen Knieposition steht. Wir bezeichnen mit dem Prädikat y(t) = 0, dass in Runde t diese Ungleichung erfüllt wird und mit y(t) = 1 das Gegenteil. Jeder Teilnehmer bestimmt nun in Runde t + 1 aufgrund von y(t) und seiner alten Datenratewahl x i (t) die Datenrate der nächsten Runde. Diese Entscheidung beschreiben wir durch eine Funktion f : [0,B] {0,1} [0,B], wobei für alle i [1..n] gilt x i (t + 1) = f(x i (t),y(t)).

21 2.2. FAIRNESS UND EFFIZIENZ VON AIMD XIX Das bedeutet insbesondere, dass alle Teilnehmer sich an die selbe Datenratenanpassungsstrategie f halten. Damit wenden alle Teilnehmer in Runde t + 1 entweder die Funktion f 0 (x) = f(x,0) oder f 1 (x) = f(x,1) an. Damit ergibt sich die Grundanforderungen an f 0 und f 1 : Wenn y(t) = 0, also n x i(t) K, sollen Teilnehmer ihre Datenrate geeignet erhöhen, d.h. f 0 (x) > x. Wenn y(t) = 1, also n x i(t) > K, sollen Teilnehmer ihre Datenrate geeignet verringern, d.h. f 1 (x) < x. Hierbei ist nicht unmittelbar klar, ob diese Eigenschaft für alle Spieler gelten muss. Wir möchten daher die Wahl der Funktionen f 0 und f 1 eine Funktionenklasse zugrunde legen und diese gemäß einiger Schlüsselkriterien untersuchen. In diesem Abschnitt beschränken wir uns für die Wahl der Funktionen f 0 und f 1 auf lineare Funktionen: f 0 (x) = a I + b I x und f 1 (x) = a D + b D x. Als besonders interessante Spezialfälle werden hierbei folgende gesondert betrachten: 1. Multiplicative Increase/Multiplicative Decrease (MIMD) wobei b I > 1 und b D < Additive Increase/Additive Decrease (AIAD) wobei a I > 0 und a D < 0. f 0 (x) = b I x und f 1 (x) = b D x, f 0 (x) = a I + x und f 1 (x) = a D + x, 3. Additive Increase/Multiplicative Decrease (AIMD) wobei a I > 0 und b D < 1. f 0 (x) = a I + x und f 1 (x) = b D x, Bewertungskriterien Die Schlüsselkriterien sind Effizienz, Fairness und Konvergenz. Effizienz Die Effizienz wird durch die Nähe der Gesamtlast X(t) := x i (t) an der Knielast K gemessen. Ist X(t) > K verlängert sich die Antwortzeiten und ist sogar X(t) > B, gehen Datenpakete verloren und müssen wieder versandt werden. Ist dagegen X(t) < K entstehen Opportunitätskosten dadurch, dass die Netzwerkkapazität nicht ausgenutzt wird. Als Effizienzmaß betrachten wir daher X(t) K. Ist die Last effizient gewählt, erhalten wir 0, ansonsten positive Werte, die wie das milde Kostenmaß linear vom Optimalwert zunehmen.

22 XX KAPITEL 2. TCP Fairness Die Datenraten verschiedener Teilnehmer sind absolut fair, wenn für alle i,j gilt x i (t) = x j (t). Wir möchten aber mit einem Parameter aus dem Bereich [0, 1] den Grad der Fairness einer bestimmten Konstellation beschreiben. Für x = (x 1,...,x n ) definieren wir daher für alle x (R + 0 )n \ {(0,...,0)} : F(x) = ( n x i) 2 n n (x i) 2. Dieses Fairnessmaß besitzt folgende Eigenschaften: a) Es gilt für alle x (R + 0 )n \ {(0,...,0)}: F(x) [ 1 n,1], wobei F(x) = 1 äquivalent zu absoluter Fairness ist, d.h. x 1 = x 2 =... = x n. Je kleiner F wird, desto unfairer wird die Wahl der Datenraten. Sind alle Datenraten bis auf einem Spieler 0, so erreicht die Funktion ihr Minimum mit F(x) = 1 n. b) Dieses Fairnessmaß ist skalierungsunabhängig, d.h. die genaue Lastgröße ist nicht von der eigentlichen Größe der Datenraten abhängig. c) Die Fairnessfuntion ist kontinuierlich, stetig und differenzierbar. Selbst kleinere à nderungen sind deswegen meßbar. d) Wennn k von n Teilnehmern eine faire Aufteilung erreichen, aber n k Teilnehmer keine Datenraten erhalten, ergibt sich eine Fairness von F(x) = k n. Konvergenz Aufgrund des binären Feedbacks, können wir keine Konvergenz erwarten. Im besten Fall oszilliert das System, wobei Effizienz und Fairness innerhalb bestimmter Grenzen bleiben. Wir unterscheiden hier zwischen der Einschwingzeit und der Amplitude der Oszillation, siehe Abbildung 2.7 (in [CJ89] responsiveness und smoothness genannt). Abbildung 2.7: Oszillation Die Oszillationsamplitude A wird beschrieben durch Als Einschwingzeit T erhalten wir daher A = inf t 0 0 sup t t 0 X(t) K. T = min{t 0 t t 0 : X(t) K A}.

23 2.2. FAIRNESS UND EFFIZIENZ VON AIMD XXI Faire und effiziente Datenratenwahl Vektordarstellung Für zwei Teilnehmer kann man dieses System sehr gut grafisch untersuchen. In Abbildung 2.8 wird die Datenrate x 1 des ersten Teilnehmer und die Datenrate x 2 eines zweiten Teilnehmers als Punkt (x 1,x 2 ) dargestellt. Die Effizienzlinie bezeichnet alle Punkte, die die Netzwerklast X im optimalen Bereich K halten, d.h. x 1 + x 2 = K. Punkte unter dieser Linie stehen für Netzwerkzustände, die das Netzwerk zu wenig belasten, Punkte darüber für eine Überlastung des Netzwerks. Abbildung 2.8: Vektordarstellung Mit der Fairnesslinie werden alle Punkte mit x 1 = x 2 dargestellt. Je nachdem, ob man über oder unter dieser Linie steht, erhält x 2 oder x 1 mehr Datenrate. Für Datenraten (x 1,x 2 ) bezeichnen Datenraten (x 1 + c,x 2 c) Netzwerkzustände gleicher Effizienz, da X = x 1 + x 2 konstant bleibt. Multipliziert man dagegen die Datenraten mit einem Faktor c > 0, so erhält sich die Fairness, wie man wie folgt sieht: F(cx 1,cx 2 ) = (cx 1 + cx 2 ) 2 2((cx 1 ) 2 + (cx 2 ) 2 ) = (x 1 + x 2 ) 2 2((x 1 ) 2 + (x 2 )) 2 = F(x 1,x 2 ). In Die Punkte gleicher Effizienz und gleicher Fairness wie (x 1,x 2 ) sind durch getrichelte Linien dargestellt. Mit Hilfe dieses Diagramms kann man nun leicht die Schwächen der AIAD- und MIMD-Strategie beschreiben. Wählt man die AIAD-Strategie (Additive Increase/Additive Decrease), so bewegen sich die Datenraten auf einer Linie (x 1 + y,x 2 + y). Hiermit ist es zwar möglich sich der Effizienzlinie bis auf einen additiven Term von max{a I, a D } (entspricht der Oszillationsamplitude) anzunähern, es ist aber nicht möglich die Fairness zu verbessern (Abbildiung 2.9). Bei der MIMD-Strategie (Abbildung 2.10) können nur Zustände erreicht werden, die durch die Gerade (cx 1,cx 2 ) für variables c beschrieben werden. Alle Punkte dieser Gerade stehen für Netzwerkzustände gleicher Fairness. Es ist also unmöglich, mit MIMD die Fairness zu verbessern. Daneben kann der Schnittpunkt mit der Effizienzlinie nur mit dem Faktor max{b I,1/b D } approximiert werden. Abbildung 2.11 zeigt, dass die AIMD-Strategie für zwei Spielern anscheinend den Kriterien von Fairness und Effizienz genügt. Um dies zu verifizieren, werden wir zuerst den allgemeinen Fall linearer Funktionen untersuchen.

24 XXII KAPITEL 2. TCP Abbildung 2.9: AIAD Effizienz Um eine beschränkte Oszillation um die Effizienzlinie zu garantieren, muss, falls X(t) > K vorliegt, gelten X(t + 1) < X(t). Das heißt, dass X(t + 1) < X(t) x i (t + 1) < a D + b D x i (t) < na D + (b D 1)X(t) < 0 x i (t) x i (t) b D < 1 na D X(t). Ist a D 0, so folgt hieraus b D 1, da diese Ungleichung für jede Kombination aus n und X(t) gelten muss. Ist a D positiv, kann der Fall X(t) na D auftreten. Deswegen muss b D dann negativ gewählt werden. Analog muss für X(t) < K gelten X(t + 1) > X(t) und damit erhalten wir folgendes. X(t + 1) > X(t) x i (t + 1) > a I + b I x i (t) > na I + (b I 1)X(t) > 0 x i (t) x i (t) b I > 1 na I X(t). Diese Ungleichung muss für alle n und alle X(t) B gelten. Wir müssen davon ausgehen, dass jede

25 2.2. FAIRNESS UND EFFIZIENZ VON AIMD XXIII Abbildung 2.10: MIMD positive Kombination aus n und X(t) vorliegen kann. Damit also die letzte Ungleichung immer erfüllt wird, muss falls a I 0 der Wert b I 1 gewählt werden. Ist a I < 0 und insbesondere a I = k, dann muss für alle n, X(t) gelten b I > 1 + k n X(t). Damit muss b I mit der Anzahl der Teilnehmer steigen. Dieses wollen wir prinzipiell ausschließen. Damit ist a I 0 zu wählen (und gleichzeitig b I 1). Fairness Wir möchten sicherstellen, dass die Fairness von x(t) = (x 1 (t),...,x n (t)) gegen 1 konvergiert, d.h. Für F(x(t + 1)) erhalten wir: lim F(x(t)) = 1. t F(x(t + 1)) = F(x(t)) + (1 F(x(t))) ( 1 ) n (x i(t)) 2 n (c + x i(t)) 2, (2.1) wobei c = a b wie die nun folgende Nebenrechnung zeigt. Wir erhalten direkt F(x(t + 1)) = = ( n x i (t + 1) n ) 2 = (x i (t + 1)) 2 ( n a + bx i (t) n ) 2 (a + bx i (t)) 2 ( n ) 2 ( n ) 2 a b + x i(t) c + x i (t) ( a ) =, wobei c = 2 a n b + x i(t) n (c + x i (t)) 2 b.

26 XXIV KAPITEL 2. TCP Abbildung 2.11: AIMD Für eine übersichtliche Darstellung schreiben wir für c = a b X = x i (t), Q = In dieser Notation ist und entsprechend Es ist also zu zeigen, dass L = (x i (t) + c), R = F(x(t)) = X2 nq F(x(t + 1)) = L2 nr. (x i (t)) 2, (x i (t) + c) 2. ( F(x(t + 1)) = F(x(t)) + (1 F(x(t))) 1 Q ) R L 2 nr = X2 nq + )( (1 X2 1 Q ) nq R QL 2 = RX 2 + ( nq X 2) (R Q) QL 2 = RX 2 + nqr nq 2 RX 2 + QX 2 L 2 = nr nq + X 2 Nun ist L 2 X 2 = n(r Q). n(r Q) = n (x i (t) + c)) 2 x i (t) 2 = n (2cx i (t) + c 2 ) = 2cnX + c 2 n 2.

27 2.2. FAIRNESS UND EFFIZIENZ VON AIMD XXV Für die andere Seite gilt, da ( i a i) 2 = i,j a ia j, das Folgende. L 2 X 2 = i,j [1..n] (x i (t)+c)(x j (t)+c) x i (t)x j (t) = i,j [1..n] cx i (t)+cx j (t)+c 2 = 2cnX +c 2 n 2. Dies beweist Gleichung 2.1, die wir hier noch einmal wiedergeben: ( ) n F(x(t + 1)) = F(x(t)) + (1 F(x(t))) 1 (x i(t)) 2 n (c + x i(t)) 2. Der letzte multiplikative Term nimmt mit wachsenden c zu. Für c = 0 ist dieser Term 0, daher muss er für c < 0 negativ sein und für c > 0 positiv. Damit die linearen Funktion für die Konstanten a I,b I und a D,b D die Fairness nicht verschlechtern muss gelten: a I b I 0 und a D b D 0. Das bedeutet, dass a und b das gleiche Vorzeichen haben müssen. Negative Werte machen für a und b keinen Sinn, also muss gelten a,b 0. Außerdem macht es keinen Sinn b I = 0 oder b D = 0 zu setzen, da dann die Datenraten auf bestimmte konstante Werte zurückgesetzt werden würden, was schlecht für die Oszillationssamplitude ist. Kombinieren wir also die Betrachtungen über sinnvolle Parametermöglichkeiten hinsichtlich der Effizienz und Fairness, erhalten wir a D = 0, 0 < b D < 1, a I 0 und b I 1. Die Decrease-Strategie verhält sich wegen a D = 0 neutral gegenüber der Fairness, deswegen muss die Increase-Strategie ai b I > 0 garantieren,, um die Fairness zu erhöhen. Das impliziert a I > 0. Wir halten also fest: Theorem 1 Werden für f 0 und f 1 lineare Funktionen gewählt, die Fairness und Effizienz gewährleisten, muss für x 0 gelten: f 0 (x) x + a I, wobei a I > 0 und f 1 (x) = b D x, wobei 0 < b D < 1. Wir erkennen also, dass die Datenratenerhöhung einen additiven Anteil und die Datenratenverkleinerung einen multiplikativen Anteil haben muss, was die Wahl einer AIMD-Strategie rechtfertigt.

28 XXVI KAPITEL 2. TCP

29 Literaturverzeichnis [BEY98] [CJ89] Allan Borodin and Ran El-Yaniv. Online Computation and Competitive Analysis. Cambridge University Press, Cambridge, Dah-Ming Chiu and Raj Jain. Analysis of the increase and decrease algorithms for congestion avoidance in computer networks. Computer Networks and ISDN Systems, 17:1 14, [Jac88] Van Jacobson. Congestion Avoidance and Control. In ACM SIGCOMM 88, volume 18, 4, pages ACM SIGCOMM, ACM Press, August Stanford, CA. [Jac90] V. Jacobson. Modified tcp congestion avoidance algorithm. end2end-interest mailing list, April [KKPS00] Richard Karp, Elias Koutsoupias, Christos H. Papadimitriou, and Scott Shenker. Optimization problems in congestion control. In 41st Annual Symposium on Foundations of Computer Science (FOCS 00), pages 66 74, [KP87] P. Karn and C. Partridge. Improving round-trip time estimates in reliable transport protocols. Computer Communication Review, 17(5):2 7, [Pos81] J. Postel. Transmission Control Protocol. Network Information Center RFC 793, pages 1 85, September [Pos87] J. Postel. Internet Protocol. TCP and IP Bake Off, pages 1 6, [PS01] Antonio Piccolboni and Christian Schindelhauer. Discrete prediction games with arbitrary feedback and loss. In 14th Annual Conference on Computational Learning Theory, (COLT 01) and 5th European Conference on Computational Learning Theory, (EuroCOLT 01), pages , [Ste95] W. R. Stevens. TCP/IP Illustrated, Volume 1; The Protocols. Addison Wesley, Reading, XXVII