Mobilkommunikationsnetze - Transportschicht · • Silly Window Syndrome – voller Empfängerpuffer ( RWIN = 0, Sender stoppt) – Entnahme in kleinen Häppchen ( RWIN sehr klein,

Mobilkommunikationsnetze

Vorlesung

1

Prof. Dr.-Ing. habil. Andreas Mitschele-Thiel

Fachgebiet Integrierte Kommunikationssysteme

www.tu-ilmenau.de/iks


- Transportschicht -

Vorlesung

Andreas Mitschele-Thiel


Vorlesung

2




Inhalt

• TCP

– Überblick

– Probleme im mobilen Einsatz

– Lösungsansätze

• SCTP Multihoming

• Literatur

– W. Richard Stevens: „TCP/IP Illustrated Vol. 1: The

Protocols“

– Standards: http://www.ietf.org oder http://www.rfc-

editor.org


Vorlesung

3




Ü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


Vorlesung

4




TCP – Header

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)

Daten

Nummer des ersten Bytes dieses Segmentes innerhalb

des Bytesstromes

Bestätigung der Gegenseite für empfangene Daten (nächste erwartete Sequenznummer)

Bestandteil des Verbindungsendpunktes

Prüfsumme: Einerkomplementsumme12 Byte IP-Pseudo-Header+TCP-Header+Daten)

Falsche Checksumme → Paketverwerfen. Wiederholung durch ARQ sichergestellt

Fenstergröße (Anzahl an Bytes, die der Empfänger empfangen kann, Puffergröße)

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


Vorlesung

5




TCP – Verbindungsaufbau

Client Server

Verbindung offen Datentransfer

Segment 1: SYN + ISN + Optionen

(bspw. MSS)

Active open Passive open

Segment 2: SYN, ACK + ISN +

Optionen (bspw. MSS)

Segment 3: ACK

Anwendung schließt Verbindung

Segment 1: FIN

EOF an Anwendung

Segment 2: ACKAnwendung darf noch

senden

Anwendung auf Serverseite geschlossen Segment n-1: FIN

Segment n: ACK

half-close #1

half-close #2

Active closePassive close


Vorlesung

6




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 als

Option gesendet kann theoretisch für beide Richtungen

unterschiedlich sein

– Gegenüber sendet Segmente

≤ min(𝑀𝑇𝑈 − 𝑠𝑖𝑧𝑒 𝐼𝑃𝐻𝑒𝑎𝑑𝑒𝑟 − 𝑠𝑖𝑧𝑒 𝑇𝐶𝑃𝐻𝑒𝑎𝑑𝑒𝑟 ,𝑀𝑆𝑆)

– normalerweise: abgeleitet von MTU des L2 (weitere

Grenzen möglich)

– ggf. Anpassung auf Basis von Path MTU Discovery


Vorlesung

7




TCP – Maximum Segment Size (MSS)

Client Server

Segment 1: SYN + ISN + MSS=536

Segment 2: SYN, ACK + ISN +

MSS=1460

Segment 3: ACK

Anwendung stellt Datenblocküber 1500 Byte ein

Segment 3:Seq: ISN+1

Payload: 536 ByteSegment 4: ACK, ACKSeq: ISN+537






Vorlesung

8




TCP – Acknowledgements

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

• neues ACK für jedes Segment in der richtigen

Reihenfolge

39

Sender EmpfängerRouter Router

xx

yy

Segment xxACK für Segment yy

3536

36

3738

353433


Vorlesung

9




TCP – Delayed ACKs

• ACK-Anzahl reduzieren durch Verzögerung bis

– weiteres Segment empfangen wurde

– Timer abläuft (typisch: 200 ms)

39


xx

yy


3536

36

3738

34


Vorlesung

10




TCP – Duplicate ACKs

• Bei Empfang eines außerplanmäßigen Segments:

letztes planmäßiges Segment erneut bestätigen

Fehlerindikator

• Beispiel Paketverlust

39


36

xx

yy


3536

36

3738


Vorlesung

11




TCP – Duplicate ACKs

• Beispiel Paketvertauschung

• unterschiedliche Dup-ACK-Muster

– Einzeln: Paketvertauschung

– Serie: wahrscheinlich einzelner Paketverlust

39


36

xx

yy


3537

38

3638

36


Vorlesung

12




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)

