2.8.12 Reliable Multicast Transport (rmt)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01

Chair(s):

Allison Mankin <mankin@east.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@east.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:

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.

Internet-Drafts:
Request For Comments:

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

Current Meeting Report

Reliable Multicast Transport Working Group Minutes
50th IETF, Minneapolis
Chairs:
Roger Kermode
Allison Mankin
Lorenzo Vicisano

The Reliable Multicast Transport Working Group met for one hour on Tuesday, March 20 and one and one and half hour on Wednesday, March 21, 2001

The fist session started with a update on the Author Guidelines draft, that is ready to be go for WG last call, followed by 3 short presentations on the status of NORM, ALC and GRA.

Brian Adamson gave the presentation on the NORM protocol instantiation
and related building blocks. This generated, as an action item, the
commitment from Brian to edit the FEC BB to incorporate some additions
needed by NORM.

Mike Luby gave the next presentation on the general status of ALC protocol instantiation and BBs. ALC has currently three building blocks: FEC, LCT (Layered Coding Transport) and LCC (layered congestion control). The fist two are very close to be ready for WG last call (modulo minor editing), the third is quite advanced but requires more work (tuning/experiments). ALC currently lack of a PI document because LCT has been extracted from the original PI to create a general-purpose BB. The new ALC API, to be submitted, will be a short document that specifies the few details needed to merge the three BBs together.

Tony Speakman reported on the status of the Generic Router Assist work. Since last IETF the group working on this has been re-staffed and a plan made on the deliverables. The documents that the group is trying to produce are:
- an architecture specification
- a functional specification outlining the filter model and each of its specific predicates and operators
- a GRA protocol specification providing the mechanics of a specific implementation of GRA
- a requirement document in which to record the control protocol support needed for GRA session definition and management
The only document currently available is the architecture specification that the editing group is planning to revise by the next IETF.

The fist session of the meeting ended with Lorenzo Vicisano presenting PGMCC, a congestion control proposal for NORM and possibly TRACK. This work by Luigi Rizzo and others was presented at the RMRG months ago and recently submitted as WG draft. It is currently considered one of the most advanced proposal among the CC building blocks, but still needs some work to address a few secondary issues.

Another congestion control algorithm proposed by Mark Handley and others and discussed within the RMRG will be submitted as WG draft by the next IETF meeting. The WG will then decide whether to go forward with both proposals, choose one or merge them.

The second session of the meeting started with Miriam Kadansky and Brian Whetten giving updates the status of the TRACK PI and related building blocks.

Mirian Kadansky gave some updates on the Tree Auto-configuration BB, that has undergone some algorithm refinements and API specification. A little more work needs to be done to remove the remaining overlap with the TRACK BB.

Brian Whetten presented updates on the TRACK BB and PI. Work has been done to the BB to update/define interfaces and messages. The PI document missed the submission deadline and will be submitted soon.
The ongoing work is on BBs integration (Tree Conf., TFMCC and TRACK BB).

The following presentation was by Shin-Gak Kang:
draft-koh-rmt-bb-tsm-00.txt, a candidate "Session Management" building block. The draft focused on membership notification and management, group membership tracking and troublemaker ejection. The WG reckons that this document defines useful features but not generally applicable within the transport layer. Some other WG might be more appropriate for the document.

The meeting ended with Lorenzo Vicisano starting a discussion on procedures and criterias for promoting congestion control BBs to RFCs. Two documents already exist that address this problem: Brian Whetten's "proposal for reliable multicast CC requirements" (May '99) and "More thoughts on reference simulations for RM CC schemes" (by various WG members), however only real network deployment can ultimately demonstrate the safety and stability of a CC algorithm. The proposal is to continue the work on the mailing list to refine the CC guideline/criteria documents. In addition, CC schemes that meet these criteria and are considered mature by the WG should be submitted as experimental RFC. Standard-track submission should happen only after medium/large scale deployment has taken place.

