Mobilkommunikationsnetze - Transmission Control · PDF file- Transmission Control Protocol - Mobilkommunikationsnetze Markus Brückner Page 2 Prof. Dr.-Ing. habil. ... TCP: Flow Control

Prof. Dr.-Ing. habil. Andreas Mitschele-ThielIntegrated Communication Systems Groupwww.tu-ilmenau.de/ics

VorlesungMarkus Brückner

Mobilkommunikationsnetze- Transmission Control Protocol -

MobilkommunikationsnetzeMarkus Brückner

Page 2


Überblick TCP

● Verbindungsorientiert

– Datentransport erst nach Verbindungsaufbau möglich

– 1:1-Beziehung zwischen Endsystemen

● Zuverlässig

– Auslieferungsgarantie durch Automatic Repeat Request (ARQ)

● Stromorientiert

– Applikationen sehen durchgehenden Bytestrom statt einzelner Pakete

– Reihenfolgegarantie für Bytes im Strom


Page 3


Paketformat

Source Port (16 Bit) Destination Port (16 Bit)

Sequenznummer (32 Bit)

Acknowledgement-Sequenznummer (32 bit)Headerlänge reserviert Flags (6 Bit) Window Size (16 Bit)

Prüfsumme (16 Bit) Urgent Pointer (16 Bit)

Optionen (soweit vorhanden)

DatenURG: Urgent Field PointerACK: Acknowledgement Sequence beachtenPSH: Push Function - Daten sofort übertragenRST: Verbindung abbrechenSYN: Sequenznummern synchronisieren (Verbindungsaufbau)FIN: keine weiteren Daten (Verbindungs- abbau)

Prüfsumme: Einerkomplementsumme

12 Byte IP-Pseudo-Header+TCP-Header+Daten)

Falsche Checksumme → Paketverwerfen. Wiederholung durch

ARQ sichergestellt

Fenstergröße (Anzahl anBytes, die der Empfänger

empfangen kann, Puffergröße)

Bestätigung der Gegenseite fürempfangene Daten (nächsteerwartete Sequenznummer)

Nummer des ersten Bytesdieses Segmentes innerhalb

des Bytesstromes

BestimmtVerbindungsendpunkt


Page 4


Verbindungsaufbau

Client Server

Active open Dreiwege-Handshake

Segment 2:SYN, ACK + ISN + Optionen

(bspw. MSS)

Segment 3: ACK

Verbindung offenDatentransfer

Passive open

Active close

Segment 1:SYN + ISN + Optionen

(bspw. MSS)

Anwendung schließtVerbindung

→ Segment 1: FIN

Passive close

EOF an Applikation

Segment 2: ACKApplikation kann noch

Daten senden

Schließen auf ServerseiteSegment 2:

→ Segment 3: FINSegment 4: ACK

Half-close #1

Half-close #2


Page 5


TCP: Maximum Segment Size (MSS)

● Problem: Fragmentierung von TCP-Segmenten steigert Verlustrate → erhöhter Aufwand zur Neuübertragung

● Lösung: 1 TCP-Segment = 1 IP-Paket → MSS

● Idee:

– MSS wird von jedem Teilnehmer im Verbindungsaufbau gesendet → kann für beide Richtungen unterschiedlich sein

– Gegenüber sendet Segmente <= MSS

– normalerweise: abgeleitet von MTU des L2 (weitere Grenzen möglich)

– ggf. Anpassung auf Basis von Path MTU Discovery


Page 6


Client ServerAnwendung

TCP

IP

Link Layer

Verbindungsanforderung

SYN, MSS=536TCP Verbindungs-

aufbau

MSS = 536 minus TCP header = 20

minus IP header = 20

MTU = 576 (bspw. Modem)

MSS = 1460

minus TCP header = 20

minus IP header = 20

MTU = 1500 (bspw. Ethernet)

SYN, ACK, MSS=1460

TCP: Maximum Segment Size (MSS)

Passendes Interface finden


Page 7


TCP: Acknowledgements

● jedes ACK bestätigt alle Segmente bis zu dieser Stelle

● neues ACK für jedes Segment in der richtigen Reihenfolge

Sender Router Router Empfänger38 37 36

34 35

xx

yy

Segment xx

ACK für Segment yy

33

39

36

35


Page 8


TCP: Delayed ACKs

● ACK-Anzahl reduzieren durch Verzögerung bis

– weiteres Segment empfangen wurde

– Timer abläuft (typisch: 200 ms)

Sender Router Router Empfänger38 37 36

34

xx

yy

Segment xx

