TRANSMISSION CONTROL PROTOCOL Jasleen Kaur Fall 2015 1 Impact - - PDF document

transmission control protocol
SMART_READER_LITE
LIVE PREVIEW

TRANSMISSION CONTROL PROTOCOL Jasleen Kaur Fall 2015 1 Impact - - PDF document

11/12/15 COMP 635: WIRELESS NETWORKS TRANSMISSION CONTROL PROTOCOL Jasleen Kaur Fall 2015 1 Impact of Wireless on Protocol Layers Application layer service location new/adaptive applications multimedia Transport layer


slide-1
SLIDE 1

11/12/15 ¡ 1 ¡

1 ¡

COMP 635: WIRELESS NETWORKS

TRANSMISSION CONTROL PROTOCOL

Jasleen Kaur Fall 2015

2 ¡

Impact of Wireless on Protocol Layers

Application layer Transport layer Network layer Data link layer Physical layer service location new/adaptive applications multimedia congestion/flow control quality of service addressing, routing device location hand-over authentication media access/control multiplexing encryption modulation interference attenuation frequency

slide-2
SLIDE 2

11/12/15 ¡ 2 ¡

3 ¡

Outline

q TCP Congestion Control Ø Issues in wireless networks q Link-layer approaches Ø Reliability through retransmissions q Splitting Ø Proxy-based solutions q Snooping Ø TCP-aware link layers q Making TCP smarter q TCP-unaware approaches

4 ¡

TCP Congestion Control

q Goal: Ø Maintain transfer rate at the maximum that all involved

resources can handle (max-min fairness)

q Approach: Ø Ramp up sending rate till congestion detected

§ Rapid ramp up initially (Slow-Start) § Cautious ramp-up subsequently (Congestion Avoidance)

Ø If congestion, reduce sending rate and resume ramp-up q Mechanisms: maintain congestion-window (Cwin) Ø Increasing Cwin:

§ Slow Start, Congestion Avoidance

Ø Decreasing Cwin:

§ Retransmission Timeouts, Fast Retransmit/Recovery

slide-3
SLIDE 3

11/12/15 ¡ 3 ¡

5 ¡

q Additive Increase: Ø Increment cwin by 1 MSS per RTT q Multiplicative Decrease: Ø Shrink cwin by at least 50% on packet

loss

Congestion Avoidance

Source ¡ Destination ¡ … ¡ 60 ¡ 20 ¡ 1.0 ¡ 2.0 ¡ 3.0 ¡ 4.0 ¡ 5.0 ¡ 6.0 ¡ 7.0 ¡ 8.0 ¡ 9.0 ¡ KB ¡ Time (seconds) ¡ 70 ¡ 30 ¡ 40 ¡ 50 ¡ 10 ¡ 10.0 ¡

6 ¡

q Goal: Ø Hastening up initial bandwidth discovery q For every new ACK received: Ø Increase exponentially (not linearly), when

cwin < “SSThresh”

§ Double the number of packets-in-transit every RTT

q After recovery from timeout:

SSThresh = cwin/2 cwin = 1

Slow Start Behavior

Source ¡ Destination ¡ … ¡

slide-4
SLIDE 4

11/12/15 ¡ 4 ¡

7 ¡

q Fast Retransmit: Ø Goal:

§ Triggering retransmissions sooner than timeouts

Ø Exploit:

§ Receivers send ACKs (when data received) even if they are duplicates

  • f earlier ACKs

Ø Heuristic:

§ Use receipt of 3 duplicate ACKs as indicator that next segment was lost

q Fast Recovery: Ø Decrease cwin to SSThresh after fast

retransmit

Fast Retransmit/Recovery (FR/R)

Packet 1 ¡ Packet 2 ¡ Packet 3 ¡ Packet 4 ¡ Packet 5 ¡ Packet 6 ¡ Retransmit ¡ packet 3 ¡ ACK 1 ¡ ACK 2 ¡ ACK 2 ¡ ACK 2 ¡ ACK 6 ¡ ACK 2 ¡ Sender ¡ Receiver ¡

8 ¡