During the second session of the meeting the WG also discussed the individual submission of PGM (draft-speakman-pgm-spec-06.txt) for experimental RFC. This draft has been submitted to the RFC editor for direct publication as an RFC, and it was thought that some discussion was needed within the RMT WG about whether or not it was appropriate to publish this draft as an RFC. A spirited discussion took place during which a number of concerns were raised:

Tony Speakman spoke in favor of publishing the draft as an RFC, citing the need for permanent reference and the need for the PGM authors to put the draft to bed so they could work on the GRA work. He went on to state that PGM was destined for obsolesce because of this. A number of people raised concerns about whether allowing PGM to be published as an experimental RFC was good idea as
- it could constitute an end-run around the working group
- the general public doesn't read the word experimental and just sees RFC, thereby anointing PGM as a defacto standard for RMT
- PGM doesn't meet the requirements set out in RFC2357. (pgmcc is not quite there yet)
- it was potentially unfair to other vendors who has stopped working on their own proprietary protocols to contribute to the RMT work
Bob Braden reminded everyone that the WG could only make a recommendation to the RFC editor, and did not have the power to grant or deny the right to publish the draft as RFC. Mark Handley suggested that PGM should be gated on the publication of PGM Congestion Control as an RFC. Roger Kermode suggested that one way to proceed would be to publish the draft as historic immediately given that the intent was to obsolete it once the RMT work came out. Finally, Scott Bradner took a sense from the room, the end result being that the majority of the room favor publication of the draft as an RFC with disclaimers being included at the front. It was agreed that further discussion would take place on the list.

----------------------
Minutes (thanks to Sally Floyd and Ken Calvert for this)

Notes of the Reliable Multicast Working Group, Tuesday, 1PM, March 20, 2001
Note-taker: Sally Floyd

* Agenda Bashing.
Some things got moved around.

----------------

* Charter of Working Group.
There are two items left on the charter.
Many things are waiting for the congestion control draft.

-------------------

* NORM - NACK-Oriented Relaible Multicast. Brian Adamson.
** Get viewgraphs of presentation.
Not much has changed since the last round of the document.
The presentation described the NORM Data Messages, NACK Formats, Sender Command Messages, Issues.

BW: Why do you need the advertisement message?
This would be addressed offline.

BW: Some of the ACKs are scope-creep into the TRACK space.

Chair: A recommendation for the authors to Look at the building block guidelines document, particularly about the need for an applicability statement.

MH: These sessions require out-of-band negotiation for set-up.
Perhaps advertisement messages could go there?

MH: Some of the commands seem to be application-level functionality rather than transport-level functionality, and therefore shouldn't go in this document. The ACK request, in particular.

BW: There is some other application-level semantics in this document.

Chair: A recommendation to look at what belongs in the core protocol, and what is application-level and doesn't belong there.

------------------

* Mike Luby - LCT, FEC, LCC, ALC Overview
** Get viewgraphs of presentation.

LCT: Layer Coding Transport. The goal is to move to RFC before the next IETF.

FEC: The goal is to move to RFC before the next IETF.
Question: Inclusion of variable-size redundant symbols?

LCC: Layered Congestion Control. There are several technical issues still to be resolved. What is the criteria for congestion control to move to RFC?

ALC: This is the protocol instantiation draft, and it needs to be reinvigorated. It draws on the other three drafts.

---------------------------------

* Tony Speakman, GRA drafts

Tony's notes from his presentation:

> New GRA author line-up is Brad Cain, Ken Calvert, Christos
> Papadopoulos,
> and Swapna Yelamanchi and me. Don Towsley TBD.
>
> We are planning four documents:
>
> - a revision of the architecture spec
> - a functional spec outlining the filter model and each of
> its specific predicates and operators
> - a GRA protocol spec providing the mechanics of a specific
> implementation of GRA
> - a requirements doc in which to record the control protocol
> support we need for GRA session definition and management

By London they hope to have a new and hopefully final draft of the architecture document. They will have an applicability statement.

-----------------------------------------------------------

* Lorenzo Vicisano: PGMCC Single Rate Multicast Congestion Control
** Get viewgraphs of presentation.

