350 likes | 541 Views
Router Assistance for Transport Protocols. Lachlan Andrew. Talk outline. History and transport layer roles Types of router assistance Is it necessary? Benefits Fundamental limits Is it possible? Enforcement / trust Hazards Signalling. Transport protocols.
E N D
Router Assistancefor Transport Protocols Lachlan Andrew
Talk outline • History and transport layer roles • Types of router assistance • Is it necessary? • Benefits • Fundamental limits • Is it possible? • Enforcement / trust • Hazards • Signalling
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
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
Talk outline • History and transport layer roles • Types of router assistance • Is it necessary? • Benefits • Fundamental limits • Is it possible? • Hazards • Signalling
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
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
Wireless multihop • Cause of congestion may not be affected • Beyond MAC: Must slow source down • Contagious congestion • Effect on transport?
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
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
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?
Talk outline • History and transport layer roles • Types of router assistance • Is it necessary? • Benefits • Fundamental limits • Is it possible? • Enforcement / trust • Hazards • Signalling
“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?
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?
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?
Incremental deployment • Clouds. Avoid “separate queues”
Incremental deployment • Tunnels • Uncongestable cores. Avoid speed issue?
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?)
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
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
Convergence to a fixed price DPM Ryu
Tracking a Changing Price • Model: • Random walk: price up/down by per packet arrival • Drift of • Mean squared error is at most • Asymptotically,
Conclusion • Many open issues • Look for fundamental limits of “assistance free” TCP • To move forward, need consensus on signalling • Algorithms can be tweaked later
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
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
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
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
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
Comparison: REM • Estimate probability of marking • Error: Variance of Binomial(k,p) random variable • Approximately Gaussian (pk, p(1-p)k) • 1/k
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
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
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
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 ?