ACK für Segment yy

39

36

35


Page 9


TCP: Duplicate Acks

● Bei Empfang eines außerplanmäßigen Segments: letztes planmäßiges Segment erneut bestätigen→ Fehlerindikator

● Beispiel Paketverlust

Sender Router Router Empfänger36 35

xx

yy

Segment xx

ACK für Segment yy

37

34

3334


Page 10


TCP: Duplicate Acks

● Beispiel Paketvertauschung

● unterschiedliche Dup-ACK-Muster

– Einzeln: Paketvertauschung

– Serie: wahrscheinlich einzelner Paketverlust

Sender Router Router Empfänger36 34

xx

yy

Segment xx

ACK für Segment yy

37

34

3335

36


Page 11


TCP: ARQ

● Detektion von Paketverlusten durch Timeout

– Stellen eines Timers für gesendetes Segment x

– Senden von n-1 weiteren Paketen (Fenstergröße n)

– bei Ablauf des Timers: Neuübertragung ab x→ go-back-N ARQ

● Berechnung des Retransmission Timeouts (RTO)(RFC 6298)

– SRTT=gewichteter Mittelwert von RTT, RTTVAR = mittlere Abweichung von SRTT, G = Auflösung d. Systemtimers, K = Gewichtung RTTVAR (oft: K = 4)

RTTVAR ← (1−β)⋅RTTVAR+β⋅∣SRTT−RTT∣SRTT ← (1−α)⋅SRTT +α⋅RTTRTO ← SRTT +max (G ,K⋅RTTVAR)


Page 12


TCP: ARQ - Exponential Backoff

● Problem: zu viele Neuübertragungen verstopfen bereits überlastete Router im Netz

● Lösung: Verdoppelung RTO bei aufeinander folgenden Timeouts

– Einschränkung des Maximums möglich, min. 60 s, in der Realität meist deutlich mehr

● Vorteil: löst Probleme mit Überlast

● Nachteil: ggf. lange Timeouts bis Erholung bei kurzzeitigen Linkunterbrechungen (bspw. Satellitenübertragung)

T 1=RTO ,T 2=2⋅T 1 ,T 3=2⋅T 2 ,…


Page 13


TCP: ARQ – Fast Retransmit

● Problem: Timeout bei einzelnen verlorenen Pakete zu lang → ineffizient

● Idee: mehrere DUP-ACK mit gleicher Nummer deuten auf Einzelverlust hin→ sofortige Neuübertragung des betreffenden Segments (selective repeat ARQ)

● Beispiel: Segmente 33, 35, 36 ausgeliefert → 3 DUP-ACK für 34 → sofortige Neuübertragung, statt Timeout

● Nachteil: unnötige Neuübertragung, wenn Pakete stark umsortiert → zuverlässig nur mit „nahezu reihenfolgetreuen“ unteren Schichten


Page 14


TCP: ARQ - Selective ACK

● Problem: Cumulative ACKs können nur durchgehende Datenbereiche bestätigen → bei einzelnem Paketverlust ggf. unnötige Übertragung mehrerer Segmente

● Idee: Selective ACKs (RFC 2018) erlauben Bestätigung unzusammenhängender Bereiche

– Bestätigung durch SACK-Blöcke (von x bis y) in TCP Option Header

– Neuübertragung nur fehlender Segmente

– nur möglich, wenn beidseitig unterstützt → Aushandlung während Verbindungsaufbau


Page 15


TCP: Flow Control – Sliding Window Protocol

● Übertragungsfenster: mögliche Größe ohne ACK zu übertragender Daten

– Beispiel: Window Size = 10 kB → 10 kB Daten können „auf Verdacht“ vom Sender losgeschickt werden (auch in mehreren Segmenten)

● Fenstergröße ist Minimum aus

– Receive Window Size: vom Empfänger in jedem ACK bekannt gegeben, bestimmt von der Größe des Empfangspuffers

– Congestion Window: laut Slow-Start-Algorithmus aktuell zulässige Anzahl unbestätigt übertragener Segmente


Page 16



● Optimale Fenstergröße: W = Datenrate · RTT(Bandbreitenverzögerungsprodukt)

● Bestätigung frühestens nach RTT möglich→ Leitung ist „voll“, wenn während RTT ständig Daten nachfließen

● Datenmenge in RTT = Datenrate · RTT→ optimale Fenstergröße

Sender Empfänger

Daten

ACK


Page 17



● Zu großes Übertragungsfenster

– Daten verbleiben im lokalen Puffer oder