PGMCC: for a general NACK-based protocol, with an acker, an elected representative of the receivers that sends ACKs. A NACK-based election procedure is used to select the acker, and the sender and acker run TCP-style congestion control.

Reliability and congestion control are decoupled.

Issues: Generation of NACKs, NACK suppression.

Requirements for RTT estimation are fairly loose.

MH: Will PGMCC be specified for TRACK-based protocols?

Answer: That would be an easy extension.

BW: Issues for adaption to TRACK. The fast response time is a drawback.

MH: We are still working on TFMCC, and are planning on writing an RFC on that.

Issues for PGMCC: Session startup; Loss estimation at the receiver; Security.
-----------------------------------------------------------

The rest of the presentations will be in tomorrow's session for this group.

MH: Mark Handley
BW: Brian Whetten

=============================================================
RMT Working Group (2nd session)
Wed, 21 March 2001
Note-taker: Ken Calvert

0. Agenda Bashing -- Roger

1. Update on TRACK Tree Autoconfig, BB and PI drafts -- Miriam Kadansky, Brian Whetten

Tree AutoConfig-02 is current.
Updates:
- Mesh discovery refinements, including flow chart and discussion of handling loss of SN
- External interface to SN discovery: child/parent sides.
getSNs(), setSN(), optimize...
accept child, remove child, ...
Issues: still some overlap with TRACK BB

TRACK BB-01: Updated interfaces, message types. Tried to unify messages. Interfaces: BB->PI, PI->BB defined

TRACK PI: this draft didn't make the IETF cutoff, will be out soon.
Builds on architecture document.
Key issue: integration with Building Blocks.

(Overview picture showing relationship among pieces)

TRACK BB functions: hierarchical session establishment. Aggregation types.
TRACK PI: "leftover functionality" = state machine, abstract API, packet

formats

ISSUES: Do we need a BB for Nack-only?
How much can be re-used from/unified with NORM?
Session Management -- additional needed?
don't need another BB
just need another [...?]
Next steps: finish draft of PI
finish details of TRACK, tree BBs
TFMCC BB

(No discussion on any of these three drafts.)

2. PGM draft submission to IESG for publication as Experimental. -- Roger
IESG referred issue back to WG because of work going on in the area (as is their custom).

Questions for the WG:
"Would issuing PGM as an Experimental RFC derail the WG?"
[Description of RFC2357 criteria for stds track RM protocols, etc.]

Some concern that this would be a bad precedent for other firms that want their protocols to be "blessed" as Experimental RFC.

Discussion:

Tony Speakman: in the submission to IESG, he acknowledged that not all the reqs of 2357 were met, that's why he's asking for EXP. As for congestion control, he believes 2 approaches exist, of which one (pgmcc) is on track for standardization. The goal is to have a tool/platform that can supply experimental data to shed light on the work of the group. This protocol doesn't belong in the WG's charter.

As for relationship to the WG's work: GRA is the most important by-product. Intends to push GRA so he (and company) can get out of the transport protocol business. Getting PGM to EXP will free him up to do that.

As for other commercial offerings: this draft went through an IETF-like, open process, w/feedback from the experts in the WG, which was incorporated into the spec.

As for the analysis: there hasn't been a *formal* analysis, but don't at this point have any reason to believe the protocol will cause problems.

Bob Braden: Point of order -- it's the RFC Editor that publishes RFC's, not the IESG. The IESG makes recommendations, but the bottom line is that the "other vendors/special treatment" question isn't an issue -- anybody can *ask* for their protocol to be published as EXP.

[Bradner: Bob is one of the people who believes that the RFCs are just what we say they are.]

Brian Whetten: Yes, Talerian has an implementation of PGM.

Tony: Anybody from Tibco here? (No.)

Scott Bradner: Concerns about RM RFC's: it's pretty easy to do "bad impacts" with this technology. What we're trying to evaluate here is what the advice/caveat to go with this should be. What's the hurry? Why not wait six months and see what the WG comes up with?

