Ermitteln der RTT - Uni Koblenz-Landauunikorn/lehre/gdrn/ss15/07... · • Slow‐Start, wenn die...

Ermitteln der RTT

SS 2014 Grundlagen der Rechnernetze ‐ Transportschicht 21

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:

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.

Ermitteln der RTT


Warum lautet dieser gleitende Mittelwert eigentlich exponentiell gewichtet? Expandieren liefert:

Also z.B. für alpha=0,8:

Problem: Zuordnung von ACKs


Sender Empfänger Sender Empfänger

SampleRTTzu lang

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

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.



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.



Die komplette Berechnung nach Jacobson/Karels‐Algorithmus ist dann wie folgt:

Hierbei ist nach der Originalveröffentlichung von Jacobson:g = 1/8 = 0,125h = 1/4 = 0,25f = 2 (bzw. später auch f=4 korrigiert)

Diskussion


Bandbreite Zeit bis Sequenz‐nummern verbraucht sind

T1 (1,5 Mbps) 6,4 Stunden

Ethernet (10 Mbps) 57 Minuten

T3 (45 Mbps) 13 Minuten

Fast Ethernet (100 Mbps) 6 Minuten

OC‐3 (155 Mbps) 4 Minuten

OC‐12 (622 Mbps) 55 Sekunden

OC‐48 (2,5 Gbps) 14 Sekunden

Bandbreite Delay‐Bandbreiten‐Produkt für beispielsweise 100ms RTT

T1 (1,5 Mbps) 18 KB

Ethernet (10 Mbps) 122 KB

T3 (45 Mbps) 549 KB

Fast Ethernet (100 Mbps) 1,2 MB

OC‐3 (155 Mbps) 1,8 MB

OC‐12 (622 Mbps) 7,4 MB

OC‐48 (2,5 Gbps) 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...

TCP‐Erweiterungen


32‐Bit‐Timestamp• Speichere Sendezeit in Segment• Wiederhole die Zeit im ACK• Berechne RTT bei ACK‐EmpfangSender braucht keine Timestamps zuverwalten. Die sind „im Netz gespeichert“.

32‐Bit‐Sequenznummern: Lösung der vorhin beschriebenen kurzen Wrap‐around‐Zeiten• Verwende oben beschriebenen

Timestamp• Segmente mit gleichen

SequenceNum‐Werten sind anhand des Timestamp unterscheidbar

SrcPort DstPortSequenceNum

AcknowledgmentHdrLen

ChecksumOptions (variable)

0 Flags AdvertisedWindow

UrgPtr

Data

0 4 10 16 31

Erinnerung: TCP‐Header

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

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

SrcPort DstPortSequenceNum

AcknowledgmentHdrLen

ChecksumOptions (variable)

0 Flags AdvertisedWindow

UrgPtr

Data

0 4 10 16 31

NextByteExpected

LastByteRead

LastByteRcvd

… …

TCP‐Überlastkontrolle


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 Überlastkontrolleverwendet werden: ...

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.

Additive‐Increase‐Beispiel


Source Destination

RTT

RTT

RTT

Erhöhe um eine MSS

Erhöhe um eine MSS

Erhöhe um eine MSS

...... ...

Inkrement pro RTT:

Inkrement pro ACK?

Sei c die alte Länge des CongestionWindow. Nach einem RTT‐Durchlauf ist:

Ein typisches AIMD‐Muster


Congestio

nWindo

w‐Größe

Zeit

Slow‐Start


RTT

RTT

RTT

... ...

Source DestinationStarte 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?

Warum heißt das eigentlich Slow‐Start? Historischer Grund: In TCP‐Anfängen wurde zum Starten direkt mit einem großen CongestionWindow gestartet.

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

Ein Beispiel

SS 2014 Grundlagen der Rechnernetze ‐ Transportschicht 38Bildquelle: Andrew S. Tanenbaum, „Computer Networks“, Fourth Edition, 2003

Fast‐Retransmit


Sender EmpfängerPaket 1Paket 2

* ACK 1ACK 2

ACK 2

ACK 2ACK 2

ACK 6

Paket 4

Paket 5Paket 6

Paket 3(retransmit)

Paket 3

Erinnerung: ACKS sind kummulativ(d.h. bestätigen die bisher voll‐ständig zusammenhängende Se‐quenz von Segmenten)

Verlorene Sequenz führt zu „duplicate ACKs“.

Fast‐Retransmit: Warte nicht auf Timeout, sondern reübertrage ein Segment, nach drei aufeinander folgenden Duplicate‐ACKs.

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.

TCP‐Überlastvermeidung


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.

Random‐Early‐Detection (RED)


Router berechnet regelmäßig die mittlere Queuelänge AvgLenanhand von gemessenen Queuelängensamples SampleLen:

Jeder Router hat ein MinThreshold und ein MaxThreshold. Bei Ankunft eines Paketes wird folgender Algorithmus ausgeführt:

if AvgLen <= MinThresholdspeichere Paket in der Queue

else if AvgLen < MaxThresholdberechne Wahrscheinlichkeit pverwerfe das Paket mit der Wahrscheinlichkeit p

elseverwerfe das Paket immer

Berechnung der Drop‐Wahrscheinlichkeit


Bestimme die Wahrscheinlichkeit TempP zunächst in Abhängigkeit von AvgLenwie folgt:

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:

TempP

1.0

MaxP

MinThresh MaxThresh

AvgLen

TCP‐Varianten


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 TCP‐

und 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


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.


Beispiele von TCP‐Varianten


TCP existiert/existierte in verschiedenen Varianten

TCP TahoeUrsprüngliche TCP‐Implementierung des beschriebenen Congestion‐Control‐Mechanismus; mit Ausnahme des diskutierten Fast‐Recovery

TCP RenoUnter anderem wurde Fast‐Recovery hinzugefügt

TCP VegasBeobachtung der RTT auf den sendenden Knoten und proaktive Anpassung des CongestionWindows, um Congestion vorab zu vermeiden

Zusammenfassung und Literatur

Grundlagen der Rechnernetze ‐ Transportschicht 49SS 2014

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


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 Format5.2.3 Connection Establishement and Termination5.2.4 Sliding Window Revisited5.2.5 Triggering Transmission5.2.6 Adaptive Retransmission5.2.7 Record Boundaries5.2.8 TCP Extensions6.3.1 Additive Increase/Multiplicative Decrease6.3.2 Slow Start6.3.3 Fast Retransmit and Fast Recovery6.4.2 Random Early Detection (RED)


Ermitteln der RTT - Uni Koblenz-Landauunikorn/lehre/gdrn/ss15/07... · • Slow‐Start, wenn die...

Documents

Transcript of Ermitteln der RTT - Uni Koblenz-Landauunikorn/lehre/gdrn/ss15/07... · • Slow‐Start, wenn die...