Congestion Control For Coded TCP Doug Leith
Outline Why do error-correction coding at the transport layer? Congestion control on lossy paths Implementation & performance measurements
Why error-correction coding at the transport layer? Interference-related losses are challenging, yet increasingly common in dense 802.11 deployments Hidden terminals New dynamic devices e.g. channel bonding, will only make this worse Microwave interference in unlicensed band
Why error-correction coding at the transport layer? Why not enhance error-correction at the link layer? Link layer offers many advantages: Link layer has access to low-level information e.g. whether a packet loss is due to queue overflow or channel error. Usually quick feedback, so ARQ efficient Hop by hop encoding is generally more efficient than end-to-end encoding If link layer improvements are possible, make them! lossy link loss-free link
Why error-correction coding at the transport layer? Transport layer has some compelling practical advantages: No need for changes to installed network equipment. Recent estimate is 1.2 billion wireless devices shipped to date. What about servers, and especially user equipment? lossy link loss-free link
Why error-correction coding at the transport layer? Transport layer has some compelling practical advantages: No need for changes to installed network equipment client server No need for root-privilege changes to user equipment, just a user-space app No need for changes to installed servers ctcp proxy lossy link ctcp proxy
Why error-correction coding at the transport layer? Plus potential exists for considerable performance gains. 10 0 Efficiency 10 1 10 2 CTCP CTCP, 0.25 BDP Buffer Std TCP Std TCP Theory H TCP Cubic 10 3 10 2 10 1 Loss Probability Link 25Mbps, RTT 20ms
Congestion control on lossy paths Standard congestion control approach is window based using AIMD cwnd number of unacknowledged packets in flight cwnd cwnd + 1 every RTT without loss cwnd cwnd/2 on loss cwnd (packets) 300 250 200 150 100 50 0 throughput cwnd 0 0 20 40 60 80 100 time (s) Reno 10Mbps, 100ms RTT, buffer 1 BDP. 10 9 8 7 6 5 4 3 2 1 throughput (Mbps)
Congestion control on lossy paths Standard approach assumes loss = congestion On lossy path, backoff on loss means cwnd collapses to a low value Low throughput, many timeouts Efficiency 10 0 10 1 10 2 CTCP CTCP, 0.25 BDP Buffer Std TCP Std TCP Theory H TCP Cubic 10 3 10 2 10 1 Loss Probability Link 25Mbps, RTT 20ms
Congestion control on lossy paths Modify AIMD backoff on loss to cwnd cwnd RTT min RTT pkts W=BT+Q RTT = (BT+Q)/B = T+Q/B cwnd Q If queue empty, RTT = T, cwnd = BT Backoff cwnd to W T/(T+Q/B) = W BT/(BT+Q) queue occupancy time
Congestion control on lossy paths Modify AIMD backoff on loss to cwnd cwnd RTT min RTT Never ignores packet loss Reverts to standard TCP on links without noise losses On lossy links yields dramatic improvement in throughput by avoiding cwnd collapse. An important source of the x10-x20 thoughput gains observed. 120 100 80 cwnd (packets) 60 40 queue occupancy (packets) 20 0 0 5 10 15 20 25 30 35 40 45 50 time (s)
Congestion control on lossy paths A hybrid loss-delay approach, well established cf Compound TCP Builds on earlier work in H-TCP, well tested over a wide range of network conditions Known issues 1. Does not distinguish between: 1. A congested lossy link (where have packet losses and the RTT is much higher than the base propagation delay) 2. A non-congested lossy link where the base RTT fluctuates. How common are such links? Takes prudent approach and assumes (i) i.e. reduces send rate. Known issues 2. On paths with a standing queue, can be difficult to observe RTT min. How common are such links?
Link layer-agnostic measurements Testbed setup: ctcp proxy ctcp proxy Delay T Packet discard probability p Buffer, size Q packets Rate, B Mbps Server Dummynet Router Client
Link layer-agnostic measurements Efficiency 1 Theory 5M/10ms 0.98 10M/10ms 25M/10ms 0.96 5M/25ms 10M/25ms 0.94 25M/25ms 5M/50ms 0.92 10M/50ms 25M/50ms 5M/100ms 0.9 10M/100ms 25M/100ms 0.88 10 3 10 2 10 1 Loss Probability Link 25Mbps, RTT 20ms
Link layer-agnostic measurements 10 0 Efficiency 10 1 10 2 CTCP CTCP, 0.25 BDP Buffer Std TCP Std TCP Theory H TCP Cubic 10 3 10 2 10 1 Loss Probability Link 25Mbps, RTT 20ms
Link layer-agnostic measurements Friendliness - loss-free path Goodput (Mbps) 20 18 16 14 12 10 8 6 Std TCP (10Mbps link) Coded TCP (10Mbps link) Std TCP (25Mbps link) Coded TCP (25Mbps link) 4 2 0 10 25 50 100 RTT (ms) Standard TCP and a CTCP flow sharing a loss-free link
Friendliness - lossy path Link layer-agnostic measurements Goodput (Mbps) 10 1 10 0 10 1 Std TCP CTCP Std TCP vs Std TCP 10 2 Loss Probability Goodput (Mbps) 10 1 10 0 10 1 Std TCP CTCP Std TCP vs Std TCP 10 2 Loss Probability 10Mbps link, RTT=25ms 25Mbps link, RTT=25ms TCP and CTCP flow sharing link (solid lines), and (ii) two TCP flows sharing link (dashed line).
Link layer-agnostic measurements Application performance - HTTP 10 3 Completion Time (s) 10 2 10 1 10 0 10 1 10 2 25Mbps 0 0.001 0.01 0.05 0.1 0.2 10 1 10 2 10 3 10 4 10 5 10 6 File Size (KB) 25Mbps link, RTT 10ms Standard TCP (red) and CTCP (black)
Link layer-agnostic measurements Application performance - Video streaming 10 4 Completion time (s) 10 3 10 2 Std TCP CTCP 10 1 0 0.05 0.1 0.15 0.2 Loss Probability 25Mbps link, RTT 10ms, 60s video playout Standard TCP (red) and CTCP (black)
802.11 wireless measurements Testbed setup: Proprietary 802.11 featrures disabled 802.11 rate control manual Cubic as standard TCP. Sender Receiver Inteferer
802.11 wireless measurements
802.11 wireless measurements Microwave oven interference Mean Throughput (Mbps) 4 3 2 1 0 2 5.5 9 11 18 36 54 WiFi Tx Rate (Mbps) TCP CTCP
802.11 wireless measurements Hidden terminal setup: Modified 802.11 driver to disable carrier sense Poisson interference traffic Sender Receiver Hidden Terminal Inteferer
802.11 wireless measurements Throughput (Mbps) CTCP and TCP Throughput Hidden Terminal Poisson Distributed Traffic 5 TCP CTCP 4 3 2 1 0 0 0.2 0.4 0.6 0.8 Hidden Terminal Tx Rate (Mbps) Throughput vs intensity of hidden terminal interference when using standard TCP (Cubic TCP) and CTCP over an 802.11b/g wireless link.
802.11 hot spot measurements Various public WiFi networks in the greater Boston area Downloaded a 50 MB file from a server located on MIT campus to a laptop Default operating system (Ubuntu) settings are used for all network parameters on client and server.
802.11 hot spot measurements 2 Goodput (Mbits/sec) 1.5 1 0.5 0 0 500 1000 Time (sec) Standard TCP (red), CTCP (black)
Sheraton Hotel, Needham. No link loss Standard TCP, 5% loss Coded TCP, 5% loss 23rd May 2013, MAC OS X 10.7.4