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>
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>
Scott Bradner <sob@harvard.edu>
General Discussion:rmt@lbl.gov
To Subscribe: majordomo@listserv.lbl.gov
In Body: subscribe rmt
Archive: send msg to majordomo@lbl.gov,
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.
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. |
Jun 00 |
|
Congestion control draft submitted for publication as Proposed Standard. |
· Generic Router Assist (GRA) Building Block Motivation and Architecture
· RMT BB Forward Error Correction Codes
· Asynchronous Layered Coding: A massively scalable reliably content delivery protocol
· Author Guidelines for RMT Building Blocks and Protocol Instantiation documents
· 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
· The use of Forward Error Correction in Reliable Multicast
· Reliable Multicast Transport Building Block: Layered Congestion Control
· NACK-Oriented Reliable Multicast Protocol (NORM)
· Reliable Multicast Transport Building Block for TRACK
· PGMCC single rate multicast congestion control: Protocol Specification
RFC |
Status |
Title |
RFC2887 |
The Reliable Multicast Design Space for Bulk Data Transfer | |
RFC3048 |
Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer |
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:
security/DOS/authentication
firewalls
RMT support
CDI
cons
why not RTSP/sip or other existing protocol?
speakman@mike:
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?
kermode@mike
can we scope the work into mmusic?
colin perkins@mike
outside of mmusic scope
luby:
not clear its out of scope...
braden:
session ctl is for state.
Is this for transport, or for application?
- first is appropriate, rest not.
speakman:
we need it for transport....(including net. elements)...
but what is state?
whettan:
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
bradner:
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...
luby:
see draft
Vicisano:
OK get specific and work on plan...
Ken Calvert:
what about relation to to MSEC WG?
answer : TBD
2. GRA Update
Tony Speakman
---------------------
model
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..)
whettan:
? 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
Vicisano:
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
show:
TRACK/NACK/NORM/GRA/
instantiation/ protocol class hierarchy
candy:
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
speakman:
what do references to NORM mean?
whettan:
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
luby:
how does it sit on ALC (instantiation. not building block|)
Crowcroft:
we have a lot of useful stuff here - need more small group effective understanding
Handley:
yes
speakman:
GRA case:- needs more work...NORM/TRACK/GRA - aggregation
4. NORM BB draft Update
Brian Adamson
-----------------------
aggregation
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
speakman:
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...
Handley:
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...
speakman:
omitting discussion on RTT!
debate...
need to think about description of packet for local..v. global meaning of packet
6. FEC BB
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?
Adamson/Calvert:
sort of seems ok to put here
Luby:
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?
handley:
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
Luby:
yes, need to involve rm community
Handley:
need to avoid deadlock on proposed standard for protocol
cross dependance on congestion control bb awaiting approval...
and vice versa
Kermode:
wants to get a fuller set of drafts to cover the ground of RMT
work...
Vicisano: can stage things - say we use "a" congestion control so there's no link
Handley:
feedback process for congestion control is often associated with the feedback for reliability, so there's some
Luby:
not true for all protocols tho...
Handley:
with layered scheme, have another problem - dont have an idea of how much load router can take in terms of group mgmt load
Luby:
yes, need to study that for igmp and pim sparse mode stuff
Handley:
does anyone have a feel for this?
Adamson:
yes, we've done this! have some feel - more a network than a device problem...
Luby:
can you publish that (and tools to carry out experiments!)
Vicisano:
still need to decide how to proceed.
room is silent...
Kermode:
should try to put a proposal together and do this decision/resolution on the list
Vicisano:
what is wrong with current approach
(rough consenss and working code?)
Luby:
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.
Luby:
environmental factors should be documented too
Kermode:
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 -
simplifications,
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)
Future:
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
LCT,
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
Proposal:
- 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
Speakman:
need emphasis on implementation
Handley:
yes; need to close gulf between GRA and other pieces
(observed gulf in RMT #1)
Luby:
what does it mean to "implemeny something in a protocol"?
Kermode:
See what people code when they do it from spec independantly
Speakman;
problem for people working from drafts in flux
Vicisano:
so we only need interopability of things at after draft, only at proposed
Handley;
right we dont need it that strong at this stage
(c.f. proposed milestone update above)
Speakman:
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
Luby:
FEC BB will be used in more than one PI but the timeing is different
Speakman:
hold up standardisation of BB (keep BB as experimental until we have all BBs used in several PIs.
Kermode:
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
Vicisano:
how does GRA fit the proposed new Milestones?
Speakman:
ok...
Agenda
General
Generic Router Assist
Session control protocol?
'draft-ietf-rmt-bb-fec-03' Updates
TRACK Protocol Instantiation Update