2.8.11 Reliable Multicast Transport (rmt)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://rmt.motlabs.com -- Additional RMT Web Page
NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-09-30

Roger Kermode <Roger.Kermode@motorola.com>
Lorenzo Vicisano <lorenzo@cisco.com>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
Mailing Lists:
General Discussion: rmt@ietf.org
To Subscribe: rmt-request@ietf.org
In Body: subscribe
Archive: www.ietf.org/mail-archive/working-groups/rmt/current/maillist.html
Description of Working Group:
The purpose of this WG is to standardize reliable multicast transport.

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.

Goals and Milestones:
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
  • - draft-ietf-rmt-bb-norm-07.txt
  • - draft-ietf-rmt-pi-norm-08.txt
  • - draft-ietf-rmt-bb-webrc-04.txt
  • - draft-ietf-rmt-bb-tfmcc-02.txt
  • - draft-ietf-rmt-bb-fec-supp-compact-01.txt
  • - draft-ietf-rmt-flute-03.txt
  • Request For Comments:
    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

    Current Meeting Report

    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
    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
    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 
    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 
    LV: this is right for Experimental, there is a DoS attack chance on the 
    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 
    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 
    LV: We are not asking for a huge amount of work.
    RW: It just needs sanity 


    None received.