2.8.13 Reliable Multicast Transport (rmt)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01


Allison Mankin <mankin@isi.edu>
Roger Kermode <ark008@email.mot.com>
L Vicisano <lorenzo@cisco.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>

Transport Area Advisor:

Scott Bradner <sob@harvard.edu>

Mailing Lists:

General Discussion:rmt@lbl.gov
To Subscribe: majordomo@listserv.lbl.gov
In Body: subscribe rmt
Archive: send msg to majordomo@lbl.gov,

Description of Working Group:

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 Correction

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 Informational RFC.

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



Submit design-space, building-blocks, and guidelines drafts for publication as Informational RFCs



Initial Drafts for the following building blocks: negative acknowledgments, forward error correction, a generic signaling mechanism for router assist, and transport protection



Submit Initial Drafts for the three protocol instantiations.



Review drafts at the Adelaide IETF



Submit Initial Draft for Congestion Control



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.

Jun 00


Congestion control draft submitted for publication as Proposed Standard.

Request For Comments:






The Reliable Multicast Design Space for Bulk Data Transfer



Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer

Current Meeting Report

Reliable Mulitcast Transport (rmt) WG
51st IETF, London
Minute Taker: Jon Crowcroft <jon@cs.ucl.ac.uk>
Chairs: Roger Kermode <Roger.Kermode@motorola.com>
Lorenzo Vicisano <lorenzo@cisco.com>
Allison Mankin <mankin@isi.edu>

Session 1, Monday

0. Agenda Bashing
1. rccp pi: Mike Luby
2. GRA Update: Tony Speakman
3. TRACK Update: Brian Whettan
4. NORM Update: Brian Adamson
5. NACk format: Brian Adamson
6. FEC BB: Lorenzo Vicisano

1. Session control protocol discussion
Mike Luby

WG need to consider:
style of session, what kind of features will be needed
pros/cons of:
RMT support
why not RTSP/sip or other existing protocol?

given GRA need session (state setup)
for RMT - hmmm
for multicast in general...could be huge (mmusic)

draft to date is v. large
do we want to customize?

can we scope the work into mmusic?

colin perkins@mike
outside of mmusic scope

not clear its out of scope...

session ctl is for state.
Is this for transport, or for application?
- first is appropriate, rest not.

we need it for transport....(including net. elements)...
but what is state?

what is session ctl?
e.g. in TRACK its clear (e.g aggregation)
what isn't?
business aggregation, firewall, etc etc,,,
where is the line drawn

