why is tcp not good enough for mobile operators? ulas c. kozat [email protected]

12
Why is TCP not good enough for Mobile Operators? Ulas C. Kozat kozat@docomolabs- usa.com

Post on 20-Dec-2015

215 views

Category:

Documents


0 download

TRANSCRIPT

Why is TCP not good enough for Mobile Operators?

Ulas C. Kozat

[email protected]

Punch Lines

Cellular networks are carefully engineered:• Starvation observed in ad hoc/mesh deployments

or with 802.11 MAC are unlikely to occur in cellular.

• But, TCP can lead to substantially sub-optimal operating points for highly optimized/expensive cellular radio.

An operator like NTT DoCoMo do not use standard TCP.• Split with proxies, use a modified proprietary TCP

version.

Features of state-of-the-art Wireless Transmission

An explicit fairness consideration per user/connection. Constant-size radio link layer PDUs.

• E.g. 1024 bits in HDR, 320 bits in HSDPA. Time-slotted (1.67ms for HDR, 2ms for HSDPA). Separate (i.e., out-of-band) control channels. Fast rate adaptation per connection. Hybrid ARQ at PHY layer and aggressive re-transmission

at link layer. Less Radio Network delays (e.g., < 50 msec) Opportunistic scheduling across users for high capacity.

• Currently limited to downlink.

• In few years, it will be common for the uplink as well.

Multi-user Diversity and Proportional Fair Sharing (PFS)

Each user has a separate queue.

Users are sorted w.r.t.:

• Ci[n]: Achievable rate at slot n.

• Ti[n]: Weighted average throughput until slot n.

Rate

(K

bp

s)

Time (slot number)

i Ci[n]

Ti[n]

]1[]1[)1(][ nCnTnT iii

Simulated RLL, MAC layer & Scheduler RLL fragments/defragments IP packets

• PDU length = 1024 bits.• No concatenation, shorter fragments are padded.

Scheduler has perfect CSI information before each slot.• Slot length = 1.67ms.• No packet losses over the wireless channel.

Scheduler uses α=0.002 to compute weighted throughput.

Per user scheduling queue• Limited to 160 PDUs.

Simulated PHY Layer

*These modes are used for downlink only in 1x-EVDO, but I assume symmetric UL/DL

Channel Model ITU IMT-2000 channel models are used COST231-Walfish-Ikegami model

• Path Loss model takes into account• BS-MS separation distance, Carrier frequency, BS antenna height, Difference of

the BS height from the mean building height, Average separation between rows of buildings.

Shadow Fading model• Log-normal distribution (zero mean and Std.Dev=10 dB)

• Correlation with distance follows Gudmundson’s model Multipath Fading model

• Pedestian (3km/hr) model (4 tap channel model)

• Vehicular (100 km/hr) model (6 tap channel model)

• Doppler correlation follows Clark’s model

• Receiver is assumed to have 3 fingers tuned to the three strongest paths. Remaining paths only provide interference.

• Mobiles are assumed to detect signals at a maximum C/I of 13 dB due to hardware imperfections

TCP model

Ns-2 implementation is used:• set tcp [new Agent/TCP/Fack]

• set sink [new Agent/TCPSink/Sack1/DelAck]

Payload+TCP/IP header = 1024 bytes• Perfectly aligned with RLL PDU and slot

duration.

Demo-1 Scenario

50Mbps, 25ms

MH1

MH2

MH3

S1 S2 • 1 down-stream video (1.2Mbps) & 3 uploads in the same cell.• Wireless capacity is the bottleneck.• Each user sees symmetric channel rates.• We compare TCP vs. backlogged UDP.

Time (sec)

Ave

rag

e ra

te

(Kbp

s)

MH1

MH2

MH3

Inst

ant

ane

ous

rate

(K

bps)

50Mbps, 25ms Wireless Channel Quality

Demo-2 Scenario

MH1

MH3

S1

MH2

50Mbps, 25ms

• 2 Downloads and 1 P2P streaming (600Kbps).• Wireless capacity is the bottleneck.• Each user sees symmetric channel rates.• We compare TCP vs. backlogged UDP.

Time (sec)

Ave

rate

rat

e (K

bps)

MH1

MH2

MH3

Wireless Channel Quality

Summary of Problems

ACK traffic substantially interferes with the payload traffic.

Load asymmetries substantially impact the performance.

TCP fairness and scheduler fairness are not necessarily the same.

Large RTT misses transmission opportunities. Mobile P2P with TCP looks problematic.

• Unmatched channel states increases RTT.

Acknowledgements

Sandeep Kanumuri@DoCoMo USA Labs Reha Civanlar@DoCoMo USA Labs

ANY QUESTIONS?