– steigender Pufferfüllstand auf Routern (bei unterschiedlich schnellen Teilstrecken, bspw. WLAN – DSL - …)→ steigendes Delay→ mögliche Paketverluste

● Zu kleines Übertragungsfenster

– keine weiteren Daten zur Übertragung frei→ ungenutzte Übertragungskapazität


Page 18


TCP: Flow Control – Receive Window

● Freie Pufferkapazität im Empfänger

● bestimmt durch Entnahme von Daten seitens der Applikation

● Silly Window Syndrome

– voller Empfängerpuffer (→ RWIN = 0, Sender stoppt)

– Entnahme in kleinen Häppchen ( → RWIN sehr klein, Sender schickt angeforderte, kleine Datenmenge als ein Segment)

– → ineffiziente Übertragung durch großen Overhead (TCP-Header)


Page 19


TCP: Flow Control – Congestion Window

● Maximale Anzahl ohne ACK zu sendender Segmente

– Vermeidung von Überlast im Netzwerk

– faire Ressourcenverteilung ohne zentrale Steuerung

● 2 Phasen:

– Slow Start: Verdoppelung des Congestion Window (cwnd) mit jedem ACK bis Erreichen eines Schwellwerts (slow-start threshold, ssthresh)

– Congestion Avoidance: lineare Vergrößerung des cwnd um 1 MSS mit jedem ACK

● Theoretisch: Vergrößerung bis RWIN


Page 20


TCP: Flow Control – Congestion Window

0

2

4

6

8

10

12

14

0 1 2 3 4 5 6 7 8 9

Time / RTT

cwn

d (

seg

me

nts

)

Slow Start

CongestionAvoidance

ssthresh

RWIN = 12


Page 21


TCP: Flow Control – Reaktion auf Paketverlust

● 2 Fälle:

– Timeout (ernsthaftes Problem im Netz)● Zurück auf Slow Start● Congestion Window = 1 MSS● Threshold auf halbe Fenstergröße vor Verlust (min. 2 MSS)

– DUP-ACK (Link i.O., einzelner Paketverlust)● Fast Retransmit (des fehlenden Segmentes, ab TCP Reno)● Fast Recovery

– ssthresh & cwnd auf halbe Fenstergröße vor dem Verlust– weiter mit Congestion Avoidance


Page 22


TCP: Flow Control – Slow Start nach Timeout

0

5

10

15

20

25

Time / RTT

cwnd (se

gm

ents

)

ssthresh = 8ssthresh = 10

cwnd = 20Timeout

cwnd = 1


Page 23


TCP: Flow Control – Fast Recovery

0

2

4

6

8

10

Time / RTT

cwn

d (

seg

me

nts

)

nach Fast Recovery

ssthresh = 4

≥3 Dupacks

cwnd = 8

cwnd = 4


Page 24


TCP: Flow Control - Heute

● TCP Vegas, New Reno, Hybla, QUBIC etc.

– Anpassung verschiedener Parameter an unterschiedliche Einsatzzwecke (mobil, hohe Latenz, ...)

– Beispiel CUBIC ( http://research.csc.ncsu.edu/netsrv/?q=content/bic-and-cubic):


Page 25


TCP: Probleme im mobilen Einsatz

● Annahme: Paketverlust = Stau im Netzwerk

– Staukontrolle mit Slow Start etc.

● Realität: Paketverlust viel häufiger aufgrund Fehler im Medium→ unnötiges Abregeln der Senderate

● Annahme: Jitter verhältnismäßig klein

– je nach Implementierung schwache Gewichtung neuer RTT-Werte

● Realität: je nach Medium (WLAN!) massiv schwankende Übertragungsverzögerung (bspw. durch ARQ auf Link Layer)


Page 26


Literatur

● W. Richard Stevens: „TCP/IP Illustrated Vol. 1: The Protocols“

● Standards: http://www.ietf.org oder http://www.rfc-editor.org

http://www.ietf.org/

http://www.rfc-editor.org/


Page 27


Contact

Visitors address:

Technische Universität IlmenauHelmholtzplatz 5Zuse building, room 1034D-98693 Ilmenau

fon: +49 (0)3677 69 4125fax: +49 (0)3677 69 4823e-mail: [email protected]

www.tu-ilmenau.de/ics

Integrated Communication Systems GroupIlmenau University of Technology

Dipl.-Inf. Markus Brückner

Documents

Mobilkommunikationsnetze - Transmission Control · PDF file- Transmission Control Protocol - Mobilkommunikationsnetze Markus Brückner Page 2 Prof. Dr.-Ing. habil. ... TCP: Flow Control