TCP

Transcription

TCP

Vorlesung: Netzwerke (TK) WS 2011/12
Kapitel 5 Ende-zu-Ende-Protokolle
Session 17
Prof. Dr. Michael Massoth
[Stand: 17.01.2012]
Copyright: © Michael Massoth
17 - 1
Netzwerke, WS 2011/12
17 - 2
ACHTUNG:
Testat_4
am Dienstag, den 17.01.2012

Referenzmodelle (OSI, Hybrid, TCP/IP)
Hardware-Bausteine bzw. Kopplungselemente
Strukturierte Verkabelung
Ethernet (inkl. CSMA/CD) und WLAN
Paketvermittlung (Bridging, Switching, Netzwerkdesign, VLAN)
Internetworking (inkl. IPv4-Adressierung und Subnetting)
Ende-zu-Ende-Protokolle (UDP + TCP)
17 - 2
17 - 3
ACHTUNG:
Testat_5
am Dienstag, den 24.01.2012

Referenzmodelle (OSI, Hybrid, TCP/IP)
Hardware-Bausteine bzw. Kopplungselemente
Strukturierte Verkabelung
Ethernet (inkl. CSMA/CD) und WLAN
Paketvermittlung (Bridging, Switching, Netzwerkdesign, VLAN)
Internetworking (inkl. IPv4-Adressierung und Subnetting)
Ende-zu-Ende-Protokolle (UDP + TCP)
17 - 3
17 - 4
Lernziele heute :
Zuverlässige Zustellung: Stop-and-Wait-Algorithmus und
Sliding Window (Grundlagen)
Lernziele im Detail:
Zuverlässige Zustellung verstehen und anwenden können
Sliding-Window-Algorithmus für Sender und Empfänger mit
Variablenverwaltung verstehen und anwenden können
17 - 4
17 - 5
TCP
[Transmission Control Protocol ]

TCP Sequenz- und Bestätigungsnummern
Zuverlässiger Datentransfer
TCP-Flusskontrolle
Pipelining und Sliding-Window
TCP-Überlastkontrolle
17 - 5
17 - 6
Lernziele heute:
Transmission Control Protocol (TCP)
TCP als zuverlässiges Byte-Strom-Protokoll mit integrierter
Flusskontrolle verstehen, erklären und anwenden können
TCP mit variablem Sliding-Window-Algorithmus und integrierter
Flusskontrolle verstehen, erklären und anwenden können
17 - 6
Zuverlässiger Datenaustausch
17 - 7
Ein Paket wird versendet und
ein Timer gesetzt
Kommt es beim Empfänger
an wird eine Bestätigung
gesendet
Läuft der Timer ab bevor
Bestätigung ankommt wird
erneut gesendet
Nachteil: Ineffiziente Nutzung
der Bandbreite
17 - 7
Zuverlässiger Datentransfer mit Pipelining (1)
17 - 8
Gegenüberstellung von Stop-and-Wait und Pipelining:
Zuverlässiger Datentransfer mit Pipelining:
Da die vielen zwischen Sender und Empfänger im Transit
befindlichen Pakete als das „Füllen einer Pipeline“ betrachtet
werden können, wird diese Technik Pipelining genannt.
17 - 8
Zuverlässiger Datentransfer mit Pipelining (2)
17 - 9
Zuverlässiger Datentransfer mit Pipelining Î Konsequenzen:

