1 / 11

TCP, ALF and RM Futures

TCP, ALF and RM Futures. Positions for the ICNP 98 Future Transport Panel Allison Mankin mankin@east.isi.edu http://www.east.isi.edu/RMRG. Ineffability of TCP. The Internet had to have byte-stream service: imagine building any large net without assured file transfers

jeanette-brown
Télécharger la présentation

TCP, ALF and RM Futures

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, ALF and RM Futures Positions for the ICNP 98 Future Transport Panel Allison Mankin mankin@east.isi.edu http://www.east.isi.edu/RMRG

  2. Ineffability of TCP • The Internet had to have byte-stream service: imagine building any large net without assured file transfers • What other transports must be everywhere? • Perhaps none - depending on your answer to whether UDP is a transport

  3. Immobility of TCP • Improving TCP is frequently envisioned, but may now be too hard to effect • TCP Large Windows case - it’s out there, but offered window field adaptation piece never happened - need for it was seen when Internet had just grown to 100,000 hosts • Contrast RTP deployment. With hooks for Application Layer Framing, protocol fits many niches, and published transports using RTP alone number 10’s per year

  4. Invisibility of ALF Transports • Many new transports on the net are application-framed (ALF). Specs may not be public. Example: Real Network tm RTP/RTCP UDP or TCP IP or IP Multicast

  5. Inevitability of Reliable Multicast Transports • RM, such as: SRM (shared interactive Pressure to have them, especially for software update distribution (latest pull seen in Gates’ Sep 98 MegaServer memo) • Megaserver is described as using a bulk transfer RM; many other types of multicast, such as SRM (shared interactive media), MTP II (image-oriented) • Multicast transports do not yet have congestion control (but they should, see also RFC 2357)

  6. Intractability of Reliable Multicast Transports • Despite demand, none yet deployed on general Internet • Hold-ups from congestion problems (that break the product performance), reported even on the dedicated nets • Intractable too strong - simple congestion control for bulk transfer RM is on track in a design team of the RM Research Group

  7. Improvability of Reliable Multicast Transports • End2End Research Group: “It’s not an Internet transport protocol if it does not adapt to congestion” • Reliable Multicast Research Group: designing simplest possible RMCC • Enabled by progress on the “TCP-friendly” equations

  8. Inability to End This Joke? Some title words left (iniquities…) but... A NAAH

  9. Multicast Congestion Control Research Has Been Delayed, Besides Being Hard B A [R]M flow TCP flow A fallacy: Congestion on the way to B has been “paid for” because one flow went to A’s three children instead of 3.

  10. Aspects of TCP-Friendly CC [R]M flow TCP flow TCP sees RM adapting to its different bottlenecks. Potential oscillations. What share for TCP versus what share for a multicast flow is orthogonal to stabilizing both their CC behaviors

  11. Three Positions Taken • TCP will remain pretty much as is • ALF transports will continue filling niches. Traffic researchers need to be observing them • TCP-Friendly congestion control will dominate the largest, toughest class of Future Transports, the RM’s

More Related