𝑅𝑇𝑇𝑉𝐴𝑅 ← 1 − 𝛽 ∙ 𝑅𝑇𝑇𝑉𝐴𝑅 + 𝛽 ∙ 𝑆𝑅𝑇𝑇 − 𝑅𝑇𝑇

𝑆𝑅𝑇𝑇 ← 1 − 𝛼 ∙ 𝑆𝑅𝑇𝑇 + 𝛼 ∙ 𝑅𝑇𝑇𝑹𝑻𝑶 ← 𝑺𝑹𝑻𝑻 +𝐦𝐚𝐱 𝑮,𝑲 ∙ 𝑹𝑻𝑻𝑽𝑨𝑹


Vorlesung

13




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.

Satellitenkommunikation)

𝑇1 = 𝑅𝑇𝑂, 𝑇2 = 2 ∙ 𝑇1, 𝑇3 = 2 ∙ 𝑇2, …


Vorlesung

14




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

unsortiert

zuverlässig nur mit „nahezu reihenfolgetreuen“

unteren Schichten


Vorlesung

15




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

• heute Standard in allen verbreiteten Systemen


Vorlesung

16




TCP: Flow Control – Sliding Window Protocol

• Problem: Bandbreitenverzögerungsprodukt

• Übertragungsfenster: mögliches Volumen 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ässiges Volumen unbestätigt übertragener Segmente


Vorlesung

17





• Ohne Sliding Window:

• 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

Daten

ACK


Vorlesung

18





• Mit Sliding Window:

• Kontinuierlicher Datenfluss über die Leitung

optimale Ausnutzung

Daten

ACK

DatenDatenDatenDatenDaten


Vorlesung

19





• 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


Vorlesung

20




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)

Empfangene DatenRWIN

Empfängerpuffer

zur Applikation

aus demNetz


Vorlesung

21




TCP: Flow Control – Congestion Window

• Maximale Anzahl ohne ACK zu sendender Segmente

– Vermeidung von Überlast im Netzwerk und am Ziel

– faire Ressourcenverteilung ohne zentrale Steuerung

• 2 Phasen:

– Slow Start: Erhöhung des Congestion Window (cwnd) um

1 MSS je empfangenem ACK resultiert in Verdoppelung

des cwnd mit jedem RTT (bis zur Erreichung des Slow

Start Schwellwerts (ssthresh))

– Congestion Avoidance: Erhöhung des cwnd um 1/cwnd mit

jedem ACK resultiert in linearer Vergrößerung des cwnd (1

MSS je RTT)

• Theoretisch: Vergrößerung bis RWIN


Vorlesung

22




TCP: Flow Control – Congestion Window

0 1 2 3 4 5 6 7 8 9

14

12

10

8

6

4

2

0

Time (RTT)

cwn

d(S

egm

ente

)

Slowstart

Congestionavoidance

RWIN=12

ssthresh=8


Vorlesung

23




TCP: Flow Control – Reaktion auf Paketverlust

• 2 Fälle:

– Timeout (ernsthaftes Problem im Netz)

• Zurück auf Slow Start

• Cwnd = 1 MSS

• Ssthresh 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


Vorlesung

24




TCP: Flow Control – Slow Start nach Timeout

0 3 6 9 12 15 18 21 24

25

20

15

10

5

0

ssthresh = 8

cwnd = 20

Timeout

ssthresh = 10

cwnd = 1

Time (RTT)

cwn

d(S

egm

ente

)


Vorlesung

25




TCP: Flow Control – Fast Recovery

0 3 6 9 12 15 18 21 24

25

20

15

10

5

0

ssthresh = 8

cwnd = 20

≥ 3 DUP-ACK Fast Recovery

ssthresh = 10cwnd = 10

Time (RTT)

cwn

d(S

egm

ente

)


Vorlesung

26




TCP: Flow Control – Heute und Morgen

• TCP Vegas, New Reno, Hybla, CUBIC, SPDY, etc.

– Anpassung verschiedener Parameter an unterschiedliche

Einsatzzwecke (mobil, hohe Latenz, ...)

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

cwnd

Zeit

Wmax

Steady StateBehavior

Probing


Vorlesung

27




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)

einfache Änderung durch breite Verteilung nicht möglich


Vorlesung

28




TCP: Lösungsbeispiele – Indirect TCP

• Aufspaltung der Verbindung in festen und mobilen Teil

– normales TCP im Festnetz

– optimiertes TCP auf drahtlosem Link

– Vorteil: keine Anpassung der Systeme im Internet

– Nachteil: Verlust der Ende-zu-Ende-Semantik

Internet

Standard-TCP „mobiles“ TCP

Mobility SupportRouter (MSR)


Vorlesung

29




TCP: Lösungsbeispiele – Indirect TCP

• Vorteile:

– keine Änderungen am bestehenden Netz, alle TCP-

Optimierungen funktionieren wie gewohnt

– Festnetz gegen Übertragungsfehler im mobilen Teil isoliert

– sehr schnelle Neuübertragung auf Funklink möglich, da

Linkparameter gut bekannt

• Nachteile

– Verlust der Ende-zu-Ende-Semantik ACK heißt nicht

mehr, dass der Empfänger das Paket erhalten hat

– möglicherweise höhere Latenz durch Pufferung

– Probleme bei Handover/Mobilität

– scheitert an Sicherheitsmechanismen wie IPSec


Vorlesung

30




TCP: Lösungsbeispiele – Snooping TCP

• transparente TCP-Erweiterung im MSR

– Puffern von Paketen an MH

– verlorene Pakete auf dem Funklink werden lokal erkannt

und direkt neu übertragen

mehr Wissen über Funklink, ggf. schnellere Erkennung

von Ausfällen

– Filterung von DUP-ACK bei lokaler Neuübertragung

Paketverlust wird vor Sender verborgen

Internet

MSR


Vorlesung

31




TCP: Lösungsbeispiele – Snooping TCP

• Übertragung an MH (Downlink)

– Zwischenspeichern von Paketen im AP

– Neuübertragung bei DUP-ACK oder lokalem Timeout

• Übertragung von MH (Uplink)

– Erkennung von Lücken in Sequenznummern

– Explizite Signalisierung von Verlusten mittels TCP SACK

an MH schnelle lokale Neuübertragung

• Probleme

– Isolation nicht so vollständig, wie bei Indirect-TCP

– IPSec verhindert Anwendung


Vorlesung

32




TCP: Lösungsbeispiele – Sonstige

• Mobile TCP

– Indirekt-TCP-Ansatz mit TCP ohne Slow Start auf Mobilseite

– Anhalten der netzseitigen Verbindung bei Abbruch im Funklink RWIN=0

– Wiederaufnahme durch RWIN > 0

• Erzwungenes Fast Retransmit/Fast Recovery

– MH täuscht durch DUP ACKs nach Netzwechsel einzelnePaketverluste vor Fast Retransmit, statt Slow Start

– lediglich Lösung für Handover, keine Isolation von Paketverlusten im Funklink

• verschiedene andere Speziallösungen Grundproblem bleibt: Paketverluste + hoher Jitter problematisch für TCP


Vorlesung

33




Stream Control Transmission Protocol

• Transportprotokoll mit Schwerpunkt auf Signalisierungs-

transport

• RFC 4960

• nachrichtenorientiert Transport ( vgl. UDP)

• Auslieferungs- & Reihenfolgegarantie ( vgl. TCP)

• Staukontrolle ( vgl. TCP)

• Transport mehrerer, unabhängiger Ströme

• Multihoming-Fähigkeit


Vorlesung

34




SCTP Multihoming

• Mehrere Adressen pro Endpunkt möglich

• Umkonfiguration der bevorzugten Adresse im Betrieb

• Verwendung alternativer Adressen bei Neuübertragung

• Mit Erweiterung (RFC 5061): dynamisches Hinzufügen

und Löschen von Adressen (auch nach Wechsel der

Anbindung)

S1 S2

A

BC

D

E

IP-Adressen

SCTP associationS1: A, B, CS1-active: AS2: D, ES2-active: E


Vorlesung

35




Zusammenfassung

• Mobilität stellt Transportschicht vor neue Probleme

– veränderte Designannahmen

• Verlustrate

• Jitter

– Änderung des Netzzugangspunktes möglich

Probleme mit Nutzung der IP-Adresse als Identifikation

in Verbindungsinformationen

• verschiedene Lösungsansätze

– Isolation des Funklinks durch Indirect-TCP, u.ä.

– Multihoming mit dynamischer Adressverwaltung bei SCTP

Documents

Mobilkommunikationsnetze - Transportschicht · • Silly Window Syndrome – voller Empfängerpuffer ( RWIN = 0, Sender stoppt) – Entnahme in kleinen Häppchen ( RWIN sehr klein,