Current Meeting Report
2.7.14 Reliable Multicast Transport (rmt)
NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It
may now be out-of-date. Last Modified:
Roger Kermode <firstname.lastname@example.org>
L Vicisano <email@example.com>
Transport Area Director(s):
Scott Bradner <firstname.lastname@example.org>
Allison Mankin <email@example.com>
Transport Area Advisor:
Allison Mankin <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: subscribe
Description of Working Group:
Additional RMT web page: http://rmt.motlabs.com
The purpose of this WG is to standardize reliable multicast transport.
Initial efforts will focus 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 expects to initially
standardize three protocol instantiations, one each from the
the following three families:
1) A NACK-based protocol
2) A Tree-based ACK protocol
3) An "Asynchronous Layered Coding protocol that uses Forward Error
The WG will carry out protocol standardization by composing
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.
To assist in this standardization process, the WG will also complete
work on three documents. The first describes the design-space in which
the three one-to-many transport protocols will be developed. The second
explains the concepts of building-blocks and protocol instantiations.
The third provides guidelines to authors of drafts that specify
building-blocks and protocol instantiations. These three documents
will be initially submitted as WG drafts and subsequently proposed as
The WG will generate and submit for standardization drafts of the
following building-blocks for use in the construction of the three
protocols: congestion control, negative acknowledgments, forward error
correction, generic mechanisms for router assist, and to address the
RFC 2357 security requirements.
The WG will also standardize and generate RFCs for the following three
protocol instantiations: A NACK-based protocol, A Tree-based ACK
protocol and an Open Loop protocol that uses Forward Error Correction.
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 three protocol instantiations.|
|Done||  || Review drafts at the Adelaide IETF|
|Done||  || Submit Initial Draft for Congestion Control|
|Done||  || Complete building-block drafts WG Last-Call and submit for publication as Proposed Standard|
|Jun 00||  || Protocol instantiations drafts submitted for publication as Proposed Standard.|
|Dec 01||  || Congestion control draft submitted for publication as Proposed Standard.|
- - Generic Router Assist (GRA) Building Block Motivation and Architecture
- - RMT BB Forward Error Correction Codes
- - Reliable Multicast Transport Building Block: Tree Auto-Configuration
- - Security Requirements For TRACK
- - NACK-Oriented Reliable Multicast (NORM) Protocol Building Blocks
- - Layered Coding Transport: A massively scalable content delivery transport building block
- - Reliable Multicast Transport Building Block for TRACK
- - Generic Router Assist - Functional Specification
Request For Comments:
|RFC2887|| ||The Reliable Multicast Design Space for Bulk Data
|RFC3048|| ||Reliable Multicast Transport Building Blocks for
One-to-Many Bulk-Data Transfer
Current Meeting Report
Reliable Multicast Transport WG (rmt)
52nd IETF, Salt Lake City
Monday, December 10, at 0900-1130
Tuesday, December 11 at 1545-1645
CHAIRS: Roger Kermode <Roger.Kermode@motorola.com>
Lorenzon Vicisano <firstname.lastname@example.org>
1) Roger K./Lorenzo V. WG status and agenda updates 10 mins
2) Mike Luby Draft updates and call to move forward 20 mins
3) Mike Luby New draft ALC-related CC-PI 25 mins
4) Joerg Widmer New draft TFMCC CC-PI 25 mins
6) Lorenzo Vicisano (for Brian Adamson) Draft updates 15 mins
7) Chairs/AD ALC security discussion 15 mins
[Notes taken by Chuck Hardin <email@example.com>]
Comments on IPR for FEC:
Luigi Rizzo's codes should be available.
There may be other open codecs available,
at least one unencumbered codec should be
made available for each type of FEC scheme
Need to identify another codec in addition to
the Digital Fountain codec for long block codes.
are you tied to PIM or is it just specified because of popularity?
A: the latter
do we have data for other protocols?
MRTT comments for WEBRC
needn't be perfect now, can always be adjusted; also it's safe
unused protocols are always safe
safety is not security
need more data on join leave latency times from vendors,
but we need to think about this stuff now to ensure usability
what convergence times would you expect?
A: on the order of 10-20 seconds;
TCP will ramp up more quickly, TFMCC will slowly ramp up to match simulation results available in this year's sigcom paper
what simulation tool to get to 10K receivers?
simulation code is not available on ns website; it's available on Joerg Widmer's website
[Notes taken by Bill Nickless <firstname.lastname@example.org>]
Updates on the discussion of the NORM-BB and NORM-PI drafts.
NRL implementation in open source by March 2002 IETF
http://pf.itd.nrl.navy.mil - "source forge like site"
ALC Security Updates
Transport vulnerability to spoofed packets
Congestion control vulnerability
What's happening with TRACK
Not much has happened since the last meeting
working on congestion building block
drafts coming out shortly
Discussing getting the draft authors together in January possibly in Berkeley
** Lorenzo to coordinate with Mark Handley **
PGM is an experimental RFC as of 3 days ago
Roger remarks to Protocol Instantiation Authors
PI docs should contain sufficient detail for someone to implement a working protocol.
Allison (AD) remarks
Creating cross working group design team, considering security mechanisms for multicast SSM. PIM, MSEC, MAGMA. Under 10 people. Could be anchored in this WG.
- WG chairs from the above WGs will cut a first pass for people to look at.
Secure Session Management: would the chairs like to add this to the charter?
- short discussion about relationship to MAGMA
Creating a small design team to work on this issue too.
LCT BB status report 1, 2, 3