2.8.16 Reliable Multicast Transport (rmt)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional RMT Web Page

Last Modified: 2004-10-07


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: http://www.ietf.org/mail-archive/web/rmt/index.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

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

- 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

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
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


  • draft-ietf-rmt-bb-norm-09.txt
  • draft-ietf-rmt-pi-norm-10.txt
  • draft-ietf-rmt-bb-pgmcc-03.txt
  • draft-ietf-rmt-bb-tfmcc-04.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
    RFC3695 E Compact Forward Error Correction (FEC) Schemes
    RFC3738 E Wave and Equation Based Rate Control building block
    RFC3926 E FLUTE - File Delivery over Unidirectional Transport

    Current Meeting Report

    Reliable Multicast Transport (RMT) WG
    61th IETF -- Washington DC
    Tue, November 9, 2004

    Lorenzo Vicisano chairing

    Many thanks to Mark Pullen and Marshall Eubanks for taking the minutes of the meeting.


    Chairs agenda bashing 5 mins
    Chairs WG Status Update 5 mins
    Mike Luby "Raptor" FEC ID 15 mins
    Lorenzo Vicisano FEC BB possible evolution 20 mins
    Mike Luby FEC BB for streaming ? 15 mins

    WG Status Update

    NORM drafts are now finished
    RFC 3940 and 3941 - will be published
    TFMCC BB and PGMCC BB are in working group last call

    The agenda of the working group is officially done, although there are still some hanging FEC items.

    Need to update the milstones and might have to revise charter to include FEC BB revision to be discussed here.

    Mike Luby - "Raptor" FEC ID

    Raptor codes can generate as many encoding symbols as desired from a source code on the fly.

    Can decode after receiving a length just a little larger than the length of the original source blocks

    Lorenzo - Has the draft been submitted ?
    Mike - It is an individual submission.

    The code also can be made systematic (i.e., the original source codes are part of the encoding).

    Encoder : Goes from Source block -> encoding symbols, in two passes.
    The encoder starts by generating a precoding block from the source block.
    All of the details are in the draft :


    Pre-encoding : generates LDPC and Half symbols that are concatenated to the source block.

    Decoder builds up a matrix relating unknown to known symbol values, which can be solved using, e.g., Gaussian elimination.

    Very efficient code - and can decode if you receiver just a little more than the length of the source block in any order - 10^-3 probability that you cannot decode if you receive 1% more than the source block length.

    The probability of a decode failure drops to less than 10^-6 for a 2% overhead.

    Digital Fountain has IPR on all of this and will license this under the RAND ("reasonable and non-discriminatory") license.

    Lorenzo : The decision on whether to go forward will be made on the mailing list

    Allison : Is there an open source implementation ?
    Mark Handley : Are your RAND terms compatible with open source ?

    Mike Luby : I will have to think about this, but I think so. There is a independent implementation out of Nortel.

    Lorenzo Vicisano (not acting as chair) : FEC building block changes

    Shortcomings : There is no good guidance on implementation and some pieces (e.g, the splitting of objects in FLUTE) seem to be missing.

    Any changes have to be backwards compatible.

    * Fixes
    - A set of requirements for a fully specified encoding ID.

    - The FEC OTI needs to be defined in a more rigorous way. We need to make it clear that the FEC payload may contain multiple objects.

    - There need to be guidelines on how to write FEC ID's.

    * Enhancements

    - Allow for different symbols for encoded and repair symbols for optimization efficiency

    - Also want to expand the FEC range to allow for more than 256 ID's

    - Lastly, need some enhancements to allow the use for certain encoding ID's for streaming.

    Brian Adamson : From the NORM perspective - it would have been nice to have a specification for the splitting of objects into payloads.

    Colin Perkins on the FEC range : We had a similar problem with RTP - we went from static IDs to dynamically assigned ID's I would reserve part of the range. That's a good idea.

    Mike Luby - There may be consensus on doing this, but we need people who are willing to work on it.

    Mike Luby : FEC for streaming.

    Extend the FEC BB to RTP streaming.

    There have been some proprietary FEC applications to streaming.

    3GPP SA4 MBMS has adopted FEC for RMT

    this will likely be part of MBMS release 6

    Lorenzo : The charter of RMT is file transfer. However, it is a good practice to re-use the work of a working group if possible. We need to be sure that there is interest

    Stephan Wenger : Let's discuss it now.

    Colin Perkins : There is interest in having better FEC schemes While this fits into FEC well, it is not clear it fits into RTP. Previously, RTP used unchanged packets with protection packets for backwards compatibility

    Allison : The MBMS may have multiple different services.

    Mike Luby : MBMS == Multi Media Multicast Broadcast Services. This is a 3GPP concept.

    Allison : Is there a service difference ?

    Colin : The service is the same, but the implementation may or may not break RTP.

    Lorenzo : Two service models :

    FEC transport of RTP or RTP transport with extra repair packets.

    Stephan Wenger : The easiest thing to do is define streaming as the case where you do not want to wait an unlimited time for a decode.

    Colin : The crucial difference may be who handles the timing recovery - the RTP or the FEC packets.

    Stephan Wenger : Part of the confusion is that for the media practice to be protected, we are keeping the media time stamp the same. The only new thing is that the FEC time stamps have the value of when they were protected.

    When it comes to the media part, this is a straightforward media payload.

    Colin Perkins : What do you mean by streaming ? As I understand it, the 3GPP is definitely mutating the headers.

    Colin Perkins : The way we have done this in the past is to keep the RTP header and not insert an additional header.

    Stephan Wenger : But you can put in a piece of metadata if you want.

    Colin Perkins : Isn't what you are proposing redundant with the RTP header ? Why isn't it driven off of the RTP sequence numbers ?

    Mike Luby : Which packets are included in the source block ?

    Magnus Westerlund : You could have an explicit mapping between RTP sequence numbers and repair packet sequence numbers.

    Mike L. But this will cause huge inefficiencies.

    Colin : You have to use a recovery packet that is a long as the largest source packet in the block.

    Mike : If you use RFC2733 then you have to use the size of the longest packet within a block as the size of the recovery packets. You could be more sophisticated.

    Colin : I think that this is an interesting thing to do, but we need to work out the details.

    Mike Luby : So you might want to use something that is specifically designed for streaming.

    Stephan : The advantage is that with a BB you can just plug in different protection mechanisms.

    Colin : The elephant hiding in the corner is what is 3GPP doing.

    Allison : Do other standards bodies do RTP payloads ?

    Colin : 3GPP and ITU, at least.

    The was consensus in the room in pursuing the FEC BB resubmission as proposed by lorenzo and Mike. Contributors are sought; please send email to Lorenzo. Will take this item to the mailing list.


    Raptor codes for reliable multicast object delivery
    FEC BB Evolution
    Extend FEC BB to RTP streaming?