Router Assistance for Transport Protocols

1. Router Assistancefor Transport Protocols Lachlan Andrew

2. Talk outline • History and transport layer roles • Types of router assistance • Is it necessary? • Benefits • Fundamental limits • Is it possible? • Enforcement / trust • Hazards • Signalling

3. Transport protocols • Reliability, in-order delivery, flow control • Congestion control an emergency after-thought • Currently: Fairness, smooth starting • “Only in gateways…is there enough information to control sharing and fair allocation. Thus, we view the gateway ‘congestion detection’ algorithm as the next big step.” – VJ, 1988 • 20 years later, router/transport interaction still minimal “Router” assistance: IP-aware congestible device

4. FIFO/droptail WFQ/AQM ECN-like MaxNet-like XCP-like ATM-like / Policing No assistance Drops + exiting TCP Minimal explicit signals Precise signals router → source Bidirectional signalling Router takes over Types/degrees of router assistance • More than just “Router tells sources transmission rate” • Congestion charging • Route-around-congestion

5. Talk outline • History and transport layer roles • Types of router assistance • Is it necessary? • Benefits • Fundamental limits • Is it possible? • Hazards • Signalling

6. Is it necessary? • Motivation for Stanford’s “TCP train wreck” workshop • Many examples in wireless • Metrics • Throughput, fairness (accountability), slow-start time, loss, delay, stability • Will better fairness solve “net neutrality” issues? • How good can end-to-end be? • If people co-operate? If people are selfish? • Fundamental limits: Shannon, Bode

7. Wireless networks • WAN: errors → look like congestion • Universal ECN: Ignore drops? • Should lossy paths get lower rate? Router signal loss rates? • LAN: Retransmit → jitter → timeouts greater problem • Possible solution: • Aggressive Retransmission • Jitter buffer at wireless link • No TCP/IP changes needed • Is this “router assistance”? X X

8. Wireless multihop • Cause of congestion may not be affected • Beyond MAC: Must slow source down • Contagious congestion • Effect on transport?

9. Assistance for charging • Sending fast isn’t “misbehaving” – not paying for it is • Consumers want fixed price • Congestion control → sender rate = f(charge) • Will rich people starve average users? • Just normal market economy • Currently, anyone can starve average users • Caps reduce DoS? $$ X

10. Fundamental limits • Best end-to-end performance? • Shannon, Bode • Utilisation vs time to fairness? • Rapid start vs overshoot, jitter, loss • Are we far from limits? • Does router assistsurpass limits? rate time

11. Fundamental limit: Stability • Conjecture: For any TCP which reacts smoothly to queue size, there is a network for which it is unstable • “Unstable” = windows oscillate. Loss-based intrinsically unstable • Based on new modelof queue dynamics • Jacobsson et al. INFOCOM08 • Avoidable usingvirtual queues • Others limits?

12. Talk outline • History and transport layer roles • Types of router assistance • Is it necessary? • Benefits • Fundamental limits • Is it possible? • Enforcement / trust • Hazards • Signalling

13. “High RTT” Enforcement / trust • Tahoe+: senders lie → higher rate to one flow • ECN: receives lie → higher rate to one flow • XCP/RCP: senders lie → updating freezes for all flows • Charging: routers lie → ??? • Policing: identity splitting • Make better? Just not worse?

14. Hazards • Need long-term solution. IP changes rare • Hard-wire fairness / resource allocation • Inflexible assistance • Hard coded calculations in routers/protocol • Signal virtual queue better? • “Layer-2” devices • Smaller buffers, so congestion a greater problem • Very price sensitive • Often bottleneck links?

15. Oscillation/delay tradeoff? • Experiments with MaxNet • Network signals maximum virtual queue size on path • Rate a function of filtered value • Can prove “stability” – oscillations die down • Fast initial response → oscillations decrease slowly • Fundamental need to know others’ RTTs?

16. Incremental deployment • Clouds. Avoid “separate queues”

17. Incremental deployment • Tunnels • Uncongestable cores. Avoid speed issue?

