Reliable Multicast Transport BOF, Monday March 15, Minneapolis IETF.
Notetaker: Sally Floyd
Intro: Vern Paxson
The goal of this meeting is not to standardize reliable multicast in this meeting, but to discuss strategies for standardizing reliable multicast.
The Area Directors are very much in favor of setting up one Working Group for this.
This BOF will explore two fundamental strategies for standardizing reliable multicast: One approach, the building-block approach, is to standardize modules or building blocks. The other approach, the whole-protocol approach, is to standardize whole protocols. The other issue for this BOF to explore is what a charter for an RMT working group would look like.
Agenda-bashing:
Standardizing Reliable Multicast: Mark Handley
Viewgraphs:
http://www.aciri.org/mjh/rmbof.ps
http://www.aciri.org/mjh/rmbof.mgp (Magicpoint source files)
The Building Block Approach to RM Standardization: Mark Handley
Viewgraphs:
http://www.aciri.org/mjh/bb.ps
http://www.aciri.org/mjh/bb.mgp (Magicpoint source files)
Discussion:
How is FEC with the layered approach different from FEC with the other three approaches (tree/ack-based, nack-based, nack-based with network support).
Past history in the IETF of standardizing building blocks? MMusic, IP telephony both have done this.
How would the building-block approach work? What are the performance costs of doing the building-block approach?
Building blocks for mostly-reliable protocols?
Mark: I don't think that they need to be a separate class. Ohta disagrees.
Ohta: We should not begin standardization until congestion control is nailed down.
Michael Speer: RTP is a good example of the building block approach successfully applied in the past.
A concern about permutations of building blocks. What happens first, the building blocks are defined and protocols are standardized on top, or protocols are standardized while building blocks are being standardized in parallel?
Mark: this is a hard process to manage.
Tony S: Perhaps the right granularity for the building block approach is at the functional level.
Mark: Superficially it seems that packet formats are not necessary to standardize, but when you look at FEC, you see that it might be useful to standardized packet formats also.
Allison: The people who develop the protocols perhaps should write the building blocks that are useful to them.
The whole-propocol approach:
Starburst: Ken Miller absent, due to airport problems, so Brian Whetten is presenting his slides.
Viewgraphs:
http://www.aciri.org/RMT/RM-Miller.pdf
http://www.aciri.org/RMT/RM-Miller.ps
RMTP-II: Brian Whetten
Viewgraphs:
http://www.talarian.com/rmtp-ii/IETF%20RM%20BOF%20-%20March%201999.ppt
RMTP-II: http://www.talarian.com/rmtp-ii/overview.htm
Vern: The argument for the building-block approach is not short-term payoff but that of long-term payoff, so I don't understand why you say that the building block approach will save time in the short-term.
Abel: It is premature to say that we need to standardize four separate protocols; that will confuse the market.
Vern: You don't buy Mark's argument that RM is fundamentally different than TCP, and that one size doesn't fit all?
Roger: I believe that you can't have a one-size-fits-all protocol. Multiple working groups for the different protocols will loose the commonality. TCP evolved from a field of many unicast reliable protocols. People could call their current protocols version 1, and let the building-block-based approach be version 2.
Mark: Only a few of the protocols can be deployed in the big-I Internet today, and other protocols are the ones that are most in demand in Intranets, where there is router or server support.
Jon C.: I see RMTP and SRM as fully-fledged protocols, but I see PGM as a protocol piece with router support. One reason that TCP worked was that we had at least three versions of source code.
?: There is customer demand for reliable multicast in the global Internet now. Please do not slow down the development of RMTP-II and PGM.
Dino: Is the new working group going to work on interworking between the reliable multicast protocols?
PGM: Tony Speakman
Viewgraphs:
ftp://ftpeng.cisco.com/speakman/bof.slides.ps
Tony: To address the building-block vs. whole-protocol approach: There could be functional building blocks, or at the other end of the spectrum, specific mechanics of what to do in routers. I am a fan of the building-block approach to protocols, but there is a software engineering challenge that is nontrivial.
Tony: The activity of delivering and deploying these protocols in constrained circumstances is essential in determining what the building blocks should be. You certainly don't want to create building blocks that are not useful.
Vern: Is sounds like you are saying that you like the building block approach, but we don't know the right building blocks yet.
Tony: I think we need to start with per-protocol working groups. If we can get an API right for applications, then applications at least can go ahead.
Tony: We need to provide deployable instances of reliable multicast to push things along (to enable applications, to enable multicast routing, to enable more reliable multicast).
Tony: Yes, eventually we need to break out the building blocks.
?: Maybe we can have working groups directed at application-specific spaces. Does it make sense to decouple congestion control from reliability? If we agree on that, does that influence the way that we want to structure the working group?
Tony: There are service models underlying ACK-based and NACK-based approaches.
Jon C: The internet has a habit of being heterogeneous. Does this work involve changes to IP Multicast? These long-term issues might come out of the working groups.
Michael Speer: I am all for experience. We have to figure out how to punch four protocols through a protocol.
Roger: I think that we really need to have this experience shared in a single group.
Aaron: I am reminded by the discussion that we have been having on the PILC list, of the siren call of the market trying to push things through as quickly as possible. The methodology of building blocks doesn't sound baked. My proposal is to come up with classifications of topologies.
?: I don't know if we know enough yet to know exactly what the building blocks are. If we get the source code for these protocols, why do we need to formalize the building block approach. Maybe you get the building blocks as you develop it.
?: Why are we restricing ourselves to one-to-many? Many-to-many is still very important.
Scott B.: He wants to hear from people what they think the importance is of the differences between Internets and Intranets.
Vern: We will summarize to the RM mailing list. We haven't decided whether to establish a separate mailing list.
None received.