1 / 15

Upgrading Transport Protocols Using Mobile Code

Upgrading Transport Protocols Using Mobile Code. Andrew Whitaker and David Wetherall (University of Washington) Parveen Patel, Jay Lepreau, and Tim Stack (University of Utah) . Karn/Partridge algorithm (1988) Header Prediction (1990) RFC 1232 (1992) T/TCP (1995) TCP Vegas (1995)

zudora
Download Presentation

Upgrading Transport Protocols Using Mobile Code

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. Upgrading Transport Protocols Using Mobile Code Andrew Whitaker and David Wetherall (University of Washington) Parveen Patel, Jay Lepreau, and Tim Stack (University of Utah)

  2. Karn/Partridge algorithm (1988) Header Prediction (1990) RFC 1232 (1992) T/TCP (1995) TCP Vegas (1995) RAP (1996) TCP SACK (1996) FACK (1996) Fast recovery (1997) WTCP (1998) NewReno (1999) Congestion Manager (1999) TCP Connection Migration (2000) The eiffel algorithm (2000) TFRC (2000) D-SACK (2000) Limited Transmit (2001) ECN (2001) ECN nonce (2001) TCP Nice (2002) DCCP (2002) SCTP (2002) RR-TCP (2002) Appropriate Byte Counting (2002) TCP sender timeout randomization (2003) TCP is a Work-In-Progress: Problem: deployment is painfully slow (years or forever!)

  3. Why Does Deployment Take So Long? • Protocols must be standardized by the IETF • Necessary because the Internet lacks mechanisms to isolate the effects of bad protocols • Protocols must be enabled by default at both connection endpoints • 58% of nodes are SACK-enabled, but only 5% of connections use SACK (2000)

  4. Self-spreading Transport Protocols • Approach: use mobile code to achieve immediate deployment for transport protocols • Avoid standards processes • Avoid lowest-common-denominator default settings • But, do we sacrifice safety…?

  5. Safety in STP • Host Safety: • Securing local host resources • Fair resource allocation • Network Safety: • Preventing a buggy or malicious transport from consuming excessive bandwidth • Needed: • A definition of safe network behavior • An enforcement mechanism

  6. Previous Work • A definition of TCP-friendliness [SIGCOMM ’98] 1 Rate = --------------------------------------------------------------- R*√(2 * L/3) + (t_RTO*3* √(3*L/8)*L*(1+32+L2)) R = Round-trip time, L = Loss-rate • A partial enforcement mechanism: • ECN Nonce [ICNP ‘01] prevents a misbehaved TCP receiver from hiding losses. • Unmet challenges: • Detect losses when both sides are untrusted • Do it for generic protocols (not just TCP)

  7. Sender TCP-BAD <seq_no,packet> STP <nonce,seq_no,packet> Network Detecting Losses in STP

  8. Sender Receiver TCP-BAD ??? STP <nonce,seq_no,packet> <nonce,seq_no> Network Detecting Losses in STP

  9. Sender Receiver TCP-BAD ??? STP <nonce,seq_no,packet> <???,seq_no> Network Detecting Losses in STP

  10. Enforcing TCP-friendliness Drop rate = 1%

  11. TCP Performance Mbps

  12. Conclusions • Self-spreading Transport Protocols (STP) allows anyone to deploy a new transport protocol • Immediacyachieved by mobile code • Network safety achieved using a nonce mechanism • Future work: • Understanding the subtleties of the rate-limiter • Exploring a broader set of protocols • TCP migration • Streaming media • More info in SOSP 2003: http://www.cs.washingotn.edu/homes/andrew/pubs.html

  13. Receiver ???

  14. <nonce,seq_no,packet> Detecting Losses Sender TCP-BAD STP <nonce,seq_no> Network

  15. An Alternative: One-sided Extensions • We can gain immediacy by only updating one host • But, we often sacrifice robustness: • The extension may not work • Example: TCP Migrate requires cooperation from both ends • The extension might not work well • Lose the benefit of cooperation between both ends • Example: one-way delay estimation using rtt includes reverse-path noise • XXX of YYY extensions benefit from two-sided updates.

More Related