Wireless & Mobile Networking CS 752/852 - Spring 2011 Tamer Nadeem Dept. of Computer Science Wireless TCP.

Wireless & Mobile Networking

CS 752/852 - Spring 2011

Tamer NadeemDept. of Computer Science

Wireless TCP

Spring 2011 CS 752/852 - Wireless and Mobile Networking

The OSI Communication Model

Recall 1: PHY and MAC

MAC MAC

PHY PHY

• Spread Spectrum radios (DS and FH)• RTS/CTS and Carrier Sensing for Hidden Terminals• Directional antennas to reduce interference• Rate control to extract max capacity from available SINR• Power control for spatial reuse & energy savings – topology control• TDMA scheduling, multi-channel use, encryption security

… and many more

Recall 2: Network Layer

Routing

• The first view of the network

• Coping up with (uncontrolled) user mobility-Flooding the network reactively, or proactive updation

• Mobile IP, coping with handoffs, etc.

• Ad hoc routing – discovery, optimal metric, maintenance, caching• Secure routing – Routes bypassing malicious nodes

Routing

Role of Transport Layer

• Transport packets quickly and reliably over this network

• Network properties often unknown (or difficult to track)- Where is the congestion ? How much cross traffic ?- What is the bottleneck bandwidth ?- How much buffers at intermediate nodes ?

Motivation for end to end TCP

NETWORK

Some transmission methods

• Stop & Wait

• Pipelined• Go Back N

• Selective Repeat

Stop-and-wait operation

first packet bit transmitted, t = 0

sender receiver

last packet bit transmitted, t = L / R

first packet bit arriveslast packet bit arrives, send ACK

ACK arrives, send next packet, t = RTT + L / R

U sender = .008

30.008 = 0.00027

microseconds

L / R RTT + L / R

Pipelined protocols

Pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged pkts

• range of sequence numbers must be increased

• buffering at sender and/or receiver

• Two generic forms of pipelined protocols: go-Back-N, selective repeat

Pipelining: increased utilization

first packet bit transmitted, t = 0

sender receiver

last bit transmitted, t = L / R

first packet bit arriveslast packet bit arrives, send ACK

ACK arrives, send next packet, t = RTT + L / R

last bit of 2nd packet arrives, send ACKlast bit of 3rd packet arrives, send ACK

U sender = .024

30.008 = 0.0008

microseconds

3 * L / R RTT + L / R

Increase utilizationby a factor of 3!

Go-Back-N

Sender:• k-bit seq # in pkt header• “window” of up to N, consecutive unack’ed pkts allowed

ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” may receive duplicate ACKs

timer for each in-flight pkt timeout(n): retransmit pkt n and all higher seq # pkts in window

GBN inaction

Selective Repeat

• receiver individually acknowledges all correctly received pkts

• buffers pkts, as needed, for eventual in-order delivery to upper layer

• sender only resends pkts for which ACK not received• sender timer for each unACKed pkt

• sender window• N consecutive seq #’s

• again limits seq #s of sent, unACKed pkts

Selective repeat: sender, receiver windows

Selective repeat

data from above :• if next available seq # in window, send

timeout(n):• resend pkt n, restart timer

ACK(n) in [sendbase,sendbase+N]:

• mark pkt n as received

• if n smallest unACKed pkt, advance window base to next unACKed seq #

sender

pkt n in [rcvbase, rcvbase+N-1]

send ACK(n) out-of-order: buffer in-order: deliver (also deliver

buffered, in-order pkts), advance window to next not-yet-received pkt

pkt n in [rcvbase-N,rcvbase-1]

ACK(n)otherwise: ignore

receiver

Selective repeat in action

TCP Congestion Control

• Problem Definition• How much data should I pump into the network to ensure

• Intermediate router queues not filling up

• Fairness achieved among multiple TCP flows

• Why is this problem difficult?• TCP cannot have information about the network

• Only TCP receiver can give some feedbacks

The Control Problem

• Two main components in TCP• Flow Control and Congestion Control

• Flow Control• If receiver’s bucket filling up, pour less water

• Congestion Control• Don’t pour too much if there are leaks in intermediate pipes

• Regulate your flow based on how much is leaking out• Aggressive pouring calls for retransmission of lost packets

• Conservative pouring lower e2e capacity

• Challenge: At what rate(t) should you pour ?

The TCP Protocol (in a nutshell)

• T transmits few packets, waits for ACK• Called slow start