Die Sender- und Empfängerseite benötigen einen Puffer für mehr
als ein Segment. Als Minimum muss der Sender die bereits
übertragenen, aber noch nicht bestätigten Segmente
zwischenspeichern.
Bereich der Sequenz- und Bestätigungsnummern muss
entsprechend vergrößert werden.
17 - 9
TCP Sliding Window (1)
17 - 10
Fenstergröße = Anzahl von
Bytes, die ein Host übertragen
kann, während er auf eine
Bestätigung wartet
Größeres Fenster ermöglicht
dem Host, mehr Daten zu
übertragen, während eine
Bestätigung noch aussteht
Sliding bezieht sich darauf, dass
die Fenstergröße während der
TCP-Session dynamisch
ausgehandelt wird Î
effizientere Ausnutzung der
Bandbreite
17 - 10
Sliding-Window-Algorithmus allgemein
Sender
17 - 11
Receiver
Sender weist jedem Paket (hier: TCP-Segment) eine Sequenznummer
(Engl. Sequence Number) zu mit der Beschriftung Seq
Für jedes übertragene Paket setzt der Sender auch einen Timer und
überträgt dieses Paket (TCP-Segment) erneut, wenn der Timer vor dem
Eingang eines ACK abläuft
17 - 11
Sender and Receiver State
Sender
Sender
Max ACK received
Receiver
Receiver
Next expected
Next seqnum
…
…
Sent Not Acked
OK to Send
Not Usable
Max acceptable
…
…
Sender window
Sent & Acked
17 - 12
Receiver window
Received & Acked
Acceptable Packet
Not Usable
17 - 12
TCP Flusskontrolle und Sliding Window
17 - 13
Merke: Die TCP Variante des Sliding Window Algorithmus
gewährleistet:
1. Die zuverlässige Übertragung von Daten in einem Byte-Strom
2. Die Übertragung der Daten in der richtigen Reihenfolge
3. Eine Flusskontrolle zwischen Sender und Empfänger
Integrierte Flusskontrolle: Bei TCP wird keine feste SlidingWindow Größe benutzt, sondern dem Sender vom Empfänger
advertised (bekannt gemacht).
Î Dies geschieht durch das Feld AdvertisedWindow im TCPHeader
Î Empfänger wählt einen geeigneten Wert für AdvertisedWindow
auf der Grundlage des Speicherplatzes aus, der der Verbindung
für die Zwischenspeicherung von Daten zugewiesen ist
17 - 13
TCP Sliding-Window (1)
Receiving application
Sending application
LastByteWritten
LastByteAcked
TCP
LastByteSent
17 - 14
LastByteRead
NextByteExpected
(a)
TCP
LastByteRcvd
(b)
Sending side (a):
LastByteAcked ≤ LastByteSent
LastByteSent ≤ LastByteWritten
Buffer bytes between LastByteAcked and LastByteWritten
17 - 14
TCP Sliding-Window (2)
Receiving application
Sending application
LastByteWritten
LastByteAcked
TCP
LastByteSent
17 - 15
LastByteRead
NextByteExpected
(a)
TCP
LastByteRcvd
(b)
Receiving side (b):
LastByteRead ≤ NextByteExpected
NextByteExpected ≤ LastByteRcvd +1
Buffer bytes between NextByteRead and LastByteRcvd
17 - 15
TCP Flow Control Window
Sender
Receiver
Application
Application
TCP
TCP
Sender's Window
Receiver's Window
IP
lastByteFromApplication
IP
lastByteToApplication
lastByteSent
nextByteExpected
lastByteAcknowledged
17 - 16
lastByteReceived
17 - 16
TCP Timer im Überblick
17 - 17
TCP Timer im Überblick:
Retransmission Timer (Timeout => RTO) Î Nach Ablauf des
Timers werden unbestätigte Datenpakete erneut gesendet
Reconnection Timer Î Minimale Zeit, die gewartet werden
muss, um eine Verbindung abzubauen und sie erneut zur
gleichen Zieladresse wieder aufzubauen
Window Timer Î Maximale Zeit, die verstreichen darf, um nach
einer Bestätigung von Datenpaketen die Fenstergröße auf einen
neuen Wert umzustellen
Retransmit Syn Timer Î Maximale Zeit, die verstreichen muss,
um nach einem erfolglosen Verbindungsaufbauversuch einen
erneuten Connection Request zu starten
Give Up Timer Î Nach Ablauf dieses Timers wird die
Verbindung abgebaut, wenn keine Datenpakete vom Zielknoten
bestätigt werden
17 - 17
TCP Fehlerbehandlung
17 - 18
TCP Fehlerbehandlung:
Die Fehlerbehandlung erfolgt durch Go-Back-N
TCP arbeitet mit positiven Quittungen, die Summenquittungen
darstellen (für die Menge erfolgreich übertragener Bytes)
Dies bedeutet, dass ab dem ersten, nicht quittierten Paket alle
Pakete wiederholt werden
17 - 18
Datenfluss
Buffer
Buffer
TCP Modul
17 - 19
TCP Modul
17 - 19
Datenfluss
17 - 20
Korrekte und fehlerfreie Übertragung:
Sender erhält für jedes gesendete Paket ein ACK (Quittung),
besteht aus ACK-Flag=1 und ACK-Nummer
ACK-Nummer = Seq-Nummer + Größe Payload in Byte
Folgende Seq-Nummer = ACK
17 - 20
Datenfluss: Fehlerfreie Übertragung
Empfänger
Sender
Buffer
1
1
2
17 - 21
Buffer
SEQ=1 Daten: 1460 Byte
SEQ=1, ACK=1461, Daten: 0 Byte
1
2
3
4
5
1
2
3
4
5
17 - 21
Datenfluss: Fehler bei Übertragung
Empfänger
Sender
Buffer
Buffer
1
1
2
3
4
5
1
2
3
4
5
1
2
3
4
5
1
2
3
4
5
5
1
2
3
4
5
5
1
1
2
1
2
1
2
4
1
2
4
1
2
17 - 22
3
4
17 - 22
Timer abgelaufen
Retransmission
Paket 3
Datenfluss
17 - 23
Einigung im Vorfeld (Windowsize): Z. B. 5 * 1.460 Bytes
ACK
Buffer
=> Datenverlust
17 - 23
Datenfluss
17 - 24
Abhilfe: Windowfeld auf 0 (Zero Window)
Window=0
ACK, SEQ=1, ACK 7301, Window = 7300
ACK, SEQ=1, ACK 10220
Buffer
17 - 24
Sequenz/Acknowlegde Verlauf
Sender
17 - 25
Empfänger
500 Byte
s, S
eq=x
k=x+500
c
A
,
1
=
K
C
Seq=y, A
500 Bytes,
Seq=x+500
=x+1000
K
C
A
,
1
=
, ACK
Seq=y+1
17 - 25
Acknowledge / positive Quittungen
17 - 26
Solange ACK nicht eingegangen ist, darf kein neues Paket
gesendet werden
Kommt kein ACK-Paket, so ist
– entweder das Paket verloren gegangen oder
– das ACK-Paket verloren
In beiden Fällen wird das Paket wiederholt nach einem
RetransmissionTimeOut (RTO)
Es gilt: RTO < SRTT + 4 * RTTVAR

