Ermitteln der RTT Ein Sample RTT(i) bei gegebener Segment Sendezeit s und Acknowledgement Zeit a für das ite versendete Segment: Ein simpler Ansatz wäre das Stichprobenmittel darüber, also: Die gesamte Summation muss dabei nicht jedes mal neu berechnet werden: SS 2014 Grundlagen der Rechnernetze Transportschicht 21
Ermitteln der RTT Nachteil des einfachen Stichprobenmittels: jede Messung auch die in der weiten Vergangenheit haben dasselbe Gewicht Besser wäre es doch den aktuellen Messungen das meiste Gewicht zu geben Lösung exponentiell gewichteter gleitender Mittelwert (so ist es auch in der Original TCP Spezifikation in RFC 793) realisiert: Einfluss von? TCP verwendet zwischen 0,8 und 0,9. SS 2014 Grundlagen der Rechnernetze Transportschicht 22
Ermitteln der RTT Warum lautet dieser gleitende Mittelwert eigentlich exponentiell gewichtet? Expandieren liefert: Also z.b. für alpha=0,8: SS 2014 Grundlagen der Rechnernetze Transportschicht 23
Problem: Zuordnung von ACKs Sender Empfänger Sender Empfänger SampleRTT zu lang SampleRTT zu kurz Karn/Patridge Algorithmus: Ignoriere einfach die Segmente, die reübertragen wurden. Darüber hinaus: wann immer ein Segment reübertragen werden musste: Timeout = 2*Timeout (Exponential Backoff) SS 2014 Grundlagen der Rechnernetze Transportschicht 24
Einbeziehen der Varianz Warum eigentlich Timeout für Reübertragung = 2*EstimatedRTT? RTT ist variabel, d.h. man sollte einen Sicherheitsabstand (hier eine zusätzliche RTT) einhalten. Aber wieso ist genau eine zusätzliche RTT gut? Besser: berücksichtige die Varianz der RTT Messungen. Jacobson/Karels Algorithmus: schätze die folgende mittlere Abweichung: Hierbei ist E[X] der Erwartungswert von Zufallsvariable X. SS 2014 Grundlagen der Rechnernetze Transportschicht 25
Einbeziehen der Varianz Einfache Stichprobenvarianz lässt sich wie folgt berechnen: Analog zur mittleren RTT lassen sich hierbei ebenfalls durch exponentiell gleitenden Mittelwert neuere Varianzwerte höher gewichten als ältere. SS 2014 Grundlagen der Rechnernetze Transportschicht 26
Einbeziehen der Varianz Die komplette Berechnung nach Jacobson/Karels Algorithmus ist dann wie folgt: Hierbei ist nach der Originalveröffentlichung von Jacobson: g = 1/8 = 0,125 h = 1/4 = 0,25 f = 2 (bzw. später auch f=4 korrigiert) SS 2014 Grundlagen der Rechnernetze Transportschicht 27
Diskussion Bandbreite T1 (1,5 Mbps) Ethernet (10 Mbps) T3 (45 Mbps) Fast Ethernet (100 Mbps) OC 3 (155 Mbps) OC 12 (622 Mbps) OC 48 (2,5 Gbps) Zeit bis Sequenznummern verbraucht sind 6,4 Stunden 57 Minuten 13 Minuten 6 Minuten 4 Minuten 55 Sekunden 14 Sekunden Bandbreite T1 (1,5 Mbps) Ethernet (10 Mbps) T3 (45 Mbps) Fast Ethernet (100 Mbps) OC 3 (155 Mbps) OC 12 (622 Mbps) OC 48 (2,5 Gbps) Delay Bandbreiten Produkt für beispielsweise 100 ms RTT 18 KB 122 KB 549 KB 1,2 MB 1,8 MB 7,4 MB 29,6 MB Kurze Wraparound Zeit kann problematisch werden, wenn der Delay und Bandbreite groß sind. Alte Segmente interferieren mit aktuellen. Das Sendefenster erlaubt mit 16 Bit AdvertisedWindow Werten, dass maximal 64KB Daten unterwegs sind. Somit wird bei großem Delay eine große verfügbare Bandbreite kaum genutzt. Lösungen? TCP Erweiterungen... SS 2014 Grundlagen der Rechnernetze Transportschicht 28
TCP Erweiterungen 32 Bit Timestamp Speichere Sendezeit in Segment Wiederhole die Zeit im ACK Berechne RTT bei ACK Empfang Sender braucht keine Timestamps zu verwalten. Die sind im Netz gespeichert. 32 Bit Sequenznummern: Lösung der vorhin beschriebenen kurzen Wraparound Zeiten Verwende oben beschriebenen Timestamp Segmente mit gleichen SequenceNum Werten sind anhand des Timestamp unterscheidbar 0 4 10 16 31 SrcPort DstPort SequenceNum Acknowledgment HdrLen 0 Flags AdvertisedWindow Checksum UrgPtr Options (variable) Data Erinnerung: TCP Header SS 2014 Grundlagen der Rechnernetze Transportschicht 29
TCP Erweiterungen Scaling Factor für das 16 Bit Advertised Window Lösung der vorhin beschriebenen Ineffizienz bei hohem Delay Bandbreitenprodukt AdvertisedWindow Wert wird mit dem Scaling Factor multipliziert 0 4 10 16 31 SrcPort DstPort SequenceNum Acknowledgment HdrLen 0 Flags AdvertisedWindow Checksum UrgPtr Options (variable) Selective ACK (SACK) Verbesserung des kummulativen ACK von TCP. Neben dem gewöhnlichen Acknowledgement speichert das Optionale Feld zusätzliche Acknowledgements für die nicht aufeinander folgenden Segmente Sender braucht nur noch die Lücken zu reübertragen Data LastByteRead NextByteExpected LastByteRcvd SS 2014 Grundlagen der Rechnernetze Transportschicht 30
TCP Überlastkontrolle SS 2014 Grundlagen der Rechnernetze Transportschicht 31
Motivation Bisher haben wir die Flusskontrolle besprochen: Regulieren der Senderate, um eine Überlastung des Empfängers zu vermeiden. Wir interessieren uns nun für die Überlastkontrolle: Regulieren der Senderate, um eine Überlastung des ganzen Netzes zu vermeiden. Die TCP Flusskontrolle verwendet (wie schon gezeigt) das EffectiveWindow: es dürfen nur EffectiveWindow viele weitere Bytes versendet werden. Versenden von weiteren Bytes verkleinert das EffectiveWindow Empfang von Acknowledgements vergrößert das Window wieder Das EffectiveWindow kann auch für die Überlastkontrolle verwendet werden:... SS 2014 Grundlagen der Rechnernetze Transportschicht 32
EffectiveWindow für Fluss und Überlastkontrolle Annahme in der Variable CongestionWindow steht, wie viel Bytes das Netz im Transit erlaubt. Setze das EffectiveWindow wie folgt: Aber woher lernt TCP das CongestionWindow? Additive Increase / Multiplicative Decrease (AIMD): Sender halbiert das Fenster, wenn er Überlast vermutet Sonst vergrößere das Fenster um eine MSS pro RTT Das Fenster darf aber nie kleiner als eine MSS werden Wie kann man Überlast vermuten? Wann immer ein Timeout für ein ausstehendes ACK stattfindet. SS 2014 Grundlagen der Rechnernetze Transportschicht 33
Additive Increase Beispiel Source Destination Inkrement pro RTT: RTT Erhöhe um eine MSS Inkrement pro ACK? RTT Erhöhe um eine MSS RTT...... Erhöhe um eine MSS... Sei c die alte Länge des CongestionWindow. Nach einem RTT Durchlauf ist: SS 2014 Grundlagen der Rechnernetze Transportschicht 34
Ein typisches AIMD Muster CongestionWindow Größe Zeit SS 2014 Grundlagen der Rechnernetze Transportschicht 35
Slow Start Starte mit einem CongestionWindow der Länge MSS. Erhöhe CongestionWindow um eine MSS pro ACK. Somit wird das CongestionWindow pro RTT wie weit erhöht? Source RTT RTT RTT Destination Warum heißt das eigentlich Slow Start? Historischer Grund: In TCP Anfängen wurde zum Starten direkt mit einem großen CongestionWindow gestartet....... SS 2014 Grundlagen der Rechnernetze Transportschicht 36
Wann beginnt und endet der Slow Start? Wenn eine Verbindung neu hergestellt wurde. Setze CongestionWindow auf eine MSS Beginne Slow Start Wechsele in AdditiveIncrease sobald ein bestimmter Schwellwert (CongestionThreshold) überschritten wurde Wenn ein Timeout stattgefunden hat CongestionThreshold = CongestionWindow/2 (man merkt sich also den CongestionWindow nach dem durch den Timeout ausgelösten MultiplicativeDecrease) Setze CongestionWindow auf eine MSS Beginne Slow Start Wechsele in AdditiveIncrease sobald der Schwellwert CongestionThreshold überschritten wurde SS 2014 Grundlagen der Rechnernetze Transportschicht 37
Ein Beispiel Bildquelle: Andrew S. Tanenbaum, Computer Networks, Fourth Edition, 2003 SS 2014 Grundlagen der Rechnernetze Transportschicht 38
Fast Retransmit Erinnerung: ACKS sind kummulativ (d.h. bestätigen die bisher vollständig zusammenhängende Sequenz von Segmenten) Sender Paket 1 Paket 2 Paket 3 Paket 4 * Empfänger ACK 1 ACK 2 Verlorene Sequenz führt zu duplicate ACKs. Fast Retransmit: Warte nicht auf Timeout, sondern reübertrage ein Segment, nach drei aufeinander folgenden Duplicate ACKs. Paket 5 Paket 6 Paket 3 (retransmit) ACK 2 ACK 2 ACK 2 ACK 6 SS 2014 Grundlagen der Rechnernetze Transportschicht 39
Die TCP Variante mit Fast Recovery Slow Start, wenn die TCP Verbindung neu aufgebaut wurde. Die Reübertragung wegen duplicate ACK lediglich CongestionWindow wie üblich halbieren. Aber keinen Slow Start, sondern gewöhnlichen AdditiveIncrease. SS 2014 Grundlagen der Rechnernetze Transportschicht 40
TCP Überlastvermeidung SS 2014 Grundlagen der Rechnernetze Transportschicht 41
Motivation TCP implementiert Überlastkontrolle, d.h. erst wenn Segmente auf den Routern verworfen werden, wird an den Quellen die in das Netz gesendete Last reduziert. Die Idee von Überlastvermeidung: reduziere die an den Quellen erzeugte Last schon bevor die ersten Segmente (Pakete) an den Routern wegen voll gelaufener Queues verworfen werden. TCP hat an den Quellknoten keine Mechanismen eingebaut, die eine solche Strategie unmittelbar ermöglicht. Man müsste hierzu TCP durch ein neues Protokoll ersetzen. Idee: Router gaukeln vorzeitig übergelaufene Queues vor, sodass die TCP Quellknoten auch vorzeitig die Last reduzieren und somit keine Überlast an den Routern auftreten kann. SS 2014 Grundlagen der Rechnernetze Transportschicht 42
Random Early Detection (RED) Router berechnet regelmäßig die mittlere Queuelänge AvgLen anhand von gemessenen Queuelängensamples SampleLen: Jeder Router hat ein MinThreshold und ein MaxThreshold. Bei Ankunft eines Paketes wird folgender Algorithmus ausgeführt: if AvgLen <= MinThreshold speichere Paket in der Queue else if AvgLen < MaxThreshold berechne Wahrscheinlichkeit p verwerfe das Paket mit der Wahrscheinlichkeit p else verwerfe das Paket immer SS 2014 Grundlagen der Rechnernetze Transportschicht 43
Berechnung der Drop Wahrscheinlichkeit Bestimme die Wahrscheinlichkeit TempP zunächst in Abhängigkeit von AvgLen wie folgt: TempP 1.0 MaxP AvgLen MinThresh MaxThresh D.h. zwischen MinThresh und MaxThresh als Formel: Zähle die Anzahl count der nicht verworfenen Pakete während AvgLen zwischen MinThresh und MaxThresh war und berechne: SS 2014 Grundlagen der Rechnernetze Transportschicht 44
TCP Varianten SS 2014 Grundlagen der Rechnernetze Transportschicht 45
TCP erlaubt Implementationsvarianten Send Policy Keine Festlegung wie lange und wieviel gepuffert wird, bevor ein Segment gesendet wird Abzuwägen ist: Response Zeit versus Overhead wegen Nachrichten Header Deliver Policy Keine Festlegung wie lange Segmente auf der Empfängerseite gepuffert werden, bevor diese an die Anwendung weiter gegeben werden Abzuwägen ist: Response Zeit versus Overhead wegen Processing in TCPund User Software, sowie unnötige OS Interrupts Accept Policy Keine Festlegung, wie mit Out of Order Segmenten umzugehen ist Zwei Optionen Verwerfe Out of Order Segmente Behalte alle Segmente, die in das Receive Fenster passen Abzuwägen ist: Aufwand für Puffer Verwaltung versus Netzlast SS 2014 Grundlagen der Rechnernetze Transportschicht 46
TCP erlaubt Implementationsvarianten Retransmit Policy Keine Festlegung, wann ein gepuffertes und noch nicht bestätigtes Segment nochmals übertragen wird Mögliche Strategien: First only: Ein Retransmit Timeout für das Segment am Anfang der Sende Queue (wenn Timeout stattfindet sende das erste Segment und setze den Timer erneut) Batch: Sende alle Segmente erneut sobald der Retransmit Timeout stattfindet Individuell: Ein Timer für jedes Segment in der Queue Abzuwägen ist: First only: geringe Netzlast aber größere Verzögerung Batch und Individuell: geringere Verzögerung bei höherer Netzlast Acknowledge Policy Keine Festlegung, wann genau ein einkommendes Segment bestätigt werden muss Mögliche Strategien: Immediate: sende leeres Segment (d.h. ohne Daten) mit Acknowledgement Cummulative: Sammele Daten auf der Empfangsseite und sende Acknowledgement erst dann (allerdings: Persit Timer, um Acknowledgement nicht zu lange zu verzögern) Abzuwägen ist: Netzlast versus Verzögerung Zusammengefasst: im Rahmen der genannten Policies können TCP Varianten realisiert werden, die untereinander interoperabel sind. SS 2014 Grundlagen der Rechnernetze Transportschicht 47
Beispiele von TCP Varianten TCP existiert/existierte in verschiedenen Varianten TCP Tahoe Ursprüngliche TCP Implementierung des beschriebenen Congestion Control Mechanismus; mit Ausnahme des diskutierten Fast Recovery TCP Reno Unter anderem wurde Fast Recovery hinzugefügt TCP Vegas Beobachtung der RTT auf den sendenden Knoten und proaktive Anpassung des CongestionWindows, um Congestion vorab zu vermeiden SS 2014 Grundlagen der Rechnernetze Transportschicht 48
Zusammenfassung und Literatur SS 2014 Grundlagen der Rechnernetze Transportschicht 49
Zusammenfassung Die wichtigsten Internet Transportprotokolle UDP (keine Aufwertung des IP Best Effort Dienstes) TCP (zuverlässiger Byte Strom über IP) Flusskontrolle und Überlastkontrolle Flusskontrolle findet Ende zu Ende statt Überlastkontrolle betrifft das ganze Netz Design Merkmale Ende zu Ende Argument: realisiere Funktion auf der Schicht, in der diese komplett implementierbar ist TCP funktioniert nach dem Smart Sender/Dumb Receiver Prinzip Eine weitere TCP Stärke: TCP erlaubt Erweiterungen; Hosts müssen sich einigen welche Erweiterungen genutzt werden sollen; Neue TCP Erweiterung erfordert damit nicht im ganzen Internet TCP komplett neu zu installieren Die Unterscheidung zwischen Überlastkontrolle und Überlastvermeidung SS 2014 Grundlagen der Rechnernetze Transportschicht 50
Literatur [PetersonDavie2007] Larry L. Peterson and Bruce S. Davie, Computer Networks: A Systems Approach, Edition 4, 2007. 5.1 Simple Demultiplexer (UDP) 5.2.2 Segment Format 5.2.3 Connection Establishement and Termination 5.2.4 Sliding Window Revisited 5.2.5 Triggering Transmission 5.2.6 Adaptive Retransmission 5.2.7 Record Boundaries 5.2.8 TCP Extensions 6.3.1 Additive Increase/Multiplicative Decrease 6.3.2 Slow Start 6.3.3 Fast Retransmit and Fast Recovery 6.4.2 Random Early Detection (RED) SS 2014 Grundlagen der Rechnernetze Transportschicht 51