Folien

TCP - Kollisionsvermeidung
und verwandtes
Marcus Blomenkamp
Januar 2003
TCP abstrakt (Rückblick)
• verlässlicher Transportweg - realisiert durch
– Zerteilung und Versand des Datenstromes in Paketen
– wiederholtes Senden verlorengegangener Pakete
– Quittierungverfahren
∗ nicht Empfangsbestätigung werden gesendet
∗ sondern Mitteilungen über noch fehlende Segmente
• effektive Nutzung der gegebenen Bandbreite - realisiert durch
– Anwendung eines Sliding-Window Verfahrens
TCP - Kollisionsvermeidung und verwandtes
Januar 2003
<
u
>
Systembeschreibung
• TCP-Verbindung ist bidirektional
– Verfahren und Heuristiken fuer beide Richtungen identisch
– nachfolgende Beschreibungen daher nur unidirektional
• relevante Objekte
–
–
–
–
Sliding-Window beim Sender
Empfangspuffer beim Empfänger
Puffer in Zwischenstationen (zB Router)
Übertragungsmedien mit begrenzter Bandbreite
TCP - Kollisionsvermeidung und verwandtes
Januar 2003
<
u
>
Das Sliding-Window (versendeseitig)
1 2 3 4 5 6 7 8 9
A
X
B
• Bedeutung der Bereiche
– Daten bis Punkt A sind bestätigt übertragen
– Empfang der Daten zwischen A und X noch nicht bestätigt
– Daten zwischen X und B sind noch nicht gesendet.
• Definition der Trennpunkte
– Punkt A ergibt sich aus höchstem bestätigten Oktett
– Offset von Punkt B bzgl A ergibt sich aus der Grösse des Zielfensters
– Punkt X markiert den aktuellen Sendezeiger
TCP - Kollisionsvermeidung und verwandtes
Januar 2003
<
u
>
Fluss-Probleme abstrakt
• Systemgegebenheiten bedingen Flusskontrolle
– Übertragungs- und Verarbeitungs-Geschwindigkeit ist begrenzt
∗ konkrete Werte nicht vorher bekannt
∗ Konstanz der Werte nicht gegeben
– Sender-Charakteristik ist unbekannt/variiert
• Aufteilung in konkrete Fluss-Probleme
– End-To-End Flow (zwischen zwei kommunizierenden Partnern)
∗ direkt kontrollierbar
– Intermediate Flow (Routing-Probleme, Überlastung etc)
∗ nicht direkt steuerbar
TCP - Kollisionsvermeidung und verwandtes
Januar 2003
<
u
>
Endpunkt Flusskontrolle
• Prinzip:
– Empfänger informiert Sender über verbliebenen Pufferplatz bei jeder
Bestätigung (window advertisement)
– Empfänger informiert Sender über verbliebenen Pufferplatz bei Abarbeitung
– Sender kann explizit das Abarbeiten des Empfangspuffers veranlassen
(PUSH flag)
TCP - Kollisionsvermeidung und verwandtes
Januar 2003
<
u
>
Endpunkt Flusskontrolle
• Basis-Optimierung:
– Delayed Acknowledgements - Versenden der ACKs kurzeitig (<200ms)
verzögern um
∗ mehrere Bestätigungen zu einer zusammen zu fassen
∗ Bestätigung mit einem anderen Datenpaket mitzuschicken (piggyback)
– Nagle Algorithm - verzögertes Versenden von kleinen Datenmengen
∗ solange bis Menge eines Segmentes erreicht ist
∗ solange bis alle bisherigen Daten bestätigt sind
TCP - Kollisionsvermeidung und verwandtes
Januar 2003
<
u
>
Endpunkt Fluss-Probleme
• Silly-Window Syndrom, Ablauf:
–
–
–
–
–
1.
2.
3.
4.
5.
Empfangspuffer ist voll
Empfangsseite verarbeitet sehr wenig Daten (zB ein Oktett)
Empfangsseite kündigt ein freies Oktett an
Sender schickt genau ein Oktett
usw... -> Banbreitenverschwendung
• Lösung des Silly-Window Problems:
– empfängerseitig: Platzankündigung erst verschicken wenn
∗ mehr als die Hälfte des Puffers leer sind
∗ mindestens ein maximales Segment hineinpasst
– senderseitig: Nagle Algorithm
TCP - Kollisionsvermeidung und verwandtes
Januar 2003
<
u
>
Fluss-Probleme konkret
• mögliche Ereignisse und daraus folgende Probleme
– beim Empfänger
∗ Puffer läuft über -> Paketverlust
– an Zwischenstationen
∗ Puffer läuft über -> Paketverlust
∗ bei Belastung -> Paketverzögerung
∗ Datenfehler (selten) -> Paketverlust
• daraus folgen behandelbare Symptome
– variierende Paketlaufzeiten
– Paketverlust
TCP - Kollisionsvermeidung und verwandtes
Januar 2003
<
u
>
Problemfeld variiende Laufzeiten vs Paketverlust
• Entscheidung zwischen ’Paket verloren’ und ’Paket verzögert’ nicht trivial, da
– durchschnittliche Paketlaufzeit nicht bekaannt
– -> statische Vergleichswerte ungeeignet
• Lösungsansätze muessen adaptiv sein
– -> Messung bzw Bestimmung der Werte muss real erfolgen
TCP - Kollisionsvermeidung und verwandtes
Januar 2003
<
u
>
Bestimmung der Rundlaufzeitgrenzen
• In Theorie simpel: Pakete die länger als Tmax brauchen, gelten als verloren
T dif f = T (ACK RECEIV ED) − T (SEN T )
(1)
T mean = α ∗ (T mean) + (α − 1) ∗ (T dif f )
(2)
T max = γ ∗ T mean
(3)
• In Praxis nicht
– Retransmissions sind bitidentisch, dh Bezugszeitpunkt nicht eindeutig
(acknowledgement ambiguity)
– pessimistische Schätzung -> Tmean wächst bei Paketverlust stark
– optimistische Schätzung -> Stabilisierung auf zu niedrigem Wert
– -> andere Lösung muss her
TCP - Kollisionsvermeidung und verwandtes
Januar 2003
<
u
>
RTT-Bestimmung mit Karns Algorithmus
• Strategie:
– wiederholt gesendete Pakete bei der Durchschnittsberechnung ignorieren
• Problem:
– scharfer Anstieg der Verzögerung wird ignoriert
– -> Bandbreitenverschwendung folgt
• Lösung:
– Timeout bei Wiederholungen stark erhöhen (zB exponentiell)
– Timeout nach nach gültigen Samples zurücksetzen
• Ergebnis (empirisch)
– Gute Durchsatzraten auch bei hohen Verlustraten
TCP - Kollisionsvermeidung und verwandtes
Januar 2003
<
u
>
weitere Verbesserung der RTT-Abschaetzung
• Ausgangspunkt und Problem
– fixes Verhältnis zwischen RTT und Retransmission-Timeout
– Varianz der Verzögerungen steigt mit der Medienauslastung
∗ Formel:
σ = 1/(1 − L)
∗ Beispiel: 80% Auslastung -> Faktor 10
– Rückschluss: sinnvoll anwendbar bis max 30% Last
TCP - Kollisionsvermeidung und verwandtes
Januar 2003
<
u
>
weitere Verbesserung der RTT-Abschaetzung
• Lösung
– reale Varianz als Verhältnisfaktor miteinbeziehen
– Formel:
DIF F = SAM P LE − Old RT T
(4)
Smooth RT T = Old RT T + a ∗ DIF F
(5)
DEV = Old DEV + b ∗ (|DIF F | − Old DEV )
(6)
T imeout = Smooth RT T + n ∗ DEV
(7)
TCP - Kollisionsvermeidung und verwandtes
Januar 2003
<
u
>
Paketverlust und Vermeidung dessen
• Ursache:
– Paketverluste sind meist Folgen von Überlastung
• Schlussfolgerung:
– Überlastungen sind möglichst zu vermeiden -> langsam an Lastgrenze
herantasten
– vorhandene Überlastungen sind rasch abzubauen
• Implementationsmittel:
– Definition eines neuen Fensters (congestion window) als zusätzliche obere
Schranke des Datenversandes.
TCP - Kollisionsvermeidung und verwandtes
Januar 2003
<
u
>
Slow Start - Prinzip
• Initialisiere C-Window auf ein maximales Segment
• iteriere über
– Sende soviele Segment wie maximal erlaubt
– erhöhe pro ankommenendem ACK das C-Window um ein weiteres Segment
– obere Gerenze ergibt sich automatisch aus
∗ geschrumpftem Empfängerfenster
∗ Paketverlust
TCP - Kollisionsvermeidung und verwandtes
Januar 2003
<
u
>
Erkennung und Behandlung von Überlast
• Paketverlust ist erkennbar am
– Überschreiten von Bestätigungs-Timeouts
– Empfang von duplizierten Bestätigungen
• direkte Reaktion
– vermerke das Minimum von ’halbes aktuelles Fenster’ und 2 Segmenten in
neuer Slow-Start-Threshold Variable
– falls Timeout Ursache -> setze C-Window auf Minimum zurück
– danach
∗ erhöhe weiterhin C-Window nach Erhalt von ACKs
∗ Wert abhängig von C-Window <-> SST
· falls < SST dann gewöhnliche exponentielle Erhöhung
· falls >= SST dann lineare Erhöhung
TCP - Kollisionsvermeidung und verwandtes
Januar 2003
<
u
>
verbesserte Kollisionsbehandlung
Fast Retransmission/Recovery
• Beobachtungen:
– eine geringe Zahl von duplicate ACKs weist oft nur Paket-Reordering und
nicht auf Paketverlust hin
– eine grössere Zahl (> 3) ist wahrscheinlicher ein Zeichen für Paketverlust
• Nutzung:
– spekulativ das vermeintlich fehlende Paket senden
– kein Rückgriff auf Slow Start Zyklus nötig
– stattdessen direkt nachfolgend Einsatz der linearen Strategie
TCP - Kollisionsvermeidung und verwandtes
Januar 2003
<
u
>
Zusammenfassung
• TCP bietet
– einen zuverlässigen Mechanismus zur Erkennung von Paketverlusten
– eine schnelle Erholung von abnormalen Zuständen
– zügiges Erreichen einer hohen und effektiven Bandbreiten-Nutzung
• ungünstig wirkt sich aus
– Verlust von direkt aufeinander folgenden Paketen, da Wechsel zu Low Start
getriggert wird
• daher Konfigurationshinweis für Router
– nicht Tail-Drop Queueing verwenden
– besser Random-Early-Discard
TCP - Kollisionsvermeidung und verwandtes
Januar 2003
<
u
>