Mitteilen des AdvertisedWindow

(1)

Data

Mitteilen des AdvertisedWindow

Ist Bestandteil eines TCP‐Segments des Empfängers an den Sender.

Beachte: TCP ist duplex.

TCP verfolgt den Ansatz Smart Sender / Dumb Receiver

Empfänger sendet kein dediziertes Segment, um die aktuelle Größe des AdvertisedWindow mitzuteilen.

Checksum

HdrLen 0 Flags

Options (variabel)

UrgPtr

AdvertisedWindow Acknowledgement

SequenceNum

SrcPort DstPort

0 4 10 16 31

(2)

Vermeiden eines Deadlocks

AdvertisedWindow=0

Empfangspuffer wird geleert und Annahme der Empfänger sendet nichts an den Sender zurück.

Empfänger Sender

Sender sendet ab hier nicht weiter

Woher weis der Sender, dass wieder Platz im Empfängerpuffer ist?!?

AdvertisedWindow=0

Empfangspuffer wird geleert und Annahme der Empfänger sendet nichts an den Sender zurück.

Empfänger Sender

Segment der Länge 1

AdvertisedWindow=0

Segment der Länge 1

AdvertisedWindow=1200

Probing mit Segment der Länge 1

Persist timer (ca. alle 5 bis 60 sekunden)

(3)

Transmission Control Protocol (TCP)

Regulärer Duplexbetrieb inklusive Flusskontrolle

(4)

Regulärer Duplexbetrieb

AdvWnd=1024, AckedSeqNr=3463

Gerät 1 Gerät 2

AdvWnd=4020, AckedSeqNr=42783

usw.

(5)

Wann soll ein Segment versendet werden?

TCP verwaltet eine Variable Maximum‐Segment‐Size (MSS)

MSS = MTU des lokalen Netzes minus TCP‐ und IP‐Headergröße Versende Segment auf jeden Fall sobald

• mindestens MSS viele neue Bytes vorliegen oder

• der sendende Prozess explizit darum bittet (push)

Was sonst? Warum nicht aggressiv immer sofort senden?

(6)

Sofortiges Senden bedeutet unnötiger Overhead

Sender Empfänger

Sendepuffer leer

…

2 Bytes erzeugt 7 Bytes erzeugt 3 Bytes erzeugt

Segment mit ein paar wenigen Bytes bedeutet unnötiger Overhead. Versendet werden muss: Daten + IP‐Header + TCP‐Header.

Noch schlimmer: ohne weitere Vorkehrungen verweilen solche einmal eingeführten kleinen Segmente beliebig lang im Nachrichtenfluss der Fluss‐Kontrolle; das sogenannte Silly‐Window‐Syndrom.

(7)

Silly‐Window‐Syndrom

Angenommen der Sender versendet mit jedem bestätigten Segment unmittelbar wieder ein Segment.

So gesehen kann man den Nachrichtenfluss wie ein Förderband sehen. Segmente sind volle Container vom Sender zum Empfänger. Acknowledgements sind die leeren Container vom Empfänger zurück.

(8)

Behandlung auf der Empfängerseite?

Silly‐Window‐Syndrom ist nur dann ein Problem, wenn entweder der Sender ein kleines Segment sendet oder der Empfänger das Fenster um einen kleinen Betrag öffnet.

Wenn beides nicht passiert, wird ein kleiner Container niemals in den Stream eingeführt.

Es ist nicht möglich, das Senden kleiner Segmente zu verbieten. Beispielsweise kann die Anwendung nach dem Senden eines einzelnen Bytes einen Push ausführen.

Es ist jedoch möglich, den Empfänger daran zu hindern, einen kleinen Container wieder zurückzusenden.

Die Regel ist, dass der Empfänger nach seinem AdvertisedWindow=0 ein neues AdvertisedWindow erst dann mitteilet, wenn dieses mindestens MSS groß ist.

