1 / 12

Why is TCP not good enough for Mobile Operators?

Why is TCP not good enough for Mobile Operators?. Ulas C. Kozat kozat@docomolabs-usa.com. 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.

ferrol
Download Presentation

Why is TCP not good enough for Mobile Operators?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. 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.

  3. 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.

  4. 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 (Kbps) Time (slot number)

  5. 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.

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

  7. 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

  8. 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.

  9. Average rate (Kbps) MH2 MH1 Instantaneous rate (Kbps) MH3 MH2 MH3 MH1 Time (sec) Demo-1 Scenario • 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. S2 S1 50Mbps, 25ms 50Mbps, 25ms Wireless Channel Quality

  10. MH3 MH1 MH2 Demo-2 Scenario • 2 Downloads and 1 P2P streaming (600Kbps). • Wireless capacity is the bottleneck. • Each user sees symmetric channel rates. • We compare TCP vs. backlogged UDP. S1 Wireless Channel Quality 50Mbps, 25ms MH1 Averate rate (Kbps) MH2 MH3 Time (sec)

  11. 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.

  12. Acknowledgements • Sandeep Kanumuri@DoCoMo USA Labs • Reha Civanlar@DoCoMo USA Labs ANY QUESTIONS?

More Related