Upgrading Transport Protocols Using Mobile Code

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.