Jedoch sind kleine Container im Strom nicht ausgeschlossen. Es benötigt einen

Mechanismus, um diese zusammenzuführen. Der Empfänger kann dies tun, indem er ACKs verzögert (d.h. ein kombiniertes ACK anstelle mehrerer kleinerer).

Dies ist jedoch nur eine Teillösung, da der Empfänger nicht wissen kann, wie lange es für die Anwendung sinnvoll ist, zu warten bis ein weiteres Segment eintrifft oder bis die Anwendung Daten konsumiert und damit das Sendefenster wieder weiter öffnet.

Die endgültige Antwort liegt beim Absender, wodurch wir zu unserem ursprünglichen Problem zurückkehren: Wann entscheidet der TCP‐Absender, ein Segment zu übertragen?

(9)

Behandlung auf der Senderseite!

Wenn Daten gesendet werden müssen, das Fenster jedoch weniger als MSS geöffnet ist, möchten wir möglicherweise einige Zeit warten, bevor wir die verfügbaren Daten senden.

Die Frage ist jedoch, wie lange?

Wenn wir zu lange warten, verletzen wir interaktive Anwendungen wie Telnet. Wenn wir nicht lange genug warten, riskieren wir, ein paar winzige Pakete zu verschicken und

triggern damit das Silly‐Window‐Syndrom.

Die Antwort besteht darin, einen Timer einzuführen und zu senden, wenn der Timer abläuft.

Dies ist bei TCP kein Timer im Sinne einer festen Zeit, sondern ACK wird als Trigger genutzt.

Diese Vorgehensweise nennt man Self‐Clocking.

(10)

Nagle‘s Algorithmus

Routine, die von TCP ausgeführt wird, wenn die sendende Applikation neue Daten produziert hat:

if verfügbare Daten und Window >= MSS then sende volles Segment

else

if nicht-Acked Data unterwegs then

puffere die Daten bis Ack ankommt else

sende alle neuen Daten jetzt endif

endif

Bemerkung: Für besonders zeitkritische Anwendungen lässt sich aber Nagel‘s Algoritmus abschalten (setze TCP_NODELAY). Dann wird immer sofort gesendet.

(11)

Transmission Control Protocol (TCP)

Adaptive Reübertragungen

(12)

Reübertragung bei TCP der ersten Stunde

TCP‐Sender TCP‐Empfänger

Segment

*

Wie lange warten, bis das Segment

reübertragen wird?

Erste TCP‐

Implementierungen

verwenden das zweifache der RTT.

Woher kennt man die RTT? RFC 675: Specification of Internet Transmission Control Program, December 1974

(13)

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:

(14)

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.

(15)

Ermitteln der RTT

Warum lautet dieser gleitende Mittelwert eigentlich exponentiell gewichtet?

Expandieren liefert:

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

(16)

Problem: Zuordnung von ACKs

Sender Empfänger Sender Empfänger

SampleRTT

zu lang SampleRTT

zu kurz

Karn/Patridge‐Algorithmus (1987): Ignoriere einfach die Segmente, die reübertragen wurden.

Darüber hinaus: wann immer ein Segment reübertragen werden musste:

Timeout = 2*Timeout (Exponential Backoff)

(17)

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. Ein Teil des Jacobson/Karels‐Algorithmus (Änderung von TCP 1988 hinsichtlich Überlast im Netz; Diskussion folgt; hier nur der

Timeoutmechanismus): schätze die folgende mittlere Abweichung:

(18)

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.

(19)

Einbeziehen der Varianz

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

(20)

Transmission Control Protocol (TCP)

Erweiterungen

(21)

Diskussion/Motivation

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 OC‐192 (10 Gbps) 3 Sekunden

Bandbreite Delay‐Bandbreiten‐

Produkt für

beispielsweise 100 ms 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 OC‐192 (10 Gbps) 118,4 MB

(22)

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

around‐Zeiten

•

Verwende oben beschriebenen Timestamp