SRTT: gemittelte Roundtrip-Time
RTTVAR: Mittlere Abweichung der Roundtrip-Time
Startwerte für RTO zwischen 2,5 und 3 sec (RFC 2988)
17 - 26
Window-Feld
17 - 27
Datendurchsatz ist bei Quittierung jedes Pakets relativ niedrig
Zuverlässige Verbindung bedeutet, dass der Empfänger bei
Überlast den Sender drosseln können muss
Window-Size durch Empfänger im ACK-Paket
legt die neue Anzahl der sendbaren Bytes fest
17 - 27
Windowsize
HOST 1
100ms Übertragungsdauer
17 - 28
HOST 2
H1 sendet 1000 Bytes an H2
Dauer = 100ms
H2 sendet ACK zurück
Dauer = 100ms
Dauer = 100ms
Dauer = 100ms
Datendurchsatz = 2.000 Bytes in 400ms,
damit also 5.000 Bytes/s, egal, wie schnell die Leitung ist!
17 - 28
Windowsize
HOST 1
17 - 29
HOST 2
H1 sendet 65.535 Bytes an H2
Dauer = 100ms
Dauer = 100ms
H1 sendet 65.535 Bytes an H2
Dauer = 100ms
Dauer = 100ms
damit also 327.675 Bytes/s, egal, wie schnell die Leitung ist!
17 - 29
Windowsize
HOST 1
17 - 30
HOST 2
Dauer = 100ms
Dauer = 100ms
Dauer = 100ms
Dauer = 100ms
damit also 7.500 Bytes/s
17 - 30
17 - 31
TCP