• R acknowledges all packet till seq #i by ACK i (optimizations possible)• ACK sent out only on receiving a packet

• Can be Duplicate ACK if expected packet not received

• ACK reaches T indicator of more capacity• T transmits larger burst of packets (self clocking) … so on

• Burst size increased until packet drops (i.e., DupACK)

• When T gets DupACK or waits for longer than RTO• Assumes congestion reduces burst size (congestion window)

TCP Timeline

Host A

one segment

Host B

two segments

four segments

Think of a blindperson trying tostand up in a lowceiling room

Objective:Don’t bang yourhead, but standup quickly

When waited for > RTO

Time (round trips)

ssthresh = 8 ssthresh = 10

cwnd = 20

After RTO timeout

The TCP Protocol (in a nutshell)

• DupACK not necessarily indicator of congestion• Can happen due to out of order (OOO) delivery of packets

• If 3 OOO pkts, then CW need not be cut drastically• The DupACK packet retransmitted

• Continue with same pace of transmission as before

(fast recovery)

• R advertizes its receiver window in ACKs• If filling up, T reduces congestion window

Fast Recovery on 3 OOO DupACKs

Time (round trips)

Receiver’s advertized window

After fast recovery

TCP Round Trip Time and Timeout

EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT

Exponential weighted moving average influence of past sample decreases exponentially fast typical value: = 0.125

Example RTT estimation:RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106time (seconnds)

SampleRTT Estimated RTT

TCP Round Trip Time and Timeout

Setting the timeout

• EstimtedRTT plus “safety margin”• large variation in EstimatedRTT -> larger safety margin

• first estimate of how much SampleRTT deviates from EstimatedRTT:

TimeoutInterval = EstimatedRTT + 4*DevRTT

DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT|

(typically, = 0.25)

Then set timeout interval:

Several flavors of TCP: combines options / optimizations

Reno, Vegas, Eifel, Westwood …

Overall TCP has worked well – proven on the internet

Then why study it again

for wireless networks ?

Renewed Challenge

• Key assumption in TCP• A packet loss is indicative of network congestion

• Source needs to regulate flow by reducing CW

• Assumption closely true for wired networks• BER ~ 10 -6

• With wireless, errors due to fading, fluctuations• Need not reduce CW in response …

• But, TCP is e2e CANNOT see the network

• Thus, TCP cannot classify the cause of loss CHALLENGE

The Problem Model

wireless

physical

network

transport

application

physical

network

transport

application

physical

network

transport

application

TCP connection

Wireline

Impact of Misclassification

0.0E+00

5.0E+05

1.0E+06

1.5E+06

2.0E+06

0 10 20 30 40 50 60

Time (s)

TCP Reno(280 Kbps)

Best possible TCP with no errors(1.30 Mbps)

2 MB wide-area TCP transfer over 2 Mbps WaveLAN

The Solution Space

• Much research on TCP over wireless

• Difficult to cover complete ground

• We peek into some of the key ideas• Link layer mechanisms

• Split connection approach

• TCP-Aware link layer

• TCP-Unaware approximation of TCP-aware link layer

• Explicit notification

• Receiver-based discrimination

• Sender-based discrimination

Link Layer Mechanisms

• Forward error corrections• Add redundancy in the packets to correct bit-errors

• TCP retransmissions can be alleviated

• Link layer retransmissions • MAC layer ACKnowledgments

• Overhead only when errors occur (unlike FEC)

Such mechanisms require no change in TCP

Is that breaking e2e argument ??

Issues with Link Layer Mechanisms

• Link layer cannot guarantee reliability• Have to drop packets after some finite limit

• What is the retransmission limit (??)

• Retransmission can take quite long• Can be significant fraction of RTT

• TCP can timeout and retransmit the same packet again

• Increasing RTO can avoid this

• But that impacts TCP’s recovery from congestion

• Head of the line blocking• Link layer has to keep retransmitting even if bad channel

• Blocks other streams

Findings

• Link layer retransmission good• When channel errors infrequent

• When retransmit time << RTO

• When modifying TCP is not an acceptable solution

Split Connection Approach

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

wireless

physical

network

transport

application

physical

network

transport

application

physical

network

transport

application rxmt

Per-TCP connection state

TCP connection TCP connection

Base Station

Splitting Approaches

• Indirect TCP [Baker97]• Fixed host (FH) to base station (BS) uses TCP

• BS to mobile host (MH) uses another TCP connection

• Selective Repeat [Yavatkar94]• Over FH to BS: Use TCP