18. p= min(congestion)(0,1) p2 p1 Side info (IPid?) Convincing hardware vendors • “Why don’t they just implement my scheme?” • We must agree on a common signal from routers • Keep researching how to make use of it (Risky?)

19. ADPM: Threshold from Packet Data • All routers hash packet data to a threshold in [0,1] • Each router, for each packet is current price ≥ arriving threshold? • Yes: mark packet No: leave it unchanged 1 $ > thresh 0

20. ADPM: Estimator at the receiver • True price Current estimate • Don’t explicitly quantise • k packets after price jump,mean error 1/k • Compare 1/ k for random marking • Effective resolution adapts frequencyof step changes in price unmarked unmarked marked marked

21. Convergence to a fixed price DPM Ryu

22. Tracking a Changing Price • Model: • Random walk: price up/down by  per packet arrival • Drift of  • Mean squared error is at most • Asymptotically,  

23. Conclusion • Many open issues • Look for fundamental limits of “assistance free” TCP • To move forward, need consensus on signalling • Algorithms can be tweaked later

24. Unused slides…

25. Thoughts • Larry’s “fundamental limitations” question • Benefits – avoid slow start, loss tolerance? • Necessary? Possible (layer-2 congestion, “separate queues”)? • Mechanisms – ADPM , PCN • universal WFQ?? Drop based on virtual queues? • Which routers? Dumb core protected by edge routers? • Implementation cost vs (e.g.) higher capacity • Roles other than rate control • pricing, application hints • Mobility • Multicast • Operator secrecy • Spoofing / security / DoS ?? • Heat, CO2 , and radioactive waste are becoming measurable by-products of TCP inefficiency – Tom Lyon, Nuova systems. • Implementation inefficiency should not out-weigh this benefit

26. Defining router assistance • Router=“(IP-aware) congestible device” • Routers providing services to higher layers other than forwarding packets on a fixed path • Congestion signalling • Policing • Pricing • DoS • Multicast • Mobility • Grab-bag of topics to promote discussion

27. Digression: What is transport layer? TCP

28. Example signalling mechanism • Stanford “TCP train wreck” workshop • Balaji Prabhakar: “TCP facelift” 1 bit signals back-off ratio • Here is my favourite 1-bit scheme

29. Problem formulation • Map price to a value in [0,1] • p is the maximum price along a flow’s path • Side information: • Packet data itself is known at all nodes • Thommes and Coates 04: “IPid”, 16 bit header field • Receiver estimates price from marks and side information • Give estimator, find the squared error distribution

30. What MSE is needed? • Dynamic range: 1kbps to 10Gbps • Resolution: 10% of rate • Uniform relative error: send log of rate • Acceptable mean error • Mean square error: ~10-5

31. Comparison: REM • Estimate probability of marking • Error: Variance of Binomial(k,p) random variable • Approximately Gaussian (pk, p(1-p)k) •  1/k

32. Comparison: DPM • Multi-threshold marking is the “unary equivalent” of Deterministic Packet Marking • Express price in unary (111…1100…00) • IP_ID field selects a bit. Mark packet if bit is 1 • Binary marking should be better • 2-k • Problem 1: Only probes one node per packet • Problem 2: Needs fixed quantiser resolution • Low-order bits not helpful if high-order bits not known

33. Distribution of error • Distribution of error ( ) • So • Estimator lags below the true price as both increase • Error x>0, despite negative price steps • Mean squared error is at most • “Quantiser resolution” adapts to rate of drift

34. ADPM using ECN • ECN uses two bits • 00 means “I don’t understand ECN” • 01 and 10 mean “I understand ECN. This packet is not marked” • 11 means “I understand ECN. Act like packet drop” • Proposed marking approach: • Source always sends 10 • Routers “mark” packets with 01 • Still use 11 to represent a drop • Conflict with experimental RFC against “cheating” • Also used by Bob Briscoe’s proposal unmarked ADPM marked ECN marked

35. 1 0 Tunnels p • Paths often use a “virtual hop” • Security (encrypted tunnel) • Features (IPv6 tunnelled over IPv4) • What happens to congestion marks within tunnel? • Hash of new packet may be different from original • Router uses different threshold from receiver ?