q Why is increase “additive” and decrease “multiplicative”? Ø Willingness to reduce congestion window greater than

willingness to increase it

Ø Necessary condition for stability Ø Consequences of having too large a window are worse than

having too small a window

AIMD

slide-5
SLIDE 5

11/12/15 ¡ 5 ¡

9 ¡

Challenge in Wireless Networks

q TCP congestion-detection mechanisms assume: Ø A packet loss is indicative of network congestion Ø Hence, source needs to regulate flow by reducing Cwin q Assumption closely true for wired networks (BER ~10-6) q But with wireless, Ø Losses due to:

§ Errors (due to fading, fluctuations) § Mobility (user changes network)

Ø Need not reduce CW in response … Ø But, TCP is e2e à

à CANNOT see the network

§ Thus, TCP cannot classify the cause of loss à à CHALLENGE

Dilemma: End-to-end interpretation of link-local metric

10 ¡

The Problem

wireless physical link network transport application physical link network transport application physical link network transport application lossy TCP connection

Wireline ¡

slide-6
SLIDE 6

11/12/15 ¡ 6 ¡

11 ¡

Impact of Misclassification

0.0E+00 5.0E+05 1.0E+06 1.5E+06 2.0E+06 10 20 30 40 50 60

Time ¡(s) ¡ Sequence ¡number ¡(bytes) ¡

TCP ¡Reno ¡ (280 ¡Kbps) ¡ Best ¡possible ¡ ¡ TCP ¡with ¡no ¡errors ¡ (1.30 ¡Mbps) ¡

2 ¡MB ¡wide-­‑area ¡TCP ¡transfer ¡over ¡2 ¡Mbps ¡WaveLAN ¡

12 ¡

SPLIT CONNECTION APPROACHES

No Changes To Wired Internet

slide-7
SLIDE 7

11/12/15 ¡ 7 ¡

13 ¡

1 TCP = ½ TCP + ½ (TCP or XXX)

wireless physical link network transport application physical link network transport application physical link network transport application rxmt Per-TCP connection state TCP connection TCP connection

Base ¡ ¡ StaKon ¡ 14 ¡

Splitting Approaches

q Indirect TCP [Baker97] Ø Fixed host (FH) to base station (BS) uses TCP Ø BS to mobile host (MH) uses another TCP connection q Selective Repeat [Yavatkar94] Ø Over FH to BS: Use TCP Ø Over BS to MH: Use selective repeat on top of UDP q No congestion control over wireless [Haas97] Ø Also use less headers over wireless

§ Header compression

slide-8
SLIDE 8

11/12/15 ¡ 8 ¡

15 ¡

Indirect TCP (I-TCP)

q Splitting of the TCP connection (at, e.g., the foreign

agent) into 2 TCP connections

Ø Optimized TCP protocol for mobile hosts Ø No changes to the TCP protocol for wired-Internet hosts mobile host access point (foreign agent) „wired“ Internet “wireless” TCP standard TCP

16 ¡

I-TCP Socket and State Migration

mobile host access point2 Internet access point1 socket migration and state transfer

slide-9
SLIDE 9

11/12/15 ¡ 9 ¡

17 ¡

Advantages: Indirect TCP

q No changes to the fixed network necessary Ø No changes for the hosts (TCP protocol) necessary

§ Millions of computers use (variants of) this protocol

Ø All current optimizations to TCP still work q Wireless transmission errors contained Ø Do not propagate into wired network q Simple to control Ø Mobile TCP is used only for one hop (FA à

à MH)

q Very fast retransmission of packets is possible Ø The short delay on the mobile hop is known

18 ¡

Issues With Splitting

q E2E semantics totally broken Ø 2 separate connections Ø An ACK no longer means that receiver got packet

§ Foreign agents might crash

q BS maintains hard state for each connection Ø What if MH disconnected from BS? Ø Huge buffer requirements at BS Ø What if BS fails? Ø Handoff between BS requires state transfer Ø Higher latency possible (buffering, forwarding) q What if Data and ACK travel on different routes? Ø BS will not see the ACK at all – splitting not feasible