NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-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: majordomo@listserv.lbl.gov
In Body: subscribe rmt
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
· Generic Router Assist (GRA) Building Block Motivation and Architecture
No Request For Comments
Thursday, November 11 at 1300-1500
CHAIRS:
- Allison Mankin mankin@isi.edu
- Roger Kermode Roger.Kermode@motorola.com
- Lorenzo Vicisano lorenzo@cisco.com
Notes taken by Sally Floyd and Alliso Mankin.
Minutes reported by the WG chairs.
Meeting Agenda
Agenda Bashing: |
Roger Kermode |
BB & DS Drafts Update: |
Roger Kermode |
Guidelines Draft (NEW): |
Allison Mankin |
Congestion Control Update: |
Mark Handley |
Generic Router Assist: |
Tony Speakman |
Protocol 1 - NACK: |
Joe Macker |
Protocol 2 - TRACK: |
Brian Whetten |
Protocol 3 - Open Loop: |
Mike Luby |
Security Requirements: |
Thomas Hardjono |
Recharter/Discussion/Next Steps: |
Roger Kermode |
General Remarks
- Volunteers to work on any/all drafts are sought. The WG chairs are compiling a list of people interested that will be circulated in the WG mailing list.
- As a result of the WG meeting discussion, a revision to the list of building block is needed (probably need extension). This issue will be discussed in a meeting to be held in between this and next IETF.
Meeting Minutes
The content of the viewgraphs presented is not fully reported in this notes. Please refer to the presentation material for this.
Guidelines Draft
This draft is being put together by the Working Group co-chairs.
Besides the issues established initially, this draft should also discuss requirement/applicability statement for Protocol Instantiation. Protocol instantiation drafts should explicitly state how the protocol being specified meets the guidelines requirements.
Congestion Control Update
No viewgraphs available.
The IRTF RMRG has a good handle on equation-based congestion control for unicast. The multicast variant has not been developed as far as expected. A guess on time-scales are that a draft on sender-based multicast congestion control will be moved from RMRG to RMT in about six months. The above applies to sender-based congestion control with single data rate.
Sender-based and receiver-based congestion control will be covered in separate drafts.
Generic Router Assist
This constitutes one of the building blocks. The architectural design draft is available: draft-ieft-rmt-gra-arch-00.txt .
The router task is to assist in functions that can also be accomplished without their presence (albeit less efficiently). It is lightweighted and it is not active networking.
Open issues are: mechanism for splicing GRA signals into transport protocols (cannot go in network layer but should be transport-independent).
The authors of the draft solicit input from protocol designers to select the "support functions" implemented in routers. Operators that manipulate packets will be limited in number (~ 10) and not combinable.
Building Blocks for NACK-Only RM (NORM)
This presentation is intended to stimulate a discussion on building blocks for NACK-bases protocols by presenting a prototyped instantiation of NACK-based protocol (MDP).
Assumption:
- do not assume GRA, but be able to use it, if it is present.
- support loosely controlled groups
- Request for retransmission (NACK) should be based on the type/content of the transfer. (e.g. discrete objects vs. continuous stream).
- NACK suppression and other needed functionalities should not make assumptions on the underling multicast network service. These should be able to work in presence of asymmetry introduced by the current variety of routing protocol (source-based tree, shred tree, bidirectional tree, single source model). They should also work without multicast back-channel.
>From the discussion after the presentation it appears that there are more 'small' building blocks that can be extracted from the NACK protocol instantiation than the ones initially foreseen (e.g. source/session identification).
TRACK protocol instantiation
Brian Whetten solicited people interested in working on TRACK to help. The most important open issues seem to be: tree building and scalability of server-based support (e.g. in the middle of the network). Other issues belong to building blocks (e.g. congestion control and security).
The presentation was based on the assumption that most of the protocol functionalities were provided by the protocol instantiation an not by building blocks. These included ACK and NACK machinery, tree building/maintenance and session management. In the following discussion it was raised the issue on why these cannot be provided by building blocks (the same used for the NACK protocol). It seem that efforts should be made to use building blocks as far as possible.
Open Loop Protocol
The presentation was opened with the issue of agreeing on a new name for this class of protocol. Mike Luby proposed ALC (Asynchronous Layered Coding).
Two main open issues were raised for this class of protocol: specification of the session parameters (mainly FEC encoding) and congestion control. As for the former, a possible approach is using out-of-band information that apply to the session (need in-band session identification, common with the other classes). The congestion control issue will be approached along the line of RLC (layered CC by Vicisano, Rizzo, Crowcroft) after addressing the issues that are left open in this proposal.
Security Requirement
This point needs to be addressed in a more coordinated way at the next meeting (or at the pre-IETF meeting). In particular it should be made a clear distinction between the two issues:
a) Security requirement for RM protocols
b) Security building blocks
Where the first is a pre-requisite for RM protocols, aimed at protecting the network from malicious attack through security holes opened by the presence of RM protocols. The second is a optional component of RM protocols that provide additional service to the application (Data protection, authentication ...).
From the meeting discussion it seems that addressing a) with the available security techniques can pose unacceptable scalability limitation on RM protocols. Alternatively this issues could be addressed in the context of congestion control (e.g. by making sure that all the multicast traffic is accounted in the share assigned to the session by its congestion control component).
Next Meeting
It is likely that an interim meeting will be held in mid-Februrary on the west-coast of the USA. One possible date would be February 10th immediately after the IP Multicast Summit.
Reliable Multicast Transport Working Group Agenda
TRACK Protocol Overview
Asynchronous Layered Coding
RM Security and SM Reliability