TCP Sequenz- und Bestätigungsnummern
Zuverlässiger Datentransfer
TCP-Flusskontrolle
Pipelining und Sliding-Window
TCP-Überlastkontrolle
17 - 31
17 - 32
Lernziele heute:
TCP Slow Start und Congestion Avoidance verstehen, erklären und
anwenden können
Unterschied zwischen Flusskontrolle und Congestion Control (dt.
Stau- bzw. Überlastkontrolle) verstehen und erklären können
17 - 32
TCP-Überlastungsüberwachung
17 - 33
(a) Ein schnelles Netz, das an einen Empfänger mit geringer Kapazität weiterleitet.
(b) Ein langsames Netz, das an einen Empfänger mit hoher Kapazität weiterleitet.
17 - 33
TCP Slow Start and Congestion Avoidance
17 - 34
window size
congestion
avoidance
13
12
11
10
9
8
slow
start
threshold
7
new threshold
6
5
4
3
2
1
time
1
2
3
4
5
6
7
8
9
10 11
12
timeout occurs
17 - 34
TCP Slow Start
17 - 35
window size
congestion
avoidance
13
12
11
10
9
8
slow
start
threshold
7
new threshold
6
5
4
3
2
1
time
1
2
3
4
5
6
7
8
9
10 11
12
timeout occurs
17 - 35
TCP Slow Start (1)
17 - 36
Problem:
Sliding-Window funktioniert nur im selben LAN sehr gut
Probleme bei Kommunikation über Zwischensysteme (Router), mit
langsameren Verbindungen
Ansatz:
TCP Slow Start
17 - 36
TCP Slow Start (2)
17 - 37
TCP Slow Start Prinzip:
Algorithmus überwacht Kommunikation
Sender erweitert TCP-Modul um ein Congestion Window (cwnd) und
eine Slow Start Threshold Size (ssthresh)
CWND wird bei jedem ACK erhöht Î (20, 21, 22, …)
Sender kann maximal das Minimum von CWND und Windowsize an
Daten senden
Wird ein Paketverlust festgestellt, wird CWND auf letztbekannte
funktionierende Größe zurückgesetzt
17 - 37
TCP Slow Start (3)
17 - 38
TCP Slow Start:
Start with Congestion Window cwnd = 1 (segment size announced
by other side)
On each successful ACK increment cwnd with cwnd ← cnwd + 1
Exponential growth of cwnd size, if all former segements are
acknowledged successfully. Each RTT: cwnd ← 2 x cwnd
Enter Congestion Avoidance (CA) when cwnd ≥ ssthresh (slow start
threshold size)
Merke: Für jeder erfolgreiche Quittung (ACK) wird das Congestion
Window um eine Segmentgröße erhöht. Dadurch ergibt sich eine
Verdopplung der Congestion Window Größe pro RTT. Limit ist das
vom Empfänger festgelegte Empfangsfenster!
17 - 38
TCP Slow Start (4)
sender
17 - 39
receiver
cwnd
1
1 RTT
2
data
packet
ACK
3
4
5
6
7
8
cwnd ← cwnd + 1 (for each ACK)
17 - 39
TCP Congestion Avoidance
17 - 40
window size
congestion
avoidance
13
12
11
10
9
8
slow
start
threshold
7
new threshold
6
5
4
3
2
1
time
1
2
3
4
5
6
7
8
9
10 11
12
timeout occurs
17 - 40
Congestion Avoidance (1)
17 - 41
Congestion Avoidance (dt. Vermeidung von Überlast):
Annahme: TCP geht davon aus, dass Pakete durch Überlast im
Netz verloren gehen. Paketverlust durch Transmissionsfehler < 1%
Ein Verlust beruht also auf Verlust in Zwischensystemen
(Paketdrop / Bufferoverflow)
Verlust wird durch RetransmissionTimeout (RTO) und Empfang von
doppelten ACKs (=duplizierte Quittungen) festgestellt
Congestion Avoidance und Slow Start eigentlich separate
Funktionen, werden aber zusammen implementiert
17 - 41
17 - 42
Congestion Avoidance:
Starts when cwnd ≥ ssthresh
On each successful ACK: cwnd ← cwnd + 1/cwnd
Linear growth of cwnd. Each RTT: cwnd ← cwnd + 1
17 - 42
sender
receiver
cwnd
1
2
17 - 43
data
packet
ACK
1 RTT
3
4
cwnd ← cwnd + 1 (for each cwnd ACKS)
17 - 43
SSTHRESH
SSTHRESH =
=
min(window,
min(window, CWND)
CWND) // 22
(mindestens
(mindestens aber
aber 22
Segmente)
Segmente)
SSTHRESH
SSTHRESH == 65535
65535
CWND
CWND == 11
Paketverlust
Paketverlust
durch
durch Timeout
Timeout
Sende
Sende
min(WINDOW,
min(WINDOW,
CWND)
CWND) Daten
Daten
Nein
Nein
Inc(CWND)
Inc(CWND)
(Slow
(Slow Start)
Start)
Paketverlust
Paketverlust
17 - 44
CWND
CWND <=
<=
SSTHRESH
SSTHRESH
Ja
Ja
CWND
CWND == 11
Ja
Ja
Nein
Nein
Ja
Ja
Nein
Nein
Conguesten
Conguesten
Avoidance
Avoidance
Slow
Slow Start
Start
Bis
Bis CWND
CWND ==
SSTHRESH
SSTHRESH
CWND
CWND == CWND
CWND ++
1/CWND
1/CWND
(max.
(max. 11 pro
pro RTT)
RTT)
17 - 44
TCP-Überlastungsüberwachung
17 - 45
17 - 45
Slow Start and Congestion Avoidance (5)
17 - 46
Slow Start und Congestion Avoidance: [Siehe dazu Abb.]
Die maximale Segmentgröße ist 1.024 Byte (= 1 MSS)
Anfangs umfasst das Überlastungsfenster (Cwnd) 64 KByte, dann
findet ein Timeout statt, so dass der Schwellenwert auf 32 KByte
gesetzt wird. [Soweit die Vorbedingungen !!!]
Das Überlastungsfenster startet bei 1 MSS (= 1 KByte) und wächst
nach dem TCP Slow Start Algorithmus exponentiell bis es den
Schwellenwert (= Threshold hier bei 32 KByte) erreicht.
Ab dem Schwellenwert übernimmt der TCP Congestion Avoidance
Algorithmus und das Überlastungsfenster steigt nur noch linear.
Segment 13 hat kein Glück und geht verloren. Es kommt zu einem
Timeout.
Der Schwellenwert wird auf die Hälfte der aktuellen Fenstergröße
gesetzt (inzwischen 40 KByte, d. h. die Hälfte ist 20 KByte).
TCP Slow Start beginnt wieder von neuem (bei 1 ).
17 - 46
Slow Start and Congestion Avoidance (6)
17 - 47
Slow Start und Congestion Avoidance:
Slow Start Threshold Size (ssthresh):
ssthresh = minimum(window,cwnd)/2, mindestens aber 2 Segmente
17 - 47
Flow Control and Congestion Control
17 - 48
Flow Control (Flusskontrolle):
Soll verhindern, dass ein Sender zeitiger, schneller oder mehr
Daten schickt als der Empfänger verarbeiten kann
Begrenzung der Datenmenge
Congestion Control (Überlastkontrolle):
Funktion der Netzwerkschicht zur Regelung des Datenflusses
zwischen zwei Netzteilnehmern
Begrenzung der Übertragungsrate
Verhindert, dass zu viele Daten in das Netz eingespeist werden
und dadurch Vermittler oder Verbindungen überlastet werden
Merke: Flusskontrolle ist ein Ende-zu-Ende-Problem, während
Überlastkontrolle die Interaktion zwischen Hosts und Netzwerken
betrifft.
17 - 48
17 - 49
Lernziele heute:

