1 15-441 computer networking lecture 18 – tcp over wireless

1

15-441 Computer Networking

Lecture 18 – TCP over Wireless

4-3-06 Lecture 18: Wireless TCP 2

Readings

• [R.2] Hari Balakrishnan, Srinivasan Seshan, and Randy H. Katz, "Improving Reliable Transport and Handoff Performance in Cellular Wireless Networks." ACM Wireless Networks, Volume 1, Number 4. December 1995. Pages 469-481.

• [R.3] Ajay Bakre and B. R. Badrinath, "I-TCP: Indirect TCP for Mobile Hosts," Proceedings of the 15th International Conference on Distributed Computing Systems (ICDCS '95), May 30 - June 2, 1995, Vancouver, British Columbia. Pages 136-143.

• [R.6] Analysis of TCP Performance over Mobile Ad Hoc Networks, G. Holland and N. Vaidya, Wireless Networks 8, 2002

http://doi.acm.org/10.1145/280000.276437

http://doi.acm.org/10.1145/280000.276437

http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=500012

http://doi.acm.org/10.1145/313451.313540


Optional Readings

• [R.1] Ramon Caceres and Liviu Iftode, "Improving the Performance of Reliable Transport Protocols in Mobile Computing Environments." IEEE JSAC, Volume 13, Number 5. June 1995.

• [R.4] H. Balakrishnan, Venkat Padmanabhan, Srinivasan Seshan, and Randy H. Katz, A Comparison of Mechanisms for Improving TCP Performance over Wireless Links, IEEE/ACM Transactions on Networking, December 1997.

• [R.5] David Eckhardt and Peter Steenkiste, "An Internet-style Approach to Wireless Link Errors", Journal of Wireless Communications and Mobile Computing, Wiley, special issue on "Reliably Transport Protocols for Mobile Computing", Volume 2, Number 1, February 2002.

• [R.7] ATP: A Reliable Transport Protocol for Ad-hoc Networks, Karthikeyan Sundaresan, Vaidyanathan Anantharaman, Hung-Yun Hsieh, Raghupathy Sivakumar, MobiHoc'03.

• [R.8] Hung-Yun Hsieh, Kyu-Han Kim, Yujie Zhu, and Raghupathy Sivakumar. A Receiver-Centric Transport Protocol for Mobile Hosts with Heterogeneous Wireless Interfaces. MobiCom 2003.



http://dx.doi.org/10.1109/90.650137

http://doi.acm.org/10.1145/778415.778424

http://doi.acm.org/10.1145/938985.938987

http://doi.acm.org/10.1145/938985.938987


TCP Problems Over Noisy Links

• First reported in [R.1]• Wireless links are inherently error-prone

• Fades, interference, attenuation• Errors often happen in bursts

• TCP cannot distinguish between corruption and congestion

• TCP unnecessarily reduces window, resulting in low throughput and high latency

• Burst losses often result in timeouts• Sender retransmission is the only option

• Inefficient use of bandwidth


Challenge #1: Wireless Bit-Errors

Router

Computer 2Computer 1

2322

Loss Congestion

21 0

Burst losses lead to coarse-grained timeoutsResult: Low throughput

Loss Congestion

Wireless

4-3-06 Lecture 18: Wireless TCP

Performance Degradation

0.0E+00

5.0E+05

1.0E+06

1.5E+06

2.0E+06

0 10 20 30 40 50 60

Time (s)

Seq

uenc

e nu

mbe

r (by

tes)

TCP Reno(280 Kbps)

Best possible TCP with no errors(1.30 Mbps)

2 MB wide-area TCP transfer over 2 Mbps Lucent WaveLAN


Constraints & Requirements

• Incremental deployment• Solution should not require modifications to

fixed hosts• If possible, avoid modifying mobile hosts

• Probably more data to mobile than from mobile

• Attempt to solve this first


Proposed Solutions

• End-to-end protocols• Selective ACKs, Explicit loss notification

• Split-connection protocols• Separate connections for wired path and

wireless hop• Reliable link-layer protocols

• Error-correcting codes• Local retransmission


Approach Styles (End-to-End)

• Improve TCP implementations• Not incrementally deployable• Improve loss recovery (SACK, NewReno)• Help it identify congestion (ELN [R.4], ECN)

• ACKs include flag indicating wireless loss• Trick TCP into doing right thing E.g. send extra

dupacks [R.1]Wired link Wireless link


End-to-End: Selective Acks

Correspondent Host

Mobile HostBase Station

5 134

6 X2


End-to-End: Selective Acks

Correspondent Host


ack 1 ack 1,3 ack 1,3-4 ack 1,3-5 ack 1,3-6


Approach Styles (Split Connection)

• Split connections [R.3]• Wireless connection need not be TCP• Hard state at base station

• Complicates mobility• Vulnerable to failures• Violates end-to-end semantics

Wired link Wireless link


Split Connection

Correspondent Host


2 AB3 X1

ack 0 ack 0

X

sack A sack A,B

C

sack A,B,D

D


Split-Connection Congestion Window

• Wired connection does not shrink congestion window • But wireless connection times out often, causing sender to stall

0

10000

20000

30000

40000

50000

60000

0 20 40 60 80 100 120Time (sec)

Con

gest

ion

Win

dow

(byt

es)

Wired connectionWireless connection


Approach Styles (Link Layer)

• More aggressive local rexmit than TCP• Bandwidth not wasted on wired links

• Adverse interactions with transport layer• Timer interactions• Interactions with fast retransmissions• Large end-to-end round-trip time variation

• FEC does not work well with burst lossesWired link Wireless link

ARQ/FEC


Hybrid Approach: Snoop Protocol

• Described in [R.2]• Transport-aware link protocol• Modify base station

• To cache un-acked TCP packets• … And perform local retransmissions

• Key ideas• No transport level code in base station• When node moves to different base station,

state eventually recreated there


Snoop Protocol: CH to MH

Correspondent Host


5 11234

6

• Snoop agent: active interposition agent• Snoops on TCP segments and ACKs• Detects losses by duplicate ACKs and timers• Suppresses duplicate ACKs from FH sender

Snoop Agent



Correspondent Host


• Transfer of file from CH to MH• Current window = 6 packets

Snoop Agent6 5 43 21



Correspondent Host


• Transfer begins

Snoop Agent6 54 3 2 1



Correspondent Host


5 11234

6

• Snoop agent caches segments that pass by• Difference #1 from pure link-layer – does not add

a new header uses existing TCP header to identify losses

Snoop Agent



Correspondent Host


51234

6

• Packet 1 is Lost

Snoop Agent23 1

Lost Packets1



Correspondent Host


5 12346

• Packet 1 is Lost• Duplicate ACKs generated

Snoop Agent

23

Lost Packets1

4

ack 0



Correspondent Host


5 12346

• Packet 1 is Lost• Duplicate ACKs generated

• Packet 1 retransmitted from cache at higher priority

Snoop Agent

23

Lost Packets1

4

ack 0

56 1

ack 0



Correspondent Host


5 12346

• Duplicate ACKs suppressed• Difference #2 from pure link-layer – tries to

prevent sender from noticing loss• Sender may still timeout though – fortunately timeouts

are typically long (500ms+)

Snoop Agent

234

ack 4

561

ack 0X



Correspondent Host


56

• Clean cache on new ACK

Snoop Agent

234

ack 5

615

ack 4



Correspondent Host


6

• Clean cache on new ACK

Snoop Agent

234

ack 6

156

ack 5

ack 4



Correspondent Host


• Active soft state agent at base station • Transport-aware reliable link protocol • Preserves end-to-end semantics

Snoop Agent

234

ack 6

156978

ack 5


Other Issues

• What about mobility?• What about mobile-to-fixed communication?


Handling Mobility

Correspondent Host

Base Station

Mobile Host

Base Station

Router5 4

3

2 121

1

Send packets to multiple base stations


Handling Mobility

Correspondent Host

Base Station

Mobile Host

Base Station

Router6 5

4

3 132

1

1 2

Resend missed packets from Snoop cache on handoff


Snoop Protocol: MH to CH

Mobile Host Correspondent HostBase Station

02

• Caching and retransmission will not work• Losses occur before packet reaches BS• Congestion losses should not be hidden

• Solution: Explicit Loss Notifications (ELN)• In-band message to TCP sender

1

564 3



Mobile Host Base Station

50

6

• MH begins transfer to CH

4321

Correspondent Host




502

6

• Packet 1 lost on wireless link

14 3

Correspondent Host



Mobile Host ReceiverBase Station

5 02

6

• Add 1 to list of holes after checking for congestion

4 3

Lost Packets1

1

ack 0




502

6

• Duplicate ACKs sent

43

Lost Packets1

1

ack 0ack 0 Correspondent Host




5 02

6

• ELN information added to duplicate ACKs

4 3

Lost Packets1

1

ack 0 ack 0 ELN

ack 0 Correspondent Host




5 026

• ELN information on duplicate ACKs• Retransmit on Packet 1 on dup ACK + ELN • No congestion control now

4 3

Lost Packets1

1

1

ack 0 ELN

ack 0 ELN

ack 0 Correspondent Host



Mobile Host ReceiverBase Station

5 026

• Clean holes on new ACK• Link-aware transport decouples congestion control from loss

recovery• Technique generalizes nicely to wireless transit links

4 3

ack 6

1


Discussion

• Why does Snoop perform well?• Hides out-of-order delivery from sender

• Current reliable MACs do single packet at a time reliability no out-of-order delivery [R.5]


• [R.6] Analysis of TCP Performance over Mobile Ad Hoc Networks, G. Holland and N. Vaidya, Wireless Networks 8, 2002

http://doi.acm.org/10.1145/313451.313540

http://doi.acm.org/10.1145/313451.313540


TCP ELFN (Explicit Link Failure Notification )

• Analysis of TCP performance in static, linear, multi hop wireless network

• Analysis of TCP in MANETs using expected throughput and measured throughput

• Suggestion of TCP ELFN• Simulation results


TCP performance in simple, static, linear multi-hop network

• A simple multi-hop network

• TCP-Reno throughput over an 802.11 fixed, linear, multi-hop network of varying length


Performance metric

• Performance metric• Expected throughput =

Σi=0∞

Σi=0∞

t i

t i * Ti

i: # of hops

ti: the duration for which the shortest path contains i hops

Ti: the throughput obtained “over a linear chain” using i hops

• Expected throughput does not take into account the performance overhead of determining new routes after route failures

• It serves as a upper bound of throughput in mobile network


Performance metric :Expected throughput

• Example

S R

Δt=to Δt=t1 Δt=t2

Throughput = TH1 Throughput = TH3 Throughput = TH1

Expected throughput = to + t1 + t2

t 0*TH1 + t1*TH2 + t2*TH1

S R S R

Throughput in linear network when # hops is n


Expected throughput and Measured Throughput

• Simulation environment

• ns network simulator• TCP-Reno over 802.11• DSR, BSD’s ARP• 30 nodes, 1500X300 m2 ,

the random waypoint• The average throughput

of 50 scenarios

From 2m/s to 10m/s the throughput drops sharply


Measured and expected throughput


Zero Throughput

• T = 0s, route fail, packet dropped

S A B C R

• T = 6s, data packet retransmitted

S A B C R

• T = 6.1xxs, ACK dropped, due to stale cached route

S A B C R

• T = 18.1xxs, the second retransmission of data packet, dropped again due to stale cached route

S A B C R• T=42,90,120s no ACK from the TCP receiver


Some facts

• In previous example, only for 6 s of 120 s the network is partitioned

• DSR’s stale cached route can degrade TCP throughput significantly

• DSR does not retransmit dropped packet when it receives Route Error Msg, and the TCP sender or receiver does not know about the packet loss

• The TCP sender waits for occurring time out• Unnecessary RTO back-off of the TCP sender makes

problems even worse


TCP ELFN

• Explicit Link Failure Notification (ELFN)• The objective :

• To provide the TCP sender with information about link and route failures

• TCP sender can avoid responding to the failures as if congestion occurred

• DSR’s route failure message is modified• A payload similar to the “host unreachable” ICMP

message• The sender and receiver’s addresses and ports and

seq number

S A B C D R

TCP data

DSR ROUTE ERROR + ELFN

Probing message


TCP ELFN

• Sender reaction• When a TCP sender receives an ELFN,

• It disables its retransmission timers and enters a “stanby” mode

• While on standby,• A packet is sent at periodic intervals to probe the

network to see if a route has been established• If an acknowledgment is received,

• Then it leaves standby mode


Simulation for the 50 different Mobility patterns(2m/s, 10m/s, 20m/s, 30m/s)


Simulation for the different probing intervals and different window and RTO modification

• Different probing interval• If the interval is too large, it delays the discovery of new routes• If the interval is too small, the rapid injection of probes into the

network will cause congestion and lower throughput


• [R.7] ATP: A Reliable Transport Protocol for Ad-hoc Networks, Karthikeyan Sundaresan, Vaidyanathan Anantharaman, Hung-Yun Hsieh, Raghupathy Sivakumar, MobiHoc'03.

http://doi.acm.org/10.1145/778415.778424

http://doi.acm.org/10.1145/778415.778424


Time spent in Slow-Start phase

Average time in Slow-Start phase.Total simulation time: 100sTCP New Reno

1. The time spent in Slow-Start increases with the increasing of the mobility.

2. The proportion of time goes above 50% for the higher load situation.

3. The connections spend a large portion of the lifetime probing for the available bandwidth.

50%


Key design elements of ATP

• Cross layer coordination

• Rate based transmissions• This is the core of ATP

• Decoupled congestion control and reliability


Layer Coordination

Similar to TCP-ELFN • Utilize explicit feedback from intermediate

nodes.

• ATP uses layer coordination for • Path failure notification• Initiating a sending-rate estimation for the

new route


Rate based transmissions

• What is rate based transmission• Transmit fixed size of data in each time interval.

• GSM example, 260bits from speech codec in every 20ms• Use timer to clock the new data, not the sending window

• Avoids drawbacks due to burstiness

• The need for self-clocking by the arrival of ACKs is eliminated

• Allows decoupling of congestion control mechanism from the reliability mechanism

• Timer granularity in low bandwidth MANETS large enough to be realized without significant overheads


Decoupling of Congestion Control & Reliability

• For congestion control:• Intermediate nodes provide the feedback of

available rate.• The feedback is piggybacked on forward path and

sent back from receiver to sender.• The sender adjusts the sending rate accordingly.

• For reliability:• The receiver uses SACK to report any new holes

in the data stream.


• [R.8] Hung-Yun Hsieh, Kyu-Han Kim, Yujie Zhu, and Raghupathy Sivakumar. A Receiver-Centric Transport Protocol for Mobile Hosts with Heterogeneous Wireless Interfaces. MobiCom 2003.

http://doi.acm.org/10.1145/938985.938987

http://doi.acm.org/10.1145/938985.938987

http://doi.acm.org/10.1145/938985.938987


Core Thesis Behind Proposal

• The wireless last link is crucial• Receiver has accurate knowledge of

channel conditions• Receiver has knowledge of all its interfaces• Receiver can handle functionality without

making changes at the sender


Loss recovery

• React to non-congestion related losses

• Sender-centric approach• Sender needs feedback from receiver• Difficult to provide all types of feedback

• Receiver-centric approach• Avoids feedback overheads and latency


Congestion Control

• Discover the point of threshold of packet loss

• Sender-centric• Server might need several congestion control schemes for the

different types of connections

• Receiver-centric• Receiver responsible for congestions control• Each receiver can implement its own congestion control


RCP Protocol Overview

• Data Transfer:• REQ-DATA instead of

DATA-ACK• REQ in 2 modes

• Cumulative (new data)• Pull (retransmission)

REQ

DATA

Sender Receiver

3 out-of-order DATA segments->

Fast Retransmit

In CUM or PULL mode


RCP Protocol Overview

• Congestion Window maintained at Receiver• Receiver can react to packet loss based on

its knowledge of channel conditions

Window moves forward on DATA

receipt

1 15-441 computer networking lecture 18 – tcp over wireless

Documents