• Over BS to MH: Use selective repeat on top of UDP

• No congestion control over wireless [Haas97]• Also use less headers over wireless

• Header compression

Issues with Splitting

• E2E totally broken• 2 separate connections

• 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

• What if Data and ACK travel on different routes ?• BS will not see the ACK at all – splitting not feasible

TCP-Aware Link Layer

• Link layer at BS buffers un-acknowledged packets

• Now, BS peeks into every returning TCP ACK from MH• If DupACK

• Retransmits the necessary packet

• Drops the DupACK

• DupACK does not reach sender• Prevents fast retransmit

Snoop : Example

FH MHBS40 39 3738

Example assumes delayed ack - every other packet ack’d

363738

35 TCP statemaintained at

link layer

Snoop : Example

41 40 3839

363738

Snoop : Example

42 41 3940

Duplicate acks are not delayed

dupack

373839

Snoop : Example

363636

Duplicate acks

4143 42

373839

Snoop : Example

FH MHBS41

3744 43

373839

404142

Discarddupack

Dupack triggers retransmissionof packet 37 from base station

BS needs to be TCP-aware to

be able to interpret TCP headers

Snoop : Example

4245 44

373839

404142

Snoop : Example

4346 45

373839

404142

TCP sender does notfast retransmit

Snoop : Example

4447 46

373839

404142

TCP sender does notfast retransmit

Snoop : Example

FH MHBS44

4548 47

Snoop [Balakrishnan95acm]

0400000800000

120000016000002000000

no error

1/error rate (in bytes)

/sec base TCP

2 Mbps Wireless link

Issues with Snoop

• Link layer needs to be TCP aware• Smelling cross layer

• Link layer needs to buffer and perform sliding window

• Not useful when TCP headers encrypted

• Not feasible when Data and ACK travel different routes

• RTT estimates can still go up due to link layer retransmission• Affects performance of Snoop

Wireless TCP

• WTCP attempts to nullify RTT estimation problem• When data packets are lost due to errors

• Link layer includes own time stamp in ACK packet• ACK packets that have BS time stamps indicate a wireless loss

• RTT of these packets not considered for RTO calculation

• But then, what if wireless hop is also congested !!!!!!

• Time stamping cannot take care of that

Quick look at other schemes

TCP-unaware schemes

Explicit notification

Receiver-based

TCP-Unaware, ELN

• Delayed DupACKs• Receiver waits for sometime before sending DupACK

• If link retransmission solves problem

• Then TCP sender does not send redundant packet

• Explicit Loss Notification (ELN)• BS remembers only packet’s sequence numbers

• When DupACKs return through them, they check

• If packet was received by BS, then colors the DupACK

• Sender realizes that packet lost on wireless link

• Does not cut down CW, just retransmits that packet

Closing Thoughts

• Reliable and in-order packet delivery important• TCP aims to support these features

• Implements congestion control and flow control

• TCP widely tuned for wireline networks• Proven to be efficient on the internet

• When network periphery has wireless “last mile”• TCP exhibits myriad problems

• Mainly because of

“misclassification between congestion and channel errors”

• Several solution approaches but many open problems

What’s Hot Now ??

• TCP over wireless multihop (mesh)• Each hop has contention-based MAC

• Unpredictable delays and congestion

• Fairness between TCP e2e flows a very challenging problem

• Mobility can significantly affect TCP

(Very difficult set of open problems)

• More fundamental: Is TCP the way to go for wireless• Strong ongoing debate in community

• Useful queuing solutions in ad hoc networks• Neighborhood RED solution

… and many many more …

Questions ?

Wireless & Mobile Networking CS 752/852 - Spring 2011 Tamer Nadeem Dept. of Computer Science Wireless TCP.

Documents

In-Pavement Wireless Sensor Network for Vehicle...

Nadeem Ali

Probabilistic Coverage in Wireless Sensor Networks Authors :...

Acoustic Manipulation Tamer Elnady tamer@svlab-asu.com.

2/12/20021 IEEE 802.11 Wireless Local Area Networks The...

ATP: Autonomous Transport...

Recurso TAMER

Nadeem k.k.

Lec #7: Audio, Video & Telephony - Old Dominion...

NADEEM SHRAVAN

The Giza Pyramids: A History of Wireless Electricity ... The...

Advanced Data Structures and...

NADEEM AMJAD,

Mobility Control for Throughput Maximization in Ad Hoc...

Nadeem S.f

App Development for Smart Devices - Old Dominion...