110 likes | 211 Vues
Explore the ineffability, immobility, invisibility, inevitability, intractability, improvability, and intractability of TCP, RM, and ALF in future transport protocols discussed by the ICNP '98 Future Transport Panel. Discover the challenges and potential for reliable multicast transports and TCP-friendly congestion control.
E N D
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 • What other transports must be everywhere? • Perhaps none - depending on your answer to whether UDP is a transport
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
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
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)
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
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
Inability to End This Joke? Some title words left (iniquities…) but... A NAAH
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.
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
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