Last Modified: 2004-07-13
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 | |
| Done | WG Decision on whether to pursue the router-assist building block work. These milestones may have to be modified accordingly | |
| Done | 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 |
| RFC3695 | E | Compact Forward Error Correction (FEC) Schemes |
| RFC3738 | E | Wave and Equation Based Rate Control building block |
|
RMT WG minutes IETF60 3 Aug 04
Many thanks to Mark Pullen for recording these minutes. - Agenda * bashing * status update * RMT BB outside RMT (Mike Luby) * New "simple" FEC ID (Mike Luby) - Agenda modifications Added an item proposed by Mark Pullen: use this forum to poll for interest in overlay multicast techniques with the goal of possibly forming a WG. - WG Status (Lorenzo Vicisano) - past 6 months two new RFC (Compact FEC RFC3695, WEBRC RFC3738) - due soon: NORM BB, NORM PI, FLUTE - remaining drafts TFMCC, PGMCC soon to go in WG last call. Need to discuss this on the list and move forward. - Still need to evaluate when/how to go for Proposed Standard. George Gross is considering NORM as a requirement (dependency) for some MSEC work. Similarly Mike Luby is considering the application of the FEC BB to RTP (AVT WG). Both applications do not depend on congestion control. A possibility would be to move some BB to proposed standard faster than other. Need to discuss this on the list. - The completion of the current charter is expected before November 04 IETF. This could signify the completion of this phase (pre-standard-track) of the WG, however the submission of new FEC ID drafts and the outcome of the "proposed standard" discussion could make us change our plans. - FEC BB: what's next? (Mike Luby) - now Experimental RFC - in RMT, provides architecture to add reliability to FLUTE/ALC - in 3GPP, FLUTE planned to be used for MBMS file download (needs FEC) - proposed in AVT to use RMT FEC to add reliability to streaming apps - FEC BB provides a generic way to specify a variety of FEC schemes - there is some deployment experience: commercial file delivery, streaming - seen as a fundamental BB - proposal: decouple FEC standards progress from the rest of RMT; expedite to proposed standard - issues to resolve: 1. encoding ID space needs expanded recommend: move to dynamic encoding as RTP does it 2. FEC object transmission information (OTI) not explicit enough recommend: require an explicit list of parameters 3. OTI parameters have no registered names recommend: adopt current names in FLUTE spec 4. originally written with file delivery in mind; could be used for streaming General agreement from floor, but no decisions were made on the above The above proposal cold require restructuring the FEC BB. Need to discuss on the list the viability of this option. - "Simple" FEC ID (Mike Luby) (supplement to FEC BB) - introduces two new FEC encoding IDs - one fully-specified, used for interoperability testing without specific FEC scheme - the other under-specified; useful for FEC schemes that protect file as single entity - floor comments did not favor the fully-specified ID - Luby will resubmit draft without it, which will simplify his draft; question of making it a WG item will go to the list - the other pending draft in this area will be asked to restructure/simplify: it was proposed to re-edit the existing FEC-ID specs in order to structure the documents in a more readable way. A starting point would be to define only one FEC-ID per document. - Overlay Multicast (Mark Pullen) - having extra time, the group gave Mark Pullen a few minutes to probe interest in creating an Overlay Multicast working group - most attendees were not interested, however a few were - Mark Handley suggested the topic should first be opened in the Peer-to-Peer Research Group to see if they can distill the large amount of work that his been done in this area into a recommended approach |