Last Modified: 2003-09-30
Initial efforts have focused solely on the standardization of the one-to-many transport of large amounts of data. Due to the large number of applications that fall into this category, and the sometimes orthogonal requirements these applications exhibit, it is believed that a "one size fits all" protocol will be unable to meet the requirements of all applications. In recognition of this observation, this working group will standardize two protocol instantiations, initially as Experimental protocols, and then as warranted, in the standards track, from the following families:
1) A NACK-based protocol. 2) An "Asynchronous Layered Coding protocol that uses Forward Error Correction.
The WG will carry out protocol standardization in general by composing a a set of RFCs that specify
- building blocks: A set of easily-separable coarse-grained modular components that are common to multiple protocols along with abstract APIs that define a building block's access methods and their arguments.
- protocol instantiations: Specifications that define the necessary gluing logic and minimal additional functionality required to realize a working protocol from one or more building blocks. These specifications will also include an abstract API that defines the interface between the protocol implementation and an application.
The WG has previously completed work on three documents to assist in the standardization process. RFC2887 describes the design-space in which the one-to-many transport protocols will be developed. RFC3048 explains the concepts of building-blocks and protocol instantiations. RFC3269 provides guidelines to authors of drafts that specify building-blocks and protocol instantiations.
The WG will generate and submit for standardization drafts of the following building-blocks for use in the construction of the two protocols: congestion control, negative acknowledgments, forward error correction, and to address the RFC 2357 security requirements.
Generic mechanisms for router assist are also considered for an additional building block. Initial work on the framework for router-assist has already been performed, the WG will evaluate whether to complete this task basing on available resource and interest.
The WG will also standardize and generate RFCs for the following two protocol instantiations: A NACK-based protocol, and an Asynchronous Layered Coding (ALC) protocol that uses Forward Error Correction. RFC 3450 is the Experimental RFC of the ALC protocol instantiation.
If new requirements are identified that cannot be satisfied with the building-blocks and protocol instantiations described above, the Area Directors in consultation with the IESG may add additional building-blocks and protocol instantiations to the working group deliverables.
This working group will work closely with the Internet Research Task Force (IRTF) groups on Reliable Multicast (RMRG) and Secure Multicast (SMUG), especially for meeting the congestion control and security requirements mandated by RFC 2357. This working group may work with the Area Directors to recharter to standardize reliable multicast for additional scenarios beyond the one-to-many transport of bulk data once they are sufficiently well understood.
| Done | Submit design-space, building-blocks, and guidelines drafts for publication as Informational RFCs | |
| Done | Initial Drafts for the following building blocks: negative acknowledgments, forward error correction, a generic signaling mechanism for router assist, and transport protection | |
| Done | Submit Initial Drafts for the two protocol instantiations. | |
| Done | Submit Initial Draft for Congestion Control | |
| Done | Complete building-block drafts WG Last-Call and submit for publication as Proposed Standard | |
| Done | Complete building blocks and protocol instantiations for ALC and submit for publication as Experimental RFC | |
| May 03 | WG Decision on whether to pursue the router-assist building block work. These milestones may have to be modified accordingly | |
| May 03 | Submit WEBRC (congestion control building block) for publication as Experimental | |
| Aug 03 | Submit remaining congestion control building blocks (TFMCC, PGMCC) for publication as Experimental | |
| Aug 03 | Submit NACK building block and protocol instantiation for publication as Experimental | |
| Dec 03 | Evaluate when and how the RMT Experimental specifications will be submitted for publication as Proposed Standard, and update this charter accordingly |
| RFC | Status | Title |
|---|---|---|
| RFC2887 | I | The Reliable Multicast Design Space for Bulk Data Transfer |
| RFC3048 | I | Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer |
| RFC3269 | I | Author Guidelines for RMT Building Blocks and Protocol Instantiation documents |
| RFC3450 | E | Asynchronous Layered Coding protocol instantiation |
| RFC3451 | E | Layered Coding Transport (LCT) Building Block |
| RFC3452 | E | Forward Error Correction Building Block |
| RFC3453 | I | The use of Forward Error Correction in Reliable Multicast |
Reliable Multicast Transport WG =============================== 58th IETF, Minneapolis, MN 5:00pm, 11 November 2003. =============================== Many thanks to Gorry Fairhurst for taking this minutes. List of Names: AM: A.Mankin (AD) LV: Lorenzo Vicisano (WG Chair) RK: Roger Kermode (WG Chair) MH: Mark Handley CP: Colin Perkins ML: Mike Luby RW: Rod Walsh Agenda was bashed - no changes Review of Working Group Status ------------------------------------------- WEBRC (draft-ietf-rmt-bb-webrc-04.txt) is under IESG expert review to become an Experimental RFC. The same procedure is expected for the other CC BBs, once submitted (AM). NORM PI and BB (draft-ietf-rmt-pi-norm-07, draft-ietf-rmt-bb-norm-08) are in WG last call, please comment (LV). TFMCC (draft-ietf-rmt-bb-tfmcc-02.txt) has no active work associated with it at the moment but can be considered done. It should probably be submitted experimental (MH). Need to check with PGMCC authors whether the same applies to PGMCC. The RMT WG may go dormant after the next IETF, subject to how IESG reviews and outstanding submissions proceed. ---- NORM Presentation draft-ietf-rmt-pi-norm-07 draft-ietf-rmt-bb-norm-08 Brian Adamson Some changes that would be needed: - Align NORM to FLUTE/ALC FEC - Can also now use non-IPSEC security (flag would be added) Is there time to do this? The WG agreed not to attempt last-minutes introduction of custom security protection. We suggest to use IPSEC with static keying, where available. The text from FLUTE can be re-used for this (RW). Other proposed changes: remove reference to GRA Brian will re-submit a revised version after the IETF week and the ADs will start WG last call again. ------ Presentation of FLUTE draft-ietf-rmt-flute-04 Rod Walsh The discussion after the presentation focused on the fact that the available implementations don't support layers and hence FLUTE was tested without. ALC was tested with layers but FLUTE introduces the concept of in-band FDT (File Descriptor Table) that is more susceptible to reliability and security threats. The WG is not going to use for FLUTE higher standards than the ones used for other drafts, hence it is not going to require additional testing. However the authors will have to address better the FDT issues in the draft. A transcript from this discussion is attached to this report. Flute implementors wish to write a Interop Report document. This may become a temporary RMT draft. Meeting Closed. Transcript from the FLUTE FDT discussion: LV: You said in the presentation that you didn't implement multiple layers? Multiple layers add quite a lot of complexity - can you spend time testing this? Ans: We've done two rounds of tests already - at the moment we haven't considered multiple layered congestion control. We also have a new ID we are writing on interoperability testing. This is in preparation - can we publish this in RMT? LV: Let's look at whether this will be a WG draft at the end. MH: On testing with multiple layers and CC: Are you really confident that the spec is good? RW: No, not 100%, because we haven't done interop on this yet. MH: We shouldn't go to RFC if this is not ready! - You need to be confident. RW: I'm confident it will work, but haven't implemented ML: We've implemented CC and it wasn't an issue LV: Was it using ALC? ML: It was. RK: The file description table (FDT) seems like when you do carousel mode, and do a late join, you have a problem here. I was thinking of security and DoS attacks for important objects. This is probably OK for an Experimental RFC, but need to know how MSEC can help this. Should the authors go to MSEC to push this? RW: We recommend the appropriate security in the ID and give Tesla as an example. LV: this is right for Experimental, there is a DoS attack chance on the FDT. RW: on point 1: we repeat the FDT, and we have done tests - the issue is how often we repeat the FDT.. MH: If you use one layer - then you haven't got CC. RW: The ID doesn't say no CC - that was just the tests. MH: It's multiple layers that give CC. If there are restrictions on use, then these are inappropriate for the general Internet. implementing several layers would be good, RW: This could be an action point for next testing! ML: Do all the implementations have no layers? RW: One layer - we haven't tested everything, this works. ML: I don't think you'll have problems. ML: The ID does say you must do CC - for the general Internet. CP: I am concerned we're pushing this forward too fast. The IMG in MMUSIC seems to need this - are we pushing it because of this? RW: FLUTE is well developed for an RMT draft. CP: Technically, I am not sure we claim that CC is well developed, and msec isn't well developed. The MMUSIC work (IMG) relies on this being a standard. LV: It doesn't make sense to refer to an Experimental RFC in this way. We're doing well for RMT at the moment, we don't need to do any interop. testing. AM: You also need to take care about risk analysis - security analysis. It starts to get scary when Experimental stuff is put into production by another standards body, Proposed STD is much better (even if this Proposed STD has identified risks and written them down). I'd like to see this and ALC go to Proposed STD with the loopholes documented. We're moving fast let's do this. RW: An Experimental RFC is an Experimental RFC - It's based on Experimental RFC Building Blocks in RMT. AM: We need to know about security and CC issues - we can then go to Proposed STD? RW: I don't have experience on CC in FLUTE - we just use the block that fits in here. AM: You just have to answer the questions; You don't have to do lots of work; We just need to be more thorough. MH: You don't have to demonstrate LCT, ALC, etc works. You must just guarantee there are no additional restrictions introduced by FLUTE. RW: OK. RK: I thought this was an ALC PI. There's more to it than this. It seems to have a dependency on the FDT, There's not a lot of work here to describe this- just due diligence. You should also tweak the document to make sure it does the things we said in the PI guidelines RFC. AM: That would be a good guideline. Also identify that there is a thing that MSEC needs to do because of FLUTE. RK: Just say this is a PI - it would help to add consistency. RW: it's a good idea to look at the Guidelines and do a sanity check. LV: OK, so we ask authors to check Guidelines; add applicability statement; add layering specific text to FLUTE. RK; One layer throws out CC ML: ALC can be used with a single source single layer CC - we are over focusing on this issue - It's in the spec in the FLUTE ID already. ML: To make it robust with CC you would put the FDT in the base layer of ALC. LV: We are not asking for a huge amount of work. RW: It just needs sanity |