where was luby draft...? at all
where is cow (given we don't know color to paint it)
to early to say what, but could be in scope - hard to say right now...

see draft

OK get specific and work on plan...

Ken Calvert:
what about relation to to MSEC WG?

answer : TBD

2. GRA Update
Tony Speakman

GRA is subset of routers
predefined filters

filter = fid+housekeeping/action/subfilter type
e.g . see PGM

lengthy example drawn from PGM...see slides
for actions, headers, etc

GRA schematic header... i-d's, operands
(remember filter ("program") is static in current model
sequence number (i.e.. other packet fields ) are implicit...

need discussion about identifiers
- need 1 (no more) to scope rest of action

1/2 the space of i-d's is for static i-d's
1/2 for dynamic i-d's...(i.e re-programmable)

Question: how long is id?
fixed/var? (var=future)

filter function:
packet accumulation is precluded by GRA
modification is restricted to overwriting GRA fields
i.e. v. limited - reformatting
(e.g. encapsulation/decapsulation) no no no!

operations (e.g. forwarding function:)
e.g. multicast - don't change route (graph?)
e.g. unicast yep - arbitrary...
(w.g. need to get to turning point.)
no (NO) packet generation.

ctl protocol:
in band info ok
out of band administration

Vicisano: what about transport protocol selector

Bormann: isn't it implicit(scoped by net header)

Speakman: only needs to be globally unique or scoped by transport no.
need to decouple transport...

some discussion of protocol v. gsi based de-multiplex
(Calvert/Bormann/Vicisano/?)... GSI...

GRA header processing...needs some more analysis...

GRA header has operands - what and where?
(note has a cost..)

? does this proposal preclude UDP encapsulation?
e.g. where GRA header is...

speakman answer:
could put after transport header (i.e. UDP)
e.g. end systems deployment

UDP in this use is a hack. its a "net layer"
so make EDP an exception....

goal: keep arch spec info
make functional spec active...

critical: define tight spec for language...flex v. safe...

so from the lingo being specified, can take it, and define filter in that mode...

an example will be from authors - other folks Alan roll their own...
in band, need to propagate neighbor info...
have people looking at who can use protocol specs etc...

3. Track Update
Brian Whetten

This has integration plan (with GRA implicit under NORM)

TRACK over UDP/IP for completeness...
(not recommended for general deployment)

separate document over NORM for example instantiation

instantiation/ protocol class hierarchy

application level confirm delivery;
session parameters;
statistics aggregation

other session stuff? pro: simplicity good; but?
(danger - see RTCP/RTSP/SDP etc)

Handley: watch definition of TFMCC - generic. vs. specific
(e.g. SIGCOMM paper or PGMCC paper?

whettan: ? gave generic answer

what do references to NORM mean?

NACKS are part of NORM or PGM, not TRACK...
oops = deep sixed on protocol v. class of building block!
adamson/speakman/Handley:- arghh:- implicit v. block

how does it sit on ALC (instantiation. not building block|)

we have a lot of useful stuff here - need more small group effective understanding


GRA case:- needs more work...NORM/TRACK/GRA - aggregation

4. NORM BB draft Update
Brian Adamson
nack pieces
GRA pieces

5. NACK formats
Brian Adamson
general purpose NACK encapsulation
made consistent with ALC
relates to FEC technique

e.g. abstract data hierarchy

nack type - has some semantics...
includes something without object, stream, FEC if needed...

presents various NACK forms - including "slack nack")

composite encapsulation:
e.g.of header to show specific segments in stream

Is scope of GRA sufficient to parse general nack format?
- (e.g. lists of layers, missing segments...)
- could use this format for other protocol functions....
such as SACK

problem: distance between GRA specification and
NORM spec is too huge

can separate function (structure of id can be opaque)

e.g. sequence+parity count...

problem is nack expresses too much - nack doesn't need to be globally defined
receiver only needs to parse what sender said...
can be session depended
- so long as sender can say to receiver on a session
basis what it meant

speakman: can avoid baroque (elaborate) nack...
kermode: nice structure - but need something more implementable...
adamson need to reach consensus on service model...
may need more than just tony and adamson
kermode: could be closer than we realize
time to move on...

omitting discussion on RTT!

need to think about description of packet for local..v. global meaning of packet

Lorenzo Vicisano

removed feedback packet format (NACK) - now in NORM
add id and relative small packet FEC code (see i-d)

object length question: parameters of FEC etc
is it here or somewhere else?

sort of seems ok to put here

could be de trop...sometimes, and other times need it
- so it's a higher level function...

... ... ... discussion about LCT and ALC...last call

Vicisano & luby both favor that! look forward to tomorrows agenda..

Session #2, Tuesday

0. Agenda Bashing
1. Congestion ctl Standardisation Path: Mike Luby
2. LCT BB Status Report: Mike Luby
3. ALC BB Update: Mikle Luby
4. WG overal progress/status report: Roger Kermode

1. "What is the path for congestion ctl in the WG?"
Mike Luby

We have several proposals for congestion control
none going quickly to rfc
no quick process to official approval
catch 22 - no approval, no working code, no code, no approval

proposes a process:
perf mustbe shown on basic set of tests....(ns)
real world data prove
experimemntal rfc
provide data to panel for review
panel report to RMT
then becomes a building block

how would we constitute the panel?

it's a long process - can we shorten it/streamline it?

suspect most people would have (or actually in real cases in front of RMT have already)
written a paper for the early stage already

doesn't have to be pass/fail

so if we do hit a problem, need a path to revision

yes, need to involve rm community

need to avoid deadlock on proposed standard for protocol
cross dependance on congestion control bb awaiting approval...
and vice versa

wants to get a fuller set of drafts to cover the ground of RMT

Vicisano: can stage things - say we use "a" congestion control so there's no link

feedback process for congestion control is often associated with the feedback for reliability, so there's some

not true for all protocols tho...

with layered scheme, have another problem - dont have an idea of how much load router can take in terms of group mgmt load

yes, need to study that for igmp and pim sparse mode stuff

does anyone have a feel for this?

yes, we've done this! have some feel - more a network than a device problem...

can you publish that (and tools to carry out experiments!)

still need to decide how to proceed.

room is silent...

should try to put a proposal together and do this decision/resolution on the list

what is wrong with current approach
(rough consenss and working code?)

info needed is greater...

Handley proposed this process:
1. write i-d to say what CC you use
2. write tech report saying what experiments you've done and results
3. make ns (or similar) scripts available for simulation

then put on the list, and see what people say in terms of consensus.

environmental factors should be documented too

need the caveats listed too, this is listed in the author guidelines draft

2. LCT BB Status Report
Mike Luby

draft was updated from v00 to v01

LCT reminder:
it's a transort control for a session made out of multiple objects over multiple channels - so CC is over multiple tunnels

Allows unicast or multicast (preferred)
multirate (preferred) or single rate congestion control

Deltas to the i-d are in the draft -
transport object id more prominent, and
variable length now tx & residual time independant
new bits in the header:
for close of object and close of session
More version bits,
header extensions clarified....and structure more logical.

Changed congestion control so bits not ignored.

See i-d for packet header (fixed and optional parts)

minor revisions - ready to go to rfc after that.

3. ALC BB Update
Mike Luby

draft was updated from v00 to v01

used to use UDP transport, now LCT
- now allows push service, as well as on demnd
- now is a simple combination of
FEC and
whatever congestion control building block (BB) we want (eg. LCC BB)

See i-d for the packet format

Future - minor revisions, then go to RFC.

4. WG overal progress/status report
Roger Kermode

Slides of all the i-d docs grouped by PI
(Protocol Instantiation) [ see slides ]

NORM, TRACK, ALC, Informational, RFC
and where they are used

We tried something new here (using BBs). How are we doing?
- Getting there, with most drafts started.
- Haven't got one single full protocol
spec submitted quite yet.

Need to have all authors talk to each other

- Interim meeting before next ietf
- could be at ACIRI (offerred in next month or so).

Suggested New Milestones
sep 01 complete autor guidelines
dec 01 protocol instants drafts dpme
dec 01 congestion control
mar 02 remaining PIs done
jun 02 PI drafts submit as proposed standard
jun 02 congestion control drafts submit as proposed standard

need emphasis on implementation

yes; need to close gulf between GRA and other pieces
(observed gulf in RMT #1)

what does it mean to "implemeny something in a protocol"?

See what people code when they do it from spec independantly

problem for people working from drafts in flux

so we only need interopability of things at after draft, only at proposed

right we dont need it that strong at this stage
(c.f. proposed milestone update above)

need to see more than one PI use the same BB
So for GRA, we have a lot of references
- but its only the NORM one
We can do now so Adamson & speakman will follow
Handley's remark and talk

So as a BB tho, the GRA could stay as draft until there's more than one GRA

FEC BB will be used in more than one PI but the timeing is different

hold up standardisation of BB (keep BB as experimental until we have all BBs used in several PIs.

so as an example - maybe should have the alc and other pieces go to experimental?

Discussion on process for BBs ensued.
- Consenss was that that experimental means we have room/flexibility to work on subsequent PIs with change (stress) to BBs as we would expect

how does GRA fit the proposed new Milestones?



Generic Router Assist
Session control protocol?
'draft-ietf-rmt-bb-fec-03' Updates
TRACK Protocol Instantiation Update