TCP Silly Window Syndrom verstehen und erklären können
TCP Nagle-Algorithmus verstehen, erklären und anwenden können
TCP Karn/Partridge-Algorithmus verstehen und erklären können
TCP Jacobson/Karels-Algorithmus verstehen und erklären können
17 - 49
17 - 50
TCP

Das Silly-Window-Syndrom
Nagle-Algorithmus
Karn/Partridge-Algorithmus
Jacobson/Karels-Algorithmus
17 - 50
Das Silly-Window-Syndrom
17 - 51
Silly-Window-Syndrom (dt. Dummes-Fenster-Syndrom): Tritt auf,
wenn große Datenmengen an die sendende TCP-Instanz übergeben
werden, während eine interaktive Anwendung am empfangenden Ende
die Daten nur Byte für Byte einlesen kann.
17 - 51
Silly-Window-Syndrom (1)
Sender
17 - 52
Receiver
Problem:
Aggressive Ausnutzung jedes beliebig verfügbaren Fensters
Sender verschickt sehr kleine Segmente (z. B. 1 Byte), Empfänger
bestätigt Î Sender schickt wieder sehr kleines Segment, usw. Î
kleine Segmente mit viel Overhead verbleiben (für lange Zeit) im
System
Tritt nur auf, wenn entweder der Sender ein kleines Segment
überträgt, oder der Empfänger das Fenster nur wenig öffnet
17 - 52
Silly-Window-Syndrom (2)
17 - 53
Das Silly-Window-Syndrom (Problembeschreibung):
Der Empfänger sendet ein Zero Window an den Sender, da sein
Buffer voll ist. Die Anwendung beim Empfänger liest allerdings nur
zwei Byte aus dem Buffer. Der Empfänger schickt ein TCP-Header
mit Window=2 (Window Update) an den Sender und fordert
gleichzeitig die zwei Byte an.
Der Sender kommt der Aufforderung nach und schickt die zwei Byte
in einem 42 Byte großen Paket (mit IP-Header und TCP-Header) an
den Empfänger.
Damit ist der Buffer des Empfängers wieder voll und er schickt
wieder ein Zero Window an den Sender. Die Anwendung liest jetzt
zum Beispiel hundert Byte aus dem Buffer.
Der Empfänger schickt wieder ein TCP-Header mit einem kleinen
Window-Wert an den Sender. Dieses Spiel setzt sich immer wieder
fort und verschwendet Bandbreite, da nur sehr kleine Pakete
versandt werden.
17 - 53
Abhilfe auf Empfängerseite
17 - 54
Abhilfe gegen Silly-Window-Syndrom auf Empfängerseite
von Dave Clark (1982):
Empfänger darf nur Window = 0 senden, oder
wartet mit Window-Update bis mind. ein MSS im Puffer frei ist
Also die Regel lautet:
Nachdem ein Fenster mit Größe = 0 bekannt gegeben wurde,
muss der Empfänger solange warten, bis Platz im Umfang von
einer Maximum Segment Size (MSS) vorhanden ist, bevor er
wieder ein offenes Fenster bekannt gibt
MSS von TCP: Maximal 65.515 Byte Payload
MSS von TCP über Ethernet: 1.460 Byte Payload
17 - 54
Nagle-Algorithmus (1)
17 - 55
Abhilfe gegen Silly-Window-Syndrom auf Senderseite von
Nagle (1984):
Ist ein Segment voll, dann schicke es
Ist ein Segment nicht voll, dann schicke es erst, wenn du genug
Daten hast, oder keine unbestätigten Pakete mehr unterwegs sind
Anmerkung:
Nagle-Algorithmus ist eine einfache, selbst-taktende Lösung
17 - 55
Nagle-Algorithmus (2)
17 - 56
Nagle-Algorithmus im Detail:
Anwendung hat sendebereite Daten produziert
Einfache, einheitliche Regel für die Entscheidung, wann übertragen
werden soll:
Falls sowohl die verfügbaren Daten als auch das Fenster ≥ MSS, dann
Sende ein volles Segment
Andernfalls
Falls unbestätigte Daten anstehen, dann puffere die neuen Daten,
bis ein ACK ankommt
Andernfalls
Sende alle neuen Daten sofort
Anmerkung:
Nagle-Algorithmus kann durch setzen der TCP_NODELAY-Option
ausgeschaltet werden
17 - 56
Verwaltung von Timern in TCP
17 - 57
(a) Wahrscheinlichkeitsdichte der Ankunftszeiten von Bestätigungen (ACKs) auf der
Sicherungsschicht (Layer 2, MAC-Schicht).
(b) Wahrscheinlichkeitsdichte der Ankunftszeiten von Bestätigungen (ACKs) für TCP
17 - 57
Abschätzung von Round-Trip-Times
17 - 58
RTT-Muster (Samples) und RTT-Durchschnitt (Average)
[Quelle: Kurose & Ross, Computernetze, Aufl. 2002, Abb. 3.36]
17 - 58
Adaptive Neuübertragung
17 - 59
Adaptive Neuübertragung (Original-Algorithmus):
Konzept: Ermittele ständig den gleitenden Durchschnitt der RTT
und berechne daraus den (Retransmission) Timeout-Wert
Vorgehen im Detail:
Messe SampleRTT für jedes Segment/ACK-Paar
Berechne den gleitenden (gewichteten) Durchschnitt von RTT
EstimatedRTT ← a x EstimatedRTT + (1 - a) x SampleRTT
- wobei a zwischen 0.8 und 0.9
- Parameter a wird gewählt, um EstimatedRTT zu glätten
TCP benutz EstimatedRTT, um den Timeout relative konservativ zu
berechnen:
TimeOut := 2 x EstimatedRTT
17 - 59
Karn/Partridge-Algorithmus (1)
17 - 60
Problem bei Berechnung von EstimatedRTT:
Ein ACK bestätigt in Wirklichkeit keine Übertragung, sondern nur
den Empfang von Daten
Mit anderen Worten: Wenn ein Segment erneut übertragen wird
und anschließend ein ACK beim Sender ankommt, lässt sich
nicht feststellen, ob das ACK mit der ersten oder zweiten
Übertragung des Segments in Verbindung gebracht werden soll
Ansatz:
Überlast ist die wahrscheinlichste Ursache für verlorene
Segmente, was bedeutet, dass die TCP-Quelle nicht zu aggressiv
auf einen Timeout (Retransmission Timer) reagieren sollte
17 - 60
Sender
Receiver
Orig
inal
Retr
trans
miss
io
ansm
issio
17 - 61
Sender
Orig
n
Receiver
inal
trans
miss
ion
ACK
Retr
ansm
issio
n
n
ACK
(a)
(b)
Karn/Partridge-Algorithmus:
a) Zusammenhang des ACK mit der ursprünglichen Übertragung
b) Zusammenhang des ACK mit der Neuübertragung
17 - 61
17 - 62
Lösung:
Wann immer TCP ein Segment erneut überträgt, setzt die
Messung der RTT aus
SampleRTT wird nur für Segmente gemessen, die einmal
gesendet (und bestätigt) wurden
Lösung im Detail:
Jedes Mal, wenn TCP erneut überträgt, dann setzt es den
nächsten Timeout auf das Doppelte des letzten, statt auf die letzte
Estimated RTT
17 - 62
Jacobson/Karels-Algorithmus (1)
17 - 63
Problem:
Starke Netzüberlast im Internet
Ansatz: Zusammenhang zwischen Timeout und Überlast
Wenn der Timeout zu früh abläuft, wird ein Segment
möglicherweise unnötig erneut übertragen, wodurch das Netzwerk
noch stärker belastet wird
Hauptproblem der ursprünglichen RTT-Berechnung:
Varianz der SampleRTT wurde nicht in Betracht gezogen
Weichen die Messwerte (samples) nur wenig voneinander ab, dann
dürfte die EstimatedRTT (geschätzte RTT) zuverlässig sein damit
kein Grund vorliegen RTT mit 2 zu multiplizieren
Bei großen Schwankungen der SampleRTT ist
17 - 63
17 - 64
Berechnung von mittlerer RTT (Mittelwert) und Schwankungen:
Differenz = SampleRTT - EstimatedRTT
EstimatedRTT = EstimatedRTT + (d x Differenz)
Abweichung ← Abweichung + d x ( |Differenz| - Abweichung)
- wobei d eine Zahl zwischen 0 und 1 ist
TCP berechnet den Timeout-Wert als Funktion von EstimatedRTT
und Abweichung:
TimeOut = m x EstimatedRTT + f x Abweichung
- wobei m = 1 und f = 4
TimeOut = EstimatedRTT + 4 x Abweichung
17 - 64
17 - 65
Ergebnis:
Bei geringen Schwankungen der RTT liegt Timeout nahe bei der
EstimatedRTT
Bei großen Schwankungen dominiert der Term Abweichungen
Bemerkung:
Algorithmus nur so gut wie die Granularität (Genauigkeit) der
rechnerinternen Uhr (z. B. bei Unix 500 ms)
Genauer Timeout-Mechanismus ist wichtig für Congestion Control
17 - 65
17 - 66
Vielen Dank für Ihre
Aufmerksamkeit!
Noch Fragen?
Fragen und Diskussion
17 - 66

TCP

Transcription

Documents pareils

Welche Ports werden von der Hardware

Das Obst (die Früchte)

IS NW33 SS - Notenstatistik.ch

Daemen, Heinrich: Gruppierung derzeit auf dem Markt befindlicher

1.0

Besuch der alten Herren

ZyWALL SSL-10