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 <email@example.com>
Roger Kermode <firstname.lastname@example.org>
L Vicisano <email@example.com>
Scott Bradner <firstname.lastname@example.org>
Allison Mankin <email@example.com>
Scott Bradner <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: subscribe rmt
Archive: send msg to firstname.lastname@example.org,
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.
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
Protocol instantiations drafts submitted for publication as Proposed Standard.
Congestion control draft submitted for publication as Proposed Standard.
The Reliable Multicast Design Space for Bulk Data Transfer
Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer
Reliable Mulitcast Transport (rmt) WG
51st IETF, London
Minute Taker: Jon Crowcroft <email@example.com>
Chairs: Roger Kermode <Roger.Kermode@motorola.com>
Lorenzo Vicisano <firstname.lastname@example.org>
Allison Mankin <email@example.com>
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
WG need to consider:
style of session, what kind of features will be needed
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?
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)
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...
OK get specific and work on plan...
what about relation to to MSEC WG?
answer : TBD
2. GRA Update
GRA is subset of routers
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?
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.
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
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...
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
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;
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
5. NACK formats
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")
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
6. FEC BB
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?"
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
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
draft was updated from v00 to v01
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
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
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
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?
TRACK Protocol Instantiation Update