Jon Crowcroft: We're very conflicted. Lots of pros and cons. Problem is that 99% of the experts who've reviewed it are in this room. Process implications are tricky. The folks who are in the same boat have done a *lot* of experiments already. When are we done waiting? What's the "exit strategy" if we put it on hold?

Bob Braden: Historical example: NETBLT, published as Experimental many years ago. Every six months or so, somebody asks him about it. If widely used, this protocol would destroy the Internet. Yet the world has not come apart.

Mark Handley: Agree with Scott. Exit strategy: adopt pgmcc, then evaluate PGM.

Tony: The sooner pgm is published as RFC, the sooner it can become obsolete. Publishing the spec allows comments, tracking status, etc. Also: PGM is not covered by the WG charter, because it's not BB-based. Regarding the "domino theory" of other companies rushing to publish protocols as EXP: haven't seen six drafts of any other protocol.

Allison: Had there not been progress on the BB's, other vendors might've done more. Did PGM take energy away from GRA?
[Tony: GRA holds a great deal of promise. One of the reasons to publish PGM is so people will leave me alone to work on GRA!]
Is there some way some part of GRA can come forward quite soon?
Is there some way to revise the charter to allow this [PGM] to come in, maybe as a PI?
[Tony: PGM is destined for obsolescence. What should happen is that
we put together BB's to form the logical equivalent of PGM.]

Roger: publish it as a Historical RFC?

Crowcroft: Went through an analogous situation with RTP: started monolithic, it grew, then underwent fission, migrated to a BB approach. In that process, it helped to have stuff published *along the way* as something to point to.

Allison: NETBLT didn't have a vendor associated with it.
Great concern over setting a precedent.

Bradner: Want to get sense of the room.
For non-WG docs, the IESG asks for advice from WG to make sure it's not an end-run around the process.
[Asks for show of hands on the possibilities:]
(i) AD's advise IESG that this doc should not be published at this time. [a few hands]
(ii) Publish as Experimental with "standard" notice, and pointer to WG activities in this space. [Some hands, significantly more than for the first possibility.]
(iii) AD's recommend against publishing *any* RFC's in this area unless they meet the 2357 criteria, because it is so dangerous. [~0 hands]

3. Possible RMT BB: Transport Session Management -- Shin-Gak Kang
Section 3 of RFC3048 mentions session management. Do we need a separate session mgmt BB?
Scope and direction -- provide framework & mechanisms.
membership notification and management
group membership tracking
troublemaker ejection
...
Plan -- refine the TSM document
-- consider functions that are duplicated in the TRACK BB
-- Completion of other required functions to be separate TSM BB

Discussion of necessity of separate BB ---

Handley: Apps may want this, and they may not. Some interesting and good stuff here. Maybe this is an application building block, not transport.
[Kang: TRACK already has some similar functionality.]
TRACK's the only one that seems to require this kind of thing -- NORM doesn't. This feels more like a little shim protocol than a BB.

Miriam: [...I missed this]

Handley: This seems like a good thing for the group to adopt, it just doesn't look like a BB.

Several folks: Access control, policy implementation is more application level. Statistics gathering, monitoring is more transport.

Roger: sense is that this is not a WG item, but it's good stuff and needs to find a home somewhere.

4. Proposal for promoting congestion control BBs to RFC -- Lorenzo
Two docs:
- Brian Whetten's "proposal for reliable multicast cc requirements" (May '99) [Brian: dissertation is a better doc]
- "More thoughts on reference simulations for RM CC schemes"
This proposal:
- Single requirements document after discussion on the list
- Go for Experimental RFC as first step
- Resubmit for stds track after med/large scale deployment demonstrates safety of the algorithm

Discussion:
Handley: the 2 docs are very different. Simulations document is *not* intended as a checklist. It's really a recommendation to designers, so they will run simulations, publish results, and talk to people. They are intended as recommendations for input to the group,needed for consensus.

Lorenzo; continue discussion on the list.

Slides

Agenda
'draft-ietf-rmt-bb-tree-config-02' & 'draft-ietf-rmt-bb-track-01'