NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 15-Jun-99
Chair(s):
Allison Mankin <mankin@east.isi.edu>
Roger Kermode <ark008@email.mot.com>
Lorenzo Vicisano <lorenzo@cisco.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>
Transport Area Advisor:
Vern Paxson <vern@aciri.org>
Mailing Lists:
General Discussion:rmt@lbl.gov
To Subscribe: rmt-request@lbl.gov
In Body: Subject must be subscribe
Archive: Send msg to rmt-request@lbl.gov w/Subject of archive help
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 standardize more than one protocol.
The first work item for this working group will be to write a rationale document that outlines the space in which the one-to-many transport protocols will be developed. This document will explain the requirements that lead to the development of different mechanisms (even though these mechanisms may have broader applicability than just addressing those requirements).
The second work item for this working group will be a functional decomposition document that defines a set of easily-separable coarse-grained functional blocks, and possibly some coarse-grained protocol "cores". Both the functional blocks and cores will be derived from the experience that has already gained with a number of advanced existing proposed solutions.
Once these two drafts are completed, this working group will examine the success of these efforts and develop a strategy for developing particular protocols. Once a strategy is agreed upon, the working group will recharter to continue the standardization of specific functional blocks and protocol cores.
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 standardize reliable multicast for additional scenarios beyond the one-to-many transport of bulk data once they are sufficiently well understood.
Goals and Milestones:
May 99 |
|
Working Group chartered |
Jun 99 |
|
Submit Internet-Drafts on rationale and functional block |
Jul 99 |
|
Meet at IETF in Oslo |
Aug 99 |
|
Revise drafts for submission as Informational RFCs |
Aug 99 |
|
Recharter Working Group in light of analysis of functional decomposition. |
Internet-Drafts:
· Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer
· The Reliable Multicast Design Space for Bulk Data Transfer
No Request For Comments
Reliable Multicast Transport WG
Minutes from the 45th IETF Meeting Oslo
Time: Thursday July 15th, 0900 - 1130
Minutes Taken by Colin Perkins
Edited by:
- Roger Kermode
- Allison Mankin
- Lorenzo Vicisano
Intro
Presenter: Roger Kermode
History... how we spun off from RMT, relation to SMuG,
how we settled on the building block approach
Design Space
Presenter: Mark Handley
- Brief summary of draft-ietf-rmt-design-space-00.txt
- Aiming to get the standardization of the sender controlled single group approach by the end of this year. Thinks this is reasonably well understood.
- Jon Crowcroft: Multiple rate congestion control is important and there has been research work on this (e.g. layered approach).
- Mark Handley: a problem is that multicast leave latency cannot be characterized.
- Jon Crowcroft: input into the network layer people doing multicast would be useful.... to deal with limitations on number of groups, igmp churn, etc, we should push back to idmr, pim, mboned, etc Maybe we need an "mboned considerations" section in each draft?
- Greg M: Receiver controlled single group is a nice backup security mechanism for the entire net... but there is a problem with congestion still, lack of goodput
- Jon: use of unicast as part of RM protocols? do we have to consider hybrids?
Discussion
- language tweaks - MUST vs SHOULD
- Too much emphasis on the tie between congestion control and reliability
- Mike Luby; if we're doing a building blocks approach, the two should be different building blocks and worrying about how the implementation of one affects the other seems a little odd
- Mark Handley: agree that they're orthogonal from a design space point of view, and that the feedback that would be used for one does not necessarily work for the other. Need to reword the draft, to make this clear
- Cite additional work - we know this is just a first attempt, and are not trying t give a complete history of RM research
- why are intermittent data flows not being considered? because we don't know how to do congestion control. although they're not explicitly excluded
- Tony Speakman: draft is good intent, and good for newcomers. But is important to indicate tradeoffs between all the approaches, it currently ignores the tradeoffs of some mechanisms and goes into more detail on others. Attempts to lead rather than create discussion right now
- Speakman - clarify jargon, to expose the tradeoffs more
- Luby - a good start, but may wish to categorize by functionality rather than by mechanisms?
- Kermode - need to describe how things fit together to do specific things, rather than jut listing ways of doing things?
- Jon - point of info: this is not a conference, we do standards work, we don't have to provide complete academic peer review style citation for our work.....
- Mankin - remember that RMRG was chartered by an IETF process to provide input into the IETF. People should give feedback if they think we're going too much into research here....
- Speakman - concern over the use of continuous flows with active services??? transitory bottleneck vs generally slow receiver?
- Mark - but this is to make congestion control work.....
- Speakman - wants it highlighted that the requirement for continuous long lived flows is because of the specific congestion control mechanisms we understand
Building Blocks
Presenters: Brian Whetton/Lorenzo Vicisano summary of the building blocks document...
Discussion:
- Lorenzo - agree with Jon that providing requirements input into, for example, multicast routing groups, is very important.
- Carsten - confused by the two documents, they seem to be competing on who gets to define the requirements, and are not entirely consistent. Do we need an additional requirements document?
- Whetton - clearly not complete drafts.....
- Carsten - need a clear idea of how the two drafts work together
- GregM - procedural: might be a good idea to have the building blocks not totally specified, but be specific about what they're not being specific about. Building block frameworks????
- Lorenzo - draft on guidelines for building block writers??
- Greg - packet propagation time? rough concept on who/what the membership is? might be nice for building blocks....
- Luby - "bulk data xfer" is not well defined yet.... define the problem to be solved and the requirements better
- Luby - clarify between functional components and mechanisms for doing something. wants a graph showing how they fit together
- Luby - has most problem with reliability - "goodput" vs "reporting reception" is unclear... doesn't show how some components fit together to produce good protocols, when individually they don't work well
- Speakman - peal acks apart into "reception report notification" (application level ACKs) and transport layer acks for congestion control. we're currently confused about these two, since they are different things
- acks for reliability vs acks for congestion control
- whetten - conceptually agree, but in an implementation/mechanism point of view he's not so sure.....
- whetten - application vs transport level reliability. Putting the app level reliability semantics into the transport is controversial
- speakman - no reason why the return path for acks used for congestion control is organized in the same way as that for receiver reports
- speakman - app semantics are provided by an app level protocol, which uses the transport layer protocol. The transport layer protocol doesn't need to know application level details....
- ????? - in the building blocks diagram, hopes we're not settling on RMTP-II as our HACK protocol
- ????? - wants to make sure we don't settle only on TFMCC as out congestion control scheme
- Cabo - app vs transport ack. noone cares if the transport got the data across, they care if the app gets the data, so app level reporting is the only useful sort
- cabo - does the transport have a means of getting receiver report info back to the sender?
- jon - disagree - the app can specify what it means when the transport has delivered the data, but the transport shouldn't have app semantics - this is what reliable unicast does.....
- luby - curious about why the different protocols are here? are we defining different service models or different ways of implementing a service? does each protocol implement a single service model?
- ????? - maybe we need some indication of which building blocks exist but we're not considering here?
- speakman - procedure - we've been caring that congestion control works, what constraints does this place on the design space? Do we understand this, and how different congestion control schemes which may be developed in future, may influence this?
- lorenzo - doesn't think it restricts the design space, TFMCC is only one way of doing the CC building block, should leave the design open to additional CC schemes.
- jon - but be careful of bias towards particular solutions which may constrain future designs. chairs seem to be biased towards TFMCC at the expense of others....
- speakman - session management, tree building, and group membership maybe shouldn't be standardized?
- mankin - will discuss which blocks are to be standardized later....
- canetti - three security concerns: authentication of source/data, confidentiality/access control, protection from denial of service. The first two can be considered out of scope of this group and dealt with by smug, but the last is vital for RMT
- sally - talking back to speakman - many of tony's concerns for building blocks are for things we're not trying to make building blocks, just things we consider as protocol components...
- jon - security - push back to smug about traitor tracing?
- speakman - think he was disagreeing with canetti about what's in scope...
- canetti - key management needs reliable multicast, so RMT relying on SMUG for key distrib which is relying on RMT for reliability.....
- jon - traitor tracing is not the same as authentication! the security associations are different....
- canetti - maybe control of group membership is a security issue rather than a reliability issue, and should be done in smug?
Discussion of rechartering
Facilitator: Roger Kermode
aims of todays discussion
- obtain feedback on drafts
- is there consensus to move the drafts forward? not quite - will take to the list...
- if the technical details for voluminous we'll go to the list, especially for the building blocks draft
Comments:
- jon - be explicit in your bias - right now the chairs are leading the direction, and some don't agree with their categorization of the problem space...
- handley - not convinced that the open loop congestion control has been proved safe yet...
- speakman - need to specify what we mean by "the big I internet", what network characteristics does this mean?
- luby - patents of FEC work...... fun fun fun....how do we work with IPR?
- Vern - up to the working group to decide how to deal with protocols which are covered by IPR
- jon - watercast patent, which is very similar to Luby's patents...
- vern - presumption that people active in the working group disclose relevant IPR
- handley - if we have two functionally equivalent schemes, one covered by a patent, we should choose the others.....
- speakman - no patent on PGM, yeah!
- speakman - should separate building blocks and instantiations into subgroups when rechartering
- handley - clarify what is meant by subgroups?
- kermode - design teams! Which building blocks?
- handley- nack reliability block should be able to cope with fec to do the repair, even though it's a separate block from the fec. The key point in the nack block is the suppression mechanism
- luby - again, confusing building blocks with functional areas. We nack building block can be used for different functions
- whetten - disagree, the building blocks are mechanisms rather than protocol components
- speakman - common headers is the agenda of the generic router work...take this to the list
Summary/Actions
The design space and building block drafts were presented with each garnering lively discussion. The general consensus of those present was that both drafts were reasonable first attempts, with the design space draft being closer to completion than the building blocks draft. The authors of the drafts concurred with this views and were encouraged to revise the drafts to reflect the feedback provided via email and during the meeting for re-submission in 6 to 8 weeks time. In recognition of some of the confusion as to how building blocks and protocol instances drafts should be written, the chairs of the group agreed to write an additional draft to act as a guideline to would be authors of building block and protocol instances documents. It is intended that this draft should also be ready in a similar timeframe to the revised design space and building block drafts. The chairs also agreed to work with the Area Directors on rechartering so that the members of the WG could write building block drafts for presentation at the next IETF meeting in Washington in November.