•

Segmente mit gleichen

SequenceNum‐Werten sind anhand des Timestamp unterscheidbar

SrcPort DstPort

SequenceNum Acknowledgment

HdrLen

Checksum

Options (variable)

0 Flags AdvertisedWindow

UrgPtr

Data

0 4 10 16 31

Erinnerung: TCP‐Header

(23)

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

SrcPort DstPort

SequenceNum Acknowledgment

HdrLen

Checksum

Options (variable)

0 Flags AdvertisedWindow

UrgPtr

Data

0 4 10 16 31

(24)

Transmission Control Protocol (TCP)

Überlastkontrolle

(25)

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

•

(26)

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.

(27)

Additive‐Increase‐Beispiel

Source Destination

RTT

Erhöhe um eine MSS

Inkrement pro RTT:

Inkrement pro ACK?

Sei c die alte Länge des

(28)

Ein typisches AIMD‐Muster

CongestionWindow‐Größe

Zeit

(29)

Slow‐Start

RTT

Source Destination

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?

Warum heißt das eigentlich Slow‐Start?

(30)

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

•

CongestionThreshold ist erst mal auf das Flow‐Control‐Window gesetzt Wenn ein Timeout stattgefunden hat

•

CongestionThreshold = CongestionWindow/2 (man merkt sich also das 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

(31)

Ein Beispiel

(32)

Fast‐Retransmit

Sender Empfänger

Paket 1 Paket 2

*

^ACK 1

ACK 2 ACK 2

ACK 6 Paket 4

Paket 5 Paket 6

Paket 3

(retransmit) Paket 3

Erinnerung: ACKs sind kumulativ (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.

(33)

Die TCP‐Variante mit Fast‐Recovery

(34)

Transmission Control Protocol (TCP)

Überlastvermeidung

(35)

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.

Mögliche Optionen

•

Aktives Queue‐Management auf den Routern (active queue management AQM): erfordert Anpassung von Routern

•

Ohne notwendige Veränderung einer TCP‐Implementation

•

Erweiterung von TCP mit einem Signalisierungsmechanismus

•

Quellbasierte Lösung: erfordert keine Anpassung von Routern aber erfordert

(36)

AQM mittels RED (Random‐Early‐Detection)

Beispiel für Aktives Queue‐Management auf den Routern Ohne notwendige

Veränderung einer TCP‐Implementation

Idee: Router „gaukeln“ durch zufällig verworfene IP‐Pakete vorzeitig

übergelaufene Queues vor, sodass die TCP‐Quellknoten auch vorzeitig die Last

reduzieren und somit keine Überlast an den Routern auftreten kann.

(37)

RED: Zufälliges Verwerfen von Paketen

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

(38)

RED: Berechnung der Drop‐Wahrscheinlichkeit

Bestimme die Wahrscheinlichkeit TempP zunächst in Abhängigkeit von AvgLen wie 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

(39)

AQM mittels DECbit bzw. ECE

Beispiel für aktives Queue‐Management inklusive Erweiterung von TCP mit einem Signalisierungsmechanismus

DECbit: Zusammenspiel von IP und TCP; Router setzen bei mittlerer Queue‐Länge größer 1 ein Bit im Paket‐Header. Dieses Bit wird dem Sender über ACK des Empfängers übermittelt.

Wenn mehr als die Hälfte eines Congestion‐Windows an Paketen dieses Flag gesetzt haben, reduziere das Window exponentiell, ansonsten erhöhe linear.

ECE (Explicit Congestion Notification):

• vergleichbares Prinzip wie mit DECbit; definiert den Rahmen, wie Hosts und Router kommunizieren.

• Zwei Bits im TOS‐Feld von IP‐Header:

ECT = ECN‐Capable‐Transport (gesetzt durch Quelle), CE = Congestion Encountered (gesetzt durch Router)

• Zwei weitere optionale Flags im TCP‐Header: