mobilkommunikationsnetze - transmission control · pdf file- transmission control protocol -...

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

VorlesungMarkus Brückner

Mobilkommunikationsnetze- Transmission Control Protocol -

MobilkommunikationsnetzeMarkus Brückner

Ü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

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

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

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

Client ServerAnwendung

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

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

Segment xx

ACK für Segment yy

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

Segment xx

ACK für Segment yy

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

Segment xx

ACK für Segment yy

TCP: Duplicate Acks

● Beispiel Paketvertauschung

● unterschiedliche Dup-ACK-Muster

– Einzeln: Paketvertauschung

– Serie: wahrscheinlich einzelner Paketverlust

Sender Router Router Empfänger36 34

Segment xx

ACK für Segment yy

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)

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 ,…

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

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

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

● 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

● 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

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)

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

TCP: Flow Control – Congestion Window

0 1 2 3 4 5 6 7 8 9

Time / RTT

Slow Start

CongestionAvoidance

ssthresh

RWIN = 12

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

TCP: Flow Control – Slow Start nach Timeout

Time / RTT

cwnd (se

ssthresh = 8ssthresh = 10

cwnd = 20Timeout

cwnd = 1

TCP: Flow Control – Fast Recovery

Time / RTT

nach Fast Recovery

ssthresh = 4

≥3 Dupacks

cwnd = 8

cwnd = 4

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):

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)

Literatur

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

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

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: markus.brueckner@tu-ilmenau.de

www.tu-ilmenau.de/ics

Integrated Communication Systems GroupIlmenau University of Technology

Dipl.-Inf. Markus Brückner

mobilkommunikationsnetze - transmission control · pdf file- transmission control protocol -...

Documents

mobilkommunikationsnetze - ieee 802.11 · nach ieee...

msd atomic transmission control module stand … atomic...

stream control transmission protocol (sctp), a proposal...

transmission control protocol

atpc: adaptive transmission power control for...

infection control disease transmission([1]

operation of one speed control valve. transmission control...

stream control transmission protocol (sctp)

lab9 tcp (transmission control protocol)

transmission control protocol - tcp

improved transmission control protocol congestion control

performance enhancements of transmission control protocol...

transmission control protocol

electronic control transmission (ect ... - autoshop...

tcp (transmission control protocol)

mobilkommunikationsnetze - medienzugriff ·...

transmission control...

infrared remote control transmission

mobilkommunikationsnetze - lte & weiter? · pdf fileumts lte...

mobilkommunikationsnetze - gsm/umts -...– node b sendet...