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.