1 / 30

TCP Meets Mobile Code

The advent of untrusted mobile code introduces a new paradigm for upgrading transport protocols like TCP. Traditional methods of upgrading TCP have proven slow and cumbersome, requiring changes at both ends. This paper proposes XTCP, a mechanism allowing connection peers to upgrade independently using mobile code. By leveraging extensions such as TCP SACK and TCP Nice, XTCP improves the connection efficiency and performance while addressing safety and resource consumption concerns. We discuss implementation, simulation results, and potential deployment scenarios, illustrating how XTCP accelerates upgrades in a TCP-friendly manner.

komala
Télécharger la présentation

TCP Meets 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. TCP Meets Mobile Code Parveen Patel David Wetherall Jay Lepreau Andrew Whitaker (Univ. of Utah) (Univ. of Washington)

  2. The Key Idea • Transport protocols, such as TCP, need a better upgrade mechanism • Untrusted mobile code will work!

  3. TCP is a work-in-progress • A steady stream of TCP extensions and new transport protocols • TCP SACK (1996) • TCP Connection Migration (2000) • ECN and ECN nonce (2001) • TCP Nice (2002) • TFRC (2000) • DCCP (2002) • SCTP (2002) • …

  4. Upgrading TCP takes forever • Research and simulation • Prototype • Standards committee • Implementation in OS 1 • Implementation in OS 2 • … • Addition into standard build OS 1 • Addition into standard build OS 2 • … • Enable by default • Enable by default on peer

  5. Lousy fallback: one-ended change • Immediate deployment for self benefit • Does not always work • Can’t exchange new information • Does not work very well • Lose the benefit of cooperation between both ends

  6. Survey of transport extensions

  7. Our Solution: XTCP • Connection peers can upgrade each other with new transport protocols using mobile code • Deployment at one end is all we need !

  8. Upgrading with XTCP is faster • Research and simulation • Prototype • Standards committee • Implementation to the XTCP API • Implementation in OS 1 • Implementation in OS 2 • … • Addition into standard build OS 1 • Addition into standard build OS 2 • … • Enable by default • Enable by default on peer

  9. Client (Download TCP-HP) XTCP usage scenario #1 • A web server pushes a “high-performance” TCP to its clients the first time they connect Server

  10. Server Client (Download TCP-Migrate) XTCP usage scenario #2 • A mobile client pushes “TCP connection migration” [MobiCom ’00] to a server to allow itself to move

  11. Host B XTCP usage scenario #3 • A user installs “TCP nice” [OSDI ’02] to support background data transfer Host A (With TCP-Nice)

  12. Will it work ? • XTCP sounds similar to the challenging domain of active networking • Challenges can be met in this restricted domain

  13. XTCP Challenges • Host safety – must isolate and limit resource consumption • Network safety – should not compete unfairly or attack other nodes • Performance – should not undermine improvement due to extensions

  14. Download manager Compiler TCP-A TCP-B XTCP API XTCP SANDBOX XTCP Design APPLICATION 1 Sockets Layer XTCP Network Layer

  15. 1. Host safety • No shared state between extensions • Easy resource accounting • Easy termination • Memory safety: type-safety of Cyclone • CPU timer-based CPU protection

  16. 2. Network safety • Well-defined notion of network safety • TCP-friendliness [RFC 2914] • TCP response function is mathematically defined [SIGCOMM ’98] • Enforcement without trusting transports • Adapt ECN nonce mechanism is used for validation [ICNP ’01]

  17. send (seq_no) Datagram with nonce datagram with nonce Nonce Mechanism[unstrusted red,trusted greencomponents] sender receiver TCP-A TCP-A XTCP XTCP

  18. ack (seq_no, nonce) send_ack ack+nonce ack+nonce Nonce Mechanism sender receiver TCP-A TCP-A XTCP XTCP

  19. 3. Performance • Connections proceed without delays • Code is downloaded out-of-band • Benefits later connections • Efficient to share data between the C-based kernel and Cyclone code • No garbage collection • Lightweight runtime

  20. Status • Prototype in FreeBSD 4.7 • Modest memory and CPU cost • CPU cost is 80% more than base TCP on the sender side, without any optimizations. • Ported TCP Friendly UDP, TCP NewReno and TCP SACK to the XTCP API • User-level version in progress

  21. It works! UDP

  22. It works! TCP

  23. Open research issues • TCP rate policing function • Quickly detect unresponsive extensions • Admit all responsive extensions • XTCP API • Must be sufficient and portable

  24. Conclusions • Transport protocols need self upgrade mechanism • Mobile code works ! • Constrained domain and recent advances • Mathematical definition of TCP response function (1998) • Cyclone (2002)

  25. END OF TALK ….BACKUP/DETAIL SLIDES

  26. Policies • Applications can use socket options • Administrators can set policies • Policy daemons can collaborate

  27. Granularity of extensions • Transport protocols are written to the XTCP API • Complete transport protocols are transferred over the network • Retains the way protocols are written now • Maximum flexibility • Maximum simplicity • Code is not large: 85K compressed source

  28. Connection setup and code loading

  29. Network safety • TCP friendly network access API • xtcp_net_send (seq_no) • xtcp_net_resend (seq_no) • xtcp_net_ack (seq_no, nonce) • xtcp_net_acksum (seq_no, nonce_sum)

  30. A Fourth Challenge:Deployment of XTCP framework • Benefits self • Can only harm self • Deployment only needed at end points • TCP-friendliness is non-threatening

More Related