From Majordomo@lbl.gov Fri Oct 19 09:51:35 2001 Date: Fri, 19 Oct 2001 06:45:37 -0700 (PDT) From: Majordomo@lbl.gov To: sweilnau@ietf.org Subject: Majordomo file: list 'rmt' file 'archive' -- >From se@tellique.de Sat Mar 20 07:42:05 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id HAA01641 for ; Sat, 20 Mar 1999 07:42:04 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id HAA17912 for ; Sat, 20 Mar 1999 07:42:04 -0800 (PST) Received: from mail.tellique.de (big-gw.tellique.de [195.126.133.179]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id HAA17907 for ; Sat, 20 Mar 1999 07:42:02 -0800 (PST) Received: from tellique.de (marc.tellique.de [62.144.106.59]) by mail.tellique.de (8.8.7/8.8.8) with ESMTP id QAA09255 for ; Sat, 20 Mar 1999 16:41:54 +0100 Message-ID: <36F3C1A1.4693E0E3@tellique.de> Date: Sat, 20 Mar 1999 16:41:21 +0100 From: Nils Seifert Organization: Tellique GmbH X-Mailer: Mozilla 4.07 [en] (Win98; I) MIME-Version: 1.0 To: rmt@lbl.gov Subject: subcribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- Gruesse, Nils Seifert -- Nils Seifert / se@tellique.de Tellique Kommunikationstechnik GmbH Berlin / http://www.tellique.de Gustav-Meyer-Allee 25, D-13355 Berlin (Germany) Tel. +49.30.463 07-551 /Fax. +49.30.463 07-579 /Funk: +49.172.8850112 >From luigi@labinfo.iet.unipi.it Thu Apr 1 09:36:15 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id JAA23546 for ; Thu, 1 Apr 1999 09:36:14 -0800 (PST) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id JAA16273 for ; Thu, 1 Apr 1999 09:36:13 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by SpamWall.lbl.gov (8.9.0/8.9.0) with SMTP id JAA16233 for ; Thu, 1 Apr 1999 09:36:10 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id RAA16107; Thu, 1 Apr 1999 17:15:48 +0200 From: Luigi Rizzo Message-Id: <199904011515.RAA16107@labinfo.iet.unipi.it> Subject: CfP: First Intl Workshop on Networked Group Communication To: rmt@lbl.gov Date: Thu, 1 Apr 1999 17:15:48 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Dear RMT'ers, Just a short note to announce the Call for Papers for an event sponsored by COST264 and fully dedicated to Networked Group Communicaton: First International Workshop on Networked Group Communication Pisa, November 17-20, 1999 http://www.iet.unipi.it/~luigi/ngc99/ At the above URL you can get the complete CfP and related information. A textual version is attached below. Please disseminate this as you feel appropriate, and the usual apologies for duplicates. Cheers Luigi -----------------------------------+------------------------------------- Luigi RIZZO . EMAIL: luigi@iet.unipi.it . Dip. di Ing. dell'Informazione HTTP://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) -----------------------------------+------------------------------------- FIRST INTERNATIONAL WORKSHOP ON NETWORKED GROUP COMMUNICATION Sponsored by COST 264 Pisa, November 17-20, 1999 http://www.iet.unipi.it/~luigi/ngc99/ CALL FOR PAPERS The aim of the Workshop is to allow researchers and practioners to present the design and implementation techniques for networked group communication. The focus of the workshop is strictly on multicast and networked group communication, and this workshop is the first and only internationational event in this area. To be considered for acceptance, contribution should clearly demonstrate the peculiarity of the solutions proposed in relation to the presence of multiple communicating parties. Original research papers are solicited for topics related to the architecture and deployment of multicast services, including but not limited to: * multicast congestion control * multicast routing, naming, address allocation * scalability in multicast services * reliable and semi-reliable multicast protocols * novel multicast architectures * multicast over heterogeneous media * multipeer applications (distributed interactive applications, games, DIS) * QoS issues with multicast * Pricing and economic model for multicast traffic * group management techniques * network engineering for multicast services The Proceedings of the Workshop will be published by a major publisher and will be available for participants at the Workshop. The workshop will start with one day of tutorials on aspects of the IP multicast architecture, held by key researchers in the area, followed by two days presentations and invited talks, and a one-day COST264 Management Committee Meeting. IMPORTANT DATES Paper submission deadline: July 1st, 1999 Notification of acceptance: September 15, 1999 Camera Ready Due: September 30, 1999 Tutorials: November 17, 1999 Conference: November 18-19, 1999 SUBMISSION INFORMATION Only full paper submissions will be accepted, not exceeding 20 pages double spaced. Overlenght papers will not be reviewed and immediately returned to their authors. Papers must be submitted by electronic means only, in Postscript or PDF format. Make sure that your paper can be properly printed with Ghostscript. The email address will be announced, and become active, one month before the conference. CONTACT ADDRESS For more information on the Workshop, contact luigi@iet.unipi.it PROGRAM CHAIRS Luigi Rizzo luigi@iet.unipi.it Serge Fdida sf@lip6.fr PROGRAM COMMITTEE (preliminary) Kevin C. Almeroth, USCB Mostafa Ammar, GeorgiaTech Ernst Biersack, EURECOM Jon Crowcroft, University College London Andre Danthine, U.Liege Christophe Diot, SPRINT Wolfgang Effelsberg, Uni.Mannheim Serge Fdida, LIP6 Domenico Ferrari, CRATOS JJ Garcia-Luna, UC Santa Cruz Jim Gemmel, Microsoft Mark Handley, ACIRI Marcus Hofman, BELL LABS David Hutchison, Lancaster University Jim Kurose, UMass Luciano Lenzini, Univ.Pisa Helmut Leopold, Telekom AT Allison Mankin, ISI Jorg Nonnenmacher, Bell Labs Radia Perlman, SUN Jean-Jacques Quisquater, UCL (BE) Luigi Rizzo, Univ. Pisa Burkhard Stiller, ETH Zurich Don Towsley, UMass Giorgio Ventre, Univ.Napoli Brian Whetten, Talarian Corporation >From vern@daffy.ee.lbl.gov Tue Apr 13 20:32:31 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id UAA21672 for ; Tue, 13 Apr 1999 20:32:30 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id UAA16172 for ; Tue, 13 Apr 1999 20:32:30 -0700 (PDT) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id UAA16168 for ; Tue, 13 Apr 1999 20:32:29 -0700 (PDT) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.2/8.9.2) id UAA10818; Tue, 13 Apr 1999 20:32:29 -0700 (PDT) Message-Id: <199904140332.UAA10818@daffy.ee.lbl.gov> To: rmt@lbl.gov Subject: Fwd: WG Review: Reliable Multicast Transport (rmt) Date: Tue, 13 Apr 1999 20:32:29 PDT From: Vern Paxson ------- Forwarded Message Date: Mon, 12 Apr 1999 10:40:26 -0400 From: The IESG Subject: WG Review: Reliable Multicast Transport (rmt) To: IETF-Announce: ; Cc: new-work@ietf.org, maddogs@ietf.org reply-to: iesg@ietf.org Sender: scoya@ns.cnri.reston.va.us Status: U A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination as yet. The following Description was submitted, and is provided for informational purposes only: Reliable Multicast Transport (rmt) - ---------------------------------- 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. ------- End of Forwarded Message >From floyd@elk.aciri.org Mon Apr 19 16:59:10 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id QAA17555 for ; Mon, 19 Apr 1999 16:59:09 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id QAA00366 for ; Mon, 19 Apr 1999 16:59:09 -0700 (PDT) Received: from elk.aciri.org ([192.150.187.21]) by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id QAA00355 for ; Mon, 19 Apr 1999 16:59:08 -0700 (PDT) Received: from elk.aciri.org (localhost [127.0.0.1]) by elk.aciri.org (8.9.2/8.9.2) with ESMTP id QAA89860 for ; Mon, 19 Apr 1999 16:58:45 -0700 (PDT) (envelope-from floyd@elk.aciri.org) Message-Id: <199904192358.QAA89860@elk.aciri.org> To: rmt@lbl.gov From: Sally Floyd Subject: first draft of notes from the Reliable Multicast Transport BOF Date: Mon, 19 Apr 1999 16:58:45 -0700 Sender: floyd@elk.aciri.org Here is the first draft of the notes from the Reliable Multicast Transport BOF. (Yes, a little late...) Corrections could be sent to me, or to the list. - Sally ----------------------------------------------------- Reliable Multicast Transport BOF, Monday March 15, Minneapolis IETF. Notetaker: Sally Floyd Intro: Vern Paxson The goal of this meeting is not to standardize reliable multicast in this meeting, but to discuss strategies for standardizing reliable multicast. The Area Directors are very much in favor of setting up one Working Group for this. This BOF will explore two fundamental strategies for standardizing reliable multicast: One approach, the building-block approach, is to standardize modules or building blocks. The other approach, the whole-protocol approach, is to standardize whole protocols. The other issue for this BOF to explore is what a charter for an RMT working group would look like. Agenda-bashing: Standardizing Reliable Multicast: Mark Handley Viewgraphs: http://www.aciri.org/mjh/rmbof.ps http://www.aciri.org/mjh/rmbof.mgp (Magicpoint source files) The Building Block Approach to RM Standardization: Mark Handley Viewgraphs: http://www.aciri.org/mjh/bb.ps http://www.aciri.org/mjh/bb.mgp (Magicpoint source files) Discussion: How is FEC with the layered approach different from FEC with the other three approaches (tree/ack-based, nack-based, nack-based with network support). Past history in the IETF of standardizing building blocks? MMusic, IP telephony both have done this. How would the building-block approach work? What are the performance costs of doing the building-block approach? Building blocks for mostly-reliable protocols? Mark: I don't think that they need to be a separate class. Ohta disagrees. Ohta: We should not begin standardization until congestion control is nailed down. Michael Speer: RTP is a good example of the building block approach successfully applied in the past. A concern about permutations of building blocks. What happens first, the building blocks are defined and protocols are standardized on top, or protocols are standardized while building blocks are being standardized in parallel? Mark: this is a hard process to manage. Tony S: Perhaps the right granularity for the building block approach is at the functional level. Mark: Superficially it seems that packet formats are not necessary to standardize, but when you look at FEC, you see that it might be useful to standardized packet formats also. Allison: The people who develop the protocols perhaps should write the building blocks that are useful to them. The whole-propocol approach: Starburst: Ken Miller absent, due to airport problems, so Brian Whetten is presenting his slides. Viewgraphs: http://www.aciri.org/RMT/RM-Miller.pdf http://www.aciri.org/RMT/RM-Miller.ps RMTP-II: Brian Whetten Viewgraphs: http://www.talarian.com/rmtp-ii/IETF%20RM%20BOF%20-%20March%201999.ppt RMTP-II: http://www.talarian.com/rmtp-ii/overview.htm Vern: The argument for the building-block approach is not short-term payoff but that of long-term payoff, so I don't understand why you say that the building block approach will save time in the short-term. Abel: It is premature to say that we need to standardize four separate protocols; that will confuse the market. Vern: You don't buy Mark's argument that RM is fundamentally different than TCP, and that one size doesn't fit all? Roger: I believe that you can't have a one-size-fits-all protocol. Multiple working groups for the different protocols will loose the commonality. TCP evolved from a field of many unicast reliable protocols. People could call their current protocols version 1, and let the building-block-based approach be version 2. Mark: Only a few of the protocols can be deployed in the big-I Internet today, and other protocols are the ones that are most in demand in Intranets, where there is router or server support. Jon C.: I see RMTP and SRM as fully-fledged protocols, but I see PGM as a protocol piece with router support. One reason that TCP worked was that we had at least three versions of source code. ?: There is customer demand for reliable multicast in the global Internet now. Please do not slow down the development of RMTP-II and PGM. Dino: Is the new working group going to work on interworking between the reliable multicast protocols? PGM: Tony Speakman Viewgraphs: ftp://ftpeng.cisco.com/speakman/bof.slides.ps Tony: To address the building-block vs. whole-protocol approach: There could be functional building blocks, or at the other end of the spectrum, specific mechanics of what to do in routers. I am a fan of the building-block approach to protocols, but there is a software engineering challenge that is nontrivial. Tony: The activity of delivering and deploying these protocols in constrained circumstances is essential in determining what the building blocks should be. You certainly don't want to create building blocks that are not useful. Vern: Is sounds like you are saying that you like the building block approach, but we don't know the right building blocks yet. Tony: I think we need to start with per-protocol working groups. If we can get an API right for applications, then applications at least can go ahead. Tony: We need to provide deployable instances of reliable multicast to push things along (to enable applications, to enable multicast routing, to enable more reliable multicast). Tony: Yes, eventually we need to break out the building blocks. ?: Maybe we can have working groups directed at application-specific spaces. Does it make sense to decouple congestion control from reliability? If we agree on that, does that influence the way that we want to structure the working group? Tony: There are service models underlying ACK-based and NACK-based approaches. Jon C: The internet has a habit of being heterogeneous. Does this work involve changes to IP Multicast? These long-term issues might come out of the working groups. Michael Speer: I am all for experience. We have to figure out how to punch four protocols through a protocol. Roger: I think that we really need to have this experience shared in a single group. Aaron: I am reminded by the discussion that we have been having on the PILC list, of the siren call of the market trying to push things through as quickly as possible. The methodology of building blocks doesn't sound baked. My proposal is to come up with classifications of topologies. ?: I don't know if we know enough yet to know exactly what the building blocks are. If we get the source code for these protocols, why do we need to formalize the building block approach. Maybe you get the building blocks as you develop it. ?: Why are we restricing ourselves to one-to-many? Many-to-many is still very important. Scott B.: He wants to hear from people what they think the importance is of the differences between Internets and Intranets. Vern: We will summarize to the RM mailing list. We haven't decided whether to establish a separate mailing list. >From vern@daffy.ee.lbl.gov Wed Apr 28 23:22:17 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id XAA17054 for ; Wed, 28 Apr 1999 23:22:17 -0700 (PDT) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id XAA09683 for ; Wed, 28 Apr 1999 23:22:16 -0700 (PDT) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.2/8.9.2) id XAA07986; Wed, 28 Apr 1999 23:22:16 -0700 (PDT) Message-Id: <199904290622.XAA07986@daffy.ee.lbl.gov> To: rmt@lbl.gov Subject: Fwd: WG ACTION: Reliable Multicast Transport (rmt) Date: Wed, 28 Apr 1999 23:22:16 PDT From: Vern Paxson ------- Forwarded Message Date: Wed, 28 Apr 1999 16:20:42 -0400 From: The IESG Subject: WG ACTION: Reliable Multicast Transport (rmt) To: IETF-Announce: ; Cc: new-work@ietf.org Sender: scoya@ns.cnri.reston.va.us Status: U A new working group has been formed in the Transport Area of the IETF. Please contact the chair or Area Directors for additional information. Reliable Multicast Transport (rmt) - ---------------------------------- Current Status: Active Working Group Chair(s): Allison Mankin Roger Kermode Lorenzo Vicisano Transport Area Director(s): Scott Bradner Vern Paxson Transport Area Advisor: Vern Paxson Mailing Lists: General Discussion:rmt@lbl.gov To Subscribe: rmt-request@lbl.gov In Body: Subject 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. ------- End of Forwarded Message >From chiu@bridge.East.Sun.COM Thu Apr 29 08:19:14 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id IAA18568 for ; Thu, 29 Apr 1999 08:19:14 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA26883 for ; Thu, 29 Apr 1999 08:19:13 -0700 (PDT) Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA14181 for ; Thu, 29 Apr 1999 08:19:10 -0700 (PDT) Received: from bridge.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id LAA06288; Thu, 29 Apr 1999 11:19:03 -0400 Received: from bridge (bridge [129.148.75.125]) by bridge.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id LAA16925 for ; Thu, 29 Apr 1999 11:18:59 -0400 (EDT) Message-Id: <199904291518.LAA16925@bridge.East.Sun.COM> Date: Thu, 29 Apr 1999 11:18:59 -0400 (EDT) From: Dah Ming Chiu - Sun Microsystems Reply-To: Dah Ming Chiu - Sun Microsystems Subject: RE: Fwd: WG ACTION: Reliable Multicast Transport (rmt) To: rmt@lbl.gov MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: o4LB+qnOS69peIqVLXmEdw== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc testing the new distribution list... >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). There are a couple of rather orthognal application requirements for a "one-to-many transport of large amounts of data". I will call them "file transfer" and "publish and subscribe" below. 1) File transfer All data is available at the beginning of the session. The performance metric is time to transfer the whole file to the whole multicast group (however you care to define what the group is). 2) Publish and Subscribe Data arrive bits and pieces during the session. The performance metric is the time it takes to get each piece to the whole group. Each bit and piece may not be very big. The repair and flow/congestion control algorithms can be quite different for the two cases. On the other hand, a single protocol can probably be designed to handle both of these extremes reasonably well. >From dykim@ccl.chungnam.ac.kr Wed May 12 18:19:48 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id SAA27417 for ; Wed, 12 May 1999 18:19:47 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA29521 for ; Wed, 12 May 1999 18:19:46 -0700 (PDT) Received: from ccl.chungnam.ac.kr (ccl.chungnam.ac.kr [168.188.48.128]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA29509 for ; Wed, 12 May 1999 18:19:43 -0700 (PDT) Received: from ccl.chungnam.ac.kr (ghil.chungnam.ac.kr [168.188.48.2]) by ccl.chungnam.ac.kr (8.9.0/8.9.0) with ESMTP id LAA15215; Thu, 13 May 1999 11:17:21 +1000 (KDT) Message-ID: <373A283B.BB789A41@ccl.chungnam.ac.kr> Date: Thu, 13 May 1999 10:17:47 +0900 From: Dae Young KIM Organization: Chungnam Nat'l Univ., InfoCom Eng. Dept. X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt , rm Subject: taxonomy Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Dear all, Obeserving the mails on rm/rmt, I find people would like to differentiate among different topological multicast contexts by calling them 'one-to-many' or 'many-to-many'. One way of differentiating among these different multicast context would be use terms like: Simplex Multicast (SM) Duplex Multicast (DM) N-plex Multicast (NM) Simplex Multicast is a one-to-many multicast wherein there are one sender and many receivers; one send-only user with multiple receive-only users. Duplex Multicast is a one-with-many multicast wherein all are send and receive members but whereas the data from the central (master) reach every other member, data from each of the rest flow only to the master. N-plex Multicast is the one wherein all are send- and receive-capable and data from any member reach all the other members. Here, only the main data flow is used as a criteria for classification. For example, backward controls (e.g., ACKs) can be sent also in Simplex Multicast. If people would agree to do so, we can use these simpler wordings than have to say every time 'one-to-many', 'many-to-many', ect. -- Dae Young http://ccl.chungnam.ac.kr/~dykim/ *** Come to ICT'99 *** http://ict99.icu.ac.kr >From luigi@labinfo.iet.unipi.it Tue May 18 10:38:39 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id KAA24736 for ; Tue, 18 May 1999 10:38:39 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA13819 for ; Tue, 18 May 1999 10:38:38 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id KAA13808 for ; Tue, 18 May 1999 10:38:35 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id RAA01957; Tue, 18 May 1999 17:32:39 +0200 From: Luigi Rizzo Message-Id: <199905181532.RAA01957@labinfo.iet.unipi.it> Subject: RMRG meeting info. (fwd) To: rmt@lbl.gov Date: Tue, 18 May 1999 17:32:38 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text (sorry for the intrusion and the duplicate for those also subscribing to the irtf rmrg list...) Dear RM'ers, as the date for the RMRG meeting (5&6 june, Pisa) is approaching, i need to know how many people are coming in order to arrange things properly. The page with program and travel info is at http://www.iet.unipi.it/~luigi/rmrg/ There is no registration fee for the meeting, but if you are coming, would you mind reply to this email with the following data (for the name tags and participant list): NAME: EMAIL: COMPANY For those interested, I am organizing a dinner in Lucca on saturday night, but i am afraid i could only reserve some 40 seats at the restaurant (which could be enough, i just have no idea. If numbers are significantly higher, i will try to arrange something). The cost should be around 50.000 lire each. If you are interested, please mention this in the email (don't worry, you will have time to see Pisa as well; the town is small!) thanks luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ ==== First International Workshop on Networked Group Communication ==== -----------------------------------+------------------------------------- >From luigi@labinfo.iet.unipi.it Mon Jun 14 10:47:21 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id KAA10172 for ; Mon, 14 Jun 1999 10:47:20 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA27511 for ; Mon, 14 Jun 1999 10:47:19 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id KAA27478 for ; Mon, 14 Jun 1999 10:47:15 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id RAA09910; Mon, 14 Jun 1999 17:18:06 +0200 From: Luigi Rizzo Message-Id: <199906141518.RAA09910@labinfo.iet.unipi.it> Subject: CfP: First Intl. Workshop on Networked Group Communication To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Mon, 14 Jun 1999 17:18:05 +0200 (MET DST) In-Reply-To: <199904011510.RAA16046@labinfo.iet.unipi.it> from "Luigi Rizzo" at Apr 1, 99 05:09:56 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Just a brief reminder -- the deadline (July 1st) for submissions to the First International Workshop on Networked Group Communication (NGC99) http://www.iet.unipi.it/~luigi/ngc99/ is approaching. Please note that in addition to regular contributions we will also select a few "student contributions", authored by students only. See the online call for papers at the above URL for detailed info. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ ==== First International Workshop on Networked Group Communication ==== -----------------------------------+------------------------------------- >From ark008@email.mot.com Sun Jun 20 18:31:27 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id SAA02910 for ; Sun, 20 Jun 1999 18:31:27 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA01718 for ; Sun, 20 Jun 1999 18:31:26 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [129.188.136.102]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA01714 for ; Sun, 20 Jun 1999 18:31:25 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id UAA08202 for ; Sun, 20 Jun 1999 20:32:34 -0500 (CDT)] Received: [from superman.arc.corp.mot.com (superman.arc.corp.mot.com [217.1.10.18]) by pobox.mot.com (MOT-pobox 2.0) with SMTP id UAA05678 for ; Sun, 20 Jun 1999 20:31:18 -0500 (CDT)] Received: from email.mot.com ([217.1.10.230]) by superman.arc.corp.mot.com (8.6.12/8.6.12) with ESMTP id LAA05080 for ; Mon, 21 Jun 1999 11:30:20 +1000 Message-ID: <376D95EF.31125AA3@email.mot.com> Date: Mon, 21 Jun 1999 11:31:27 +1000 From: Roger Kermode Organization: Motorola X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt@lbl.gov Subject: RMT: Design Space and Building Blocks Internet Drafts now available Content-Type: multipart/mixed; boundary="------------7B71CA24ABEE300E086F0BEF" This is a multi-part message in MIME format. --------------7B71CA24ABEE300E086F0BEF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Everyone, We'd like to announce the availability of the two internet-drafts on the design-space and building-blocks for one-to-many bulk-data transfer as per the RMT WG charter. They will shortly appear on the ietf rfc-mirrors. Until then you can fetch them from http://www.aciri.org/rmt/ cheers, Allison, Roger, and Lorenzo --------------7B71CA24ABEE300E086F0BEF Content-Type: text/x-vcard; charset=us-ascii; name="ark008.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Roger Kermode Content-Disposition: attachment; filename="ark008.vcf" begin:vcard n:Kermode;Roger tel;fax:+61-2-9666-0501 tel;home:+61-2-9664-8335 tel;work:+61-2-9666-0558 x-mozilla-html:FALSE url:www.mot.com.au org:Motorola Australian Research Centre;Scalable Commodity Internet Lab version:2.1 email;internet:ark008@email.mot.com title:Principal Research Engineer adr;quoted-printable:;;Level 3,=0D=0A12 Lord St.;Botany;NSW;2019;Australia fn:Roger Kermode end:vcard --------------7B71CA24ABEE300E086F0BEF-- >From nsyracus@ns.cnri.reston.va.us Mon Jun 21 10:43:03 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id KAA04845 for ; Mon, 21 Jun 1999 10:43:03 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA12968 for ; Mon, 21 Jun 1999 10:43:02 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA12962 for ; Mon, 21 Jun 1999 10:43:00 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06590; Mon, 21 Jun 1999 13:42:26 -0400 (EDT) Message-Id: <199906211742.NAA06590@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rmt@lbl.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rmt-buildingblocks-00.txt Date: Mon, 21 Jun 1999 13:42:26 -0400 Sender: nsyracus@ns.cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Multicast Transport Working Group of the IETF. Title : Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer Author(s) : B. Whetten, L.Vicisano, R. Kermode, M. Handley, S.Floyd Filename : draft-ietf-rmt-buildingblocks-00.txt Pages : 19 Date : 18-Jun-99 This document describes a framework for the standardization of bulk-data reliable multicast transport. It builds upon the experience gained during the deployment of several classes of contemporary reliable multicast transport, and attempts to pull out the commonalties between these classes of protocols into a number of building blocks. To that end, this document recommends that certain components that are common to multiple protocol classes be standardized as 'building blocks.' The remaining parts of the protocols, consisting of highly protocol specific tightly intertwined functions shall be designated as 'protocol cores.' Thus, each protocol can then be constructed by merging a 'protocol core' with a number of 'building blocks' which can be re-used across multiple protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-buildingblocks-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rmt-buildingblocks-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmt-buildingblocks-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990618093419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-buildingblocks-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-buildingblocks-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990618093419.I-D@ietf.org> --OtherAccess-- --NextPart-- >From nsyracus@ns.cnri.reston.va.us Mon Jun 21 11:31:59 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id LAA05250 for ; Mon, 21 Jun 1999 11:31:58 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA29498 for ; Mon, 21 Jun 1999 11:31:57 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA29483 for ; Mon, 21 Jun 1999 11:31:56 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07374; Mon, 21 Jun 1999 14:31:23 -0400 (EDT) Message-Id: <199906211831.OAA07374@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rmt@lbl.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rmt-design-space-00.txt Date: Mon, 21 Jun 1999 14:31:23 -0400 Sender: nsyracus@ns.cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Multicast Transport Working Group of the IETF. Title : The Reliable Multicast Design Space for Bulk Data Transfer Author(s) : M. Handley, S. Floyd, B. Whetten, R. Kermode, L. Vicisano Filename : draft-ietf-rmt-design-space-00.txt Pages : 19 Date : 18-Jun-99 The design space for reliable multicast is rich, with many possible solutions having been devised. However, application requirements serve to constrain this design space to a relatively small solution space. This document provides an overview of the design space and the ways in which application constraints affect possible solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-design-space-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rmt-design-space-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmt-design-space-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990618111448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-design-space-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-design-space-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990618111448.I-D@ietf.org> --OtherAccess-- --NextPart-- >From hofmann@bell-labs.com Fri Jun 25 07:30:10 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id HAA25949 for ; Fri, 25 Jun 1999 07:30:09 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA06753 for ; Fri, 25 Jun 1999 07:30:08 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id HAA06740 for ; Fri, 25 Jun 1999 07:30:05 -0700 (PDT) Received: from chair.dnrc.bell-labs.com ([135.180.161.201]) by dirty; Fri Jun 25 10:29:17 EDT 1999 Received: from bell-labs.com (apache [135.180.160.86]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA09206; Fri, 25 Jun 1999 10:29:14 -0400 (EDT) Message-ID: <37739232.32295F6C@bell-labs.com> Date: Fri, 25 Jun 1999 10:29:06 -0400 From: Markus Hofmann Organization: Bell Labs / Lucent, USA X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en,de-DE MIME-Version: 1.0 To: rmt@lbl.gov, rm@mash.cs.berkeley.edu CC: Jonathan Rosenberg , Jorg Nonnenmacher , Markus Hofmann Subject: new draft on feedback for multicast Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, we have put together an Internet draft that talks about the problem of feedback for multicast. Its basically a taxonomy of the various mechanisms that can be applied for sending feedback on multicast reception. We believe this taxonomy is useful for both rmt (reliable multicast transport) and avt. For rmt, it outlines the options for a feedback building block, and for avt, options for an alternate profile for RTCP (which was discussed at the last meeting). The draft is an individual submission, and will appear in the archives shortly. Until then, you can pick up a copy at: http://www.cs.columbia.edu/~jdrosen/papers/draft-hnrs-rmt-avt-feedback-00.txt Comments welcome. Thanks, Markus >From luigi@labinfo.iet.unipi.it Tue Jun 29 04:17:12 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id EAA08273 for ; Tue, 29 Jun 1999 04:17:11 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA07959 for ; Tue, 29 Jun 1999 04:17:10 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id EAA07955 for ; Tue, 29 Jun 1999 04:17:08 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id KAA03568; Tue, 29 Jun 1999 10:34:16 +0200 From: Luigi Rizzo Message-Id: <199906290834.KAA03568@labinfo.iet.unipi.it> Subject: NGC99 Workshop -- New Submission Deadline 13 july 1999 !!! To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Tue, 29 Jun 1999 10:34:15 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text NGC99 Workshop -- New Submission Deadline 13 july 1999 !!! Dear All, as you all know the "Networking Paper Deadline Control Authority" has announced potential congestion for deadlines around the first week of july (read: INFOCOM2000 has moved its deadline to july 5th). As this might have an impact on the schedule of potential authors, and also in response to a huge number of requests for extensions, we have decided to move the deadline for submissions to NGC99 Workshop. >>> The NEW DEADLINE FOR SUBMISSIONS is 13 July 1999, 10am (GMT+2) <<< We hope that this move will minimize deadline conflicts with other multicast-related events and give authors the time they requested to work on their papers. Because we already had tight schedules for the review process, the switch of deadlines was not an easy decision. Thus we encourage potential authors to SUBMIT NOW a preliminary title+abstract for their papers so we can start mapping papers to the reviewers. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ ==== First International Workshop on Networked Group Communication ==== -----------------------------------+------------------------------------- >From luby@dfountain.com Wed Jun 30 13:01:09 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id NAA17625 for ; Wed, 30 Jun 1999 13:01:09 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA05435 for ; Wed, 30 Jun 1999 13:01:08 -0700 (PDT) Received: from monarch.dfountain.com ([207.90.190.130]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA05429 for ; Wed, 30 Jun 1999 13:01:07 -0700 (PDT) Received: by PACIFIC with Internet Mail Service (5.5.2448.0) id ; Wed, 30 Jun 1999 12:53:02 -0700 Message-ID: <619F2FB3840CD311AC2C0090273BF1AC017BC1@PACIFIC> From: Mike Luby To: "'rmt@lbl.gov'" Cc: Mike Luby Subject: Short version of comments on building blocks and design space dra fts Date: Wed, 30 Jun 1999 12:52:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" RMT mailing list: I have some proposals and comments on both the building blocks draft and the design space draft that I am including in the next two emails. I include below some preliminary motivation (the short version) for the primary proposal. The detailed comments on the two drafts explore the ramifications of this proposal and provide additional commentary as well. Mike Luby Digital Fountain and ICSI A BRIEF MOTIVATION FOR MY COMMENTS: One of the primary motivations for my writing the detailed comments on both the building blocks draft and the design space draft is to propose the separation of data reliability into two logical components, which I call the ensuring goodput component and the reporting reception component. Ensuring goodput is the component that makes sure enough information eventually gets to the receivers so that they can reliably recover the data, and reporting reception is the component that makes sure the sender receives confirmation that receivers have recovered the data. The argument for making this separation is that for IP multicast there are mechanisms that are excellent for ensuring goodput (using NACK packets or FEC data packets) that do not alone provide reporting reception, but overall are very efficient at providing reliability when augmented with mechanisms for providing reporting reception. For TCP/IP, ACK packets are used to implement both components, and thus the distinction between the two components is blurred because of the use of the same mechanism. ACK packets can also be used to implement both components of reliability for IP multicast, but in addition NACK packets and FEC data packets have turned out to be very useful and, in some circumstances, more efficient than ACK packets for ensuring goodput. However, neither NACK packets nor FEC data packets alone are enough to support the reporting reception component of data reliability, and if this is needed then other mechanisms should be used. (NACK packets can provide a very limited amount of reception reporting, but FEC data packets provide none.) Yet, mechanisms have been proposed for the reporting reception component of reliability (e.g., ACK the entire application data unit) that when used in combination with FEC data packets or NACK packets for ensuring goodput provide overall reliability very efficiently. Furthermore, there are multicast applications where ensuring goodput is required, but not reporting reception. Thus, it makes sense to separate reliability into these two components in these two IP multicast drafts. >From luby@dfountain.com Wed Jun 30 13:02:40 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id NAA17651 for ; Wed, 30 Jun 1999 13:02:40 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA05967 for ; Wed, 30 Jun 1999 13:02:39 -0700 (PDT) Received: from monarch.dfountain.com ([207.90.190.130]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA05951 for ; Wed, 30 Jun 1999 13:02:37 -0700 (PDT) Received: by PACIFIC with Internet Mail Service (5.5.2448.0) id ; Wed, 30 Jun 1999 12:54:33 -0700 Message-ID: <619F2FB3840CD311AC2C0090273BF1AC017BC2@PACIFIC> From: Mike Luby To: "'rmt@lbl.gov'" Cc: Mike Luby Subject: Comments on Building Blocks draft Date: Wed, 30 Jun 1999 12:54:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Michael Luby, Digital Fountain and ICSI Comments on: Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer General Comments One key point that seems to be largely missing from the document (hereafter referred to as the 'building blocks draft') in the definition of data reliability is a distinction between: (a) Ensuring goodput: Protocols to ensure that a sender sends data packets that are useful to receivers in recovering an application data unit. (b) Reporting reception: Protocols to ensure receivers report reception status information of a given application data unit back to a sender (or other management entity). For different applications both can be important, and it would be useful to develop the language in the building blocks draft so that they are considered as separate components and so that the different mechanisms for doing both can be described separately. Of course for some overall protocols the mechanisms for implementing these two components may be intertwined and thus there is little distinction between these two components, but for many overall protocols this distinction is useful and crucial. These two components together loosely constitute the data reliability component in the current building blocks draft. The notion of application data unit depends on the application, and for some applications it is not defined, although in most cases it can be defined in a way that makes sense. For example, for file distribution the application data unit is usually defined to be the entire file. For a streaming video application, the application data unit may be a single frame of the video, or it may be a group of pictures (several frames that are encoded as a unit) in an MPEG transmission, or it may be defined as 10 seconds of the video stream. In the above description of ensuring goodput, the definition of 'useful' depends on the application. For example, for file distribution it is 'useful' to a receiver to receive a set of packets that allow the entire file to be recovered. For other applications, such as MPEG streaming video, it may be 'useful' even if only a low quality video can be played out from the received packets, and the higher the quality of the playback from the received packets the more 'useful' those set of packets are. In the above description of reporting reception, the definition of 'reception status information' also depends on the application. A common requirement for reception status information for file distribution is notification of completion by each receiver once it can recover the file. A more stringent form might be that a receiver sends status information to the sender each time another 10% of the download has been completed. A less stringent requirement might be that no reception status information is ever sent back to the sender. For a video streaming application, reception status information may include the quality of the video that is played out. Status information can be useful for a variety of purposes, including confirmation of receipt of an application data unit for both billing and tracking reasons. The interaction between the various building block components can be crucial, either as building blocks that work together to create higher level functionality or in terms of implementations. As an example of higher level functionality, ensuring goodput combined with reporting reception provides what can be considered full data reliability, e.g., the file gets to the receivers as quickly as possible and the sender knows when each receiver has fully recovered the file. As another example, reporting reception can be very useful when combined with group membership to decide when the sender stops transmitting packets containing data about a given application data unit, e.g., stop transmitting when all members in the group have reported that they have completed the reception of the file. As an example of implementation interaction, in some protocols there is an intimate connection between the congestion control mechanisms used and the ensuring goodput mechanisms. A primary motivation for having ensuring goodput as a building block component is that there may be packet loss that is varied both over different receivers and over different time periods in a multicast transmission. The basic mechanisms that have been proposed for ensuring goodput can be partitioned into the following general categories: 1) ACK based protocols: receivers send positive acknowledgements for received packets, the sender resends packets that are not acknowledged. 2) NACK based protocols: receivers send negative acknowledgements when they perceive that they have missed packets that have been sent, the sender resends packets that are acknowledged. 3) FEC based protocols: the sender uses some form of erasure codes (FEC codes) to ensure that all packets are sent are useful to all receivers. Full descriptions of these types of protocols and their hybrids and variants have all been described in the literature and in the building blocks draft. It may be advantageous to consider defining building blocks with respect to these three sub-components. Primary motivations for reporting reception are network efficiency (e.g., stop the transmission when all receivers are finished), billing (e.g., a receiver can only be charged if it is confirmed that they received the full file), and tracking (e.g., crucial for monitoring the scalability and usefulness of the overall system). Examples of the mechanisms for reporting reception include piggy-backing this information in ACK-NACK packets, implicit usage of ACK-NACK packets, sending unicast packets directly back to the sender, and sending unicast packets to higher level management application tools. The proposals made here are that: i. The notion of an application data unit is useful and should be defined explicitly and examples should be given. It may be for some applications that an application data unit does not make sense, but this is the exception rather than the rule. ii. Components should be defined for both ensuring goodput and reporting reception. One use of the combination of these two components is to provide what is called data reliability in the current building blocks draft. While it might be tempting to call ensuring goodput by the name data reliability since ensuring goodput is close in meaning to the definition of data reliability in the current draft, this would be confusing. For example, it seems that implicitly data reliability in the current draft sometimes does and sometimes does not include some form of reporting reception, depending on the mechanisms used to implement it. (This explains in large part the differences between the various types of delivery guarantees for different reliability protocols in the current building blocks draft.) For example, ACKs may be used for ensuring goodput as well as for reporting reception. On the other hand, NACKs and FEC cannot be directly used to implement reporting reception, and other mechanisms must be employed. There is nothing wrong with combining the implementations of one or more components. For example, ACKs could be used simultaneously for verifying receipt of data packets so that they are not retransmitted (part of ensuring goodput) and for reporting reception of an entire file (as witnessed by all packets constituting the file being ACKed). Nevertheless, it seems cleaner to logically separate data reliability into ensuring goodput and reporting reception as suggested in these comments, especially since different approaches implement them differently. iii. Consider decomposing ensuring goodput into 'ACK', 'NACK', and 'FEC' building block mechanisms (and perhaps into some hybrids including 'HACK' and schemes that aggregate). iv. Integrate these definitions into the other parts of the building blocks draft, including descriptions as appropriate of how they may interact functionally and how they may interact as mechanisms. v. Consider the specific comments made in the following subsection in conjunction with the four preceding proposals. Specific Comments The specific comments on the building blocks draft contained in this section are written in a style that assumes the above proposals have been accepted for incorporation into the building blocks draft. If a full or partial incorporation of the proposals does not occur, then these specific comments are still valid and can be considered independently of the proposals on their own merits. 1. Page 4, Section 1.1: The title of this section and the lead in paragraph are misleading. This section is all about ensuring goodput, and how this impacts receiver scalability. The current title suggests that the section is focused on complete protocol families instead of just the ensuring goodput components of these protocols. The title is more appropriately 'Ensuring goodput Mechanisms'. The current lead in paragraph suggests the section is about receiver scalability. The lead in paragraph would be better suited to say that ensuring goodput is one of the crucial issues that affects receiver scalability, and then talk about the scalability of the ensuring goodput implementations used in several protocols. There are other components that also affect receiver scalability, including congestion control (already mentioned in the section), group management, and reporting reception. 2. Page 4, Parts 1-4: The difference in the delivery guarantees between the different protocols is a function of a combination of the ensuring goodput component and the reporting reception component. In some of the described protocols there is both an ensuring goodput component and a reporting reception component, whereas for other described protocols there is only an ensuring goodput component. It is possible to supplement each protocol that is lacking reporting reception with this component so that all protocols would have about the same level of delivery guarantees. 3. Page 4, Part 3, Router assist: It seems clear that adding an appropriate reporting reception component would provide message stability. 4. Page 4, Part 4, Open-Loop delivery: The implication of how this is written is that this mechanism provides a lower reliability guarantee, and that FEC is the reason why. An FEC based ensuring goodput implementation, when combined with an appropriate reporting reception component, has the potential for providing the highest and most efficient type of overall delivery reliability. For some types of applications, it is true that one can afford a lower level of overall delivery reliability, and thus one might consider a deployment with no reporting reception component. However, with an FEC based ensuring goodput component it is easy to add a low bandwidth reporting reception component. Furthermore, the combination of a FEC based ensuring goodput component and a reporting reception component ensures the highest level of overall reliability, is as efficient as possible, and because it is low bandwidth it fits in very nicely with even highly-asymmetric networks such as satellite. 5. Page 4, Section 2: It is stated that 'no single reliable multicast protocol can meet the needs of all applications'. This is certainly the case today, and all evidence points to this conclusion, but as written this categorically concludes that there is no possibility in the future of some overall protocol that can meet the needs of all applications. Suggest rephrasing this so that it isn't embarrassing sometime in the future (although given the six month lifetime of the draft, maybe this is not an issue). 6. Page 6, Section 2.3, Building Block Requirements: The last sentence of the 'Wide Applicability' section concludes that the fourth class (with no back channel) is fundamentally different than the first three and so may be less amenable to building blocks. One the fourth class is defined properly (with the possibility of a reporting reception component that would require a limited back channel), I don't see any reason why it is any different than the other three in terms of amenability to building blocks. Some aspects of it are simpler, i.e., no back channel needed for ensuring goodput, but we are trying to design overall protocols, not just the ensuring goodput component, and thus just because one component is implemented differently (in fact, it is pure 'FEC') doesn't put it out of scope. 7. Page 7, Section 3, Protocol Components, last paragraph: There is a conclusion there that the fourth class of protocols defined above does not require many of these functions, including loss notification, loss recovery, and group membership. When the FEC portion of that protocol is redefined to be just the ensuring goodput component of an overall protocol, a full version of the fourth class definitely could benefit from some of these other functions. Loss notification is not part of the overall protocol for ensuring goodput, but it may be part of a congestion control protocol, and it may be part of the reporting reception component. Group membership combined with a reporting reception component may be crucial for such an overall protocol to be efficient, e.g., stop transmitting when all members of the group have reported completion. 8. Page 8, Section 3.1, Sub-Components Definition: Replace the data reliability component with an ensuring goodput component and a reporting reception component. The sub-parts of ensuring goodput should be the same as for the current definition of data reliability, except that the full definition should concentrate on ensuring goodput aspects and not on reporting reception. The sub- parts of the reporting reception component may include confirmation that a particular receiver has completely received an application data unit, or received enough to have 'useful' information about the application data unit (e.g., video streaming examples described above). This higher level information is useful for scheduling multicast transmissions of different application data units (for example, to make a decision for when to stop transmitting one group of pictures in an MPEG transmission and start transmitting the next), and potentially for tracking and billing purposes. 9. Page 10, Session Start/Stop: This is higher level functionality that can be supported by a reporting reception component for the 'data fountain' approach. 10. Page 13, Section 4.4, Generic Router Support: Packet filtering for reducing the rate of flow to constrained bandwidth and/or congested links is another function that could be mentioned here. 11. Page 15, Section 7, References: The following five references may be appropriate: The following paper describes how the basic protocol labeled as (4) with layering for congestion control would work: John Byers, Michael Luby, Michael Mitzenmacher, Ashu Rege, ''A Digital Fountain Approach to Reliable Distribution of Bulk Data'', ICSI technical report TR-98-005, February 1998, SIGCOMM '98, September 1998. The following paper describes how streaming video might be layered and protected into application data units for transmission over the Internet: W.Tan and A.Zakhor, 'Real-time Internet Video Using Error Resilient Scalable Compression and TCP-friendly Transport Protocol', IEEE Trans. Multimedia, June 1999. The following paper describes a Reed-Solomon implementation of FEC that is available in software for transmission over the Internet (used to protect MPEG streams in vic): Johannes Bloemer, Malik Kalfane, Marek Karpinski, Richard Karp, Michael Luby, David Zuckerman, ''An XOR-Based Erasure- Resilient Coding Scheme'', ICSI Technical Report No. TR-95-048, August 1995. The following paper describes a new class of FEC codes that are scalable to protect much larger application data units in a software based implementation: Michael Luby, Michael Mitzenmacher, Amin Shokrollahi, Daniel Spielman, Volker Stemann, ''Practical Loss-Resilient Codes'', 29th Annual ACM Symposium on Theory of Computing, 1997. >From luby@dfountain.com Wed Jun 30 13:03:30 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id NAA17677 for ; Wed, 30 Jun 1999 13:03:29 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA06156 for ; Wed, 30 Jun 1999 13:03:28 -0700 (PDT) Received: from monarch.dfountain.com ([207.90.190.130]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA06149 for ; Wed, 30 Jun 1999 13:03:27 -0700 (PDT) Received: by PACIFIC with Internet Mail Service (5.5.2448.0) id ; Wed, 30 Jun 1999 12:55:23 -0700 Message-ID: <619F2FB3840CD311AC2C0090273BF1AC017BC3@PACIFIC> From: Mike Luby To: "'rmt@lbl.gov'" Cc: Mike Luby Subject: Comments on Design Space draft Date: Wed, 30 Jun 1999 12:55:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Michael Luby, Digital Fountain and ICSI Comments on: The Reliable Multicast Design Space for Bulk Data Transfer General Comments The following comments are written in response (hereafter referred to as the 'design space draft'). These comments were written after the comments I wrote on (hereafter referred to as the 'building blocks draft'). The specific comments on the design space draft contained herein are written in a style that assumes the proposals made to the building blocks draft have been accepted for incorporation into the building blocks draft. If a full or partial incorporation of the proposals does not occur, then these specific comments are still valid and can be considered independently of the proposals on their own merits. Specific Comments 1. Page 3, Section 2.1, Did everyone receive the data?, third paragraph: suggest changing 'If the application does need to know that everyone got the data, then a positive acknowledgement must be received ...' to 'If the application does need to know that everyone got the data, then a reception report confirming receipt must be received ...'. This assumes that the concept of an application data unit has already been introduced. In the current design space draft, this is defined just after this in the fourth paragraph. Suggest moving the mention of application data unit be moved up and expanded on a bit to include some possible examples as proposed in my comments to the building blocks draft (e.g., for file transfer, application data unit = file, for streaming MPEG video, application data unit = group of pictures). 2. Page 4, Section 2.3, Receiver Set Scaling: The title of this section is misleading given its content. A more appropriate title would be 'The Affect of Ensuring Goodput on Receiver Scaling'. There are other components that also significantly affect receiver scalability, including congestion control, group membership, and reporting reception. It is the case that ensuring goodput is one of the thornier issues with respect to receiver scalability, and thus this section does make sense to include. 3. Page 4, Section 2.3, Receiver Set Scaling: In the fourth paragraph there is mention that it is difficult to incorporate effective congestion control into such protocols because of the sparseness of feedback. The problem here is the mixing of the implementation of two components - ensuring goodput and congestion control. It may not be difficult to incorporate effective congestion control into such schemes, it just may be difficult to piggy-pack the congestion control onto the ensuring goodput ACK packets in this case because of the sparseness of ACK packets. There are two points here: (a) Sometimes it is advantageous to combine the implementations of components together, e.g., piggy-backing the congestion control signaling using the ACK packets that also are used for ensuring goodput. This is similar to how TCP combines congestion control and reliability in one overall protocol without separating them out. It is cleaner to separate them out, but may be more efficient in some cases to combine them. Nevertheless, there should be no inherent reason why they can't be implemented separately and still be efficient, and thus the conclusion that congestion control would suffer if the ensuring goodput protocol uses sparse feedback seems to be an inappropriate conclusion. The congestion control could use a separate signaling mechanism and still be effective. (b) It is important to consider the combined effects of one or more components. For example, it is important to consider the aggregate feedback traffic to the server, and not try to optimize the feedback required for one component (say ensuring goodput) at the expense of another (say congestion control). This does not seem to be the point of this fourth paragraph however. The point of designing the various components of the overall protocol so that it is overall efficient is an important one though, and could be made somewhere. 4. Page 6, Section 3.1, Internet vs Intranet: The last sentence seems a fairly strong conclusion that may change at some point in the future. A proposed rewording is 'In the public Internet, it is less likely that the additional expense required to support ...'. 5. Page 7, Section 4, The RM Solution Space: The title and introduction don't accurately lead into this section. This section concentrates on the ensuring goodput component of the overall protocol. A new proposed title would be 'The ensuring goodput solution space'. There should be a lead in sentence or two that makes it clear that this section is addressing the issue of lost packets and thus is discussing various ways to implement the ensuring goodput component. Note that the sub-component decomposition here is roughly what I proposed for adding to the building blocks draft for the ensuring goodput component. (See proposal iii in my comments to the building blocks draft). 6. Page 10, Section 4.3, Redundancy: The title of this section is confusing, because FEC is often thought of in the context of redundancy. Furthermore, what is described here is not so much redundancy as a 'stateless streaming application'. This is an application where the data can be thought of as a stateless stream and whatever is sent in the future supercedes very quickly what was sent in the past, and thus FEC techniques are inappropriate. Perhaps 'Stateless streaming applications' could be the title? In the second paragraph, the sentence 'The major advantage of redundancy is that ...' could be changed to 'The major advantage of a stateless streaming application is that ...'. Further on in the same paragraph, 'redundant streams' could be changed to 'stateless streams'. 7. Page 12, Section 4.4, paragraph 6: The paragraph starts off with the sentence 'To apply reactive FEC, the sender must group data packets into rounds, and the receivers ...'. It is unclear what the definition of a 'round' is. One assumption could be that it is somewhere between the size of an application data unit and a packet. Perhaps the most compelling assumption is that it is the set of packet associated with an application data unit. Then, reports coming back on how many packets were missing could be considered as reception reports. The decision on when to terminate sending packets associated with one application data unit and move on to the next is based on all receivers having confirmed receipt of the entire application data unit using what logically would be considered reporting receptions (implemented perhaps using ACKs or NACKs as proposed). 8. Page 12, Section 4.4: No mention is made of applications where proactive FEC might be useful. Examples that might be mentioned are streaming video applications. One person who is doing work in this area is Avideh Zakhor at UC Berkeley (a reference to one of her relevant papers is given at the end). Another person is Philip Chou of Microsoft (I don't have any references to his work). They use some combination of proactive and reactive FEC. There are surely others. 9. Page 12, Section 4.5, Layered FEC: The assumption with layered FEC is made that packets are repeatedly transmitted. The relevant sentence is 'The n encoded packets are then striped across multiple multicast groups, and repeated (sic) transmitted'. That really depends on the application and is not a requirement of the scheme. For example, using a reporting reception component combined with perhaps a group membership component, the transmission of packets about the current application data unit can be terminated when all (or enough) receivers have successfully recovered the application data unit, and then transmission of the next application data unit can proceed. 10. Page 12, Section 4.5, Layered FEC: The last phrase in last sentence of last paragraph seems debatable. Doesn't Rizzo and Vicisano propose a layered multicast scheme where 'tracer' packets are sent out from the sender in each layer to coordinate joins and leaves of receivers from the groups, and isn't their protocol feedback free? 11. Page 14, Router-based congestion control: The paragraph that starts 'For reliable multicast protocols, it is important to consider congestion control at the same time as reliability is being considered ...' This entire paragraph jumps to some conclusions that have been recently challenged. For example, Lorenzo Vicisano, Tony Speakman and I made a presentation at the RMG in PISA for router supported congestion control that completely separated the issue of congestion control from that of reliability. (I give the reference at the end.) Probably worth considering rewriting this paragraph and citing what the conclusions are based on, and integrating it with the subsequent paragraph that starts 'In the case of receiver-based congestion control ...'. 12. Page 15, Section 6, Security Concerns: Another form of denial-of- service attack that is worth mentioning is in the layered approach a non-cooperating receiver may subscribe to all layers behind a bottleneck link and thus realize a denial-of-service attack to receivers behind the bottleneck. In fact, this kind of attack is even more perverse, as it also could overload the network and could lead to possible collapse of the network. On the other hand, a similar network collapse could also be induced by a TCP/IP receiver sending fake acknowledgements at a fast rate. 13. Page 15, Section 7, References: The following references may be appropriate: The following paper describes how FEC and router supported packet filtering might be combined to provide congestion control for reliable multicast in a heterogeneous network: Michael Luby, Lorenzo Vicisano, Tony Speakman, 'Heterogeneous multicast congestion control based on router packet filtering', presentation at RMG in PISA, June 1999, work in progress. The following paper describes how the basic protocol labeled as (4) with layering for congestion control would work: John Byers, Michael Luby, Michael Mitzenmacher, Ashu Rege, ``A Digital Fountain Approach to Reliable Distribution of Bulk Data'', ICSI technical report TR-98-005, February 1998, SIGCOMM '98, September 1998. The following paper describes how streaming video might be layered and protected into application data units for transmission over the Internet: W.Tan and A.Zakhor, "Real-time Internet Video Using Error Resilient Scalable Compression and TCP-friendly Transport Protocol", IEEE Trans. Multimedia, June 1999. The following paper describes a Reed-Solomon implementation of FEC that is available in software for transmission over the Internet (used to protect MPEG streams in vic): Johannes Bloemer, Malik Kalfane, Marek Karpinski, Richard Karp, Michael Luby, David Zuckerman, ``An XOR-Based Erasure- Resilient Coding Scheme'', ICSI Technical Report No. TR-95-048, August 1995. The following paper describes a new class of FEC codes that are scalable to protect much larger application data units in a software based implementation: Michael Luby, Michael Mitzenmacher, Amin Shokrollahi, Daniel Spielman, Volker Stemann, ``Practical Loss-Resilient Codes'', 29th Annual ACM Symposium on Theory of Computing, 1997. >From chiu@bridge.East.Sun.COM Thu Jul 1 10:12:57 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id KAA22430 for ; Thu, 1 Jul 1999 10:12:57 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA25629 for ; Thu, 1 Jul 1999 10:12:56 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA25622 for ; Thu, 1 Jul 1999 10:12:55 -0700 (PDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22747 for ; Thu, 1 Jul 1999 10:12:53 -0700 (PDT) Received: from bridge.East.Sun.COM (bridge.East.Sun.COM [129.148.75.125]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA12580 for ; Thu, 1 Jul 1999 13:12:52 -0400 (EDT) Received: from bridge (bridge [129.148.75.125]) by bridge.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id NAA19783 for ; Thu, 1 Jul 1999 13:12:52 -0400 (EDT) Message-Id: <199907011712.NAA19783@bridge.East.Sun.COM> Date: Thu, 1 Jul 1999 13:12:52 -0400 (EDT) From: Dah Ming Chiu - Sun Microsystems Reply-To: Dah Ming Chiu - Sun Microsystems Subject: Comments on building-block and design-space drafts To: rmt@lbl.gov MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 3JDLZJ8YRYi8c3i9nFHDyg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Some thoughts after reading the building block draft: 1) My basic concern is whether this is too ambitious. How much success have we had in standardizing APIs? It is perhaps feasible for very well-defined and narrowly focused functions, such as FEC, encryption and decryption, authentication, rate-based packet scheduling, or rate calculation. For more abstract, complex, close-to-application functions, it is very hard to get different people to agree. 2) I would like to see a more compeling argument for the building-block effort, than the stated advantages which are mostly to ease software development and maintanance. For example, we might want to make it possible for (different) multicast receivers to receive from different kinds of senders; or standardized router functions for different end systems to use. 3) It might help to group the currently listed building blocks into two categories - those that affect the main business of getting data from sender to receivers (reliability, congestion control and security mechanisms); and those that are session support functions (group, session, tree config, notification). 4) The coverage of the different topics are quite uneven, and lacks focus. For example, in the security section, it talks about the need to authenticate control messages to deal with DoS. There are zillions of other DoS attacks in multicast, how are we going to deal with the rest of them? Comment on the design space draft: This document is quite well written. I have one comment regarding the specific exclusion of "intermittent data flows". The cited reason is "we do not yet have effective congestion control for such applications". Well, TCP congestion control assumes continuous data transfer as well, does that mean we should not use TCP for http type of request/response short intermittent sessions? It seems to me that intermittent data flows can use some very simple-minded congestion control to make sure they are friendly with other flows. From my experience, intermittent data model is a very important class of application for reliable multicast. We mustn't drop it because it does not fit a particular congestion control algorithm one try to standardize (at the moment). >From ken_birman@email.msn.com Thu Jul 1 12:01:51 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id MAA23516 for ; Thu, 1 Jul 1999 12:01:50 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA00132 for ; Thu, 1 Jul 1999 12:01:49 -0700 (PDT) Received: from secure.smtp.email.msn.com (secure.smtp.email.msn.com [207.46.181.28]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA00125 for ; Thu, 1 Jul 1999 12:01:48 -0700 (PDT) Received: from adsl39 - 128.84.216.39 by email.msn.com with Microsoft SMTPSVC; Thu, 1 Jul 1999 12:00:05 -0700 Message-ID: <002601bec3f3$edd6d020$27d85480@cit.cornell.edu> From: "Kenneth P. Birman" To: References: <199907011712.NAA19783@bridge.East.Sun.COM> Subject: Comments on building-block and design-space drafts Date: Thu, 1 Jul 1999 14:59:12 -0400 Organization: Cornell University X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 I've also felt that the drafts leave open some issues. I wrote a detailed comment to the authors, but since several people have posted comments, let me share my own reaction very briefly. First, I should stress that although my points are critical, I am actually very impressed in a positive sense with the quality of these RFC's and view them as very good first steps in a process. I don't think they are finished -- my comments will all point to ways to revise and extend the RFC's -- but I am not at all suggesting that they need to be tossed out and rewritten, or anything of that sort. Indeed, I think the multicast community owes its thanks to the authors, for teaming up and producing a very convincing first cut. But having said this, I do have some criticisms, which I intend in a positive way: 1) I found the treatment of multi-sender groups inconsistent. On the one hand, we are told that these drafts limit attention to single-sender multicast scenarios, but on the other, there is some specific material in the building-blocks RFT which states (incorrectly, in my opinion and experience) that with multiple senders, there are no scalable flow control and congestion control protocols. In fact, there have been many such protocols. Some of them simply route the multicasts through a sequencer, as in the work done by Kaashoek at MIT (but fault-tolerantly). Now, these protocols look like they support multiple senders, and the messages get through reliably. Is there a good reason to presume that multisender protocols can't work? Perhaps certain styles of multi-sender protocols don't scale, but even so, why does this rule out other styles of solution? 2) The drafts fail to cite a considerable body of work on the reliable multicast problem itself, and on the problem of compositional design of multicast systems -- van Renesse's work on Horus, Hayden's work on Ensemble, and Rick Schlictings work on the multicast extensions to the x-Kernel architecture at Arizona. These projects are important because they demonstrate that one can build modular multicast architectures, and because they attack the various overheads associated with layering in different and important ways. My book, "Building Secure and Reliable Network Applications" (Manning and Prentice Hall, 1997) discusses some of the issues in a chapter on modular design of multicast protocols. Reliable multicast dates back at least to 1985 -- the V system supported a multicast and Willy and David talk about reliability in their papers on it, and Isis came out around 1987. Isis was used in air traffic control systems, it runs stock exchanges (the Swiss and New York systems are both based on Isis -- a broader survey is coming out later this summer in Software, Practice and Experience in the August 1999 issue). Wouldn't an IETF standard be stronger by trying to encompass this prior work, rather than simply overlooking it? 3) The drafts fail to cite much of the recent work on local repair protocols and probabilistic scalable and reliable protocols. Obviously, I have my own protocol in mind here -- Bimodal Multicast, subject of a paper in the May issue of ACM Trans. on Computer Systems. But there are many. Instead, the draft seems biased in favor of the tree-based hierarchical architectures (such as SRM, RMTP), arguing that tree-based nack/resend schemes are preferable to other options for acknowledgement or negative acknowledgement. Not mentioned are the recent results showing that in systems lacking membership data, such protocols can give very high rates of overhead, for example in the presense of low systemwide loss rates. Again, since I happen to believe strongly that randomized gossip protocols scale better and represent a very interesting alternative (and one which can be analyzed effectively), this option should at least be mentioned. 4) Some issues are not mentioned, but should be. For example, suppose I want to know that my multicast protocol will survive any single link failure, or any single router failure. The broad implications of such a requirement are not mentioned here. Similarly for other aspects of the reliability spectrum -- levels of consistency guarantee, strong membership semantics (virtual synchrony), steady throughput guarantees (isochrony), security (often seen by the user as an aspect of a single "secure and reliable multicast problem"), real-time properties. Not all of these can co-exist, so they all should be seen as possible dimensions of an architecture. That is, reliability is in the eye of the beholder. The job of the standards developer is to accomodate many kinds of possible users, not to pick a single scheme and stamp it as the winner... 5) All of this, it seems to me, argues that the architecture needs to be separate from the protocols that populate it. For example, Horus has an architecture supporting compositional protocol layering -- protocols built as stacks of microprotocols. The actual protocol you run could be virtually synchronous, probabilistic, secure, SRM-style, RMTP-style -- this depends on the choice of components in the stack you use. So one can imagine standardizing the stacking framework, inter-layer optimization methodology, etc, and yet not having any real opinion on the relative merits of SRM, RMTP, pbcast (bimodal multicast), vscast, the causal-delta protocols of Raynal, or whatever. Indeed, such an architecture would support many solutions which could live side by side. The RFC's, as written, promote a choice in favor of tree based nack-only schemes using local repair. Is this a wise decision? Such protocols, after all, are not amenable to providing at least some of the properties listed above! Why not opt for diversity and illustrate this by showing that a single architecture can elegantly accomodate many of the important protocol options? 6) I question the decision to focus on 1-many bulk data transfer. In particular, the RFC's lack any content specific to the bulk data aspects and seem inconsistent about whether or not this is really even a 1-many situation. Why not just accept that reliable multicast will often be used in situations with many senders, and often used in situations where membership awareness is important? Often -- not always -- but also, not rarely or never... Lest this all seem overly negative, please be aware that I find these RFC's quite impressive as a first try. I don't think they are finished yet, but I'm not advocating tossing them out either. I simply believe that they could be made stronger and more broad with a little additional effort, and that the result would be a more fitting IETF standard and more valuable to a broader community. Ken >From J.Crowcroft@cs.ucl.ac.uk Fri Jul 2 00:43:01 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id AAA25615 for ; Fri, 2 Jul 1999 00:43:00 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA04191 for ; Fri, 2 Jul 1999 00:42:59 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id AAA04187 for ; Fri, 2 Jul 1999 00:42:58 -0700 (PDT) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 2 Jul 1999 08:42:52 +0100 To: "Kenneth P. Birman" cc: rmt Subject: Re: Comments on building-block and design-space drafts In-reply-to: Your message of "Thu, 01 Jul 1999 14:59:12 EDT." <002601bec3f3$edd6d020$27d85480@cit.cornell.edu> Date: Fri, 02 Jul 1999 08:42:50 +0100 Message-ID: <864.930901370@cs.ucl.ac.uk> From: Jon Crowcroft In message <002601bec3f3$edd6d020$27d85480@cit.cornell.edu>, "Kenneth P. Birman " typed: >>1) I found the treatment of multi-sender groups inconsistent. I think that there is a parallel point here. The proponents of the view that we have to solve the single source problem first have, I believe, a strong case: but BEWARE that we don't push the IP level folks into optimising for single source - many ISPs would gladly adopt an Express like model which would work fine for streaming RTP and for single soruce RMT for software and web mirror data distribution but would close the door pretty heavily against the sort of things that multiple source enables (games etc etc) >>hand, we are told that these drafts limit attention to single-sender >>multicast scenarios, but on the other, there is some specific material in >>the building-blocks RFT which states (incorrectly, in my opinion and >>experience) that with multiple senders, there are no scalable flow control >>and congestion control protocols. In fact, there have been many such >>protocols. Some of them simply route the multicasts through a sequencer, as >>in the work done by Kaashoek at MIT (but fault-tolerantly). Now, these >>protocols look like they support multiple senders, and the messages get >>through reliably. Is there a good reason to presume that multisender >>protocols can't work? Perhaps certain styles of multi-sender protocols >>don't scale, but even so, why does this rule out other styles of solution? yes - i think the idea tho is to leave enough hooks in the current work to allow us to edge towards including the full range of multiple source protocols later...... >>2) The drafts fail to cite a considerable body of work on the reliable >>multicast problem itself, and on the problem of compositional design of >>multicast systems -- van Renesse's work on Horus, Hayden's work on Ensemble, >>and Rick Schlictings work on the multicast extensions to the x-Kernel >>architecture at Arizona. These projects are important because they >>demonstrate that one can build modular multicast architectures, and because >>they attack the various overheads associated with layering in different and >>important ways. My book, "Building Secure and Reliable Network >>Applications" (Manning and Prentice Hall, 1997) discusses some of the issues >>in a chapter on modular design of multicast protocols. good reference - thanks! >>Reliable multicast dates back at least to 1985 -- the V system supported a >>multicast and Willy and David talk about reliability in their papers on it, >>and Isis came out around 1987. Isis was used in air traffic control >>systems, it runs stock exchanges (the Swiss and New York systems are both >>based on Isis -- a broader survey is coming out later this summer in >>Software, Practice and Experience in the August 1999 issue). Wouldn't an >>IETF standard be stronger by trying to encompass this prior work, rather >>than simply overlooking it? i guess the issue here was discussed at some of the RMRG and handover meetings to RMT - yes, but later on - its not being excluded at all but the priority was to deal with what was perceived as open _internet_ customer requirements - there are, as ou say, a lot of intranets running very succesful horus, tibnet, etc etc systems......we need a good understanding of the impact of these in the open internet, and at the RMRG in pisa, we outlined some of the relevant things that nheed to emerge fro mthe research community over the next year or two to allow us to think about engineering open-internet-friendly multiple source protocols... >>3) The drafts fail to cite much of the recent work on local repair protocols >>and probabilistic scalable and reliable protocols. Obviously, I have my own >>protocol in mind here -- Bimodal Multicast, subject of a paper in the May >>issue of ACM Trans. on Computer Systems. But there are many. Instead, the >>draft seems biased in favor of the tree-based hierarchical architectures >>(such as SRM, RMTP), arguing that tree-based nack/resend schemes are >>preferable to other options for acknowledgement or negative >>acknowledgement. Not mentioned are the recent results showing that in >>systems lacking membership data, such protocols can give very high rates of >>overhead, for example in the presense of low systemwide loss rates. Again, >>since I happen to believe strongly that randomized gossip protocols scale >>better and represent a very interesting alternative (and one which can be >>analyzed effectively), this option should at least be mentioned. i guess we are not trying to write an academic paper here so completeness of references to related work is not a critical issue (how many ieee, itu or iso standards cite ANY work!), but useful input again...thanks >>4) Some issues are not mentioned, but should be. For example, suppose I >>want to know that my multicast protocol will survive any single link >>failure, or any single router failure. The broad implications of such a >>requirement are not mentioned here. Similarly for other aspects of the >>reliability spectrum -- levels of consistency guarantee, strong membership >>semantics (virtual synchrony), steady throughput guarantees (isochrony), >>security (often seen by the user as an aspect of a single "secure and >>reliable multicast problem"), real-time properties. Not all of these can >>co-exist, so they all should be seen as possible dimensions of an >>architecture. >> >>That is, reliability is in the eye of the beholder. The job of the >>standards developer is to accomodate many kinds of possible users, not to >>pick a single scheme and stamp it as the winner... >>5) All of this, it seems to me, argues that the architecture needs to be >>separate from the protocols that populate it. For example, Horus has an >>architecture supporting compositional protocol layering -- protocols built >>as stacks of microprotocols. The actual protocol you run could be virtually >>synchronous, probabilistic, secure, SRM-style, RMTP-style -- this depends on >>the choice of components in the stack you use. So one can imagine >>standardizing the stacking framework, inter-layer optimization methodology, >>etc, and yet not having any real opinion on the relative merits of SRM, >>RMTP, pbcast (bimodal multicast), vscast, the causal-delta protocols of >>Raynal, or whatever. Indeed, such an architecture would support many >>solutions which could live side by side. The RFC's, as written, promote a >>choice in favor of tree based nack-only schemes using local repair. Is this >>a wise decision? Such protocols, after all, are not amenable to providing >>at least some of the properties listed above! Why not opt for diversity and >>illustrate this by showing that a single architecture can elegantly >>accomodate many of the important protocol options? hmmmmmmmm.... >>6) I question the decision to focus on 1-many bulk data transfer. In >>particular, the RFC's lack any content specific to the bulk data aspects and >>seem inconsistent about whether or not this is really even a 1-many >>situation. Why not just accept that reliable multicast will often be used >>in situations with many senders, and often used in situations where >>membership awareness is important? Often -- not always -- but also, not >>rarely or never... well, i guess one solution is to ask the proponents of commercial 1-many solutions to write a bit more about user requirements... >>Lest this all seem overly negative, please be aware that I find these RFC's >>quite impressive as a first try. I don't think they are finished yet, but >>I'm not advocating tossing them out either. I simply believe that they >>could be made stronger and more broad with a little additional effort, and >>that the result would be a more fitting IETF standard and more valuable to a >>broader community. ace.. cheers jon >From whetten@talarian.com Sun Jul 4 20:47:43 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id UAA02303 for ; Sun, 4 Jul 1999 20:47:39 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA05052 for ; Sun, 4 Jul 1999 20:47:37 -0700 (PDT) Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA05048 for ; Sun, 4 Jul 1999 20:47:37 -0700 (PDT) Received: from tahoe (ta038.talarian.com [204.147.187.38] (may be forged)) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id UAA02383; Sun, 4 Jul 1999 20:46:43 -0700 (PDT) Message-Id: <4.1.19990702161157.023a9a30@pop3.concentric.net> Message-Id: <4.1.19990702161157.023a9a30@pop3.concentric.net> X-Sender: bwhetten@mailhost.talarian.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 04 Jul 1999 14:31:44 -0700 To: Mike Luby , "'rmt@lbl.gov'" From: Brian Whetten Subject: Re: Short version of comments on building blocks and design space drafts Cc: Mike Luby In-Reply-To: <619F2FB3840CD311AC2C0090273BF1AC017BC1@PACIFIC> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Mike, Thank you for the detailed feedback! I am on vacation at the moment, so haven't yet had the time to read through all your detailed comments. Let me give you my quick thoughts, however. I've been having problems reading email, so others may have already responded to your email...I appologize for any redundancy, if so. In general, there are many different ways to "slice up" RM, and we will probably never get complete consensus on all the questions involved. To be fair, the first draft doesn't stress your class of "digital fountain" algorithms as much as it does the NACK/ACK/Router Assist approaches. While I'm sure part of that is because I am a little less familiar with this newer class of protocols (which I appologize for), the biggest reason is that we saw much less commonality between DF and the other three classes. So we tried to focus on the area where we knew we could probably get the most reuse and sharing--and which we thought would be the most controversial. Your notion of reporting reception is very similar to the "message stability" feature in RMTP-II and other HACK protocols. The primary differences that I can see are: 1) Reception reporting is explicitly tied to ADU's, while message stability is tied to a stream of transport level packets. The advantage of the former is that it can provide slightly better fault tolerant semantics, since the confirmation can include the application's flushing a file to disk, for example. The potential tradeoff is that it makes the programming API potentially more complex. This whole question of the advantages of ALF is a religous debate, however, that has been going on for years. 2) For a streaming protocol, message stability can also provide flow control and dramatically reduce the required buffers at the sender. 3) For a DF type protocol, reporting reception can also tell the sender when to "turn off the fountain". >From the perspective of getting consistent language, we have been struggling with terminology for how to differentiate between protocols that do and do not provide message stability. The fact that you raised this means we obviously didn't do a good enough job. :) However, I'm not sure how to reconcile the above two differences in a single term, and would welcome suggestions on this. >From the perspective of how to actually break the building blocks up, there are three places that I see that reception reporting/message stability can be done. 1) As part of the ACK/HACK mechanism, like in RMTP-II. In this case, the message stability is inextricably tied to the rest of the protocol, and is extremely difficult to separate out. 2) As part of an application specific protocol, like in MFTP. If you are not using HACKs, it is much more difficult to scale reception reporting (you have to use ACKs for this, by definition), and so this makes much more sense for a file transfer application where your ADU is large enough to prevent ACK implosion. 3) As part of a more generic session management protocol, which could also provide total group membership, session advertisement, session start/stop, etc. Note that when coupled with message stability, a session management protocol can also provide scaleable real-time reception reporting, by polling the DRs for the total group membership, and matching this up against the count on # of receivers that comes from message stability (although this has slightly different reliability semantics, since it is transport reliability, not application reliability). HACK protocols can work for both non-real time and real-time applications, but typically need to build a hierarchy for real-time apps or very large scale non-real time apps (>1000's nodes). For a HACK based protocol like RMTP-II, the data reliability and recovery is intimately coupled with the message stability, which is what allows it to support real-time apps. So this is a tough one to break out. In the RM BOF, I proposed that we have a File Transfer building block, which would provide session management for a file transfer session, and might also have an application level acknowledgement scheme built in. For the building blocks draft, I was encouraged to take that out (at least for now), because it was felt that this was an application level protocol, and outside the scope of a transport working group. Perhaps that question is one that we should open up for discussion. In the draft, we briefly talked about the session management requirements, but didn't put in any building blocks for those features, as I don't think we felt there was consensus on how to best do that yet. It clearly is important, particularly for the DF class of protocols, and I think your feedback can help with this. Personally, this is where I had envisioned the features you are talking about residing. To complicate matters, a HACK protocol such as RMTP-II can work with other standardized reliability mechanisms. With RMTP-II, you can tune the HACK traffic down to the point where it is being primarily used just for "reporting reception"/message stability. In fact, we already recommend this for users which can turn on NACKs. If you run RMTP-II in a one-level hierarchy, with the HACKs tuned down to just the level at which you would do application level acknowledgements, then this is actually pretty similar to what I think you are suggesting, except it isn't an application level acknowledgement, and you don't have total group membership information (just a count). So, RMTP-II's intricately coupled message stability can work with the NACK and FEC building blocks, to provide much of "reporting reception". It could also work with a generic router assist building block to take advantage of PGM-style NACKs. So, in conclusion, I think that while we might not have made it clear in the draft, we are already thinking along somewhat similar lines, but the necessity of supporting real-time applications and of concentrating on the area with primary overlap, has caused us (or me, at least) to structure things somewhat differently. I'd like us to be able to come up with consensus for a consistent language on reliability semantics (which by itself has generated a tremendous amount of research, much by Ken Birman and his group). Then, perhaps we need to debate whether reception reporting belongs in a file-transfer specific component, or as part of a session management block. I do think that ADU semantics make more sense at the session management / file transfer level, but less from a data naming perspective than from an application level acknowledgement perspective. Brian >From whetten@talarian.com Sun Jul 4 20:47:50 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id UAA02318 for ; Sun, 4 Jul 1999 20:47:49 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA05071 for ; Sun, 4 Jul 1999 20:47:48 -0700 (PDT) Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA05061 for ; Sun, 4 Jul 1999 20:47:47 -0700 (PDT) Received: from tahoe (ta038.talarian.com [204.147.187.38] (may be forged)) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id UAA02390; Sun, 4 Jul 1999 20:47:10 -0700 (PDT) Message-Id: <4.1.19990704144448.00d82580@mailhost.talarian.com> Message-Id: <4.1.19990704144448.00d82580@mailhost.talarian.com> X-Sender: bwhetten@mailhost.talarian.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 04 Jul 1999 16:11:08 -0700 To: "Kenneth P. Birman" , From: Brian Whetten Subject: Re: Comments on building-block and design-space drafts In-Reply-To: <002601bec3f3$edd6d020$27d85480@cit.cornell.edu> References: <199907011712.NAA19783@bridge.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Ahh..nothing like a vacation to give you the chance to catch up on emails. ;) Ken, Thanks for the positive nature of your comments. RM seems to be like philosophy....six opinions for every five researchers....but if we all follow the positive nature of your comments, hopefully we can continue to work towards community consensus. >1) I found the treatment of multi-sender groups inconsistent. On the one >hand, we are told that these drafts limit attention to single-sender >multicast scenarios, but on the other, there is some specific material in >the building-blocks RFT which states (incorrectly, in my opinion and >experience) that with multiple senders, there are no scalable flow control >and congestion control protocols. In fact, there have been many such >protocols. Some of them simply route the multicasts through a sequencer, as >in the work done by Kaashoek at MIT (but fault-tolerantly). Now, these >protocols look like they support multiple senders, and the messages get >through reliably. Is there a good reason to presume that multisender >protocols can't work? Perhaps certain styles of multi-sender protocols >don't scale, but even so, why does this rule out other styles of solution? This may not have been presented clearly, but this comment was supposed to provide a partial rationale for why we were not looking at multiple sender cases. I agree that there may be some solutions for multi-sender flow control, but other than a centralized sequencer, I don't know of any solutions for congestion control that I would consider provably safe and fair with TCP. A centralized sequencer is a useful component for some applications, and could be built on top of a 1-many RM protocol. For now, I think this was considered out of the scope of this draft (we're trying to start small, and then expand, as we already have too much on our collective plates). >2) The drafts fail to cite a considerable body of work on the reliable >multicast problem itself, and on the problem of compositional design of >multicast systems -- van Renesse's work on Horus, Hayden's work on Ensemble, >and Rick Schlictings work on the multicast extensions to the x-Kernel >architecture at Arizona. These projects are important because they >demonstrate that one can build modular multicast architectures, and because >they attack the various overheads associated with layering in different and >important ways. My book, "Building Secure and Reliable Network >Applications" (Manning and Prentice Hall, 1997) discusses some of the issues >in a chapter on modular design of multicast protocols. > >Reliable multicast dates back at least to 1985 -- the V system supported a >multicast and Willy and David talk about reliability in their papers on it, >and Isis came out around 1987. Isis was used in air traffic control >systems, it runs stock exchanges (the Swiss and New York systems are both >based on Isis -- a broader survey is coming out later this summer in >Software, Practice and Experience in the August 1999 issue). Wouldn't an >IETF standard be stronger by trying to encompass this prior work, rather >than simply overlooking it? It is no one's intention to overlook this very influential prior work. First off, my appology to you and to all the other researchers whose work we did not cite. We got this draft out under severe time pressures, and so fell back on the crutch of citing a couple prior survey papers, rather than citing all the work individually. Speaking at least for myself, I am happy to add additional references....although we risk doubling the size of the draft. :) The work on functional decomposition (as opposed to specific protocols) we should have cited specifically, as it is directly relevant to the draft. Again, my appologies. One difference between that approach and the building blocks we conceive of is that a building block is defined primarily as a "unit of work" that we think the community can come to consensus on, rather than as a engineering component. >3) The drafts fail to cite much of the recent work on local repair protocols >and probabilistic scalable and reliable protocols. Obviously, I have my own >protocol in mind here -- Bimodal Multicast, subject of a paper in the May >issue of ACM Trans. on Computer Systems. But there are many. Instead, the >draft seems biased in favor of the tree-based hierarchical architectures >(such as SRM, RMTP), arguing that tree-based nack/resend schemes are >preferable to other options for acknowledgement or negative >acknowledgement. Not mentioned are the recent results showing that in >systems lacking membership data, such protocols can give very high rates of >overhead, for example in the presense of low systemwide loss rates. Again, >since I happen to believe strongly that randomized gossip protocols scale >better and represent a very interesting alternative (and one which can be >analyzed effectively), this option should at least be mentioned. Please see the response to #5, below. >4) Some issues are not mentioned, but should be. For example, suppose I >want to know that my multicast protocol will survive any single link >failure, or any single router failure. The broad implications of such a >requirement are not mentioned here. Similarly for other aspects of the >reliability spectrum -- levels of consistency guarantee, strong membership >semantics (virtual synchrony), steady throughput guarantees (isochrony), >security (often seen by the user as an aspect of a single "secure and >reliable multicast problem"), real-time properties. Not all of these can >co-exist, so they all should be seen as possible dimensions of an >architecture. > >That is, reliability is in the eye of the beholder. The job of the >standards developer is to accomodate many kinds of possible users, not to >pick a single scheme and stamp it as the winner... Yes, reliability can become very subtle (and contentious) when you start talking about fault tolerance guarantees, which is one of the primary reasons why I think consensus has been reached that we should be targeting 1->many applications first, where ordering/virtual synchrony/etc. are less important. Again, we're not saying that many-many distributed systems protocols aren't important (remember, RMP is the only real protocol I can truly claim initial authorship of), just that they are a more difficult problem to achieve consensus on, and also of less immediate applicability in the Big-I Internet. There is clearly a spot for many-many standards...but a lot more consensus building needs to be done first, and no clear leaders of this yet in the RMRG community. As one of the top world experts in this area, would you like to help on this? >5) All of this, it seems to me, argues that the architecture needs to be >separate from the protocols that populate it. For example, Horus has an >architecture supporting compositional protocol layering -- protocols built >as stacks of microprotocols. The actual protocol you run could be virtually >synchronous, probabilistic, secure, SRM-style, RMTP-style -- this depends on >the choice of components in the stack you use. So one can imagine >standardizing the stacking framework, inter-layer optimization methodology, >etc, and yet not having any real opinion on the relative merits of SRM, >RMTP, pbcast (bimodal multicast), vscast, the causal-delta protocols of >Raynal, or whatever. Indeed, such an architecture would support many >solutions which could live side by side. The RFC's, as written, promote a >choice in favor of tree based nack-only schemes using local repair. Is this >a wise decision? Such protocols, after all, are not amenable to providing >at least some of the properties listed above! Why not opt for diversity and >illustrate this by showing that a single architecture can elegantly >accomodate many of the important protocol options? First, there is a difference between engineering/implementation issues, and standardization building blocks. As I mentioned above, a building block is sort of a "political unit of work". A vendor that wishes to offer many different protocols would be well advised to read through the very good work that Horus and others have done on how to do micro-protocol composition...but I think that micro protocols are too small of components to achieve consensus on in a reasonable time frame. The question of how many protocols to standardize is somewhat orthoganol, and obviously very politically charged. A RM/distributed systems toolkit vendor could offer many protocols, and high end developers (like many of the people who are active in the IETF) could actually make intelligent decisions to best pick the components they want. However, the vast majority of programmers--and the OS vendors that offer protocols to them--do not want to support 20 protocols. I personally think that in the 1-many space, 4 will be more than enough...and would actually like to see the router-assist broken in to a separate component, rather than as a protocol core, so that we could reduce this down to 3. Now, as to _which_ protocols to standardize, this is even more contentious, and is part of why I think the IETF initially chose to charter the RMRG rather than a WG. This has provided a forum for researchers to reach a partial consensus on many contentious topics, as we cross-educated each other. Taking RMTP-II as an example (and the only one I can speak for), while its name gives credit to Sanjoy's pioneering work, it is really a product of the last two+ years of RMRG meetings and all the great research that has been done on scaleable hierarchical protocols over the past 5 years. I think Vern Paxson originally (and wisely) proposed this 4-fold taxonomy, based on the type of network infrastructure support. I think bimodal multicast was not mentioned because it hasn't yet been published. We should mention it under the class of no-router support protocols. When I read it, my initial impression was that as proposed, it was more of a many-many distributed systems protocol, rather than a 1-many WAN protocol. However, I personally think that the class of protocols that has no network infrastructure support is much more difficult to solve than those that take advantage of router or server assist....and so any new contributions to that area, such as bimodal multicast, should be considered. Speaking for myself, I would rather not see more than 1 protocol core come out of any of the areas, and hope that a consensus can be reached among the researchers in each area. >6) I question the decision to focus on 1-many bulk data transfer. In >particular, the RFC's lack any content specific to the bulk data aspects and >seem inconsistent about whether or not this is really even a 1-many >situation. Why not just accept that reliable multicast will often be used >in situations with many senders, and often used in situations where >membership awareness is important? Often -- not always -- but also, not >rarely or never... Again, let me reiterate that 1-many is the _initial_ focus, because it is a well-bounded problem, which we have spent three years building consensus on, for which we know of specific applications that need it in the Big-I internet. Many-many apps and protocols make up a very real commercial segment, but the requirements are sufficiently different that we feel that they should be tackled separately. Hopefully, some of the building blocks we are starting with can be used in many-many protocols (one of the specific reasons why we chose to go with building blocks at all, over strong objections from the whole-protocol camp). Finally, group membership is definitely important...but more difficult to do in a scaleable fashion...which is why a hierarchical solution is the only one I think we have consensus on so far. Brian >From whetten@talarian.com Sun Jul 4 20:47:56 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id UAA02343 for ; Sun, 4 Jul 1999 20:47:56 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA05105 for ; Sun, 4 Jul 1999 20:47:55 -0700 (PDT) Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA05101 for ; Sun, 4 Jul 1999 20:47:54 -0700 (PDT) Received: from tahoe (ta038.talarian.com [204.147.187.38] (may be forged)) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id UAA02386; Sun, 4 Jul 1999 20:47:02 -0700 (PDT) Message-Id: <4.1.19990704143210.00dea680@mailhost.talarian.com> Message-Id: <4.1.19990704143210.00dea680@mailhost.talarian.com> X-Sender: bwhetten@mailhost.talarian.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 04 Jul 1999 14:42:17 -0700 To: Dah Ming Chiu - Sun Microsystems , rmt@lbl.gov From: Brian Whetten Subject: Re: Comments on building-block and design-space drafts In-Reply-To: <199907011712.NAA19783@bridge.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >1) My basic concern is whether this is too ambitious. How much success > have we had in standardizing APIs? It is perhaps feasible for > very well-defined and narrowly focused functions, such as FEC, encryption > and decryption, authentication, rate-based packet scheduling, or > rate calculation. For more abstract, complex, close-to-application > functions, it is very hard to get different people to agree. A good concern. :) I don't think the building blocks we singled out are overly ambitious, as they are all pretty cleanly defined, and I think we can get consensus on most of them. The API's are not the primary thing being standardized...the algorithms would be. However, building blocks definitely carry risks with them, which we should constantly be cognizant of. However, note that we didn't yet come to a consenus on session management building blocks...which could prove contentious, although I hope not. >2) I would like to see a more compeling argument for the building-block > effort, than the stated advantages which are mostly to ease software > development and maintanance. For example, we might want to make it > possible for (different) multicast receivers to receive from different > kinds of senders; or standardized router functions for different > end systems to use. The first doesn't seem to have much value to me. The second one is there as a building block (generic router assist), although perhaps not as an argument....good comment. >3) It might help to group the currently listed building blocks into two > categories - those that affect the main business of getting data from > sender to receivers (reliability, congestion control and security > mechanisms); and those that are session support functions (group, > session, tree config, notification). Maybe. >4) The coverage of the different topics are quite uneven, and lacks focus. > For example, in the security section, it talks about the need to > authenticate control messages to deal with DoS. There are zillions of > other DoS attacks in multicast, how are we going to deal with the rest > of them? Are there other areas you felt were uneven? Security is something that I feel will mostly be handled by SMUG, not by RMT (though others may disagree). We are trying to show where it fits in the overall picture, but not specify it...which means it will be necessity be treated more lightly. >From Ken_Birman@email.msn.com Tue Jul 6 01:20:03 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id BAA05914 for ; Tue, 6 Jul 1999 01:20:02 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA00501 for ; Tue, 6 Jul 1999 01:20:01 -0700 (PDT) Received: from secure.smtp.email.msn.com (secure.smtp.email.msn.com [207.46.181.28]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA00484 for ; Tue, 6 Jul 1999 01:20:00 -0700 (PDT) Received: from adsl40 - 208.251.65.23 by email.msn.com with Microsoft SMTPSVC; Tue, 6 Jul 1999 01:19:25 -0700 Message-ID: <001501bec788$41c10100$1741fbd0@cit.cornell.edu> From: "Kenneth P. Birman" To: , "Brian Whetten" References: <199907011712.NAA19783@bridge.East.Sun.COM> <4.1.19990704144448.00d82580@mailhost.talarian.com> Subject: Re: Comments on building-block and design-space drafts Date: Tue, 6 Jul 1999 04:19:09 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Hi Brian, To avoid one of those exponential dialogs, I won't reply on a point by point basis. I think that IETF has good reasons for focusing on one thing at a time, and if the focus is to be 1-many initially, this is fine. But again, one then needs to use care to make sure the RFT actually reflects that decision. The building blocks one seems to discuss many-many issues around the third page. I suspect that this is a sign of the difficult reality of the thing -- the issues don't split so easily, particularly if processes other than the sender help with recovery. Bimodal multicast: the protocol works the same way whether 1-many or many-to-many. I don't think this makes it a many-to-many protocol, though.... WIll I help on the extention to a more general solution? Sure. Actually, the people to really focus on here are Robbert van Renesse and Farnam Jahanian, who have a proposal for a standard in this area too, albeit less elaborate and less formalized than yours. (They focus on what might be called engineering building-block interfaces) Finally: on the distinction between political and engineering building blocks: I doubt that you would find an actual political consensus behind any specific building block simply because none of the protocols you have in mind has the market power to force a consensus. If I were Novell or Cisco I wouldn't want to accidently anoint the wrong protocol as the designated winner. So, it would be wise, politically, for IETF to adopt an engineering building block approach instead. This is not likely to be political in the unwinnable sense and hence has a good chance of success. The other kind of politics can lead to standards -- the world has lots of them -- but not actually to widespread adoption of the standard, it seems to me... Ken >From whetten@talarian.com Tue Jul 6 11:46:56 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id LAA09845 for ; Tue, 6 Jul 1999 11:46:56 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA20270 for ; Tue, 6 Jul 1999 11:46:55 -0700 (PDT) Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA20260 for ; Tue, 6 Jul 1999 11:46:54 -0700 (PDT) Received: from tahoe ([10.3.9.17]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id LAA03530; Tue, 6 Jul 1999 11:46:21 -0700 (PDT) Message-Id: <4.1.19990706105632.01cd2ba0@mailhost.talarian.com> X-Sender: bwhetten@mailhost.talarian.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 06 Jul 1999 11:45:48 -0700 To: "Kenneth P. Birman" , From: Brian Whetten Subject: Re: Comments on building-block and design-space drafts In-Reply-To: <001501bec788$41c10100$1741fbd0@cit.cornell.edu> References: <199907011712.NAA19783@bridge.East.Sun.COM> <4.1.19990704144448.00d82580@mailhost.talarian.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >I think that IETF has good reasons for focusing on one thing at a time, and >if the focus is to be 1-many initially, this is fine. But again, one then >needs to use care to make sure the RFT actually reflects that decision. The charter for RMT states that: "Initial efforts will focus solely on the standardization of the one-to-many transport of large amounts of data." So we felt it came implicitly out of the charter. The idea that we will then expand in to many-many has also been reiterated at the BOF and each RMRG meeting. But it never hurts to clarify...good point. >Bimodal multicast: the protocol works the same way whether 1-many or >many-to-many. I don't think this makes it a many-to-many protocol, >though.... My reasons for thinking that bimodal multicast was primarily a many-many LAN protocol were: 1) Unless I remember wrong, you stated in the paper that it was presently only designed to work in a LAN/enterprise environment, although you had promising avenues of exploration you were working on for WAN scalability. 2) One of the most exciting features of bimodal multicast, which you so well analyze, is its ability to give very strong statistical guarantees on atomicity of delivery, which makes it a potentially powerful building block for high-end distributed systems applications like air traffic control. I see that class of applications as fundamentally being many-many. Even if there are apps in that space that don't need many-many, the fault tolerance/atomicity/ordering guarantees needed by most of the apps in that space, combined with the typically milder scalability requirements, seem to me to justify treating that class as fundamentally different than the 1-many, non-ordered/atomic apps that the WG is initially focused on. Potentially bi-modal could be used for both, but it seems that the work to date has focused on distributed apps. >Finally: on the distinction between political and engineering building >blocks: I doubt that you would find an actual political consensus behind any >specific building block simply because none of the protocols you have in >mind has the market power to force a consensus. If I were Novell or Cisco I >wouldn't want to accidently anoint the wrong protocol as the designated >winner. So, it would be wise, politically, for IETF to adopt an engineering >building block approach instead. This is not likely to be political in the >unwinnable sense and hence has a good chance of success. The other kind of >politics can lead to standards -- the world has lots of them -- but not >actually to widespread adoption of the standard, it seems to me... Well, on this point I strongly disagree, based on long discussions over the past four years with both large OS vendors, router vendors, middleware vendors, and application vendors. At GlobalCast, we started out trying to sell RM in to both the many-many and 1-many markets. We quickly heard that the many-many market was not compelling for now, because of the lower needs for scalability. There was a lot of confusion at first about which 1-many protocols were needed, and we offered both SRM, RMTP, PGM, RMP, and RMTP-II to the market. What we heard from the market, after multiple years of being protocol agnostic, was that almost all of the immediate application needs could be met by RMTP-II. The interest breakdown was 70% RMTP-II, 20% RMP, 10% PGM. Again....RMTP-II is not my protocol. The reason I'm been trying to lead efforts (for 2+ years) to build a consensus around a HACK/server based protocol is that it is precisely what I've heard the market needs. Certainly not 100% of the market, and RMTP-II needs lots of work still before it is ready for worldwide deployment...but certainly at least 60% of the market. Again, I think that there is a real market need for a many-many protocol (as illustrated by the 20% interest in RMP), and hope that you, Robert, and others can help start building a consensus in that area, not necessarily for a framework of 100 different protocols, but towards the 1-2 concrete and fully tested protocols that an OS vendor or middleware vendor would want to support. A framework with lots of protocols makes lost of sense if you are selling to very high end customers, and can offer lots of consulting and support...the business model that ISIS successfully followed. For other vendors, the support of such a thing is too burdensome. Brian >From kenm@starburstcom.com Tue Jul 6 13:16:12 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id NAA11184 for ; Tue, 6 Jul 1999 13:16:11 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA16673 for ; Tue, 6 Jul 1999 13:16:05 -0700 (PDT) Received: from gummo.starburstcom.com (gummo.starburstsoftware.com [206.33.96.31]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA16656 for ; Tue, 6 Jul 1999 13:16:03 -0700 (PDT) Received: from accord.starburstsoftware.com (accord.starburstcom.com [206.33.96.71]) by gummo.starburstcom.com (8.9.1/8.9.1) with SMTP id QAA08078; Tue, 6 Jul 1999 16:07:49 -0400 (EDT) Received: by accord.starburstsoftware.com with Microsoft Mail id <01BEC7CA.DA53D180@accord.starburstsoftware.com>; Tue, 6 Jul 1999 16:16:07 -0400 Message-ID: <01BEC7CA.DA53D180@accord.starburstsoftware.com> From: Ken Miller To: "'luby@dfountain.com'" , "'rmt@lbl.gov'" Subject: RE: Comments on Design Space draft Date: Tue, 6 Jul 1999 16:16:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by listserv.lbl.gov id NAA11184 >>Reply to your message of 6/30/99 8:31 PM >>Michael Luby, Digital Fountain and ICSI >> >> >> >> >>Comments on: >>The Reliable Multicast Design Space for Bulk Data Transfer >> >> >>7. Page 12, Section 4.4, paragraph 6: The paragraph starts off with the >>sentence 'To apply reactive FEC, the sender must group data packets >>into rounds, and the receivers ...'. It is unclear what the >>definition of a 'round' is. One assumption could be that it is >>somewhere between the size of an application data unit and a packet. >>Perhaps the most compelling assumption is that it is the set of >>packet associated with an application data unit. Then, reports >>coming back on how many packets were missing could be considered as >>reception reports. The decision on when to terminate sending >>packets associated with one application data unit and move on to the >>next is based on all receivers having confirmed receipt of the >>entire application data unit using what logically would be >>considered reporting receptions (implemented perhaps using ACKs or >>NACKs as proposed). I believe a "round" is actually a parity group in which any packet or set of packets may be derived from the same number of parity packets from that group (or sometimes slightly more if the code is not perfect). >> >>8. Page 12, Section 4.4: No mention is made of applications where >>proactive FEC might be useful. Examples that might be mentioned are >>streaming video applications. One person who is doing work in this >>area is Avideh Zakhor at UC Berkeley (a reference to one of her >>relevant papers is given at the end). Another person is Philip Chou >>of Microsoft (I don't have any references to his work). They use >>some combination of proactive and reactive FEC. There are surely >>others. We have implemented both pro-active and reactive FEC in our MFTP based products since late last year. Our pro-active FEC is used in either one-way satellite environments with no back channel or in highly lossy radio environments with a back channel often encountered in tactical military radio environments. >> Ken Miller ----------------------------------------------------------------------------------------------------- Ken Miller Chairman & CTO StarBurst Software Phone: (978) 287-5560 x223 150 Baker Avenue FAX: (978) 287-5561 Concord, MA 01742 Web: http://www.starburstsoftware.com ------------------------------------------------------------------------------------------------------ >From Ken_Birman@email.msn.com Sat Jul 10 00:44:39 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id AAA04553 for ; Sat, 10 Jul 1999 00:44:39 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA14756 for ; Sat, 10 Jul 1999 00:44:37 -0700 (PDT) Received: from secure.smtp.email.msn.com (secure.smtp.email.msn.com [207.46.181.28]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA14752 for ; Sat, 10 Jul 1999 00:44:36 -0700 (PDT) Received: from adsl40 - 208.251.65.5 by email.msn.com with Microsoft SMTPSVC; Sat, 10 Jul 1999 00:44:04 -0700 Message-ID: <000201becaa7$fab270a0$0541fbd0@cit.cornell.edu> From: "Kenneth P. Birman" To: , "Brian Whetten" References: <199907011712.NAA19783@bridge.East.Sun.COM><4.1.19990704144448.00d82580@mailhost.talarian.com> <4.1.19990706105632.01cd2ba0@mailhost.talarian.com> Subject: Re: Comments on building-block and design-space drafts Date: Fri, 9 Jul 1999 13:19:13 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Hi Brian, Your point seems to come down to a marketing position for your company, GlobalCast: in your experience, GlobalCast only makes money off of RMTP-II, so this should be the standard. Fine... but in this case, why not just do an RMTP-II RFC, call it that ("the RMTP design space" and "RMTP building blocks") and promote truth in advertising? Based on GlobalCast's marketing experiences and partners, this would presumably draw at least the same degree of commercial interest as the current reliable multicast labels do. And you wouldn't find your group in the awkward position of seeming to create a reliable multicast standard, but actually doing so primarily for the hack based protocols of greatest interest to you as products, and for which you presumably hold some pretty strong patents. As it stands, you are putting forward a reliable multicast RFC and yet replying to comments about it by saying, more or less, RMTP-II doesn't do that, or doesn't need that, or that GlobalCast isn't interested in that market... In effect, rewriting the group's charter to narrow it around your product line. Ken >From whetten@talarian.com Mon Jul 12 02:55:16 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id CAA08153 for ; Mon, 12 Jul 1999 02:55:16 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA16601 for ; Mon, 12 Jul 1999 02:55:15 -0700 (PDT) Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA16597 for ; Mon, 12 Jul 1999 02:55:14 -0700 (PDT) Received: from tahoe (dhcp29182.ietf.uninett.no [128.39.29.182]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id CAA09001; Mon, 12 Jul 1999 02:54:41 -0700 (PDT) Message-Id: <4.1.19990712024649.00a15f00@mailhost.talarian.com> X-Sender: bwhetten@mailhost.talarian.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 12 Jul 1999 02:48:50 -0700 To: "Kenneth P. Birman" , From: Brian Whetten Subject: Re: Comments on building-block and design-space drafts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Ken, Perhaps I didn't do a good enough job of explaining my points. First, let me see if I correctly understood the points you were making, and that I was attempting to respond to. I understood you to be stating that: 1) You didn't think any of the major classes of protocols under discussion (HACK based, NACK without server or router support, open-loop FEC only, router supported) met a sufficient market demand to be turned into real standards that would be deployed by major vendors. 2) Therefore we should instead by standardizing a framework (perhaps similar to Horus) which would allow many protocols to be standardized and deployed simultaneously. My response was meant to convey two major points: 1) Yes, there are protocols that meet enough of the current market demand to have the potential for widespread adoption. We know for sure that such protocols need to evolve as we get additional real world experience with them, which is part of why building blocks are so important, but we can definitely get the process going now. 2) The major vendors you talk about are not, from my experience, very interested in deploying more complex toolkits, which offer lots of protocols, because they require dramatically more support and QA. In order to lend weight to these opinions, I called on my experience as part of one of the few companies which has offered multiple RM protocols to the market. Neither I, nor any of the other document editors, feel that a single protocol (such as RMTP-II) can meet all the standards needs for RM, even in the scope of the initial focus of 1-many distribution--and have no plans of only standarizing a single protocol. We also know that we do not understand every market requirement or every technical detail. Both of these motivations are driving the goal of using building blocks in the standards process. However, many concerns have been raised (by major vendors) about the risks of "protocol explosion". As you so rightly point out, it is very important for this body to take in to account market requirements, if we hope to have these vendors pick up the standards and promulgate them in to widespread use. Again, I'd love to see you and/or one of your colleagues, as some of the top experts in many-many multicast, pick up the ball in the RMRG for many-many multicast, which we are now starting to work on there. The RMRG could really use your help in the consensus building exercise that needs to be done--similar to the processes we have been working on in one-many multicast for the past years, and are continuing to work on as we finally push these efforts in to the IETF. Brian At 01:19 PM 7/9/99 -0400, Kenneth P. Birman wrote: >Hi Brian, > >Your point seems to come down to a marketing position for your >company, GlobalCast: in your experience, GlobalCast only makes >money off of RMTP-II, so this should be the standard. > >Fine... but in this case, why not just do an RMTP-II RFC, call >it that ("the RMTP design space" and "RMTP building blocks") >and promote truth in advertising? Based on GlobalCast's >marketing experiences and partners, this would presumably >draw at least the same degree of commercial interest as the >current reliable multicast labels do. And you wouldn't find your >group in the awkward position of seeming to create a reliable >multicast standard, but actually doing so primarily for the hack >based protocols of greatest interest to you as products, and >for which you presumably hold some pretty strong patents. > >As it stands, you are putting forward a reliable multicast RFC >and yet replying to comments about it by saying, more or less, >RMTP-II doesn't do that, or doesn't need that, or that GlobalCast >isn't interested in that market... In effect, rewriting the group's >charter to narrow it around your product line. > >Ken > > > > >From tmont@csee.wvu.edu Mon Jul 12 10:52:31 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id KAA10446 for ; Mon, 12 Jul 1999 10:52:31 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA07364 for ; Mon, 12 Jul 1999 10:52:30 -0700 (PDT) Received: from Venus.ivv.nasa.gov (venus.ivv.nasa.gov [129.164.30.24]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA07336 for ; Mon, 12 Jul 1999 10:52:24 -0700 (PDT) Received: from [129.164.10.55] by Venus.ivv.nasa.gov; Mon, 12 Jul 1999 13:54:07 -0400 Message-Id: <4.1.19990712131414.00ad3d10@naur.csee.wvu.edu> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 12 Jul 1999 13:49:43 -0400 To: Brian Whetten , "Kenneth P. Birman" , From: "Todd L. Montgomery" Subject: Re: Comments on building-block and design-space drafts In-Reply-To: <4.1.19990712024649.00a15f00@mailhost.talarian.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" I wanted to make a few observations and comments on the drafts being developed and on comments seen on the mailing list. First off, I think the drafts are good first steps. Most of the shortcomings have been mentioned and I am glad to see things are progressing. However, the building block draft is really vague..... I mean, really vague..... it really does not describe a framework, it just lists what should be in the framework with no technical details. It is necessary to develop the building block draft as it stands, but it is definitely not a document that I feel can go very far without a LOT more detail. I think that the building block draft should be retitled to "Building Block Design Space" and be its own document. We need some initial design here. I think with the work done with Horus, APPLCORE, and even the whole design pattern field, we should be able to draw on a large body of work to aid us in this. As a start, I would suggest basing things on capabilities (like is used in IMAP, etc.). (If I was not wearing 20 hats, I would take a stab at this....) Secondly, I want to respond to Brian's comment on the demand for different protocols (RMTP-II 70%, RMP 20%, PGM 10%). I have to disagree.... first off, I am no longer with GlobalCast so I am not qualified to talk about their specific market. However, even when I was involved with GlobalCast, I wouldn't have agreed with Brian's assessment. My point here is simple.... using protocol market demand (as defined by one or two people) to drive feature sets is not going to be productive. We should understand the design space (like the building block draft spells out), build an extensible framework (like used by a lot of other protocols), and put the features in that we each need. Basing importance of features on what one or even a few say are important is not something I feel this working group _needs_ to do. If we are building a framework that can support a lot of varying protocols, then let's develop a simple framework, and let each person carve out their own space in it. We have all worked in this space for a while. We know a good bit about what we need. At least as much as we need to know to get something out that works and won't blow up the Internet. :) For most RM apps, I would choose PGM or SRM. They are light, simple, and easy to use. The more advanced features that RMTP-II and RMP offer can be run on top of them. This is the lesson from Horus in my eyes. I also see a LOT of demand for PGM... and we are going to be seeing a lot of implementations of it over the next few months. BTW: I WILL update the RM links page eventually. But I'm spread a little thin right now to get to it. :) -- Todd >From kenm@starburstcom.com Mon Jul 12 14:26:10 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id OAA13523 for ; Mon, 12 Jul 1999 14:26:06 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA17200 for ; Mon, 12 Jul 1999 14:26:05 -0700 (PDT) Received: from gummo.starburstcom.com (gummo.starburstsoftware.com [206.33.96.31]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA17184 for ; Mon, 12 Jul 1999 14:26:02 -0700 (PDT) Received: from accord.starburstsoftware.com (accord.starburstcom.com [206.33.96.71]) by gummo.starburstcom.com (8.9.1/8.9.1) with SMTP id RAA11503; Mon, 12 Jul 1999 17:15:00 -0400 (EDT) Received: by accord.starburstsoftware.com with Microsoft Mail id <01BECC8B.5A11F7C0@accord.starburstsoftware.com>; Mon, 12 Jul 1999 17:24:09 -0400 Message-ID: <01BECC8B.5A11F7C0@accord.starburstsoftware.com> From: Ken Miller To: "'tmont@csee.wvu.edu'" , "'Brian Whetten'" , "'Ken_Birman@email.msn.com'" , "'rmt@lbl.gov'" Subject: RE: Comments on building-block and design-space drafts Date: Mon, 12 Jul 1999 17:24:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by listserv.lbl.gov id OAA13523 I can also make the comment that 90+% of the current installations of reliable multicast based applications are actually MFTP, and it has gained the experience of 4 years in the commercial marketplace with production use. Ken >>Reply to your message of 7/12/99 1:46 PM >> >>I wanted to make a few observations and comments on the drafts >>being developed and on comments seen on the mailing list. >> >>First off, I think the drafts are good first steps. Most of >>the shortcomings have been mentioned and I am glad to see >>things are progressing. However, the building block draft is >>really vague..... I mean, really vague..... it really >>does not describe a framework, it just lists what should be >>in the framework with no technical details. It is necessary to >>develop the building block draft as it stands, but it is definitely >>not a document that I feel can go very far without a LOT more >>detail. I think that the building block draft should be >>retitled to "Building Block Design Space" and be its own >>document. We need some initial design here. I think with the work done with >>Horus, APPLCORE, and even the whole design pattern field, >>we should be able to draw on a large body of work to aid us >>in this. As a start, I would suggest basing things on >>capabilities (like is used in IMAP, etc.). (If I was >>not wearing 20 hats, I would take a stab at this....) >> >>Secondly, I want to respond to Brian's comment on the >>demand for different protocols (RMTP-II 70%, RMP 20%, PGM 10%). >>I have to disagree.... first off, I am no longer with GlobalCast >>so I am not qualified to talk about their specific market. However, >>even when I was involved with GlobalCast, I wouldn't have agreed >>with Brian's assessment. My point here is simple.... using >>protocol market demand (as defined by one or two people) to drive feature >>sets is not going to be productive. We should understand >>the design space (like the building block draft spells out), >>build an extensible framework (like used by a lot of other >>protocols), and put the features in that we each need. >>Basing importance of features on what one or even a few >>say are important is not something I feel this working group >>_needs_ to do. If we are building a framework that can support >>a lot of varying protocols, then let's develop a simple >>framework, and let each person carve out their own space in it. >>We have all worked in this space for a while. We know a good >>bit about what we need. At least as much as we need to know >>to get something out that works and won't blow up the >>Internet. :) >> >>For most RM apps, I would choose PGM or SRM. They are light, >>simple, and easy to use. The more advanced features that >>RMTP-II and RMP offer can be run on top of them. This is >>the lesson from Horus in my eyes. I also see a LOT of demand >>for PGM... and we are going to be seeing a lot of implementations >>of it over the next few months. >> >>BTW: I WILL update the RM links page eventually. But I'm spread >>a little thin right now to get to it. :) >> >>-- Todd >> >>End of message ----------------------------------------------------------------------------------------------------- Ken Miller Chairman & CTO StarBurst Software Phone: (978) 287-5560 x223 150 Baker Avenue FAX: (978) 287-5561 Concord, MA 01742 Web: http://www.starburstsoftware.com ------------------------------------------------------------------------------------------------------ >From whetten@talarian.com Tue Jul 13 06:57:58 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id GAA17600 for ; Tue, 13 Jul 1999 06:57:57 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA21617 for ; Tue, 13 Jul 1999 06:57:55 -0700 (PDT) Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA21613 for ; Tue, 13 Jul 1999 06:57:54 -0700 (PDT) Received: from tahoe (dhcp30238.ietf.uninett.no [128.39.30.238]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id GAA28205; Tue, 13 Jul 1999 06:55:24 -0700 (PDT) Message-Id: <4.1.19990713010459.00d26f00@mailhost.talarian.com> Message-Id: <4.1.19990713010459.00d26f00@mailhost.talarian.com> X-Sender: whetten@pop3.concentric.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 13 Jul 1999 01:10:29 -0700 To: Ken Miller , "'tmont@csee.wvu.edu'" , "'Brian Whetten'" , "'Ken_Birman@email.msn.com'" , "'rmt@lbl.gov'" From: Brian Whetten Subject: RE: Comments on building-block and design-space drafts In-Reply-To: <01BECC8B.5A11F7C0@accord.starburstsoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" My appologies, Ken. I should have also mentioned MFTP when discussing market interest and uptake. Some may disagree, but I classify MFTP as a one-layer HACK protocol (with, of course, NACK and FEC assist), at least at the pure transport level. MFTP of course also includes higher level file-transfer-specific session management, which we need to consider as we define the higher level building blocks. Brian At 05:24 PM 7/12/99 -0400, Ken Miller wrote: >I can also make the comment that 90+% of the current installations of >reliable multicast based applications are actually MFTP, and it has gained >the experience of 4 years in the commercial marketplace with production use. > >Ken > >>>Reply to your message of 7/12/99 1:46 PM > >> > >>I wanted to make a few observations and comments on the drafts > >>being developed and on comments seen on the mailing list. > >> > >>First off, I think the drafts are good first steps. Most of > >>the shortcomings have been mentioned and I am glad to see > >>things are progressing. However, the building block draft is > >>really vague..... I mean, really vague..... it really > >>does not describe a framework, it just lists what should be > >>in the framework with no technical details. It is necessary to > >>develop the building block draft as it stands, but it is definitely > >>not a document that I feel can go very far without a LOT more > >>detail. I think that the building block draft should be > >>retitled to "Building Block Design Space" and be its own > >>document. We need some initial design here. I think with the work done with > >>Horus, APPLCORE, and even the whole design pattern field, > >>we should be able to draw on a large body of work to aid us > >>in this. As a start, I would suggest basing things on > >>capabilities (like is used in IMAP, etc.). (If I was > >>not wearing 20 hats, I would take a stab at this....) > >> > >>Secondly, I want to respond to Brian's comment on the > >>demand for different protocols (RMTP-II 70%, RMP 20%, PGM 10%). > >>I have to disagree.... first off, I am no longer with GlobalCast > >>so I am not qualified to talk about their specific market. However, > >>even when I was involved with GlobalCast, I wouldn't have agreed > >>with Brian's assessment. My point here is simple.... using > >>protocol market demand (as defined by one or two people) to drive feature > >>sets is not going to be productive. We should understand > >>the design space (like the building block draft spells out), > >>build an extensible framework (like used by a lot of other > >>protocols), and put the features in that we each need. > >>Basing importance of features on what one or even a few > >>say are important is not something I feel this working group > >>_needs_ to do. If we are building a framework that can support > >>a lot of varying protocols, then let's develop a simple > >>framework, and let each person carve out their own space in it. > >>We have all worked in this space for a while. We know a good > >>bit about what we need. At least as much as we need to know > >>to get something out that works and won't blow up the > >>Internet. :) > >> > >>For most RM apps, I would choose PGM or SRM. They are light, > >>simple, and easy to use. The more advanced features that > >>RMTP-II and RMP offer can be run on top of them. This is > >>the lesson from Horus in my eyes. I also see a LOT of demand > >>for PGM... and we are going to be seeing a lot of implementations > >>of it over the next few months. > >> > >>BTW: I WILL update the RM links page eventually. But I'm spread > >>a little thin right now to get to it. :) > >> > >>-- Todd > >> >>>End of message > >---------------------------------------------------------------------------- >------------------------- >Ken Miller >Chairman & CTO >StarBurst Software Phone: (978) 287-5560 x223 >150 Baker Avenue FAX: (978) 287-5561 >Concord, MA 01742 Web: http://www.starburstsoftware.com >---------------------------------------------------------------------------- >-------------------------- > >From speakman@cisco.com Tue Jul 13 21:09:25 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id VAA20845 for ; Tue, 13 Jul 1999 21:09:24 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA24454 for ; Tue, 13 Jul 1999 21:09:24 -0700 (PDT) Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA24450 for ; Tue, 13 Jul 1999 21:09:23 -0700 (PDT) Received: from localhost (speakman@localhost) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id VAA25668 for ; Tue, 13 Jul 1999 21:08:52 -0700 (PDT) Message-Id: <199907140408.VAA25668@zipper.cisco.com> To: rmt@lbl.gov Subject: Scope of the bb spec Date: Tue, 13 Jul 1999 21:08:52 -0700 From: Tony Speakman I have several more narrowly focussed comments on the bb draft, but I'd like to address a few basic points ahead of the wg meeting. The most fundamental is that I think the list in section 3 contains 3 items that don't relate to the transport of data in the network and don't require standardization. These are group membership, session management, and tree configuration. These three components add a conceivably large variety of attributes to ways of operating a multicast transport protocol, but they can be designed entirely in isolation from the TP and, since they can have no dependencies on it, can evolve and diverge in variety as higher layer models of multicast service emerge. From the network perspective, there is no need to mandate anything about these components. From a practical/ commercial/application/perspective, I'm sure the market would like there to be a common implementation of these components, but we should keep our hands off them and leave creative application layer developers free to improvise these components according to application feature requirements. Since there's already an IRTF for security, that leaves us with data reliability and congestion control, a much more focussed mandate and one which is already aligned with the coverage we have seen in the RM IRTF. At a more specific level of detail, I'd like to clarify an important distinction I see blurred in the statement just ahead of section 4 that PGM contains an hierarchical element and thus a tree building component. Clarifiying the notion of tree building helps in understanding why I think it can come off the list along with the other two. One of the things SPMs do in PGM is carry explicit neighbour information downstream on the distribution tree. This function is entirely superfluous in a pure PGM topology, so in it's current incarnation it is just establishing a logical distribution tree that is used to return NAKs. That tree is coincident with the data distribution tree and constists of network elements. It is just reinforcing an hierarchical relationship those network elements already have as a result of multicast routing protocols. By contrast, the arrangement of non-network elements into a hierarchy relative to each other does require tree building and that tree building may or may not relate to the distribution tree. The tree building component should permit ACK aggregators or retransmitters to be arranged in an arbitrary topology optimized for any metric including a metric that allows that hierarchy to be coincident with the distribution tree. IMHO, Tony S >From mpullen@netlab.gmu.edu Thu Jul 15 08:07:48 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id IAA26139 for ; Thu, 15 Jul 1999 08:07:47 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA05308 for ; Thu, 15 Jul 1999 08:07:46 -0700 (PDT) Received: from netlab.gmu.edu (netlab40.gmu.edu [129.174.40.125]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA05298 for ; Thu, 15 Jul 1999 08:07:45 -0700 (PDT) Received: from localhost (mpullen@localhost) by netlab.gmu.edu (8.8.5/8.8.5) with SMTP id LAA13210; Thu, 15 Jul 1999 11:07:43 -0400 (EDT) Date: Thu, 15 Jul 1999 11:07:43 -0400 (EDT) From: Mark Pullen X-Sender: mpullen@netlab To: rmt@lbl.gov cc: Mark Pullen Subject: Re: I-D ACTION:draft-ietf-rmt-design-space-00.txt In-Reply-To: <199906211831.OAA07374@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII RMT folks, I am chagrined that I missed today's session, due to a schedule error. Here are some points I had planned to make regarding the Design Space draft. These are based on experience with a hybrid RM protocol for distributed simulation. The points admittedly are not specific to bulk data transfer, but then a lot of this I-D seems to go beyond bulk data transfer. That is not necessarily a bad thing, because this document is helping to build up a common frame of reference for RM in general. 1. Introduction: 5th line "many" seems strong, perhaps it should be "some" 2. Application Constraints: two constraint categories seem to be missing: o Does the application send a mix of reliable and best-effort traffic? (it is possible to use the best-effort traffic to inform receivers that a new reliable message has been sent; they can NACK if they have not received) o Does the application require intermediate values of transmitted information, or only the last transmitted value? (if only the last value there is a large reduction in state requirements for repairs, somewhat related to the point on sender state reduction made in section 4.2) 2.5 Time-bounded delivery: it might be good to refine the point in the last sentence, which states "Time bounded delivery usually also implies a semi-reliable protocol..." Given that this draft envisions use of a shared network with only best-effort IP, one can say that time-bounded delivery ALWAYS implies a semi-reliable protocol, because there is no mechanism to ensure that other users' transmissions will not congest the network. 3.3 Network Assistance: I'm not sure the taxonomy here covers the cases completely. We have been working on a design for many-to-many multicast where the transport layer in participating hosts can be elected to answer with repairs (transparent to the application), in order to localize repairs as much as possible. This might fit under "Server-based approaches", but I would suggest a category "Peer-based approaches" to cover the case where any multicast group member can provide repairs, not just dedicated servers. Mark >From mjh@aciri.org Thu Jul 15 08:29:04 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id IAA26250 for ; Thu, 15 Jul 1999 08:29:04 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA12003 for ; Thu, 15 Jul 1999 08:29:03 -0700 (PDT) Received: from aardvark.aciri.org (aardvark.aciri.org [192.150.187.20]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA11984 for ; Thu, 15 Jul 1999 08:29:01 -0700 (PDT) Received: from aardvark.aciri.org (localhost [127.0.0.1]) by aardvark.aciri.org (8.9.2/8.9.2) with ESMTP id IAA82081; Thu, 15 Jul 1999 08:28:42 -0700 (PDT) (envelope-from mjh@aardvark.aciri.org) From: Mark Handley X-Organisation: ACIRI To: Mark Pullen cc: rmt@lbl.gov Subject: Re: I-D ACTION:draft-ietf-rmt-design-space-00.txt In-reply-to: Your message of "Thu, 15 Jul 1999 11:07:43 EDT." Date: Thu, 15 Jul 1999 08:28:42 -0700 Message-ID: <82079.932052522@aardvark.aciri.org> Sender: mjh@aciri.org >RMT folks, > >I am chagrined that I missed today's session, due to a >schedule error. Here are some points I had planned to make >regarding the Design Space draft. Thanks Mark - I mostly agree with your points, and will include them in the next version. One exception: >2. Application Constraints: two constraint categories seem to >be missing: > >o Does the application send a mix of reliable and best-effort > traffic? (it is possible to use the best-effort traffic to > inform receivers that a new reliable message has been sent; > they can NACK if they have not received) What you describe is less a requirement than an implementation question. This mechanism is normal for a many-to-many NACK-based protocol such as SRM, where tail loss detection is critical. It's less clear to me how important it is for bulk data transfer applications, which this draft covers though. Tail loss detection is still required, but can normally be dealt with though other means. Cheers, Mark >From J.Crowcroft@cs.ucl.ac.uk Fri Jul 16 01:16:19 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id BAA00025 for ; Fri, 16 Jul 1999 01:16:18 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA16013 for ; Fri, 16 Jul 1999 01:16:17 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id BAA16009 for ; Fri, 16 Jul 1999 01:16:16 -0700 (PDT) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 16 Jul 1999 09:16:13 +0100 To: rmt@lbl.gov Subject: RM delivery semantics Date: Fri, 16 Jul 1999 09:16:12 +0200 Message-ID: <384.932112972@cs.ucl.ac.uk> From: Jon Crowcroft I guess it would be nice to really nail down what we meant by RM delivery semantics stable mesages refers to messages which the application has receiverd acknowldged messaged refers to thanks the transport has receiverd in the example i gave during RMT, NFS uses an RPC protocol - A write message in NFS is supposed to have the semantics of unix write, which is to write thru the caxce onto stable store... If the RPC is carried over UDP, the RPC response from the application happends when the message has been resceived and saved by the application If the RPC is carried over TCP, the RPC level dows the same thiing, but, potentnailly, if the reciver is a bit slow in gettign the data to disk, the TCP in the reciver will aclk the TCP data packet that carried the ack and then the recvier rpc response will cause the send of a data packet (with the same ack seq number of course) the diffrence in the two TCP cases shows that while there are two levels, that transport acknlowdgement of receipt, and the applicatio acknowledgement of receipt, they are OFTEN piggybacks for lots of good reasons. THe point for RM protocls is that (of course,) the tight timeing coupling required to get this piggybacking to work is completely at odds with a lot of the feedback implosion control strategies....i.e. it is probably anathema to scaling. Also, we should note, this is ANOTHER reason to staty wih application where the _eventual_ message stability is important (although sender knowledge of all-receiver meassage stability may not be) bcecause we are not doing transacations or RPC like applications, but ratehr, long-lived ftp like applications...... my two NOKs jon >From redmonst@cisco.com Mon Jul 19 03:10:09 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id DAA08181 for ; Mon, 19 Jul 1999 03:10:09 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA01175 for ; Mon, 19 Jul 1999 03:10:08 -0700 (PDT) Received: from jindo.cisco.com (jindo.cisco.com [171.69.43.22]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA01171 for ; Mon, 19 Jul 1999 03:10:07 -0700 (PDT) Received: from jaws.cisco.com (jaws.cisco.com [198.135.1.36]) by jindo.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with SMTP id DAA27233 for ; Mon, 19 Jul 1999 03:09:34 -0700 (PDT) Date: Mon, 19 Jul 1999 11:09:32 +0100 (BST) From: Richard Edmonstone To: rmt@lbl.gov Subject: commets on drafts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Here are some specific comments on the two RMT drafts. Cheers, Richard. -- Comments for buildingblocks-00.txt ---------------------------------- a1.) Page 3, para 2; is 1000 - 10000 a large enough target for number of receivers ? For an internet multicast protocol should our aim be higher ? a2.) Page 4, section 1.1. The wording implies that the 4 "families" of protocol are mutually exclusive. For example, a reader new to the problem space would think from reading this section that FEC was unreliable and mutually exclusive of the others. IMHO, text could be added after points 1-4 along the lines of: "Note that these families are not exclusive. For example, some protcols may combine FEC and an ACK or NAK mechanism to increase overall reliability." a3.) Page 4, section 1.1, point 2. The server assist point misses out the notion of local retransmitters that can be useful in certain network scenarios; eg. asymmetric networks or at key points in the internet. This notion should not be lost and could either be added to this section or somewhere else. a4.) Page 4, section 1.1, point 3. An important point of router assist can be the strengthening of NAKs; the routers maintain state and retransmit NAKs in a hop by hop basis. This could be mentioned so as not to misrepresent PGM. a5.) Page 7, section 3. Are we missing a section for the obvious protocol component of data delivery ? Should this or the data reliability section mention a "Data Ordering" sub component ? a6.) Page 8, section 3. Session management section. There was some debate at the IETF RMT meeting about ACKs and whether an ACK based protocol gives better "message stability" than a NAK based protocol. It was suggested that "receipt confirmation" is appropriate and could be viwed as separate from the transport level ACK mechanism. Do we want to put the function of receipt confirmation into a building block ? a7.) Page 9, section 3.1. After the IETF meeting, we are in a position to clarify that only denial of service style attacks are within the scope of the RMT protocols and that the other security issues will be dealt with by SMuG. The text could be changed to reflect this. This comment applies to section 4.6 aswell. a8.) Reference FLST98; one author is S.Lin not A.Lin. Comments for design-space-00.txt ---------------------------------- b1.) Page 3, section 2. A missing application constraint is : "Does the application need ordered data ?". b2.) Page 3, section 2.1. Relates to comment a6 above. I think we need to decouple the transport layer packet by packet ACK/NAK mechanism from the notion of receipt confirmation. Here's a good place to do it. ADU acknowledgement still implies (to me) smallish data chunks of a form. I'd like to see an session ack component based around acking "large" self-describing objects. This component would sit on "top" of the data delivery / reliability component, regardless of this component's reliability mechanism (ACK, NAK, FEC or whatever). b3.) Page 4, section 2.3. Section should state that the different solutions can be combined into hybrids. See comment a2 above. b4.) Maybe I'm biased, but I don't hold with the statements in section 3.1 as regards the cost of extra state required for router assist. I'd like to see these statements removed and replaced with a statement that "it may take several years to deploy router assist in the internet, due to the release / quality cycle associated with service providers upgrading to new router software." b5.) page 5, section 3.2, paragraph 1. Limits on the number of S,G states that internet routers can deal with definately limit the use of multicast for NAK suppression. Local wire multicasts could be used for some local suppression. The notion of NAK elimination on the return path could be brought in here aswell. b6.) page 10, section 4.2. NAK elimination needs mentioned aswell as the already mentioned suppression. Probably a small subsection 4.2.2 could be added for this. b7.) page 10, section 4.2.1, point 4. PGM is mis-represented here. PGM uses several mechanisms to suppress NAKs. It uses random timers on the receivers that will adjust their random period dynamically to local group size. It uses feedback from the 1st hop PGM capable router to the receivers to suppress NAKs. In addition, it optionally uses a local scope multicast from a NAKing receiver to other receivers. b8.) page 10, section 4.2.1, last paragraph. For my education, what is a "sender triggered NACK mechanism" ? b9.) Reference FLST98; one author is S.Lin not A.Lin. >From whetten@talarian.com Tue Jul 20 14:45:42 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id OAA17902 for ; Tue, 20 Jul 1999 14:45:41 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA11937 for ; Tue, 20 Jul 1999 14:45:40 -0700 (PDT) Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA11925 for ; Tue, 20 Jul 1999 14:45:39 -0700 (PDT) Received: from tahoe (ta035.talarian.com [204.147.187.35] (may be forged)) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id OAA15225; Tue, 20 Jul 1999 14:45:01 -0700 (PDT) Message-Id: <4.1.19990720100536.024ce9f0@mailhost.talarian.com> Message-Id: <4.1.19990720100536.024ce9f0@mailhost.talarian.com> X-Sender: bwhetten@mailhost.talarian.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 20 Jul 1999 10:32:42 -0700 To: Jon Crowcroft , rmt@lbl.gov From: Brian Whetten Subject: Re: RM delivery semantics In-Reply-To: <384.932112972@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Jon, I think this debate simply comes down to the question of whether or not message stability requires getting acknowledgements from the transport, or from the application. From a semantics/taxonomy perspective, I would suggest/agree that we have a major division between "statistical reliability/goodput ensurance" and "message stability", and then an additional minor division within message stability, as to whether the acknowledgement is from the transport or the application. i.e. Reliability Semantics - Statistical Reliability (anyone have a better name yet?) - Message Stability - Optimistic Stability (transport layer) - Pessimistic Stability (transport layer) - Application level stability >From a building blocks/implementation perspective, unless we are doing high-end (ISIS/Horus/RMP/etc.) fault tolerant applications (which we're not, for now), the primary reason I see to care about getting an application level acknowledgement is if the application is going to do something persistent with the data, either writing it to disk or to a database--which may happen relatively quickly (<50ms), or could take up to seconds to complete. I could see some other cases which would have much longer time scales for application acks, but I think those are outside our primary scope. >From a layering semantics perspective, I feel that a transport protocol should provide transport layer semantics as the default. We need to remember that our principal audience is the same community that uses sockets, not the high-end research-aware developers that participate in the IETF. >From an implementation/performance perspective, having an implementation that offers high end developers the option to piggy-back application level acknowledgements on top of a TRACK (previously named HACK) infrastructure seems useful, and I don't think it will impact performance that much. Taking RMTP-II as an example, message stability is reported in a different field than those used for requests for retransmission and measurements of loss. Therefore, it would not directly impact the performance of the TRACK generation, retransmission algorithms, or of congestion control. It would simply delay the stability at the sender, and require additional message buffering throughout the protocol. Again taking RMTP-II as an example, it already offers two levels of message stability -- optimistic and pessimistic. Application message stability semantics are a simple extension to pessimistic aggregation (they make no sense with optimistic aggregation), so you can just have a third option, for application stability. Again, I'd recommend that from a usability perspective we don't focus on application stability except as a special option...but its pretty trivial to standardize/implement. Brian At 09:16 AM 7/16/99 +0200, Jon Crowcroft wrote: > >I guess it would be nice to really nail down what we meant by RM >delivery semantics > >stable mesages refers to messages which the application has receiverd >acknowldged messaged refers to thanks the transport has receiverd > >in the example i gave during RMT, NFS uses an RPC protocol - >A write message in NFS is supposed to have the semantics of unix >write, which is to write thru the caxce onto stable store... > >If the RPC is carried over UDP, the RPC response from the application >happends when the message has been resceived and saved by the >application > >If the RPC is carried over TCP, the RPC level dows the same thiing, >but, potentnailly, if the reciver is a bit slow in gettign the data to >disk, the TCP in the reciver will aclk the TCP data packet that >carried the ack and then the recvier rpc response will cause the >send of a data packet (with the same ack seq number of course) > >the diffrence in the two TCP cases shows that while there are two >levels, that transport acknlowdgement of receipt, and the applicatio >acknowledgement of receipt, they are OFTEN piggybacks for lots of good >reasons. > >THe point for RM protocls is that (of course,) the tight timeing >coupling required to get this piggybacking to work >is completely at odds with a lot of the feedback implosion control >strategies....i.e. it is probably anathema to scaling. > >Also, we should note, this is ANOTHER reason to staty wih application >where the _eventual_ message stability is important (although sender >knowledge of all-receiver meassage stability may not be) bcecause we >are not doing transacations or RPC like applications, but ratehr, >long-lived ftp like applications...... > >my two NOKs > > >jon > >From vogels@cs.cornell.edu Wed Jul 21 07:21:10 1999 Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id HAA20673 for ; Wed, 21 Jul 1999 07:21:09 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA09305 for ; Wed, 21 Jul 1999 07:21:09 -0700 (PDT) Received: from opus.cs.cornell.edu (EXCHANGE.CS.CORNELL.EDU [128.84.248.73]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA09301 for ; Wed, 21 Jul 1999 07:21:08 -0700 (PDT) Received: by EXCHANGE.CS.CORNELL.EDU with Internet Mail Service (5.5.2448.0) id <311Q4CJK>; Wed, 21 Jul 1999 10:20:36 -0400 Message-ID: From: Werner Vogels To: rmt@lbl.gov Subject: RE: RM delivery semantics Date: Wed, 21 Jul 1999 10:20:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" A "short" reply, I feel a more extensive discussion belongs in RMRG not rmt. The way I read Jon's message, and the way it is important for the RMT building block design space, is that: if the application or protocols above the immediate transport wants to piggyback some additional data on transport information flowing back to the sender (xxACK's in general), how can we support this. - I don't think it would be difficult to get consensus on whether the piggybacking is a "good thing": it is only the transport layer that has access to a preferred path back to the sender. It does not seem a good idea if the application would also start sending UDP packets back to the sender with stability style information, where they are likely to travel side-by-side xxACK messages triggered by the same data. - In contrast to Brian I do not feel it is simple to implement. The biggest problem I see, is that it is almost impossible to do with the transport being a black box. In the ideal case if the receiver transport periodically sends back reports to the sender, it could upcall to an upper module to request whether it has data to piggyback. At the sender, at the receipt of this report, it indicates this data to the upper sender module. Perfect, optimal resource usage. The problem starts if the "report back to the sender" is not that simple: if we use a tree structure, or use gossip techniques for the reports, intermediate nodes that are able to collapse multiple reports into a single message, would also need a condensation function for the data that the upper modules at receivers have generated. If the data is simple: a single sequence number identical to the message seq#, it could be done. If the data is more extensive it becomes almost impossible to have this knowledge in all the intermediate nodes. The second problem here is what the sender can do with the data reported to it: if he receives a condensed report, does he know to which receivers it applies without having a view of the transport topology? Which means that more of the transport information needs to be exposed to support this. So I feel it can be done, but not by using strict layering or black box transports. - some additional experiences: it is a misconception that application stability information is only useful for fancy fault-tolerance style applications. It is dangerous to split the world into two parts "networking" on one side and "distributed systems" on the other. You will miss out on a lot of good stuff if you draw a strict line at the transport level, and ignore the rest as "research". For example if there is a simple way to disseminate stability info, a number of the web object caching protocols can be made a lot simpler. While currently many of your customers may be still stuck at socket level (Brian's words, not mine ...), eventually they are all solving problems in the application that are distributed in nature and thus will be doing things that are beyond simple transport message exchange. But they are far from fault-tolerance style apps. Our experience is that customers are looking hard at the reliable-multicast space to solve a number of their scalability problems, restructuring systems such that they can exploit rm to make their apps scalable, and the results are complex systems that need all the help they can get from us. 2cnts, -- Werner -----Original Message----- From: Brian Whetten [mailto:whetten@talarian.com] Sent: Tuesday, July 20, 1999 1:33 PM To: Jon Crowcroft; rmt@lbl.gov Subject: Re: RM delivery semantics Hi Jon, I think this debate simply comes down to the question of whether or not message stability requires getting acknowledgements from the transport, or from the application. From a semantics/taxonomy perspective, I would suggest/agree that we have a major division between "statistical reliability/goodput ensurance" and "message stability", and then an additional minor division within message stability, as to whether the acknowledgement is from the transport or the application. i.e. Reliability Semantics - Statistical Reliability (anyone have a better name yet?) - Message Stability - Optimistic Stability (transport layer) - Pessimistic Stability (transport layer) - Application level stability >From a building blocks/implementation perspective, unless we are doing high-end (ISIS/Horus/RMP/etc.) fault tolerant applications (which we're not, for now), the primary reason I see to care about getting an application level acknowledgement is if the application is going to do something persistent with the data, either writing it to disk or to a database--which may happen relatively quickly (<50ms), or could take up to seconds to complete. I could see some other cases which would have much longer time scales for application acks, but I think those are outside our primary scope. >From a layering semantics perspective, I feel that a transport protocol should provide transport layer semantics as the default. We need to remember that our principal audience is the same community that uses sockets, not the high-end research-aware developers that participate in the IETF. >From an implementation/performance perspective, having an implementation that offers high end developers the option to piggy-back application level acknowledgements on top of a TRACK (previously named HACK) infrastructure seems useful, and I don't think it will impact performance that much. Taking RMTP-II as an example, message stability is reported in a different field than those used for requests for retransmission and measurements of loss. Therefore, it would not directly impact the performance of the TRACK generation, retransmission algorithms, or of congestion control. It would simply delay the stability at the sender, and require additional message buffering throughout the protocol. Again taking RMTP-II as an example, it already offers two levels of message stability -- optimistic and pessimistic. Application message stability semantics are a simple extension to pessimistic aggregation (they make no sense with optimistic aggregation), so you can just have a third option, for application stability. Again, I'd recommend that from a usability perspective we don't focus on application stability except as a special option...but its pretty trivial to standardize/implement. Brian At 09:16 AM 7/16/99 +0200, Jon Crowcroft wrote: > >I guess it would be nice to really nail down what we meant by RM >delivery semantics > >stable mesages refers to messages which the application has receiverd >acknowldged messaged refers to thanks the transport has receiverd > >in the example i gave during RMT, NFS uses an RPC protocol - >A write message in NFS is supposed to have the semantics of unix >write, which is to write thru the caxce onto stable store... > >If the RPC is carried over UDP, the RPC response from the application >happends when the message has been resceived and saved by the >application > >If the RPC is carried over TCP, the RPC level dows the same thiing, >but, potentnailly, if the reciver is a bit slow in gettign the data to >disk, the TCP in the reciver will aclk the TCP data packet that >carried the ack and then the recvier rpc response will cause the >send of a data packet (with the same ack seq number of course) > >the diffrence in the two TCP cases shows that while there are two >levels, that transport acknlowdgement of receipt, and the applicatio >acknowledgement of receipt, they are OFTEN piggybacks for lots of good >reasons. > >THe point for RM protocls is that (of course,) the tight timeing >coupling required to get this piggybacking to work >is completely at odds with a lot of the feedback implosion control >strategies....i.e. it is probably anathema to scaling. > >Also, we should note, this is ANOTHER reason to staty wih application >where the _eventual_ message stability is important (although sender >knowledge of all-receiver meassage stability may not be) bcecause we >are not doing transacations or RPC like applications, but ratehr, >long-lived ftp like applications...... > >my two NOKs > > >jon > >From owner-rmt@listserv.lbl.gov Fri Jul 30 08:02:45 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.0/8.9.0) id IAA03280; Fri, 30 Jul 1999 08:01:04 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from labinfo.iet.unipi.it (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with SMTP id IAA03276 for ; Fri, 30 Jul 1999 08:00:59 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id OAA09854; Fri, 30 Jul 1999 14:25:51 +0200 From: Luigi Rizzo Message-Id: <199907301225.OAA09854@labinfo.iet.unipi.it> Subject: Finally! PGM source code for FreeBSD available! To: rm@mash.cs.berkeley.edu Date: Fri, 30 Jul 1999 14:25:51 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-rmt@listserv.lbl.gov Precedence: bulk [apologies for the duplicates to rmt and rm list members, the feedback is directed to rm only] After way too much delay I am glad to announce the availability of the first snapshot of my PGM Host implementation for FreeBSD. For the full details (kernel code, sample code, notes...) see http://www.iet.unipi.it/~luigi/pgm.html feedback appreciated, support for developing this also appreciated... The code is rapidly evolving, so make sure to get the latest version when you decice to try it! enjoy luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ ==== First International Workshop on Networked Group Communication ==== -----------------------------------+------------------------------------- >From owner-rmt@listserv.lbl.gov Sat Jul 31 01:46:48 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.0/8.9.0) id BAA06094; Sat, 31 Jul 1999 01:44:24 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id BAA06090 for ; Sat, 31 Jul 1999 01:44:22 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA11631 for ; Sat, 31 Jul 1999 01:44:21 -0700 (PDT) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA11624 for ; Sat, 31 Jul 1999 01:44:20 -0700 (PDT) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.2/8.9.2) id BAA07453; Sat, 31 Jul 1999 01:44:20 -0700 (PDT) Message-Id: <199907310844.BAA07453@daffy.ee.lbl.gov> To: rmt@lbl.gov Subject: Administrative: rmt@lbl.gov now managed by majordomo In-reply-to: Your message of Sat, 31 Jul 1999 01:27:02 PDT. Date: Sat, 31 Jul 1999 01:44:19 PDT From: Vern Paxson Sender: owner-rmt@listserv.lbl.gov Precedence: bulk The mailing list management of rmt@lbl.gov has been changed to be via email to majordomo@listserv.lbl.gov. Let me know if you encounter any problems. Vern >From owner-rmt@listserv.lbl.gov Mon Aug 2 08:25:13 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.0/8.9.0) id IAA23461; Mon, 2 Aug 1999 08:20:39 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id IAA23457 for ; Mon, 2 Aug 1999 08:20:37 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA20916 for ; Mon, 2 Aug 1999 08:20:36 -0700 (PDT) Received: from hubbub.cisco.com (hubbub.cisco.com [171.69.11.2]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA20903 for ; Mon, 2 Aug 1999 08:20:34 -0700 (PDT) Received: from OranLT ([171.69.210.9]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with SMTP id IAA04139; Mon, 2 Aug 1999 08:18:09 -0700 (PDT) From: "David Oran" To: , , , , , , , Subject: Maestro BoF Results Date: Mon, 2 Aug 1999 11:17:41 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-rmt@listserv.lbl.gov Precedence: bulk The Routing Area held a BoF at the Oslo IETF whose purpose was to discuss potential refinements to the IP multicast model in two areas: 1) Enhanced two-part multicast addressing to ease scalability and deployment headaches, 2) Optimizations to exploit the single-sender case The BoF announcement, along with its scope and agenda, may be found at: http://www.ietf.org/ietf/99jul/maestro-agenda-99jul.txt. I am sending this message to who I think are all the relevant WG mailing lists, and it will also be sent out via IETF-announce, so please let me know directly if I've missed a relevant group rather than risk clogging peoples' mailboxes with multiple forwards. The minutes of BoF are attached below. One of the conclusions from the BoF was to continue discussions on these subjects to ascertain if there is a critical mass of support to charter one or more Working Groups to pursue IETF standards (or other outputs) in these areas. We are therefore resurrecting a moribund Routing Area mailing list for this purpose: routing-discussion@ietf.org Subscription is via majordomo@ietf.org Thanks to all who participated in the BoF and in advance for useful low-flamability discussion on the mailing list. Regards, Dave Oran (routing co-area director) MAESTRO BOF, Dave Oran ---------------------- AGENDA History - modify multicast model, do we need a working group on this? A number of people think if we simplify the multicast model there are significant benefits in reducing complexity. changes: addressing model, assume single sender. We want to look at the problems today and see how proposed simplications might help. Ground rules: talk about problems and how they map to the proposed simplifications. from two perspectives, isp's and architectural view. Bryan Lyles, Sprint Deployment Strategy --------------------------------------- Today, multicast enabled, working with vendors and customers to make it work. built on PIM-SM, MSDP, MBGP, IGMPV2, GLOP. Short Term - push current protocols, work in ietf to enhance base. Certain kinds of applications want single server (radio station, politician giving speech, dont want opposition heckling him) Hugh Holbrook, Stanford/Cisco ----------------------------- Some multicast applications work well with unicast others its impossible, high data rates, many receivers questions to isp's - how do you bill for it. make billing reflect cost. so charge by size of group. dmm - if i am a source, receivers on same isp are onnet, other receivers are offnet. want to billed for offnet folks. brad cain - bill by bandwidth, can isp's break even on multicast. Queries flow down tree, counts flow back up, somehow gather data to bill src. access control for large groups, restrict senders in advance (pirates on tv station), important for commercial applications too. kevin almeroth - why does it work with radia, lawyers are the answers, no one owns a multicast address, if they did you could sue someone for using yours without permission. security - source provides passwd to receivers www.dsg.stanford.edu/hollbrook/express Jeremy Hall, uunet ------------------ Problems - scalability, single source model ok, hard to implement. you are trying to restrict something that is not restrictable. lots of protocols running as ships in the night, ok when it works, never know which one is not working correctly. way too much ad hoc stuff going on. which protocol is broken. nice to be able to trace a problem from the sender, to the receiver. receiver says i'm not receiving this content. have to figure out from that info, where the source is and what the problem is. Some applications hide the group, so you cant figure out where to troubleshoot. people dont understand how it works, so they cant help you debug. need education. Billing problems, counting receivers might be nice but is hard as groups get big. onnet vs offnet. tried to employ things that are parallel to unicast. unicast routing tries to dump traffic asap, mulitcast wants to keep as long as possible. current model doesnt scale. anyone can source to any group and thats a security problem. there are a lot of security issues with multicast. Mark Handley, ACIRI ------------------- Internet Standard Multicast, where it came from and why it had nice properties. direct extension of the unicast model, host sends packets to destination address, it gets there. nice architecure, senders dont need to know about receivers. recievers dont need to know who senders are. distributed binding is useful resource. senders and receivers dont need to know about topology, robust, route around failures etc. hosts dont need to knows about routing protocool. need distinction between service model and its implementation in the network. separates what the application wants and how the network achieves it. clean separation of routing and transport/application layer. What can we do with it: Regular one to many applications - video distribution, data distribution many to many applications - conferening, games, dont know members in advance, distributed binding is very robust, changes the way you design applications (eg wb) Many to few applications - server discovery Scoping, used to have ttl scoping, poor for traffic engineering, great for self organizing applications, expanding ring search, we lost the ttl in pim, admin scoping getting it back, mzap Security - can only restrict traffic safely with encryption. content providers want authentication, have the mechanisms already. problems: forwarding table size, aggregation helps some; how can isp's make money; lack of scalable routing protocol, bgmp, hierarchical pim, bi-direction pim with grib, bgmp will probably work, hierarchical pim too; lack or good network management and diagnostic tools. serious growing pains, transition from dvmrp painful distributed binding a key - wb, sdr, mimaze applications important to avoid constraining network mechanisms to support only one to many applications Bryan - lots of differences of opionion in the community. Hugh - avoid overly commplicating things for futures applications when we have existing applications that need support now. jon crowcroft, ucl, www.cs.ucl.ac.uk/research/rama -------------------------------------------------- Enhancing deering multicast, enhancing the addressing scheme. class D address is a channel, not really an ip address. Anonymously names a group of receivers, allows anyone to send to it. alternatives, allow end systems to be explicit DCM/connectionless multicast - add list of addresses, transparency and fault tolerance David Oran - Final Questions ---------------------------- we have 5 minutes, where should we go with this? Brian Whetten - wishes had heard more from isps about problems. TODO - decide which problems are of deployment and which are based on what we are deploying. Scott Petrak - 3 things: think about low bandwidth hosts at the end, like wireless; thing 2 i missed; small number of senders a worthy optimization. Dorian Kim - deployment problems have been maturity of implementation issues and how to make all the hacks play together. havent tried running native multicast at scales we want. will find more answers as we deploy and ramp up, at this point probably not worth limiting model. Hum votes create a mailing list 2/3 hum no mailing list 1/3 hum >From owner-rmt@listserv.lbl.gov Mon Aug 2 09:00:09 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.0/8.9.0) id IAA23516; Mon, 2 Aug 1999 08:59:46 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (localhost [127.0.0.1]) by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id IAA23512 for ; Mon, 2 Aug 1999 08:59:43 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA01973 for ; Mon, 2 Aug 1999 08:59:43 -0700 (PDT) Received: from mailman.sprintlabs.com (mx.sprintlabs.com [208.30.174.2]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA01965 for ; Mon, 2 Aug 1999 08:59:41 -0700 (PDT) Received: from sprintlabs.com (ip199-2-54-117.sprintlabs.com [199.2.54.117]) by mailman.sprintlabs.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id P60ZAK1M; Mon, 2 Aug 1999 08:59:40 -0700 Message-ID: <37A5C07E.9482F819@sprintlabs.com> Date: Mon, 02 Aug 1999 08:59:58 -0700 From: christophe diot Organization: SPRINT ATL X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: David Oran CC: maddogs@ietf.org, idmr@cs.ucl.ac.uk, idr@merit.edu, msdp@network-services.uoregon.edu, pim@catarina.usc.edu, mboned@network-services.uoregon.edu, malloc@catarina.usc.edu, rmt@lbl.gov Subject: Re: Maestro BoF Results References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@listserv.lbl.gov Precedence: bulk David Oran wrote: > > The Routing Area held a BoF at the Oslo IETF whose purpose was to discuss > potential refinements to the IP multicast model in two areas: > 1) Enhanced two-part multicast addressing to ease scalability and > deployment > headaches, > 2) Optimizations to exploit the single-sender case > > The BoF announcement, along with its scope and agenda, may be found at: > http://www.ietf.org/ietf/99jul/maestro-agenda-99jul.txt. > > I am sending this message to who I think are all the relevant WG mailing > lists, and it will also be sent out via IETF-announce, so please let me know > directly if I've missed a relevant group rather than risk clogging peoples' > mailboxes with multiple forwards. > > The minutes of BoF are attached below. One of the conclusions from the BoF > was to continue discussions on these subjects to ascertain if there is a > critical mass of support to charter one or more Working Groups to pursue > IETF standards (or other outputs) in these areas. We are therefore > resurrecting a moribund Routing Area mailing list for this purpose: > routing-discussion@ietf.org > Subscription is via majordomo@ietf.org > > Thanks to all who participated in the BoF and in advance for useful > low-flamability discussion on the mailing list. > > Regards, Dave Oran (routing co-area director) > > MAESTRO BOF, Dave Oran > ---------------------- > > AGENDA > > History - modify multicast model, do we need a working group > on this? > > A number of people think if we simplify the multicast model > there are significant benefits in reducing complexity. > changes: addressing model, assume single sender. > > We want to look at the problems today and see how proposed > simplications might help. > > Ground rules: talk about problems and how they map to the > proposed simplifications. from two perspectives, isp's > and architectural view. > > Bryan Lyles, Sprint Deployment Strategy > --------------------------------------- > Today, multicast enabled, working with vendors and customers to make > it work. built on PIM-SM, MSDP, MBGP, IGMPV2, GLOP. > > Short Term - push current protocols, work in ietf to enhance base. > > Certain kinds of applications want single server (radio station, > politician giving speech, dont want opposition heckling him) If I remember well, this is not exactly what we said ... What we "also" sayed is that we encouter problems with providing stable and robust multicast service, and that we are not really satisfied with the current protocol architecture and with its implementation (difficult to know if the architecture or the implementation is broken). The conslusion of the talk was that Sprint would like IETF to consider a protocol architecture that would be stable, more simple, and more scalable. > Hugh Holbrook, Stanford/Cisco > ----------------------------- > Some multicast applications work well with unicast > others its impossible, high data rates, many receivers > questions to isp's - how do you bill for it. make billing reflect > cost. so charge by size of group. > > dmm - if i am a source, receivers on same isp are onnet, > other receivers are offnet. want to billed for offnet folks. > > brad cain - bill by bandwidth, can isp's break even on multicast. > > Queries flow down tree, counts flow back up, somehow gather data > to bill src. access control for large groups, restrict senders > in advance (pirates on tv station), important for commercial > applications too. > > kevin almeroth - why does it work with radia, lawyers are > the answers, no one owns a multicast address, if they did > you could sue someone for using yours without permission. > > security - source provides passwd to receivers > > www.dsg.stanford.edu/hollbrook/express > > Jeremy Hall, uunet > ------------------ > Problems - scalability, single source model ok, hard to implement. > you are trying to restrict something that is not restrictable. > lots of protocols running as ships in the night, ok when it works, > never know which one is not working correctly. way too much ad hoc > stuff going on. which protocol is broken. nice to be able to trace > a problem from the sender, to the receiver. receiver says i'm not > receiving this content. have to figure out from that info, where > the source is and what the problem is. > > Some applications hide the group, so you cant figure out where > to troubleshoot. people dont understand how it works, so they > cant help you debug. need education. > > Billing problems, counting receivers might be nice but is hard > as groups get big. onnet vs offnet. tried to employ things > that are parallel to unicast. unicast routing tries to dump traffic > asap, mulitcast wants to keep as long as possible. current model > doesnt scale. anyone can source to any group and thats a security > problem. there are a lot of security issues with multicast. > > Mark Handley, ACIRI > ------------------- > Internet Standard Multicast, where it came from and why it had > nice properties. direct extension of the unicast model, host > sends packets to destination address, it gets there. nice > architecure, senders dont need to know about receivers. > recievers dont need to know who senders are. distributed binding > is useful resource. senders and receivers dont need to know about > topology, robust, route around failures etc. hosts dont need to > knows about routing protocool. need distinction between service > model and its implementation in the network. separates what > the application wants and how the network achieves it. clean > separation of routing and transport/application layer. > > What can we do with it: > > Regular one to many applications - video distribution, data distribution > many to many applications - conferening, games, dont know members in > advance, distributed binding is very robust, changes the way you design > applications (eg wb) > > Many to few applications - server discovery > > Scoping, used to have ttl scoping, poor for traffic engineering, > great for self organizing applications, expanding ring search, > we lost the ttl in pim, admin scoping getting it back, mzap > > Security - can only restrict traffic safely with encryption. > content providers want authentication, have the mechanisms already. > > problems: > > forwarding table size, aggregation helps some; > how can isp's make money; > lack of scalable routing protocol, bgmp, hierarchical pim, > bi-direction pim with grib, bgmp will probably work, > hierarchical pim too; > lack or good network management and diagnostic tools. > > serious growing pains, transition from dvmrp painful > > distributed binding a key - wb, sdr, mimaze applications > > important to avoid constraining network mechanisms to support only one > to many applications > > Bryan - lots of differences of opionion in the community. > Hugh - avoid overly commplicating things for futures applications > when we have existing applications that need support now. > > jon crowcroft, ucl, www.cs.ucl.ac.uk/research/rama > -------------------------------------------------- > Enhancing deering multicast, enhancing the addressing scheme. > class D address is a channel, not really an ip address. > Anonymously names a group of receivers, allows anyone to send to it. > alternatives, allow end systems to be explicit > DCM/connectionless multicast - add list of addresses, > transparency and fault tolerance > > David Oran - Final Questions > ---------------------------- > we have 5 minutes, where should we go with this? > > Brian Whetten - wishes had heard more from isps about problems. > > TODO - decide which problems are of deployment and which are based > on what we are deploying. > > Scott Petrak - 3 things: think about low bandwidth hosts at the end, > like wireless; thing 2 i missed; small number of senders a worthy > optimization. > > Dorian Kim - deployment problems have been maturity of implementation issues > and how to make all the hacks play together. havent tried running native > multicast at scales we want. will find more answers as we deploy and ramp > up, at this point probably not worth limiting model. > > Hum votes > create a mailing list 2/3 hum > no mailing list 1/3 hum -- ======================================================= christophe Diot | tel: 1(650)375.4539 Sprint ATL | fax: 1(650)375.4490 1 Adrian Court | cdiot@sprintlabs.com Burlingame CA 94010 | www.sprintlabs.com USA | >From owner-rmt@listserv.lbl.gov Mon Aug 16 05:20:44 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id FAA24038; Mon, 16 Aug 1999 05:18:34 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (root@postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA24034 for ; Mon, 16 Aug 1999 05:18:32 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA07377 for ; Mon, 16 Aug 1999 05:18:32 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id FAA07365 for ; Mon, 16 Aug 1999 05:18:29 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id LAA25813; Mon, 16 Aug 1999 11:39:43 +0200 From: Luigi Rizzo Message-Id: <199908160939.LAA25813@labinfo.iet.unipi.it> Subject: New version of pgm source for FreeBSD To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Mon, 16 Aug 1999 11:39:43 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-rmt@lbl.gov Precedence: bulk [Bcc to rm, rmt and another pgm-related list to avoid spam as a result of replies.] As the subject says, there is a newer snapshot of my PGM code for FreeBSD available from the usual URL http://www.iet.unipi.it/~luigi/pgm.html This one is much more complete and robust than the previous one, and works on FreeBSD 3.x and 2.2.x . cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ ==== First International Workshop on Networked Group Communication ==== -----------------------------------+------------------------------------- >From owner-rmt@listserv.lbl.gov Mon Sep 6 06:17:14 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id GAA14077; Mon, 6 Sep 1999 06:14:25 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (root@postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA14073 for ; Mon, 6 Sep 1999 06:14:23 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA17307 for ; Mon, 6 Sep 1999 06:14:22 -0700 (PDT) Received: from ccl.chungnam.ac.kr (ccl.chungnam.ac.kr [168.188.48.128]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA17303 for ; Mon, 6 Sep 1999 06:14:21 -0700 (PDT) Received: from ccl.chungnam.ac.kr (ghil.chungnam.ac.kr [168.188.48.2]) by ccl.chungnam.ac.kr (8.9.0/8.9.0) with ESMTP id WAA00288 for ; Mon, 6 Sep 1999 22:11:01 +1000 (KDT) Message-ID: <37D3BE06.90C4179B@ccl.chungnam.ac.kr> Date: Mon, 06 Sep 1999 22:13:42 +0900 From: Dae Young KIM Organization: Chungnam Nat'l Univ., InfoCom Eng. Dept. X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt Subject: Test Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Sorry for this test mail. Just wanted to know why this mailing list apparently seems to be dormant. -- Dae Young http://ccl.chungnam.ac.kr/~dykim/ >From owner-rmt@listserv.lbl.gov Wed Sep 8 21:53:28 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id VAA22191; Wed, 8 Sep 1999 21:49:41 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (root@postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA22187 for ; Wed, 8 Sep 1999 21:49:39 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA18950 for ; Wed, 8 Sep 1999 21:49:38 -0700 (PDT) Received: from fastmail.vertical.net (fastmail.vertical.net [146.145.74.44]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA18946 for ; Wed, 8 Sep 1999 21:49:37 -0700 (PDT) Date: Wed, 8 Sep 1999 21:49:37 -0700 (PDT) Message-Id: <199909090449.VAA18946@SpamWall.lbl.gov> Received: from fastmail (172.16.0.44) by fastmail.vertical.net (LSMTP for Windows NT v1.1b) with SMTP id <9.0002A90A@fastmail.vertical.net>; Thu, 9 Sep 1999 0:37:12 -0400 From: Computer OEM Online Subject: Computer OEM Online Newsletter To: rmt@lbl.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Sender: owner-rmt@lbl.gov Precedence: bulk ============================================================ Computer OEM Online Newsletter Volume 2 Issue 46 Wednesday, September 08, 1999 ============================================================ Computer OEM Online's System Strategy case study series continues. Frank Carau, R&D Lab Manager at Hewlett-Packard's Portable Capture and Communications facility, describes how code coverage and regression test analyses tools helped his team speed a 500-000-gate ASIC to successful first-pass completion. Read about it at http://www2.computeroemonline.com/read/nl19990907/10080. ******** NATIONAL SPONSOR ******** The 9.99% fixed Bank One Platinum Business Card Visa. No annual fee and up to $25,000 line of credit. Track expenses, simplify tax reporting, and streamline your finances. Apply online by visiting: http://app1.firstusa.com/card.cfm/XPL6UBC13/6B3Z ******** Computer OEM Online^Ňs Weekly Selection: ******** Advanced Routing of Electronic Modules A vision of the future in advanced electronics by Michael Pecht, Yeun Tsun G.Wong The rapid growth of the electronic products market has created an increasing need for affordable, reliable, high-speed and high-density multi-layer printed circuit boards (PCBs). Our Price: $95.00! To read more and purchase this book, visit: http://www2.computeroemonline.com/read/nl19990907/10138 ****** FEATURED ARTICLES selected by Alex Mendelsohn ****** 1) Digital Car Stereo DSP Chip Samples 2) Multiple Instruction-Set Technology Takes A Bow 3) Analog Devices Implements Intel Mobile Power Management ------------------------------------------------------------ 1) Digital Car Stereo DSP Chip Samples IC house STMicroelectronics starts sampling a 3 V mixed-signal DSP-based baseband processor chip for all-digital car stereos. ST's programmable approach lets you add features simply by changing firmware. Try that with your conventional analog car stereo! http://www2.computeroemonline.com/read/nl19990907/10003 2) Multiple Instruction-Set Technology Takes A Bow As part of the Navy's Dual Use Science & Technology program sponsored by the Office of Naval Research, CPU Technology, Inc. is developing a core processing architecture it says will make possible upgraded high-end embedded systems. CPU Tech will supply a system-on-a-chip that will work/run both legacy processors and software without changes, and new higher-order languages and commercial off- the-shelf software tools. http://www2.computeroemonline.com/read/nl19990907/10004 3) Analog Devices Implements Intel Mobile Power Management Chip makers Analog Devices releases the industry's first DC-to-DC converter to incorporate Intel's Mobile Voltage Positioning technology. http://www2.computeroemonline.com/read/nl19990907/10005 ******** EDITOR'S CHOICE PRODUCTS ******** 1) ZIF BGA Sockets 2) Display Driver ICs 3) LVT Logic ------------------------------------------------------------ 1) ZIF BGA Sockets Zero insertion force BGA sockets permit repeated tool-free removal and insertion of ball-grid-array-packaged microprocessors. http://www2.computeroemonline.com/read/nl19990907/10007 2) Display Driver ICs Type CS1084, '85, and '86 driver ICs contain the circuitry needed to interface between a system microprocessor and automotive Vacuum Fluorescent Display instrumentation. http://www2.computeroemonline.com/read/nl19990907/10008 3) LVT Logic Designed for 3.3 V applications, logic line includes the 74LVTH273 octal D-type flip-flop with Clear, the 74LVT373/74LVTH373 octal transparent latch with three- state outputs, and the 74LVT374/74LVTH374 octal D-type with three-state outputs. Available with and without Bus-hold, the high speed (less than 4.5 nanosecond) ICs can be used for off-board driving applications such as backplanes, memory arrays, telecom switches, and in networking applications. Bus-hold maintains a valid logic state on an unloaded input, eliminating the need for external pull-up or pull-down resistors to prevent floating inputs. http://www2.computeroemonline.com/read/nl19990907/10009 ******** ADVERTISEMENT ******** The award winning My Lycos is the fast and easy-to-use start page - providing you with personalized news, weather, stock quotes, horoscopes, weather, sports scores and more. Try it now - http://my.lycos.com. ***** FEATURED COMPANIES (information from sponsors): ****** Visit the companies below for more industry news and product information: Adapter Technologies Inc. was established in 1994 to provide interconnect solutions to OEMs that required application specific products to produce their end products. Working with fortune 100, 500 and 1000 companies world wide, their products consist from small run to large run production quantities, research and development products and high end electronic assemblies encompassing surface mount technologies and thru hole technologies. Visit Adapter Technologies Inc. at: http://www2.computeroemonline.com/storefronts/adaptertech.html NKK Switches provides comprehensive manufacturing, warehousing, and other sales services from its USA headquarters in Scottsdale, Arizona. An extensive staff of knowledgeable marketing and sales personnel is on call to provide technical information as well as pricing and delivery schedules. Visit NKK Switches at: http://www2.computeroemonline.com/storefronts/nkk.html Ziatech Corporation is a leading supplier of rugged CompactPCIŽ and STD 32Ž industrial computers. They manufacture board-level, system-level, and fully integrated microcomputer products for OEMs and end users seeking to automate their applications quickly and cost effectively. Visit Ziatech Corporation at: http://www2.computeroemonline.com/storefronts/ziatech.html Thanks for subscribing to Computer OEM Online's weekly newsletter. Tell your friends and associates about it. Have questions, or suggestions? Call Managing Editor Alex Mendelsohn at (207) 967-8812. ------------------------------------------------------------------- If you enjoy reading Computer OEM Online's Newsletter, please tell a friend or colleague about it. Anyone can sign up for a free subscription on our Web site at http://www.computeroemonline.com -------------------------------------------------------------------- If your company wishes to sponsor this newsletter, please contact Sherylen Yoak at mailto:syoak@verticalnet.com to learn more. ========================================================== If you wish to unsubscribe, please go to the following web page: http://www2.computeroemonline.com/content/newsletter/unsubscribe.asp ========================================================== The Computer OEM Online Homepage: http://www.computeroemonline.com (c) Copyright 1999 VerticalNet, Inc. All rights reserved. All product names contained herein are the trademarks of their respective holders. >From owner-rmt@listserv.lbl.gov Thu Sep 9 22:41:59 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id WAA25300; Thu, 9 Sep 1999 22:40:39 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (root@postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA25296 for ; Thu, 9 Sep 1999 22:40:37 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA20547 for ; Thu, 9 Sep 1999 22:40:36 -0700 (PDT) Received: from fastmail.vertical.net (fastmail.vertical.net [146.145.74.44]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA20543 for ; Thu, 9 Sep 1999 22:40:35 -0700 (PDT) Date: Thu, 9 Sep 1999 22:40:35 -0700 (PDT) Message-Id: <199909100540.WAA20543@SpamWall.lbl.gov> Received: from fastmail (172.16.0.44) by fastmail.vertical.net (LSMTP for Windows NT v1.1b) with SMTP id <6.00031636@fastmail.vertical.net>; Fri, 10 Sep 1999 1:28:06 -0400 From: Embedded Technology Subject: Embedded Technology Newsletter To: rmt@lbl.gov Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Sender: owner-rmt@lbl.gov Precedence: bulk ============================================================ Embedded Technology.com Newsletter Volume 1 Issue 18 Thursday, September 09, 1999 ============================================================ ******** NATIONAL SPONSOR ******** The 9.99% fixed Bank One Platinum Business Card Visa. No annual fee and up to $25,000 line of credit. Track expenses, simplify tax reporting, and streamline your finances. Apply online by visiting: http://app1.firstusa.com/card.cfm/XPL6UBC13/6B3Z ******** Embedded Technology.com^Ňs Weekly Selection: ******* A Practitioner's Guide to RISC Microprocessor Architecture by Patrick H. Stakem An introduction to Reduced Instruction Set Microprocessors which is a subfield of RISC. Retail Price: $82.95 Our Price: $70.99! You Save: $11.96 (14%) To read more and purchase this book, visit: http://www2.embeddedtechnology.com/read/nl19990907/10141 ****** FEATURED ARTICLES selected by Bruce Bennett ***** 1) Uniform Device Driver Spec Ready for Implementation 2) SBS Develops K2 CPCI Board Targeting Telecom Applications 3) Fujitsu Mikrolektronik Restructures ------------------------------------------------------------ 1) Uniform Device Driver Spec Ready for Implementation Members of Project UDI today announced the release of the UDI (Uniform Driver Interface) 1.0 Specification. This Specification is the culmination of a multi- company development effort designed to provide device driver portability for existing and future system configurations. http://www2.embeddedtechnology.com/read/nl19990907/10054 2) SBS Develops K2 CPCI Board Targeting Telecom Applications SBS Technologies, Inc. has announced the availability of K2, a 6U cPCI board targeting high performance telecommunications applications requiring hot-swap, system/non-system slot functionality, and versatile I/O with dual PMC slots. http://www2.embeddedtechnology.com/read/nl19990907/10056 3) Fujitsu Mikrolektronik Restructures Fujitsu Mikroelektronik GmbH in Dreieich-Buchschlag, Frankfurt, Germany has announced that as part of a restructuring of its European operations, it will now function as the European headquarters of Fujitsu Microelectronics Europe GmbH. Known as Fujitsu Microelectronics Europe (FME), the company will combine the activities of Marketing, Design Centres and Sales Offices in the UK, Germany, France, Italy, Sweden. http://www2.embeddedtechnology.com/read/nl19990907/10059 ******** EDITOR'S CHOICE PRODUCTS ******** 1) Multimedia PC 2) Emulator 3) I/O Solutions Guide ------------------------------------------------------------ 1) Multimedia PC The SBC-Media GX is an EBX-compliant board based on the MMX-enhanced 233-MHz MediaGX processor. -- Arcom Control Systems, Kansas City, MO. http://www2.embeddedtechnology.com/read/nl19990907/8882 2) Emulator The USP-51A emulator with a POD32X2-60 fully emulates the TS80C32X2 device in targets at the maximum clock speed of 64 MHz. -- Signum Systems, Moorpark, CA. http://www2.embeddedtechnology.com/read/nl19990907/8884 3) I/O Solutions Guide The company^Ňs catalog features a range of VMEbus boards, PC cards and IndustryPack mezzanine modules. The boards perform analog I/O, digital I/O and serial communication functions. -- Acromag, Wixom, MI. http://www2.embeddedtechnology.com/read/nl19990907/10050 ******** ADVERTISEMENT ******** The award winning My Lycos is the fast and easy-to-use start page - providing you with personalized news, weather, stock quotes, horoscopes, weather, sports scores and more. Try it now - http://my.lycos.com. ****** FEATURED COMPANY (information from sponsors): ****** Visit the company below for more industry news and product information: The Embedded Initiative is a partner program, created by Annasoft Systems in 1997, focused on providing ready-to-run Windows CE platform solutions. These solutions consist of embedded PC hardware combined with Annasoft software that enable OEM manufacturers of embedded and dedicated systems to run Windows CE off-the-shelf, without adaptation or driver development, on a wide range of commercially available single board computers and modules. Visit Annasoft Systems at: http://www2.embeddedtechnology.com/storefronts/embeddedinitiative.html The Embedded Systems Conference in San Jose, CA is just two weeks away (Sept. 27 to Sept. 30). Be sure to watch for our extensive coverage of the event on Embedded Technology.com. ------------------------------------------------------------------- If you enjoy reading Embedded Technology's Newsletter, please tell a friend or colleague about it. Anyone can sign up for a free subscription on our Web site at http://www.embeddedtechnology.com -------------------------------------------------------------------- If you're a company that wishes to sponsor this newsletter, please contact Sherylen Yoak at mailto:syoak@verticalnet.com to learn more. ========================================================== If you wish to unsubscribe, please go to the following web page: http://www2.embeddedtechnology.com/content/newsletter/unsubscribe.asp ========================================================== The Embedded Technology Homepage: http://www.embeddedtechnology.com (c) Copyright 1999 VerticalNet, Inc. All rights reserved. All product names contained herein are the trademarks of their respective holders. >From owner-rmt@listserv.lbl.gov Fri Sep 10 00:57:54 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id AAA25385; Fri, 10 Sep 1999 00:57:36 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (root@postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA25381 for ; Fri, 10 Sep 1999 00:57:34 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA02296 for ; Fri, 10 Sep 1999 00:57:33 -0700 (PDT) Received: from s2.smtp.oleane.net (s2.smtp.oleane.net [195.25.12.6]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA02292 for ; Fri, 10 Sep 1999 00:57:31 -0700 (PDT) Received: from nec.oleane.com (dyn-1-1-253.Cor.dialup.oleane.fr [62.161.8.253]) by s2.smtp.oleane.net with SMTP id JAA36430 for ; Fri, 10 Sep 1999 09:57:29 +0200 (CEST) Message-ID: <00ad01befb62$49a269a0$0201a8c0@nec.oleane.com> From: "Peter lewis" To: Subject: QoS Summit Date: Fri, 10 Sep 1999 09:58:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-rmt@lbl.gov Precedence: bulk QoS Summit: key requirements for advanced applications running on future networks. Technologies (MPLS, ATM, IntSev/DiffServ, Frame Relay). Managing, policing, billing, charging QoS. The annual rendez-vous with top senior specialists. Paris, France, 16-19 November 1999 Please see details at the following web address: http://www.upperside.fr/baqos.htm Sorry to post this message on the list. Thanks >From owner-rmt@listserv.lbl.gov Tue Sep 14 09:53:32 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id JAA06852; Tue, 14 Sep 1999 09:51:43 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (root@postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA06848 for ; Tue, 14 Sep 1999 09:51:42 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA21255 for ; Tue, 14 Sep 1999 09:51:36 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id JAA21220 for ; Tue, 14 Sep 1999 09:51:34 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id QAA00911; Tue, 14 Sep 1999 16:02:30 +0200 From: Luigi Rizzo Message-Id: <199909141402.QAA00911@labinfo.iet.unipi.it> Subject: NGC99 - Call for Posters and Participation To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Tue, 14 Sep 1999 16:02:30 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-rmt@lbl.gov Precedence: bulk [usual apologies for duplicates] Just a reminder of upcoming deadlines for NGC99: First International Workshop on Networked Group Communication Pisa, 17-19 november 1999 http://www.iet.unipi.it/~luigi/ngc99/ Registrations are now open, as well as poster submissions: Early registrations 5 october Poster submissions 5 november Tutorials and workshop 17-19 november The Workshop, sponsored by Cisco, Microsoft Research and Motorola, features: * tutorials by Mostafa Ammar and Don Towsley, Mark Handley, Radia Perlman; * invited talks by Ken Birman, Bob Briscoe, Steve Deering, Christophe Diot, Radia Perlman, Tony Speakman; * 18 technical papers, and poster sessions; all of this near the beautiful monuments and landscape of Tuscany. Check the workshop's web pages http://www.iet.unipi.it/~luigi/ngc99/ for detailed info. cheers luigi rizzo P.S. This msg is sent using Bcc to avoid spam on mailing lists by people replying to the msg. To see where you got this msg from, check the headers. -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ ==== First International Workshop on Networked Group Communication ==== -----------------------------------+------------------------------------- >From owner-rmt@listserv.lbl.gov Mon Sep 20 09:36:18 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id JAA27396; Mon, 20 Sep 1999 09:34:56 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (root@postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA27392 for ; Mon, 20 Sep 1999 09:34:54 -0700 (PDT) Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA05724 for ; Mon, 20 Sep 1999 09:34:53 -0700 (PDT) Received: from s2.smtp.oleane.net (s2.smtp.oleane.net [195.25.12.6]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA05676 for ; Mon, 20 Sep 1999 09:34:36 -0700 (PDT) Received: from Dell (dyn-1-1-230.Cor.dialup.oleane.fr [62.161.8.230]) by s2.smtp.oleane.net with SMTP id SAA31040; Mon, 20 Sep 1999 18:11:58 +0200 (CEST) Message-ID: <003701bf0382$f3a87ac0$0701a8c0@oleane.com> From: "Peter Lewis" To: Subject: Media Gateway Control 99 : Call for paper Date: Mon, 20 Sep 1999 18:06:56 +0200 Organization: Upperside MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01BF0392.ECF8CC60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002A_01BF0392.ECF8CC60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paris, France, 15-17 December 1999 Media Gateway Control 99 Conference. MGCP, Megaco, H.248. How to assure convergence between IP and PSTN = networks. Technical challenges, trials, interoperability tests, normalization = work. Call for papers: www.upperside.fr/bamgc.htm Thanks ------=_NextPart_000_002A_01BF0392.ECF8CC60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Paris, France, 15-17 December 1999

Media = Gateway=20 Control 99 Conference.

MGCP, Megaco, H.248. How to assure = convergence=20 between IP and PSTN networks.
Technical challenges, trials, = interoperability=20 tests, normalization work.

Call for papers:  www.upperside.fr/bamgc.htm=

Thanks
 
------=_NextPart_000_002A_01BF0392.ECF8CC60-- >From owner-rmt@listserv.lbl.gov Thu Sep 23 14:26:02 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id OAA09543; Thu, 23 Sep 1999 14:24:12 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA09539 for ; Thu, 23 Sep 1999 14:24:11 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA02404 for ; Thu, 23 Sep 1999 14:24:10 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [129.188.136.102]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA02371 for ; Thu, 23 Sep 1999 14:24:04 -0700 (PDT) Received: [from pobox2.mot.com (pobox2.mot.com [129.188.137.195]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id QAA21715 for ; Thu, 23 Sep 1999 16:23:52 -0500 (CDT)] Received: [from superman.arc.corp.mot.com (superman.arc.corp.mot.com [217.1.10.18]) by pobox2.mot.com (MOT-pobox2 2.0) with SMTP id QAA25216 for ; Thu, 23 Sep 1999 16:23:50 -0500 (CDT)] Received: from arc.corp.mot.com (t_il01_d_slip13.corp.mot.com [199.2.172.91]) by superman.arc.corp.mot.com (8.6.12/8.6.12) with ESMTP id HAA01847 for ; Fri, 24 Sep 1999 07:22:27 +1000 Message-ID: <37EA9ABB.BCC80FAE@arc.corp.mot.com> Date: Fri, 24 Sep 1999 07:25:15 +1000 From: Roger Kermode Organization: Motorola Austrlian Research Centre X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: IETF/RMT call for action.... Content-Type: multipart/mixed; boundary="------------7BA37A493A5E6C6957F17D22" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------7BA37A493A5E6C6957F17D22 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear RMT'ers, the next IETF is nearly upon us we'd like to fill you in what's been going on and also to ask for your participation. 1) We'd like to invite parties who are interested in writing internet drafts on the building blocks, protocol instantiations, and Abstract APIs identified in the building-blocks draft to contact the working group co-chairs ASAP. N.B. the cutoff for drafts is Oct 22 so be don't wait to respond to this message. 2) We're nearly done with revisions on the building blocks and design space draft, expect to see new versions before the meeting. 3) The working group chairs have been working on a new charter which we will send to this email list within the next week or so for comment. We'd like to incorporate any feedback pretty quickly so we can have the rechartering done before the next IETF meeting. 4) We have also identified the need for an additional draft that will outline a series of guidelines for writing internet drafts on building blocks, protocol instantiations (how to glue building blocks together with additional functionality to create a implementable protocol), and abstract APIs (how to map a specific API onto a protocol instantiation) Cheers, Roger Kermode Allison Mankin Lorenzo Vicisano --------------7BA37A493A5E6C6957F17D22 Content-Type: text/x-vcard; charset=us-ascii; name="rkermode.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Roger Kermode Content-Disposition: attachment; filename="rkermode.vcf" begin:vcard n:Kermode;Roger tel;cell:+61-408-212-284 tel;fax:+61-2-9666-0501 tel;work:+61-2-9666-0558 x-mozilla-html:FALSE url:http://www.arc.corp.mot.com org:Motorola Australian Research Centre;Scalable Commodity Internet Lab version:2.1 email;internet:ark008@email.mot.com title:Principal Research Engineer, Lab Manager adr;quoted-printable:;;12 Lord St. Level 3=0D=0A=0D=0A;Botany;NSW;2019;Australia x-mozilla-cpt:;-15680 fn:Roger Kermode end:vcard --------------7BA37A493A5E6C6957F17D22-- >From owner-rmt@listserv.lbl.gov Thu Sep 23 14:46:50 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id OAA09556; Thu, 23 Sep 1999 14:46:47 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA09552 for ; Thu, 23 Sep 1999 14:46:46 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA09023 for ; Thu, 23 Sep 1999 14:46:45 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA08998 for ; Thu, 23 Sep 1999 14:46:43 -0700 (PDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id QAA09736 for ; Thu, 23 Sep 1999 16:46:38 -0500 (CDT)] Received: [from superman.arc.corp.mot.com (superman.arc.corp.mot.com [217.1.10.18]) by mothost.mot.com (MOT-mothost 2.0) with SMTP id QAA17362 for ; Thu, 23 Sep 1999 16:46:35 -0500 (CDT)] Received: from arc.corp.mot.com (t_il01_d_slip13.corp.mot.com [199.2.172.91]) by superman.arc.corp.mot.com (8.6.12/8.6.12) with ESMTP id HAA02118 for ; Fri, 24 Sep 1999 07:45:14 +1000 Message-ID: <37EAA012.E3066662@arc.corp.mot.com> Date: Fri, 24 Sep 1999 07:48:02 +1000 From: Roger Kermode Organization: Motorola Austrlian Research Centre X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: IETF RMT: Progress Update/Call for I-D authors... Content-Type: multipart/mixed; boundary="------------863D2EC52BC16F93483C5312" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------863D2EC52BC16F93483C5312 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear RMT'ers, the next IETF is nearly upon us we'd like to fill you in what's been going on and also to ask for your participation. 1) We'd like to invite parties who are interested in writing internet drafts on the building blocks, protocol instantiations, and Abstract APIs identified in the building-blocks draft to contact the working group co-chairs ASAP. N.B. the cutoff for drafts is Oct 22 so don't wait to respond to this message. 2) We're nearly done with revisions on the building blocks and design space draft, expect to see new versions before the meeting. 3) The working group chairs have been working on a new charter which we will send to this email list within the next week or so for comment. We'd like to incorporate any feedback pretty quickly so we can have the rechartering done before the next IETF meeting. 4) We have also identified the need for an additional draft that will outline a series of guidelines for writing internet drafts on building blocks, protocol instantiations (how to glue building blocks together with additional functionality to create a implementable protocol), and abstract APIs (how to map a specific API onto a protocol instantiation) Cheers, Roger Kermode Allison Mankin Lorenzo Vicisano --------------863D2EC52BC16F93483C5312 Content-Type: text/x-vcard; charset=us-ascii; name="rkermode.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Roger Kermode Content-Disposition: attachment; filename="rkermode.vcf" begin:vcard n:Kermode;Roger tel;cell:+61-408-212-284 tel;fax:+61-2-9666-0501 tel;work:+61-2-9666-0558 x-mozilla-html:FALSE url:http://www.arc.corp.mot.com org:Motorola Australian Research Centre;Scalable Commodity Internet Lab version:2.1 email;internet:ark008@email.mot.com title:Principal Research Engineer, Lab Manager adr;quoted-printable:;;12 Lord St. Level 3=0D=0A=0D=0A;Botany;NSW;2019;Australia x-mozilla-cpt:;-15680 fn:Roger Kermode end:vcard --------------863D2EC52BC16F93483C5312-- >From owner-rmt@listserv.lbl.gov Mon Oct 4 03:56:01 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA26064; Mon, 4 Oct 1999 03:53:48 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA26060 for ; Mon, 4 Oct 1999 03:53:46 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA28581 for ; Mon, 4 Oct 1999 03:53:45 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id DAA28578 for ; Mon, 4 Oct 1999 03:53:44 -0700 (PDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 4 Oct 1999 11:53:16 +0100 To: David Oran cc: maddogs , idmr , idr , msdp , pim , mboned , malloc , rmt Subject: Re: Maestro BoF Results In-reply-to: Your message of "Mon, 02 Aug 1999 11:17:41 EDT." Date: Mon, 04 Oct 1999 11:53:15 +0100 Message-ID: <11012.939034395@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk ... ..."One of the conclusions from the BoF was to continue discussions on these subjects to ascertain if there is a critical mass of support to charter one or more Working Groups to pursue IETF standards (or other outputs) in these areas. We are therefore resurrecting a moribund Routing Area mailing list for this purpose: routing-discussion@ietf.org" so whats the conclusion vis-a-vis multicast discussion (considering imminance of next/DC) ietf? cheers jon (apols for multi-list hit, but some folks might have had a peripheral but strong enough interest to want to know the outcome without seeing the process) >From owner-rmt@listserv.lbl.gov Sat Oct 9 04:39:38 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id EAA21087; Sat, 9 Oct 1999 04:38:03 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA21083 for ; Sat, 9 Oct 1999 04:38:01 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA08757 for ; Sat, 9 Oct 1999 04:37:59 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id EAA08754 for ; Sat, 9 Oct 1999 04:37:57 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id NAA20491; Sat, 9 Oct 1999 13:41:53 +0100 From: Luigi Rizzo Message-Id: <199910091241.NAA20491@labinfo.iet.unipi.it> Subject: Updated PGM source code (FreeBSD) To: luigi@iet.unipi.it Date: Sat, 9 Oct 1999 13:41:52 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-rmt@lbl.gov Precedence: bulk [sent to a few lists/individuals with Bcc to avoid spam on return] Dear all, an updated version of our FreeBSD pgm code is available for download at the usual place http://www.iet.unipi.it/~luigi/pgm.html this include several bug fixes to out mid-august version, and now implements PGM options. A sample application (pgmtftp) also included. The usual disclaimer and guarantees (none!) apply. Successful usage or bug reports are solicited and welcome. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ ==== First International Workshop on Networked Group Communication ==== -----------------------------------+------------------------------------- >From owner-rmt@listserv.lbl.gov Fri Oct 15 05:37:23 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id FAA20577; Fri, 15 Oct 1999 05:35:34 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA20573 for ; Fri, 15 Oct 1999 05:35:32 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA02009 for ; Fri, 15 Oct 1999 05:35:31 -0700 (PDT) Received: from s2.smtp.oleane.net (s2.smtp.oleane.net [195.25.12.6]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA02000 for ; Fri, 15 Oct 1999 05:35:29 -0700 (PDT) Received: from Dell (dyn-1-1-255.Cor.dialup.oleane.fr [62.161.8.255]) by s2.smtp.oleane.net with SMTP id OAA95005; Fri, 15 Oct 1999 14:35:02 +0200 (CEST) Message-ID: <009c01bf1709$a9d953c0$0701a8c0@oleane.com> From: "Peter Lewis" To: Subject: Media Gateway Control Conference Date: Fri, 15 Oct 1999 14:34:42 +0200 Organization: Upperside MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0099_01BF171A.6B522F80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0099_01BF171A.6B522F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MGCP, Megaco, H.248: performing seamless interoperation between IP and = PSTN networks. The international rendez-vous in Paris, 15-17 December 1999. More infos:=20 http://www.upperside.fr/bamgc.htm ------=_NextPart_000_0099_01BF171A.6B522F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
MGCP, Megaco, H.248: performing seamless = interoperation=20 between IP and PSTN
networks. The international rendez-vous in Paris, = 15-17=20 December 1999.

More infos:
http://www.upperside.fr/bamgc.= htm
 
------=_NextPart_000_0099_01BF171A.6B522F80-- >From owner-rmt@listserv.lbl.gov Mon Oct 18 14:26:10 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id OAA29062; Mon, 18 Oct 1999 14:24:20 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA29058 for ; Mon, 18 Oct 1999 14:24:18 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA23867 for ; Mon, 18 Oct 1999 14:24:17 -0700 (PDT) Received: from baynet.baynetworks.com (ns1.BayNetworks.COM [134.177.3.20]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA23842 for ; Mon, 18 Oct 1999 14:24:06 -0700 (PDT) Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id OAA27686 for ; Mon, 18 Oct 1999 14:21:19 -0700 (PDT) Received: from mailhost.corpeast.BayNetworks.COM (ns3.corpeast.baynetworks.com [132.245.135.91]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id OAA18228 for ; Mon, 18 Oct 1999 14:20:45 -0700 (PDT) Received: from bl-mail1.corpeast.BayNetworks.com (bl-mail1-hme0.corpeast.baynetworks.com [132.245.135.82]) by mailhost.corpeast.BayNetworks.COM (SMI-8.6/BNET-97/05/05-S) with SMTP id RAA17098; Mon, 18 Oct 1999 17:21:53 -0400 for Received: from thardjon ([47.72.241.57]) by bl-mail1.corpeast.BayNetworks.com (Post.Office MTA v3.5.1 release 219 ID# 0-51848U14000L14000S0V35) with SMTP id com for ; Mon, 18 Oct 1999 17:19:59 -0400 Message-Id: <3.0.32.19991018171506.0127d62c@ZBL6C002.corpeast.baynetworks.com> X-Sender: thardjon@ZBL6C002.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 18 Oct 1999 17:15:12 -0400 To: rmt@lbl.gov From: Internet-Drafts@ietf.org (by way of Thomas Hardjono ) Subject: I-D ACTION:draft-irtf-smug-framework-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rmt@lbl.gov Precedence: bulk A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Secure IP Multicast: Problem areas, Framework, and Building Blocks Author(s) : T. Hardjono, R. Canetti, M. Baugher, P. Dinsmore Filename : draft-irtf-smug-framework-00.txt Pages : 21 Date : 15-Oct-99 This document provides a foundation for the research work done as the Secure Multicast Group (SMuG)of the IRTF. The document begins by introducing a Reference Framework and problem areas, and proceeds to identify functional building blocks for a secure multicast solution. The identified building blocks, their definition and realization will be the subject of future work of SmuG. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-irtf-smug-framework-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-irtf-smug-framework-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-irtf-smug-framework-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. >From owner-rmt@listserv.lbl.gov Wed Oct 20 10:29:56 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id KAA04712; Wed, 20 Oct 1999 10:28:06 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA04708 for ; Wed, 20 Oct 1999 10:27:59 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA29829 for ; Wed, 20 Oct 1999 10:27:58 -0700 (PDT) Received: from naur.csee.wvu.edu (naur.csee.wvu.edu [157.182.194.28]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA29821 for ; Wed, 20 Oct 1999 10:27:57 -0700 (PDT) Received: from naur.csee.wvu.edu (naur.csee.wvu.edu [157.182.194.28]) by naur.csee.wvu.edu (8.9.0/8.9.0) with ESMTP id NAA01577; Wed, 20 Oct 1999 13:25:54 -0400 (EDT) Date: Wed, 20 Oct 1999 13:25:54 -0400 (EDT) From: "Todd L. Montgomery" X-Sender: tmont@naur.csee.wvu.edu To: rm@mash.CS.Berkeley.EDU, rmt@lbl.gov Subject: WhiteBarn PGM source code available In-Reply-To: <380DED01.E83A19B5@whitebarn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rmt@lbl.gov Precedence: bulk I apologize to those on both the RMRG and RMT mailing lists. You will get two copies of this.... I wanted to make sure this made it to those on the research and commercial side. (I should note that WRMF is suitable for any protocol, but we have done PGM right now.) WhiteBarn, Inc. (http://www.whitebarn.com) is pleased to announce the availability of the WhiteBarn Reliable Multicast Framework (WRMF) as well as it's implementation of the Cisco PGM reliable multicast protocol in source code form. WhiteBarn is releasing this source under a community license, a free for non-commercial use license, designed to spur the deployment and expand the acceptance of reliable multicast applications and PGM. WRMF-PGM currently supports several platforms: - Windows 95 with Winsock 2 - Windows 98 - SCO UnixWare - Linux 2.x.x (Red Hat, Debian, Slackware, Mandrake, etc.) - Solaris 2.5+ - FreeBSD 3.x WRMF-PGM is designed as a stand alone daemon that acts as a proxy between a TCP stream and a PGM session. This allows developers to use a stream abstraction for communication with the group and makes porting existing TCP applications to PGM very simple. The design also helps to isolate the elevated permissions that PGM must use to send raw IP packets to just the daemon and not the whole application. If you think WRMF-PGM might be something you can use, but are not sure, feel free to send us email and we will be glad to answer any questions. The press release: http://www.whitebarn.com/links/october20_99.html WRMF-PGM source code: http://www.whitebarn.com follow the 'Download PGM' link Questions? send email to pgm@whitebarn.com Todd L. Montgomery Whitebarn, Inc. 304-291-5972 todd@whitebarn.com >From owner-rmt@listserv.lbl.gov Tue Oct 26 04:48:57 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id EAA25737; Tue, 26 Oct 1999 04:46:43 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA25733 for ; Tue, 26 Oct 1999 04:46:41 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA18391 for ; Tue, 26 Oct 1999 04:46:41 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA18388 for ; Tue, 26 Oct 1999 04:46:40 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02599; Tue, 26 Oct 1999 07:46:36 -0400 (EDT) Message-Id: <199910261146.HAA02599@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rmt@lbl.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rmt-buildingblocks-01.txt Date: Tue, 26 Oct 1999 07:46:36 -0400 Sender: owner-rmt@lbl.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Multicast Transport Working Group of the IETF. Title : Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer Author(s) : B. Whetten, L. Vicisano, R. Kermode, M. Handley, S. Floyd, M. Luby Filename : draft-ietf-rmt-buildingblocks-01.txt Pages : 21 Date : 25-Oct-99 This document describes a framework for the standardization of bulk-data reliable multicast transport. It builds upon the experience gained during the deployment of several classes of contemporary reliable multicast transport, and attempts to pull out the commonalities between these classes of protocols into a number of building blocks. To that end, this document recommends that certain components that are common to multiple protocol classes be standardized as 'building blocks.' The remaining parts of the protocols, consisting of highly protocol specific, tightly intertwined functions, shall be designated as 'protocol cores.' Thus, each protocol can then be constructed by merging a 'protocol core' with a number of 'building blocks' which can be re-used across multiple protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-buildingblocks-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rmt-buildingblocks-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmt-buildingblocks-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991025151222.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-buildingblocks-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-buildingblocks-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991025151222.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Thu Oct 28 00:35:11 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id AAA05038; Thu, 28 Oct 1999 00:32:23 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA05034 for ; Thu, 28 Oct 1999 00:32:19 -0700 (PDT) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.2/8.9.2) id JAA10201; Thu, 28 Oct 1999 09:31:26 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <199910280731.JAA10201@info.iet.unipi.it> Subject: NGC'99 Reminder To: luigi@info.iet.unipi.it (Luigi Rizzo) Date: Thu, 28 Oct 1999 09:31:26 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk [usual apologies for duplicates -- mailing lists are in Bcc to avoid spam on reply - please pass this reminder to interested parties/lists] A reminder that Nov. 5th (i.e. next week) is the deadline for poster submissions for NGC'99, First International Workshop on Networked Group Communication Pisa, 17-20 november 1999 http://www.iet.unipi.it/~luigi/ngc99/ The workshop features 17 referred contributions and 2 poster sessions. Leading experts in networking and group communications will also contribute to the workshop with 4 invited talks, 2 keynotes, and 3 tutorials. More info and details on the workshop are on the web page above. IMPORTANT NOTE: attendance is exceeding our expectations, and we might be forced to close registrations once we reach max capacity. So if you intend to participate REGISTER SOON, and if you need to register on-site PLEASE SEND A NOTE INFORMING OF YOUR INTENTIONS to luigi@iet.unipi.it so we can tell you if room will still be available. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ ==== First International Workshop on Networked Group Communication ==== -----------------------------------+------------------------------------- >From owner-rmt@listserv.lbl.gov Fri Oct 29 05:55:33 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id FAA10985; Fri, 29 Oct 1999 05:53:01 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA10981 for ; Fri, 29 Oct 1999 05:52:59 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA29236 for ; Fri, 29 Oct 1999 05:52:59 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA29233 for ; Fri, 29 Oct 1999 05:52:58 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22123; Fri, 29 Oct 1999 08:52:55 -0400 (EDT) Message-Id: <199910291252.IAA22123@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rmt@lbl.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rmt-gra-arch-00.txt Date: Fri, 29 Oct 1999 08:52:55 -0400 Sender: owner-rmt@lbl.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Multicast Transport Working Group of the IETF. Title : Generic Router Assist (GRA) Building Block Motivation and Architecture Author(s) : B. Cain, T. Speakman, D. Towsley Filename : draft-ietf-rmt-gra-arch-00.txt Pages : 19 Date : 28-Oct-99 Generic Router Assist (GRA) is a network-based service that enables end-to-end multicast transport protocols to take advantage of infor- mation distributed across the network elements in a given multicast distribution tree. The service consists of a canonical set of simple functions which network elements may apply to selected packets in the transport session as they traverse the distribution tree. The choice of function and the packet parameters to which it is applied can be defined and customized for a given transport session in a highly con- trolled fashion that still permits enough flexibility for GRA to be used to address a wide range of multicast transport problems not amenable to end-to-end solution. This document provides the motiva- tion and an architecture for GRA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-gra-arch-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rmt-gra-arch-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmt-gra-arch-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991028142330.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-gra-arch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-gra-arch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991028142330.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Sun Nov 7 11:24:20 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id LAA26049; Sun, 7 Nov 1999 11:21:05 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA26045 for ; Sun, 7 Nov 1999 11:21:02 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA09002 for ; Sun, 7 Nov 1999 11:21:01 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA08994 for ; Sun, 7 Nov 1999 11:21:01 -0800 (PST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id NAA04917 for ; Sun, 7 Nov 1999 13:21:00 -0600 (CST)] Received: [from homer.arc.corp.mot.com ([217.1.10.38]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id NAA09835 for ; Sun, 7 Nov 1999 13:20:57 -0600 (CST)] Received: from arc.corp.mot.com (t_il06_k_slip3.corp.mot.com [129.188.171.205]) by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id GAA24068 for ; Mon, 8 Nov 1999 06:20:12 +1100 (EST) Message-ID: <3825D21F.EC144775@arc.corp.mot.com> Date: Mon, 08 Nov 1999 06:25:19 +1100 From: Roger Kermode Reply-To: Roger.Kermode@motorola.com Organization: Motorola X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: RMT Agenda, 46th IETF Washington Content-Type: multipart/mixed; boundary="------------D7E96917F903C1983F487296" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------D7E96917F903C1983F487296 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear RMT'ers, Please accept our apologies for the tardiness of this message. Below is the preliminary Agenda for the RMT meeting on Thursday. Please be prompt, note that as the Agenda is *very* tight, we will be taking steps to ensure that we run to time :) Cheers, Roger, Lorenzo, and Allison RMT Agenda Thursday, Novemeber 11 at 1300-1500 =================================== CHAIRS: Allison Mankin Roger Kermode Lorenzo Vicisano Agenda Bashing: Roger Kermode [ 4 mins] BB & DS Drafts Update: Roger Kermode [ 1 mins] Guidelines Draft (NEW): Allison Mankin [15 mins] Congestion Control Update: Mark Handley [ 5 mins] Security Requirements: Thomas Hardjono [10 mins] Generic Router Assist: Tony Speakman/Brad Cain [20 mins] Leg Stretch, Brain Cramp Removal, Carpal Tunnel Break [ 5 mins] Protocol 1 - NACK: Joe Macker [20 mins] Protocol 2 - TRACK: Brian Whetten [15 Mins] Protocol 3 - Open Loop: Mike Luby [10 mins] Recharter/Discussion/Next Steps: Roger Kermode [15 mins] --------------D7E96917F903C1983F487296 Content-Type: text/x-vcard; charset=us-ascii; name="rkermode.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Roger Kermode Content-Disposition: attachment; filename="rkermode.vcf" begin:vcard n:Kermode;Roger tel;fax:+61-2-9666-0501 tel;home:+61-2-9664-8335 tel;work:+61-2-9666-0558 x-mozilla-html:FALSE url:www.mot.com.au org:Motorola Australian Research Centre;Scalable Commodity Internet Lab version:2.1 email;internet:Roger.Kermode@motorola.com title:Principal Research Engineer adr;quoted-printable:;;Level 3,=0D=0A12 Lord St.;Botany;NSW;2019;Australia x-mozilla-cpt:;-1 fn:Roger Kermode end:vcard --------------D7E96917F903C1983F487296-- >From owner-rmt@listserv.lbl.gov Mon Nov 22 02:40:05 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id CAA13115; Mon, 22 Nov 1999 02:37:55 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA13111 for ; Mon, 22 Nov 1999 02:37:54 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA16569 for ; Mon, 22 Nov 1999 02:37:53 -0800 (PST) Received: from post.netchina.com.cn ([202.94.1.48]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id CAA16566 for ; Mon, 22 Nov 1999 02:37:50 -0800 (PST) Received: (qmail 21905 invoked from network); 22 Nov 1999 10:31:55 -0000 Received: from ppp227.netchina.com.cn (HELO netchina.com.cn) (202.94.2.227) by 202.94.1.48 with SMTP; 22 Nov 1999 10:31:55 -0000 Message-ID: <38391AC8.2CD00EB9@netchina.com.cn> Date: Mon, 22 Nov 1999 18:28:26 +0800 From: Robert Tan Reply-To: tjsh@netchina.com.cn Organization: Tan Junsheng X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt@lbl.gov Subject: The title: Flash Bandwidth 1KHz to 100MHz Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk The title: Flash Bandwidth 1KHz to 100MHz Digital Controlled Broadband Anti-alias & Reconstruction Filter Dear Sir: This is my discussion article. The details: http://www.cnindex.net/~tjsh/Base_of_Broadband_Access.html http://www.cnindex.net/~tjsh/Base_of_Broadband_Access.doc Sincerely, Robert Tan 11.22 Flash Bandwidth 1KHz to 100MHz Digital Controlled Broadband Anti-alias & Reconstruction Filter The Next Era Web of Multimedia Data-stream Transmission Solution of the Internet! By Robert Tan Update: 1999. 11. 22 For the many more format and definite of standard of digital film and video, digital audio and the other multimedia data stream of tomorrow, the existing network technology including the modern internet webs will be fabulous and difficult to transmit it for us. The Endpoint Congestion almost resistant our viewer area full of the entire world, We would need the straightway link of the multi-media data-stream in real-time for us. Would you like to get a lower cost & more effective digital signal channel in a wide-bandwidth or broadband hybrid coax cable system? For the FTTX, HFC networks, especially in the HFC networks with the 256QAM or 64VSB digital modulation technology systems, the SSB-ASK or the VSB-ASK technology transmission systems would be used normally. The Flash Bandwidth 1KHZ to 100MHz digital control a variable frequency bandwidth, it is high-performance anti-alias & reconstruction (FBW) filter, it will be able to provide a variable multiplex sub-frequency band in any broadband HFC system. With the FDM assistant digital carry system and SSB or VSB signal channel, a group of FBW filters will provide separate multi-frequency bands in spectrum without any cross talking and distortion by a large frequency range in a high-speed high- effective transmission system. In a FTTX or HFC web, this digital controlled signal channel would have a very large frequency spectrum changed dynamic range. For a large client group, such as the Broadband Cable Internet Access or HFC users, one of them would like to get a variable data speed according to the applications of his needed. It will provide a lot of digital control frequency bandwidth which is separated one another in HFC transmission system, and it will more effective for the "hot clients", such as the VOD video clients or the other high-code rate users and high-speed data stream user's applications. The FBW will improve the speed of the data stream, diminish the amount of the spare resource seizing of "Cool Clients", reduce the calculations of the DSP processor of the center web main switching system and the branch switching system. Reduce the CPU utilities of the applications in all of client communication adapter and its cost of produce is very important. The "Cool Clients" mains the IP telephone users or the other lower speed code rate audio applications. Anyway, the speed of the up-stream data and down-stream data speed could be changed to any value you needed, and the changing degree will be very smoothly and very simply in writing one or two bytes in the command system of communication web switcher. By the high-speed frequency variable characteristic, if the FBW filter were used in your FTTX or HFC switching system, the upward and downward data stream speed could be managed and attempted by your command system. So that, the transmission bandwidth will be able to adjusted to your needed in any time within one millionth second. The real-time will be very more improved and more effective on the communication main roads such as FTTX and HFC system, transmission controlling system will completely control the data stream in real-time. Dear Technology Research and Development Administrator: I am an electronic engineer in the field of Analog and Digital filters researching and designing. I had been a DSP engineer for ten years. My development field is electronic circuits -- digital and analog hardware designing and researching in applications of Digital Signal Processing. My works contains the frequency spectrum analysis, digital audio and digital video systems, noise spectrum controlling and processing, and the other military applications. I have researched and designed several kind of analog and digital anti-alias & reconstruction filters. A few years before, in my R&D works, I find the special frequency of the filters is usually fixed, it could be very difficult to change the cutoff frequency of the low-pass anti-alias & reconstruction filter. But the fixed filter could not suit the target of my technical applications. If we want to get several special frequency of the filters, we must to use several different fixed filters or instead of fixed filter with switching capacity filter or digital filter, such as IIR or FIR filter, and their frequency must be variable in order to change the analysis frequency. It is very important for the spectrum analysis system and the digital random real time vibrated controlling system. But, in this way, we must pay for digital IIR or FIR filter, it is very expensive in the price, take a large space for the DSP chips and its outside memory banks to install it. So, we would get into much troubles and complex questions from a simple problem. However, we have the switching capacity technologies, and the product of up to 8th order filters is a very normally used. But the switching capacity filter will have a high noise and low frequency range, and it has a non-exactly special frequency, generally. The special frequency of most of the switching capacity filters is from 1/95 to 1/105 times of its main switching clock and it is difficult to improve its accuracy. Actually, the switching capacity filter circuit is very difficult to adjust and use in applications. Anywise, its order is normally below 8th order, and the special frequency and bandwidth of the switching capacity filters is below to 50KHz, and the amplitude response is not exactly yet, the dynamic range of the amplitude is very low, normally, it is below the 48dB. Except of frequency range from 0 to 50Hz, in this field, its dynamic range is lower than 30 dB and not usefully, it is normally being used in the speech processing circuit and the other lower frequency band processing systems. Attention, all of this analysis is not including the phase noise of the main switching clock and the noise of clock feed through yet. The others, it is difficult to get much more analysis frequency bands or special frequency points for the switching capacity filters, it is especially for the higher frequency band which is approached to the top frequency point. All of these characteristics of the switching capacity filters will restrict its applications in the area of modern digital communications. The others method of the filters designing is the contact-time analog filter .I have found some method. It could make many transfer functions. Such as the elliptical function, Chebyshev function and Butterworth function, but there is some interesting things here, it is that the same circuit frame could be built into many transfer functions, and it would have programmable (digital controlled) special frequency. Changing special frequency on line is available. It could get the very wide frequency range, very quickly to change the used band, and the digital controlled circuit is very directly and simply, the special frequency step is very smoothly (because the Frequency is controlled by long bit Digital multiplier). In that points, integrate the FBW filter circuit technology is very useful for the digital controlling and processing systems. Because of the Digital Controlling Flash Bandwidth Filer (FBW) is depend on a few chips of high quality 8 or 12 bits long Digital Multiplier and a few chips of high-speed amplifiers. The other, this filter technology is used with a few exactitude resistors and exactitude capacitors also. For example, an 8th order elliptical filter need 8chips of dual Digital Multiplier and several chips high bandwidth amplifiers, 8chips exactitude capacitors and several chips exactitude resisters. If it is possible, integrating all the Digital Multiplier and amplifiers into one chip or one plastic package (mixed circuit), place all the exactitude resistors and capacitors out of the package. It will be finest filter and very easy to used and could be re-designed agilely by the customers and the OEMs. The parameter of the filters is depending on the value of the resistors and the capacitors. Its value could be designed by the customs freely and calculated by constant functions directly, and that is very simply. And then, the FBW filters would be very usefully in the FTTX or HFC networks. For working with the 256QAM or 64VSB modulation technology and any narrow-band transmission technology systems, such as the Broadband Cable Internet Access webs, HDTV or SDTV and VOD systems, it would compress the used frequency bandwidth in mostly extent. Because of the WAN systems in any nations will be depending on the "Tree structures" as the main road in the webs in the future. The frequency source is very expensive in this web, It would be welcomed in the Internet web digital information transmission, exchanging and switching technology area, DSP area and digital communications area, such as MAN and WAN coax cable webs or the FTTX system applications. Any way, the most of modern networking transmission mode is TDM. It is very suitable for the text material or media, because of it is a fixed media in size, and it is the fixed continue time in length and generation procedure. But the most of multimedia is not to be suitable with that. The data stream of voice and video will have no constant size to be forecasted has no constant procedure time. It is only have a constant and fixed bandwidth of media data stream. Because of your interesting points is onto the generations and the procedures of the video or audio information of thus material or the news, such as the high quality digital cinema, digital musicale and so on. Certainly, you could take the any multimedia information and any moving picture on you desktop through the Internet Web. It will be appeared the true alive world with you in any site you can go! So that, the only one of best way of the media data streams transmission and exchanging is the FDM mode with the SSB-ASK or VSB-ASK technology, it should be working with the QAM or VSB- ASK digital modulation technology in the future Internet webs. FBW filter would be used in most of switchers and routers, which is depending on the FDM technologies. For the cable TV systems STB (set top box), video & audio servers in Broadband Cable Internet Access, cable modems or the client-end adapters in the most of family users and the most of business cable users in the world will need a very great deal of broadband web transmission bandwidth. Because of that, in any modern home-electronic equipment, such as the Internet officers, shopping's and the VOD or the other broadband information electronics, its using method would be depending on the FDM switching technologies. So that, the "Online Home-Electronics" or the other Internet accessing products which is used in people's homes would be simply to operate and easy to use. And it must be depend on the simply low-layer hardware equipment and protocols of the webs, such as the VOD systems and the STB terminals in the Broadband Cable Internet Access or HFC networks. The FBW technology would provide us more applicable and useable method in the physics layer of the public HFC networks, its FDM applications in a broadband web get us in a lower building price, more effective than the other technology. Such as the Broadband Cable Internet Access webs, HFC networks, FTTX networks, and the other and the other WAN public broadband networks would have a very great applications of the FBW filters. The others, using a Flash-Band-width filter will help you get in to a fully data stream bandwidth management of any expensive data-link channels and the very expensive communication data stream bandwidth, such as the communication data-link of the satellite communication systems, and the ocean bottom communication systems. FBW filter will control the any leased data-stream bandwidth in dynamic mode within a very large frequency range, a large range of signal frequency bandwidth and data-stream speed in any time for a communication administration and operation system. It will change the bandwidth with you leased data stream very imminently within several microsecond, improve your expensive bandwidth of data-stream transmission channel, save your leased payment and money cost for any customers of digital communications and any Tele-communication operating and service company. It will hold any important transmission of data-stream in smoothly and take it freely. So, in this system, any interrupt of your communication data stream will be never. The Digital Control Flash Bandwidth Filter specifications: (1) General details: Frequency range: 0.1Hz--100MHz Useable frequency range: 0.1Hz--100MHz(at least) Special frequency step: 0.001Hz-1000KHz Transfer functions: Elliptical, Butterworth, Chebyshev, and Bassel function. And the others contacted-time filters. Available filter type: Low-pass filter, High-pass filter, Notch filter, Band-pass filter and All-pass filter. Noise Level: -160dB(max) (Only depend on the number of the used amplifiers.) Order range: 2nd--12th(Depend on the sensitivity of the transfer functions.) Filter switching time: Less than 300nS (Filter Setting time is 200nS) Useful Range: Anti-alias filters, Reconstruction filters. (2) Pass Band Specifications: Frequency selectable range: 100Hz--100MHz (Depend on the performance of the selected amplifiers) Special Frequency steps: 1Hz-1000KHz Pass band Dynamic range: 90dB (Depend on the amplifiers and the order of the filter.) Ripple: 0.01--1.0dB (Only depend on the filter function and the passband ripple designed.) (3) Pass to Stop Band: Drop speed of Interim-band Cut-off: 180db/oct (8th order elliptical function with 0.05dB pass-band ripple) (4) Stop Band: Amplitude min drop: 120db(8th elliptical filter for example) Frequency range: 0.1Hz--100MHz (Depend on the amplifiers and the Digital Multiplier specifications) (5) Digital Control specifications: Digital component is used (8 bit, 10bit, 12bit, and 16bit is available). The special frequency is (N1/N2) * Frequency (ref). (The N1, N2 is the Digital component input byte, from 8bit to 16 bit.) The Frequency (ref) is form 10Hz to 10MHz. (This parameter is depends on one RC time constant.) High speed and voltage feedback high-bandwidth operation amplifiers are required. (6) Requirement: (The filter section of 8th order) Digital component: 8 chips (Selections depend on the frequency range) High-performance Amplifiers: 12 to 24 chips (Selections depend on the frequency) Capacitors or inductors: 8 chips (exactitude degree value is 1% to 0.1%) Resistors: 16-36 chips (exactitude degree value is 1% to 0.1%) (7) Group delay: Depend on the function of the filter designed, filter phase response designed, and the filter order. (8) Filter switching time: Less than 300nS (Filter Setting time is 200nS) The Comparisons of the 4 kinds active Filters For example: 8th order filter Switching Capacity Filter Digital Filter (FIR or IIR Filter) Traditional Fixed Analog Frequency Filter Digital controlling FBW filter Noise Level or (THD+N) Value: Highest -48db Lower -70db Very Low -160db Very Low -120db Filter Dynamic Range The Value: Little 50db Middle 70db Very Large 160db Large 100db Real-time active frequency The range of the value: Narrow 200Hz to 300KHz Wide 0.001Hz to 50KHz Very Wide 0.1Hz to 1MHz Very wide 0.001Hz to 100MHz The Outside in advance Anti-alias & Reconstruction assistant filter requirement The degree of assistant filter Quality Required 2nd to 4th order anti-alias & reconstruction assistant outside filter Required 4th to 6th order anti-alias & reconstruction assistant outside filter Not required. ---------- Not required ---------- The Precision of the special frequency: The ability of on-line changing the filter special frequency &Method Low. +/-3% Very easy (Changing the switching clock) High +/-3% Very difficult (Change a new programs and parameters ) Very high 0.1% Very difficult. (Changing the system time constant) Very high 0.1% Easy(Writing digital word to the filter control port) The complex degree of the filter system designing &The used space Simple Small Very complex Very large Simple Middle Middle Middle The price for produce a filter &The difficult degree of the applications Very low $10~50 Easy Very high $300~600 Difficult Low $30~90 Easy Middle $50~100 Middle Anti-alias & Reconstruction filter Performance: (1)Pass Band Ripple &Dynamic Range: (2)Stop Band Rejection (3)Interim Band Dropping Slope: Low Quality & Low Price. +/-0.2db 50db 55db 50db/oct Normal or High Quality & High price +/-0.01db 70db 70db 130db/oct Normal Quality & Low Price +/-0.01db 120db 120db 180db/oct High Quality & & Middle Price. +/-0.01db 110db 120db 180db/oct Online/offline Changing of highest/lowest special frequency rate & Range: &changing time: All available 1000 times 300Hz to 300KHz 10mS(Time of PLL tracking & locked) Offline available Not available Not available Not available (Reboot DSP & A/D system) Offline available 1000 times Not available Not available All available 100000 times 1KHz to 100MHz 160nS (TTL 2 bytes writing time) Filter online reconstruction setting time (The total time of filter frequency switched) 10mS Not available Not available 300nS Group delay and the phase response: Producer design only. Linear or Producer design only. Producer design only. Producer & User design is available. Equality data stream speed or comported speed of its TxDAC : &Butterworth 8th filter (Broadband channel HFC usable signal dynamic range is about 50dB): 4.8Kbps to 4.8Mbps (600SPS to 600KSPS) 8bit TxDAC Constant 400Kbps (50KSPS) 8bit TxDAC Constant 800Mbps (100MSPS) 8bit TxDAC 16Kbps to 1600Mbps (2KSPS to 200MSPS) 8bit TxDAC Suitable with the 8bit TxDAC and used 256QAM (or 64VSB) in SSB/VSB mode of technology (Data speed of Base Band): Carrier signal RF full-band tie up: Difficult to be used with the 256QAM and 64VSB. (High Level Phase Noise) 4.8Kbps(Min) 4.8Mbps(Max) 384Hz to 384KHz Difficult to be used in variable data-speed transmission or receiving system Difficult to be used in variable data-speed transmission or receiving system With 256QAM: 8Kbps(Min) 800Mbps (Max) With 64VSB: 12Kbps(Min) 1200Mbps (Max). 1.28KHz to 128MHz For the HFC Specialty signal TV Channel: 40dB Eb/N 6MHz Full-band 64VSB model @1KHz-6MHz Data-rate: With 64VSB: 9.375Kbps (Min) 56.25Mbps (Max) Contact Address: No.2 Buliding Room1007, Mudanyuan Beili, Haidian District Beijing P. R. China, Post Code: 100083 Name: Tan Junsheng (Robert Tan) Tele: 8610-82076834, 86-13701070213(Mobile) E-mail: Tjsh@netchina.com.cn or tanjun@hotmail.com Homepage: http://www.cnindex.net/~tjsh Details Remind: http://www.cnindex.net/~tjsh/Base_of_Broadband_Access.html >From owner-rmt@listserv.lbl.gov Mon Dec 6 02:13:09 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id CAA06580; Mon, 6 Dec 1999 02:08:05 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA06576 for ; Mon, 6 Dec 1999 02:08:04 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA11687 for ; Mon, 6 Dec 1999 02:08:03 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA11684 for ; Mon, 6 Dec 1999 02:08:02 -0800 (PST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id DAA07766 for ; Mon, 6 Dec 1999 03:07:58 -0700 (MST)] Received: [from homer.arc.corp.mot.com ([217.1.10.38]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id DAA10814 for ; Mon, 6 Dec 1999 03:07:56 -0700 (MST)] Received: from arc.corp.mot.com (IDENT:rkermode@[217.1.71.205]) by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id VAA09163 for ; Mon, 6 Dec 1999 21:07:06 +1100 (EST) Message-ID: <384B8B59.E3B1C1AB@arc.corp.mot.com> Date: Mon, 06 Dec 1999 21:09:29 +1100 From: Roger Kermode X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: rmt@lbl.gov Subject: RMT Future Progress..... Content-Type: multipart/alternative; boundary="------------E8E3F1738F8E4F1EA0F97937" Sender: owner-rmt@lbl.gov Precedence: bulk --------------E8E3F1738F8E4F1EA0F97937 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Everyone, Thanks for your efforts so far. In discussions between the RMT chairs and the Transport ADs after the RMT slot in Washington D.C., it was decided that we need to accelerate our progress. To that we'd like to propose two things: 1) Hold an all-day interim meeting in mid-february at least one month before the Adelaide IETF. It has been suggested that the west-coast of the US would be a good place to hold the meeting. Possible venues could be Berkeley or San Diego, what do people think? 2) Formation of teams to work on Building Block and Protocol Instanitaions Drafts: Below is a list of people (alphabetic order) who have expressed an interest in working on the various drafts. We'd like to see the team for each draft to solidify and for work to start in earnest for presentation at the interim meeting. ACTION: Let's use the list to start some discussion about 1) forming the teams to do the drafts and 2) whether people can attend the interim meeting in mid-feb cheers, Roger Kermode, Allison Mankin, Lorenzo Vicisano Guidelines Draft ---------------- Roger Kermode Allison Mankin Lorenzo Vicisano Building Blocks teams --------------------- ## Congestion Control (with RMRG) Sally Flloyd Mark Handley ## Generic Router Assist Brad Cain, Tony Speakman, Don Towsley ## NACK Brian Adamson Joe Macker ## FEC Jon Crowcroft? Jim Gemmel Mike Luby Luigi Rizzo Lorenzo Vicisano? ## Tree Building (with RMRG) Dah Ming Chu Roger Kermode Brian Levine Dave Thaler Brian Whetten Transport Protection ?? Protocol Instantiaions ---------------------- ## NACK Joe Macker Brian Adamson ## TRACK Brian Whetten Dah Ming Chiu ## Open Loop FEC Mike Luby --------------E8E3F1738F8E4F1EA0F97937 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Everyone,

Thanks for your efforts so far. In discussions between the RMT chairs
and the Transport ADs after the RMT slot in Washington D.C., it was
decided that we need to accelerate our progress. To that we'd like
to propose two things:
 

1) Hold an all-day interim meeting in mid-february at least one month
   before the Adelaide IETF.

   It has been suggested that the west-coast of the US would be a good
   place to hold the meeting. Possible venues could be Berkeley or
   San Diego, what do people think?

2) Formation of teams to work on Building Block and Protocol
   Instanitaions Drafts:

   Below is a list of people (alphabetic order) who have expressed an
   interest in working on the various drafts. We'd like to see the team
   for each draft to solidify and for work to start in earnest for
   presentation at the interim meeting.

ACTION: Let's use the list to start some discussion about
  1) forming the teams to do the drafts and
  2) whether people can attend the interim meeting in mid-feb

cheers,

Roger Kermode,
Allison Mankin,
Lorenzo Vicisano
 

Guidelines Draft
----------------
Roger Kermode
Allison Mankin
Lorenzo Vicisano

Building Blocks teams
---------------------

## Congestion Control (with RMRG)
Sally Flloyd
Mark Handley

## Generic Router Assist
Brad Cain,
Tony Speakman,
Don Towsley

## NACK
Brian Adamson
Joe Macker

## FEC
Jon Crowcroft?
Jim Gemmel
Mike Luby
Luigi Rizzo
Lorenzo Vicisano?

## Tree Building (with RMRG)
Dah Ming Chu
Roger Kermode
Brian Levine
Dave Thaler
Brian Whetten

Transport Protection
??

Protocol Instantiaions
----------------------
## NACK
Joe Macker
Brian Adamson

## TRACK
Brian Whetten
Dah Ming Chiu

## Open Loop FEC
Mike Luby --------------E8E3F1738F8E4F1EA0F97937-- >From owner-rmt@listserv.lbl.gov Mon Dec 6 12:08:25 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id MAA09564; Mon, 6 Dec 1999 12:07:39 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA09560 for ; Mon, 6 Dec 1999 12:07:38 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA06942 for ; Mon, 6 Dec 1999 12:07:37 -0800 (PST) Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA06934 for ; Mon, 6 Dec 1999 12:07:35 -0800 (PST) Received: from tahoe ([10.3.9.43]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id MAA21305; Mon, 6 Dec 1999 12:07:06 -0800 (PST) Message-Id: <4.1.19991206120017.01f08b90@mailhost.talarian.com> X-Sender: whetten@pop3.concentric.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 06 Dec 1999 12:07:54 -0800 To: Roger Kermode , rmt@lbl.gov From: Brian Whetten Subject: Re: RMT Future Progress..... In-Reply-To: <384B8B59.E3B1C1AB@arc.corp.mot.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_4158739==_.ALT" Sender: owner-rmt@lbl.gov Precedence: bulk --=====================_4158739==_.ALT Content-Type: text/plain; charset="us-ascii" Great to see the pointy stick out again. :) I would also be happy to/like to participate in the congestion control BB. For transport layer protection, I think Thomas Hardjorno has some interest in helping with this, and he can probably point you to some others from the SMUG community who have interest in helping on this as well. Can I please make just one strong request for the February meeting, which is that we schedule it in the next 2-3 weeksW. February 7-9 is the IP Multicast Summit, here in the bay, so scheduling it for the 10th might work well for people. Brian At 09:09 PM 12/6/1999 +1100, Roger Kermode wrote: > > Dear Everyone, > > Thanks for your efforts so far. In discussions between the RMT chairs > and the Transport ADs after the RMT slot in Washington D.C., it was > decided that we need to accelerate our progress. To that we'd like > to propose two things: > > > 1) Hold an all-day interim meeting in mid-february at least one month > before the Adelaide IETF. > > It has been suggested that the west-coast of the US would be a good > place to hold the meeting. Possible venues could be Berkeley or > San Diego, what do people think? > > 2) Formation of teams to work on Building Block and Protocol > Instanitaions Drafts: > > Below is a list of people (alphabetic order) who have expressed an > interest in working on the various drafts. We'd like to see the team > for each draft to solidify and for work to start in earnest for > presentation at the interim meeting. > > ACTION: Let's use the list to start some discussion about > 1) forming the teams to do the drafts and > 2) whether people can attend the interim meeting in mid-feb > > cheers, > > Roger Kermode, > Allison Mankin, > Lorenzo Vicisano > > > Guidelines Draft > ---------------- > Roger Kermode > Allison Mankin > Lorenzo Vicisano > > Building Blocks teams > --------------------- > > ## Congestion Control (with RMRG) > Sally Flloyd > Mark Handley > > ## Generic Router Assist > Brad Cain, > Tony Speakman, > Don Towsley > > ## NACK > Brian Adamson > Joe Macker > > ## FEC > Jon Crowcroft? > Jim Gemmel > Mike Luby > Luigi Rizzo > Lorenzo Vicisano? > > ## Tree Building (with RMRG) > Dah Ming Chu > Roger Kermode > Brian Levine > Dave Thaler > Brian Whetten > > Transport Protection > ?? > > Protocol Instantiaions > ---------------------- > ## NACK > Joe Macker > Brian Adamson > > ## TRACK > Brian Whetten > Dah Ming Chiu > > ## Open Loop FEC > Mike Luby --=====================_4158739==_.ALT Content-Type: text/html; charset="us-ascii" Great to see the pointy stick out again.  :)

I would also be happy to/like to participate in the congestion control BB.  For transport layer protection, I think Thomas Hardjorno has some interest in helping with this, and he can probably point you to some others from the SMUG community who have interest in helping on this as well.

Can I please make just one strong request for the February meeting, which is that we schedule it in the next 2-3 weeksW.  February 7-9 is the IP Multicast Summit, here in the bay, so scheduling it for the 10th might work well for people.

Brian

At 09:09 PM 12/6/1999 +1100, Roger Kermode wrote:

Dear Everyone,

Thanks for your efforts so far. In discussions between the RMT chairs
and the Transport ADs after the RMT slot in Washington D.C., it was
decided that we need to accelerate our progress. To that we'd like
to propose two things:
 

1) Hold an all-day interim meeting in mid-february at least one month
   before the Adelaide IETF.

   It has been suggested that the west-coast of the US would be a good
   place to hold the meeting. Possible venues could be Berkeley or
   San Diego, what do people think?

2) Formation of teams to work on Building Block and Protocol
   Instanitaions Drafts:

   Below is a list of people (alphabetic order) who have expressed an
   interest in working on the various drafts. We'd like to see the team
   for each draft to solidify and for work to start in earnest for
   presentation at the interim meeting.

ACTION: Let's use the list to start some discussion about
  1) forming the teams to do the drafts and
  2) whether people can attend the interim meeting in mid-feb

cheers,

Roger Kermode,
Allison Mankin,
Lorenzo Vicisano
 

Guidelines Draft
----------------
Roger Kermode
Allison Mankin
Lorenzo Vicisano

Building Blocks teams
---------------------

## Congestion Control (with RMRG)
Sally Flloyd
Mark Handley

## Generic Router Assist
Brad Cain,
Tony Speakman,
Don Towsley

## NACK
Brian Adamson
Joe Macker

## FEC
Jon Crowcroft?
Jim Gemmel
Mike Luby
Luigi Rizzo
Lorenzo Vicisano?

## Tree Building (with RMRG)
Dah Ming Chu
Roger Kermode
Brian Levine
Dave Thaler
Brian Whetten

Transport Protection
??

Protocol Instantiaions
----------------------
## NACK
Joe Macker
Brian Adamson

## TRACK
Brian Whetten
Dah Ming Chiu

## Open Loop FEC
Mike Luby


--=====================_4158739==_.ALT-- >From owner-rmt@listserv.lbl.gov Mon Dec 6 13:20:00 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id NAA09830; Mon, 6 Dec 1999 13:19:25 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA09826 for ; Mon, 6 Dec 1999 13:19:24 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA29819 for ; Mon, 6 Dec 1999 13:19:23 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA29779 for ; Mon, 6 Dec 1999 13:19:17 -0800 (PST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA14636 for ; Mon, 6 Dec 1999 13:19:16 -0800 (PST) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA12653 for ; Mon, 6 Dec 1999 16:19:14 -0500 (EST) Received: from bridge (bridge [129.148.75.125]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id QAA10750 for ; Mon, 6 Dec 1999 16:19:15 -0500 (EST) Message-Id: <199912062119.QAA10750@bcn.East.Sun.COM> Date: Mon, 6 Dec 1999 16:19:13 -0500 (EST) From: Dah Ming Chiu - Sun Microsystems Reply-To: Dah Ming Chiu - Sun Microsystems Subject: Re: RMT Future Progress..... To: rmt@lbl.gov MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: mMfyCyd3/fBAzHZorxGgug== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-rmt@lbl.gov Precedence: bulk I also like the idea of holding it in the Bay area, near IP Multicast Summit. Regards Dah Ming Chiu >From owner-rmt@listserv.lbl.gov Tue Dec 7 14:19:37 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id OAA21613; Tue, 7 Dec 1999 14:18:22 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA21604 for ; Tue, 7 Dec 1999 14:18:20 -0800 (PST) From: rhee@eos.ncsu.edu Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA28438 for ; Tue, 7 Dec 1999 14:18:19 -0800 (PST) Received: from rolex.csc.ncsu.edu (rolex.csc.ncsu.edu [152.1.213.197]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA28433 for ; Tue, 7 Dec 1999 14:18:18 -0800 (PST) Received: (from rhee@localhost) by rolex.csc.ncsu.edu (8.8.4/UC02Jan97) id RAA03393; Tue, 7 Dec 1999 17:18:16 -0500 (EST) Date: Tue, 7 Dec 1999 17:18:16 -0500 (EST) Message-Id: <199912072218.RAA03393@rolex.csc.ncsu.edu> To: rkermode@arc.corp.mot.com, rmt@lbl.gov Subject: re: RMT Future Progress..... Sender: owner-rmt@lbl.gov Precedence: bulk Hi Roger, I would like to participate in the internet-drafting process. In particular, I am interested in congestion control and FEC. Is it possible to have me in these teams? Injong >From owner-rmt@listserv.lbl.gov Thu Dec 9 13:34:40 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id NAA02820; Thu, 9 Dec 1999 13:31:53 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA02816 for ; Thu, 9 Dec 1999 13:31:51 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA21648 for ; Thu, 9 Dec 1999 13:31:50 -0800 (PST) Received: from hercules.cs.ucsb.edu (hercules.cs.ucsb.edu [128.111.41.30]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA21643 for ; Thu, 9 Dec 1999 13:31:50 -0800 (PST) Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id NAA15497; Thu, 9 Dec 1999 13:31:38 -0800 (PST) Received: by jackson.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4) id NAA28580 for ; Thu, 9 Dec 1999 13:31:33 -0800 (PST) Date: Thu, 9 Dec 1999 13:31:33 -0800 (PST) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <199912092131.NAA28580@jackson.cs.ucsb.edu> To: almeroth@cs.ucsb.edu, nonnen@research.bell-labs.com Subject: CFP: Integrating Multicast into the Internet (Special Issue of Computer Communications) Sender: owner-rmt@lbl.gov Precedence: bulk CALL FOR PAPERS: Special Issue of Computer Communications on Integrating Multicast into the Internet CFP URL: http://www.cs.ucsb.edu/~almeroth/COMCOM:cfp.html Journal URL: http://www.elsevier.com/inca/publications/store/5/2/5/4/4/0/ TOPICS: The amount of bandwidth available in the Internet is increasing dramatically, both in the backbone networks, as well as in the last mile (broadband access). One consequence is that the delivery of high-quality multimedia data will become feasible, and multimedia data, including audio and video, will become the dominant traffic. As more users gain access to broadband services, new applications and services will become possible. The result will be a growing demand for large-scale multimedia applications and services. Multicasting as a pure networking solution to the transport of media is recognized as offering economies-of-scale for large-scale applications. Multicast is also believed to enable applications which provide service to thousands, even millions of customers. While there has been significant research work on multicast, efforts to successfully deploy a production service have lagged. Reasons range from frequently changing protocols, management and engineering problems, legacy hardware limitations, traffic conflicts with unicast, etc.. This special issue focuses on research issues dealing with the challenges of deploying multicast in the network. Specific topics include, but are not limited to: * Multicast Congestion Control * Multicast Overlay Networks * Next-Generation Multicast Routing Algorithms * Multicast Media Transport * Security for Multicast-Based Services * Multicast Traffic Engineering and Management * Multicast Pricing and Quality of Service GUEST EDITORS: Kevin Almeroth Jorg Nonnenmacher Department of Computer Science Network Research Dept, Lucent Technologies University of California 600-700 Mountain Avenue Santa Barbara, CA 93106-5110 Murray Hill, NJ 07974-0636 Phone: +1(805) 893-2777 Phone: +1(908) 582-1707 Fax: +1(805) 893-8553 Fax: +1(908) 582-6632 Email: almeroth@cs.ucsb.edu Email: nonnen@research.bell-labs.com IMPORTANT DATES: Paper Submission Deadline: February 1, 2000 Feedback to Authors: May 1, 2000 Final Manuscripts Due: June 1, 2000 Publication Date: Fall 2000 SUBMISSION INSTRUCTIONS: Authors are requested to send e-mail to one or both of the Guest Editors (almeroth@cs.ucsb.edu, nonnen@research.bell-labs.com) giving a URL from where a postscript or PDF file can be downloaded. Successfully received papers will be acknowledged. AUTHOR INFORMATION: Submissions made to the special issue should not have appeared in, or been submitted to other archival publications. All papers will be subjected to the journal's usual refereeing process. >From owner-rmt@listserv.lbl.gov Thu Dec 9 15:07:51 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id PAA03178; Thu, 9 Dec 1999 15:07:30 -0800 (PST) Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA03174 for ; Thu, 9 Dec 1999 15:07:28 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA19652 for ; Thu, 9 Dec 1999 15:07:28 -0800 (PST) Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA19648 for ; Thu, 9 Dec 1999 15:07:27 -0800 (PST) Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id PAA18195 for ; Thu, 9 Dec 1999 15:07:27 -0800 (PST) Received: from localhost (lorenzo@localhost) by kouvelas-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA10767 for ; Thu, 9 Dec 1999 15:06:23 -0800 (PST) Message-Id: <199912092306.PAA10767@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.0.2 2/24/98 To: rmt@lbl.gov Subject: Draft meeting minutes Mime-Version: 1.0 Content-Type: text/plain Date: Thu, 09 Dec 1999 15:06:23 -0800 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk Hi, Please find enclosed the draft version of the Washington IETF meeting minutes. If you have comments please let us know by tomorrow Dec 10th 3pm PST. Apologize for the short notice. Cheers, The WG Chairs Content-Type: multipart/mixed ; boundary="==_Exmh_-5897494130" This is a multipart MIME message. --==_Exmh_-5897494130 --==_Exmh_-5897494130 Content-Type: text/plain ; name="rmt2-minutes"; charset=us-ascii Content-Description: rmt2-minutes Content-Disposition: attachment; filename="rmt2-minutes" Thursday, November 11 at 1300-1500 =================================== CHAIRS: Allison Mankin Roger Kermode Lorenzo Vicisano 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. --==_Exmh_-5897494130-- >From owner-rmt@listserv.lbl.gov Fri Dec 10 17:56:39 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id RAA09066; Fri, 10 Dec 1999 17:55:29 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA09062 for ; Fri, 10 Dec 1999 17:55:28 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA26623 for ; Fri, 10 Dec 1999 17:55:27 -0800 (PST) Received: from pacific.intranet (226.webfountain.com [208.48.102.226]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA26619 for ; Fri, 10 Dec 1999 17:55:26 -0800 (PST) Received: by pacific.intranet with Internet Mail Service (5.5.2448.0) id ; Fri, 10 Dec 1999 17:54:39 -0800 Message-ID: <619F2FB3840CD311AC2C0090273BF1AC151F43@pacific.intranet> From: Mike Luby To: "'Lorenzo Vicisano'" , "'rmt@lbl.gov'" Subject: RE: Draft meeting minutes Date: Fri, 10 Dec 1999 17:54:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rmt@lbl.gov Precedence: bulk Lorenzo and All, Please change all references to "open loop" in this document and subsequent documents to "ALC", which stands for "Asynchronous Layered Coding". Thanks, Mike -----Original Message----- From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Lorenzo Vicisano Sent: Thursday, December 09, 1999 3:06 PM To: rmt@lbl.gov Subject: Draft meeting minutes Hi, Please find enclosed the draft version of the Washington IETF meeting minutes. If you have comments please let us know by tomorrow Dec 10th 3pm PST. Apologize for the short notice. Cheers, The WG Chairs Content-Type: multipart/mixed ; boundary="==_Exmh_-5897494130" This is a multipart MIME message. --==_Exmh_-5897494130 --==_Exmh_-5897494130 Content-Type: text/plain ; name="rmt2-minutes"; charset=us-ascii Content-Description: rmt2-minutes Content-Disposition: attachment; filename="rmt2-minutes" Thursday, November 11 at 1300-1500 =================================== CHAIRS: Allison Mankin Roger Kermode Lorenzo Vicisano 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. --==_Exmh_-5897494130-- >From owner-rmt@listserv.lbl.gov Fri Dec 10 18:05:28 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id SAA09104; Fri, 10 Dec 1999 18:05:26 -0800 (PST) Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA09100 for ; Fri, 10 Dec 1999 18:05:24 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA28019 for ; Fri, 10 Dec 1999 18:05:23 -0800 (PST) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA28006 for ; Fri, 10 Dec 1999 18:05:18 -0800 (PST) Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id SAA11689; Fri, 10 Dec 1999 18:00:54 -0800 (PST) Received: from localhost (lorenzo@localhost) by kouvelas-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA12758; Fri, 10 Dec 1999 18:04:40 -0800 (PST) Message-Id: <199912110204.SAA12758@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.0.2 2/24/98 To: Mike Luby cc: "'rmt@lbl.gov'" Subject: Re: Draft meeting minutes In-reply-to: Your message of "Fri, 10 Dec 1999 17:54:34 PST." <619F2FB3840CD311AC2C0090273BF1AC151F43@pacific.intranet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Dec 1999 18:04:40 -0800 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk Mike, > Please change all references to "open loop" in this document and subsequent > documents to "ALC", which stands for "Asynchronous Layered Coding". Too late: I've already sent the minutes. Will do next time. Please note however the we mentioned ALC in the notes. cheers, Lorenzo >From owner-rmt@listserv.lbl.gov Fri Dec 10 20:16:35 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id UAA09435; Fri, 10 Dec 1999 20:16:19 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA09431 for ; Fri, 10 Dec 1999 20:16:17 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA07978 for ; Fri, 10 Dec 1999 20:16:16 -0800 (PST) Received: from virtualworkshop.com (IDENT:root@dino.virtualworkshop.com [208.14.33.1]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA07975 for ; Fri, 10 Dec 1999 20:16:15 -0800 (PST) Received: from virtualworkshop.com (barney.virtualworkshop.com [208.14.33.4]) by virtualworkshop.com (8.9.1/8.8.7) with ESMTP id XAA12521; Fri, 10 Dec 1999 23:16:06 -0500 Message-ID: <3851D005.9B750D41@virtualworkshop.com> Date: Fri, 10 Dec 1999 23:16:05 -0500 From: "Michael D. Myjak" Reply-To: mmyjak@virtualworkshop.com Organization: The Virtual Workshop, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Lorenzo Vicisano CC: RMT Subject: Re: Draft meeting minutes References: <199912110204.SAA12758@kouvelas-u10.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Lorenzo Vicisano wrote: > Mike, > > > Please change all references to "open loop" in this document and subsequent > > documents to "ALC", which stands for "Asynchronous Layered Coding". > > Too late: I've already sent the minutes. Will do next time. > Please note however the we mentioned ALC in the notes. > > cheers, > Lorenzo Lorenzo, Its not uncommon to circulate the minutes, make a correction or two, and recirculate a final draft. -- All the best - _ ___|0|_|___ Michael D. Myjak, Vice President R&D and CTO | N & W | The Virtual Workshop, Inc. = oo---oo = P.O. Box 98 Titusville Fl 32781 email: voice&fax: 407.264.0440 >From owner-rmt@listserv.lbl.gov Fri Dec 10 20:50:54 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id UAA09504; Fri, 10 Dec 1999 20:50:45 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA09500 for ; Fri, 10 Dec 1999 20:50:43 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA09547 for ; Fri, 10 Dec 1999 20:50:43 -0800 (PST) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA09544 for ; Fri, 10 Dec 1999 20:50:42 -0800 (PST) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.2/8.9.2) id UAA06351; Fri, 10 Dec 1999 20:50:40 -0800 (PST) Message-Id: <199912110450.UAA06351@daffy.ee.lbl.gov> To: mmyjak@virtualworkshop.com Cc: Lorenzo Vicisano , RMT Subject: Re: Draft meeting minutes In-reply-to: Your message of Fri, 10 Dec 1999 23:16:05 PST. Date: Fri, 10 Dec 1999 20:50:39 PST From: Vern Paxson Sender: owner-rmt@lbl.gov Precedence: bulk > Its not uncommon to circulate the minutes, make a correction or two, and > recirculate a final draft. I have a hard time seeing changing minutes that discuss a proposal to change the term "Open Loop" to "ALC", so that they don't mention the term "Open Loop" and just use "ALC". I think the minutes should stand as they are. In addition, the meeting summary that the chairs sent to the area directors said of the proposed name change that there "was little time for discussion of this suggestion". So I think the name change should first be open for discussion on the mailing list (personally, I think it's a good idea). Vern >From owner-rmt@listserv.lbl.gov Sat Dec 11 18:24:07 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id SAA11597; Sat, 11 Dec 1999 18:22:38 -0800 (PST) Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA11593 for ; Sat, 11 Dec 1999 18:22:32 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA04902 for ; Sat, 11 Dec 1999 18:22:31 -0800 (PST) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA04892 for ; Sat, 11 Dec 1999 18:22:26 -0800 (PST) Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id SAA10543; Sat, 11 Dec 1999 18:17:48 -0800 (PST) Received: from localhost (lorenzo@localhost) by kouvelas-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA14121; Sat, 11 Dec 1999 18:21:39 -0800 (PST) Message-Id: <199912120221.SAA14121@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.0.2 2/24/98 To: mmyjak@virtualworkshop.com cc: RMT Subject: Re: Draft meeting minutes In-reply-to: Your message of "Fri, 10 Dec 1999 23:16:05 EST." <3851D005.9B750D41@virtualworkshop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 11 Dec 1999 18:21:39 -0800 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk > Its not uncommon to circulate the minutes, make a correction or two, and > recirculate a final draft. Michael, Mike's request arrived after the deadline we had set, that was dictated by the IETF deadline. We do apologize, however, for having sent out the minutes only one day in advance. cheers, Lorenzo >From owner-rmt@listserv.lbl.gov Thu Dec 16 21:32:05 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id VAA14385; Thu, 16 Dec 1999 21:30:17 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA14381 for ; Thu, 16 Dec 1999 21:30:15 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA11441 for ; Thu, 16 Dec 1999 21:30:14 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA11438 for ; Thu, 16 Dec 1999 21:30:13 -0800 (PST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id WAA21197 for ; Thu, 16 Dec 1999 22:30:13 -0700 (MST)] Received: [from homer.arc.corp.mot.com ([217.1.10.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id WAA19310 for ; Thu, 16 Dec 1999 22:30:11 -0700 (MST)] Received: from arc.corp.mot.com (t-il06-y-port8.corp.mot.com [129.188.170.138]) by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id QAA23178 for ; Fri, 17 Dec 1999 16:28:30 +1100 (EST) Message-ID: <3859CBA1.7F682961@arc.corp.mot.com> Date: Fri, 17 Dec 1999 16:35:29 +1100 From: Roger Kermode Reply-To: Roger.Kermode@motorola.com Organization: Motorola X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: RMT Team Formation, draft editor election... Content-Type: multipart/mixed; boundary="------------00253F7E6647C5CCE17686FA" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------00253F7E6647C5CCE17686FA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear RMTers, I've done my best to add names and email addresses to the list of actively interested people for each of the RMT drafts that have currently been scheduled. I'd like each you involved in a teams to contact the other members of your team and to elect a document editor for that team. This person will be responsible for merging the inputs of other team members and ensuring the timely progress of the draft. Given that the holidays are nearly upon us it would be nice to have this sorted out in the next week or so, cheers, Roger Guidelines Draft ---------------- Roger Kermode Allison Mankin Lorenzo Vicisano Building Blocks teams --------------------- ## Congestion Control (with RMRG) Sally Flloyd Mark Handley Shivkumar Kalyanaraman Injong Rhee ## Generic Router Assist Brad Cain Tony Speakman, Don Towsley ## NACK Brian Adamson Joe Macker Carsten Borman ## Asynchronous Layered Coding Jon Crowcroft Jim Gemmel Mike Luby Luigi Rizzo Lorenzo Vicisano Bruce Lueckenhoff Vincent ROCA ## Tree Building (with RMRG) Dah Ming Chu Roger Kermode Brian Levine Dave Thaler Brian Whetten Transport Protection ?? Protocol Instantiaions ---------------------- ## NACK Brian Adamson Joe Macker Richard Edmonstone ## TRACK Brian Whetten Dah Ming Chiu ## Asynchronous Layered Coding Jon Crowcroft Jim Gemmel Mike Luby Luigi Rizzo Lorenzo Vicisano Bruce Lueckenhoff --------------00253F7E6647C5CCE17686FA Content-Type: text/x-vcard; charset=us-ascii; name="rkermode.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Roger Kermode Content-Disposition: attachment; filename="rkermode.vcf" begin:vcard n:Kermode;Roger tel;fax:+61-2-9666-0501 tel;home:+61-2-9664-8335 tel;work:+61-2-9666-0558 x-mozilla-html:FALSE url:www.mot.com.au org:Motorola Australian Research Centre;Scalable Commodity Internet Lab version:2.1 email;internet:Roger.Kermode@motorola.com title:Principal Research Engineer SNAIL MAIL: Locked Bag 5028, Botany NSW, 1455=0D=0A;Botany;NSW;2019;Australia adr;quoted-printable:;;PHYSICAL: Level 3, 12 Lord St., Botany, NSW=0D=0A= x-mozilla-cpt:;-1 fn:Roger Kermode end:vcard --------------00253F7E6647C5CCE17686FA-- >From owner-rmt@listserv.lbl.gov Fri Dec 17 11:08:59 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id LAA16603; Fri, 17 Dec 1999 11:07:52 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA16599 for ; Fri, 17 Dec 1999 11:07:50 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA25002 for ; Fri, 17 Dec 1999 11:07:49 -0800 (PST) Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA24995 for ; Fri, 17 Dec 1999 11:07:48 -0800 (PST) Received: from tahoe ([10.3.9.20]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id LAA18239; Fri, 17 Dec 1999 11:07:25 -0800 (PST) Message-Id: <4.1.19991217110709.01f59df0@mailhost.talarian.com> X-Sender: bwhetten@mailhost.talarian.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 17 Dec 1999 11:07:32 -0800 To: Roger.Kermode@motorola.com, rmt-list From: Brian Whetten Subject: Re: RMT Team Formation, draft editor election... In-Reply-To: <3859CBA1.7F682961@arc.corp.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rmt@lbl.gov Precedence: bulk Roger, I would also like to continue contributing to the TFMCC (congestion control) work. Brian At 04:35 PM 12/17/1999 +1100, Roger Kermode wrote: >Dear RMTers, > >I've done my best to add names and email addresses to the list >of actively interested people for each of the RMT drafts that >have currently been scheduled. I'd like each you involved in a >teams to contact the other members of your team and to elect >a document editor for that team. This person will be responsible >for merging the inputs of other team members and ensuring the >timely progress of the draft. > >Given that the holidays are nearly upon us it would be nice to >have this sorted out in the next week or so, > >cheers, > >Roger > > >Guidelines Draft >---------------- >Roger Kermode >Allison Mankin >Lorenzo Vicisano > >Building Blocks teams >--------------------- > >## Congestion Control (with RMRG) >Sally Flloyd >Mark Handley >Shivkumar Kalyanaraman >Injong Rhee > >## Generic Router Assist >Brad Cain >Tony Speakman, >Don Towsley > >## NACK >Brian Adamson >Joe Macker >Carsten Borman > >## Asynchronous Layered Coding >Jon Crowcroft >Jim Gemmel >Mike Luby >Luigi Rizzo >Lorenzo Vicisano >Bruce Lueckenhoff >Vincent ROCA > >## Tree Building (with RMRG) >Dah Ming Chu >Roger Kermode >Brian Levine >Dave Thaler >Brian Whetten > >Transport Protection >?? > >Protocol Instantiaions >---------------------- >## NACK >Brian Adamson >Joe Macker >Richard Edmonstone > >## TRACK >Brian Whetten >Dah Ming Chiu > >## Asynchronous Layered Coding >Jon Crowcroft >Jim Gemmel >Mike Luby >Luigi Rizzo >Lorenzo Vicisano >Bruce Lueckenhoff >From owner-rmt@listserv.lbl.gov Tue Dec 21 04:26:58 1999 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id EAA28239; Tue, 21 Dec 1999 04:24:57 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA28235 for ; Tue, 21 Dec 1999 04:24:54 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA24454 for ; Tue, 21 Dec 1999 04:24:54 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA24451 for ; Tue, 21 Dec 1999 04:24:53 -0800 (PST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id FAA00029 for ; Tue, 21 Dec 1999 05:24:52 -0700 (MST)] Received: [from homer.arc.corp.mot.com ([217.1.10.38]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id FAA19643 for ; Tue, 21 Dec 1999 05:24:51 -0700 (MST)] Received: from arc.corp.mot.com ([217.1.71.213]) by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id XAA29215 for ; Tue, 21 Dec 1999 23:22:47 +1100 (EST) Message-ID: <385F72CC.8D514497@arc.corp.mot.com> Date: Tue, 21 Dec 1999 23:30:04 +1100 From: Roger Kermode Reply-To: Roger.Kermode@motorola.com Organization: Motorola X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: Interim RMT Meeting Feb 10th at ACIRI (Berkeley) Content-Type: multipart/mixed; boundary="------------433F66D633774ED0FB7B2AB6" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------433F66D633774ED0FB7B2AB6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There will be an interim meeting of the IETF RMT WG on February 10th, 2000 at ACIRI near U.C. Berkeley. Mark Handley has kindly arranged for a room that can hold 40 people. At this stage we'd like to gauge attendance numbers to determine if we need to find a larger venue. If you plan to attend please RSVP ASAP. cheers, Roger Kermode Allison Mankin Lorenzo Vicisano --------------433F66D633774ED0FB7B2AB6 Content-Type: text/x-vcard; charset=us-ascii; name="rkermode.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Roger Kermode Content-Disposition: attachment; filename="rkermode.vcf" begin:vcard n:Kermode;Roger tel;fax:+61-2-9666-0501 tel;home:+61-2-9664-8335 tel;work:+61-2-9666-0558 x-mozilla-html:FALSE url:www.mot.com.au org:Motorola Australian Research Centre;Scalable Commodity Internet Lab version:2.1 email;internet:Roger.Kermode@motorola.com title:Principal Research Engineer SNAIL MAIL: Locked Bag 5028, Botany NSW, 1455=0D=0A;Botany;NSW;2019;Australia adr;quoted-printable:;;PHYSICAL: Level 3, 12 Lord St., Botany, NSW=0D=0A= x-mozilla-cpt:;-1 fn:Roger Kermode end:vcard --------------433F66D633774ED0FB7B2AB6-- >From owner-rmt@listserv.lbl.gov Mon Jan 3 07:33:15 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id HAA11398; Mon, 3 Jan 2000 07:30:44 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA11394 for ; Mon, 3 Jan 2000 07:30:42 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA20534 for ; Mon, 3 Jan 2000 07:30:42 -0800 (PST) Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA20523 for ; Mon, 3 Jan 2000 07:30:36 -0800 (PST) Received: from oleane (dyn-1-1-234.Vin.dialup.oleane.fr [195.25.4.234]) by smtp2.cluster.oleane.net with SMTP id QAA75711; Mon, 3 Jan 2000 16:29:34 +0100 (CET) Message-ID: <005601bf55ff$04f74a80$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: VoDSL 2000 Conference Date: Mon, 3 Jan 2000 16:27:10 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0053_01BF5607.6292A240" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0053_01BF5607.6292A240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hello, =20 The VoDSL 2000 Conference will stand in Paris next 28-31 March. Key = speakers, case studies: take a look at: = http://www.upperside.fr/bavodsl.htm =20 Regards ------=_NextPart_000_0053_01BF5607.6292A240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 =20
Hello,
 
The VoDSL 2000 Conference will stand = in Paris=20 next 28-31 March. Key speakers, case studies: take a look at:  http://www.upperside.fr/bavo= dsl.htm
 
Regards
 
------=_NextPart_000_0053_01BF5607.6292A240-- >From owner-rmt@listserv.lbl.gov Tue Jan 11 02:51:29 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id CAA03600; Tue, 11 Jan 2000 02:46:28 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA03596 for ; Tue, 11 Jan 2000 02:46:26 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA03060 for ; Tue, 11 Jan 2000 02:46:25 -0800 (PST) Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA03028 for ; Tue, 11 Jan 2000 02:45:51 -0800 (PST) Received: from oleane (dyn-1-1-186.Vin.dialup.oleane.fr [195.25.4.186]) by smtp1.cluster.oleane.net with SMTP id LAA20336; Tue, 11 Jan 2000 11:43:57 +0100 (CET) Message-ID: <008501bf5c20$6b51e020$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: SIP 2000 Call for Paper Date: Tue, 11 Jan 2000 11:41:20 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0082_01BF5C28.C79F0D00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0082_01BF5C28.C79F0D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SIP 2000: beyond H.323?=20 Discussing and debating in Paris May 10-12. A CFP is online at: http://www.upperside.fr/basip.htm =20 ------=_NextPart_000_0082_01BF5C28.C79F0D00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
SIP 2000: beyond H.323? =
Discussing and debating in Paris May = 10-12.
A CFP is online at:
http://www.upperside.fr/basip.= htm
 
 
------=_NextPart_000_0082_01BF5C28.C79F0D00-- >From owner-rmt@listserv.lbl.gov Wed Jan 12 09:34:25 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id JAA10716; Wed, 12 Jan 2000 09:32:10 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA10712 for ; Wed, 12 Jan 2000 09:32:07 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA00494 for ; Wed, 12 Jan 2000 09:32:05 -0800 (PST) Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA00485 for ; Wed, 12 Jan 2000 09:32:04 -0800 (PST) Received: from sbult1e.Cadence.COM (sbult1e.Cadence.COM [139.99.82.8]) by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id JAA26641; Wed, 12 Jan 2000 09:30:49 -0800 (PST) Received: (from brucelu@localhost) by sbult1e.Cadence.COM (8.8.5/8.8.5) id JAA21661; Wed, 12 Jan 2000 09:30:43 -0800 (PST) From: Bruce Lueckenhoff Message-Id: <200001121730.JAA21661@sbult1e.Cadence.COM> Subject: Re: RMT Team Formation To: rmt@lbl.gov Date: Wed, 12 Jan 100 09:30:43 -0800 (PST) Cc: J.Crowcroft@cs.ucl.ac.uk, jgemmel@microsoft.com, luby@dfountain.com, luigi@info.iet.unipi.it, lorenzo@cisco.com, vincent.roca@lip6.fr In-Reply-To: from "Vincent Roca" at Dec 23, 99 04:19:49 pm Organization: Cadence Design Systems, Inc. X-Mailer: ELM [version 2.4 PL25] Content-Type: text X-Received: By mailgate.Cadence.COM as JAA26641 at Wed Jan 12 09:30:49 2000 Sender: owner-rmt@lbl.gov Precedence: bulk Greetings, Mr. Roca raises a valid point. Layering should be considered separately, at least from the building block point of view. Certainly layering could be part of an ALC protocol instantiation, though. Am I missing any compelling reasons why layering ought to be bundled into the ALC building block? on December 23, 1999, Vincent Roca wrote: > ... > I see that he inserted me in the ALC list... I read the meeting > minutes and saw that it is more dedicated to FEC/CC than on > layered packet organization schemes > ... Bruce -- Bruce Lueckenhoff mailto:brucelu@cadence.com Cadence Design Systems 805-571-1246 FAX:805-571-1300 >From owner-rmt@listserv.lbl.gov Wed Jan 12 12:52:21 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id MAA11329; Wed, 12 Jan 2000 12:51:09 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA11325 for ; Wed, 12 Jan 2000 12:51:02 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA07058 for ; Wed, 12 Jan 2000 12:51:02 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA06846 for ; Wed, 12 Jan 2000 12:50:11 -0800 (PST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA17523 for ; Wed, 12 Jan 2000 12:50:00 -0800 (PST) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA22102 for ; Wed, 12 Jan 2000 15:49:58 -0500 (EST) Received: from bridge (bridge [129.148.75.125]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id PAA25668 for ; Wed, 12 Jan 2000 15:49:58 -0500 (EST) Message-Id: <200001122049.PAA25668@bcn.East.Sun.COM> Date: Wed, 12 Jan 2000 15:49:57 -0500 (EST) From: Dah Ming Chiu - Sun Microsystems Reply-To: Dah Ming Chiu - Sun Microsystems Subject: ACK Building Block To: rmt@lbl.gov MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Ambush_of_Tigers_512_000 X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-rmt@lbl.gov Precedence: bulk --Ambush_of_Tigers_512_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: YoliUetor4PDRyrANjucVA== Over a month ago, I wrote a short proposal to develop an ACK building block, and circulated it to a small set of people in RMT for comment. So far, only Brian Whetten and I have been discussing it; and we have some different opinions. Since there may be others on the RMT list who are interested in the (Tree-based) ACK approach, I would like to move the discussion here. Attached is a sketch of an ACK BB (Building Block). I have not updated it since I wrote it a month ago. It describes the relationship between a receiver and its repair head (repair node), and some basic session management functions of the sender, all in terms of an abstract API. I have also sketched out some algorithms that need to be specified (such as deciding when to ack and request ack), and some hooks to other BB's (e.g. congestion control, tree-building). Most importantly, this is all quite simple. I hope this is useful for helping us build the TRACK protocol standards as we move ahead. Comments are welcome. Dah Ming Chiu --Ambush_of_Tigers_512_000 Content-Type: TEXT/plain; name="ACKBB.txt"; charset=us-ascii; x-unix-mode=0600 Content-Description: ACKBB.txt Content-MD5: hZzSk05DmgQ2NOxJNZXvPA== ACK-based reliable multicast service building block (ACK BB) ------------------------------------------------------------ The ACK-based reliable multicast building block abstracts out the basic interface and algorithms used by an ACK-based reliable multicast transport, and described how it interacts with other building blocks such as the use (and building) of a repair tree, congestion/flow control, security and group management. The following is a rough sketch of the ACK BB, including definitions of an abstract API, a number of algorithms, and descriptions of "hooks" used for integrating with other building blocks. 1) Abstract API 1.1) Definition of some primitive datatypes used to describe the abstract API. session: This is possibly identified by the following - session id multicast address [sender address] member: This identifies a receiver using its address and port head: This identifies a repair head using its address and port 1.2) APIs for member to repair head interaction: BindToRepairHead(session, head, scope, [role], [subtree]) This function is used by a member to request repair service from a repair head. The parameter scope includes ttl and/or administrative scoping information, used by a repair head to perform localized repair. The optional parameters [role] and [subtree] provide other information about the receiver. Role says if the receiver can or cannot become head; subtree indicates if the receiver is itself a repair head, and information about its dependents. Ack(session, head, ack_info) This function is used to send an acknowledgement to a repair head. The parameter ack_info is a suitable data structure - for example can contain an ascending list of sequence numbers; the first element of the list signifying the highest sequence number of consecutively received packets, etc. Unbind(session, head, reason) This function is used to tell the current repair head that its services are no longer needed. 1.3) APIs for repair head to member interaction: AcceptMember(session, member, available_packets, [repair_addr], [level]) This function is used to respond to a BindToRepairHead request. The parameter available_packets a suitable data structure for example containing a descending list of sequence numbers; the first element of the list signifying the beginning of a consecutive packet stream this repair head is prepared to repair. Optionally, a separate multicast address can be suggested for members to listen for (multicast) repairs. The optional parameter [level] is used (when there is a repair tree) to indicate the number of other repair heads this repair head depends on. RejectMember(session, member, reason) This function is used to reject a membership request via BindToRepairHead. RequestAck(session, memberlist, seqno) This function is used to request the members in memberlist to ack. The parameter seqno contains the newest sequence number the repair head has seen. RequestFinalAck(session, memberlist, seqno) This function is used to request the members in memberlist to ack the receipt of all packets up to seqno (inclusive), which is the last packet of the session. The repair head cannot exit until it has fulfilled it obligation to see all members have received the last packet of the session. SendRepair(session, [member], seqno) This function is used to send a repair message. If a member parameter is included, then the repair head sends a unicast repair message (seqno) to this member; else the repair message (seqno) is sent to all members served by this repair head. Terminate(session, member, reason) This function is used by the head to terminate a member. Reasons for termination could be the member is not able to following the minimum data rate configured for the session, and/or causing the repair head to fill up its cache. Resign(session, reason) This function is used by the head to resign. It provides a way for its members to gracefully find other repair heads more quickly (than if the repair head crashed). 1.4) APIs for sender to group interaction: SessionStart(session) This function is used by the sender to send a multicast message to the whole group to indicate a multicast session is about to begin. SenderStatus(session, status) This function is used by the sender to tell the whole multicast group that it is still alive and optionally the sequence number of messages it has sent thus far. This is typically done when there is a (time) gap in the data packet stream. SessionEnd(session, seqno) This function is used by the sender to tell the whole multicast group that it has sent out the last packet (seqno). This is an optimization to help the whole group to recognize the end of the session. 2) Algorithms The following algorithms describe when the above functions are used (only the cases where it is s not obvious). In the process, we discuss a number of (configurable) parameters and some internal states of the receiver and repair heads. 2.1) When to ack Three events may trigger a receiver to send an ack: ack window ack timer probe The normal event is the ack window. Ack window is a configured parameter. (Note, in some implementations, this may be a dynamic parameter tied to the congestion window). For example, a receiver may be configured to send an ack once every 32 packets. If the packet stream is continuous and under normal operation conditions, this may be the only mechanism used to schedule sending of acks. The ack timer is also a configured parameter. (Note again, in some implementations this may be a dynamically adjusted parameter based on prediction of expected inter-packet arrival times). This mechanism is typically triggered when losses occur, or when application data has a (time) gap in it. The receiver also sends an ack in response to various probes from the repair head or the sender. For example, the RequestAck, RequestFinalAck, SessionEnd and RTT computation functions may all trigger a receiver to send an ack. 2.2) When to request ack When a repair head detects that a member has not sent an ack for some interval of time, it requests those members to respond with an ack. This time is similar to the ack timer discussed above. Request for ack can be a unicast message (when only one member is being polled) or a multicast message when multiple members are being polled. The addresses of the multiple members can be listed in the request message. This enables the repair heads to disown unresponsive members and reclaim buffers. Request for ack can also be used to compute RTT between a repair head and its member. 2.3) Cache management Depends on the type of late join support and the type of reliability being supported. 2.4) Repair algorithm When some member indicates missing packets, the repair head calls the SendRepair function to queue repairs to the retransmission queue. It is often the case that multiple members request the same repair. The implementation of SendRepair must carefully avoid queueing a repair packet that is already in the queue, or sending a repair that has very recently been sent. The repair head also decides when to send an ack via unicast and when to use multicast to minimize bandwidth usage. 2.5) Session close The algorithm to close the session is for the sender to call sessionEnd(). This results in a multicast message being transmitted to the whole group indicating end of session. Each repair head, separately requests all members in its repair group to send an ack of the final packet. In case the session end message from the sender is not received by a repair head, it may be sent multiple times. Failing that, the session end signal still would propagate down the tree via each repair head requesting the final ack. 3) Other Hooks The hooks describe additional ways (other than the abstract API) this building block interacts with other building blocks and a protocol instantiation. 3.1) Hooks exported 3.1.1) Missing packet info Other BB's may need to query this BB for the total number of lost packet seen and repaired up to now. This information may prove useful for congestion control, for example in calculating the suitable rate for transmission; or in determining which member is keeping the group transmission rate below the minimum data rate. Similarly, there should be a hook for zeroing the above states to accommodate the need to restart certain calculations (for example - when the sender resumes data transmission after a pause). 3.1.2) Cache info Other BB may be interested in the cache occupancy, or available packets in the cache. 3.1.3) ackWindow 3.2) Hooks expected from other BB's 3.2.1) Current Data rate This information probably comes from the congestion control BB. It may be useful for dynamically setting some timers used to send (or request) acks. 3.2.2) Keep alive function The repair head and its member need a keep-alive function which runs in the absence of repairs. If this is covered in the tree-building BB, then the hooks are needed by this BB to access it. 3.2.3) Repair scope The TREE BB may provide a repair scope for controlling the locality of repairs. The repair scope infomation is needed by this BB too. 3.2.4) Security hook Security hooks are needed to perform signature/authentication operations on all BB(protocol) control messages. 4) Issues Some functions in this BB overlap with functions in the tree configuration BB. For example, the Bind/Unbind, Accept/Reject would be used during tree building as well. On the other hand, a receiver and head need some keep-alive function that we did not specify here now (perhaps we should have), and expected it be part of the tree maintenance function in the tree BB. --Ambush_of_Tigers_512_000-- >From owner-rmt@listserv.lbl.gov Mon Jan 17 12:39:43 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id MAA28297; Mon, 17 Jan 2000 12:36:17 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA28293 for ; Mon, 17 Jan 2000 12:36:15 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA16294 for ; Mon, 17 Jan 2000 12:36:14 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA16291 for ; Mon, 17 Jan 2000 12:36:13 -0800 (PST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (VWALL-IN-motgate2 2.0) with ESMTP id NAA12832 for ; Mon, 17 Jan 2000 13:36:12 -0700 (MST)] Received: [from homer.arc.corp.mot.com ([217.1.10.38]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id NAA07552 for ; Mon, 17 Jan 2000 13:36:11 -0700 (MST)] Received: from arc.corp.mot.com ([144.187.5.100]) by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id HAA03586 for ; Tue, 18 Jan 2000 07:31:43 +1100 (EST) Message-ID: <38837C33.D4D0D71D@arc.corp.mot.com> Date: Tue, 18 Jan 2000 07:31:47 +1100 From: Roger Kermode Reply-To: Roger.Kermode@motorola.com Organization: Motorola X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: RMT: Call For Feb 10 Agenda Items Content-Type: multipart/mixed; boundary="------------CA450681D05075CD7872F10A" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------CA450681D05075CD7872F10A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Februrary 10th is rapidly approaching and the next meeting is looming up quickly. If everyone could please coordinate with the other people working on your respecitve building block drafts, and send potential agenda items to me as you can I would be most grateful. Thanks! Roger --------------CA450681D05075CD7872F10A Content-Type: text/x-vcard; charset=us-ascii; name="rkermode.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Roger Kermode Content-Disposition: attachment; filename="rkermode.vcf" begin:vcard n:Kermode;Roger tel;fax:+61-2-9666-0501 tel;home:+61-2-9664-8335 tel;work:+61-2-9666-0558 x-mozilla-html:FALSE url:www.mot.com.au org:Motorola Australian Research Centre;Scalable Commodity Internet Lab version:2.1 email;internet:Roger.Kermode@motorola.com title:Principal Research Engineer SNAIL MAIL: Locked Bag 5028, Botany NSW, 1455=0D=0A;Botany;NSW;2019;Australia adr;quoted-printable:;;PHYSICAL: Level 3, 12 Lord St., Botany, NSW=0D=0A= x-mozilla-cpt:;-1 fn:Roger Kermode end:vcard --------------CA450681D05075CD7872F10A-- >From owner-rmt@listserv.lbl.gov Tue Jan 18 04:23:16 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id EAA29267; Tue, 18 Jan 2000 04:22:47 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA29263 for ; Tue, 18 Jan 2000 04:22:45 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA28101 for ; Tue, 18 Jan 2000 04:22:44 -0800 (PST) Received: from bettina.informatik.uni-bremen.de (root@bettina.informatik.uni-bremen.de [134.102.224.3]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA28097 for ; Tue, 18 Jan 2000 04:22:43 -0800 (PST) Received: from cabo2 (dienstmann.informatik.uni-bremen.de [134.102.224.51]) by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with SMTP id NAA04911; Tue, 18 Jan 2000 13:22:15 +0100 (MET) From: "Dr. Carsten Bormann" To: , "rmt-list" Subject: RE: Call For Feb 10 Agenda Items Date: Tue, 18 Jan 2000 13:22:12 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <38837C33.D4D0D71D@arc.corp.mot.com> Sender: owner-rmt@lbl.gov Precedence: bulk Are we going to run the meeting as an RMT "plenary" or are we going to split up into BB/PI subgroups? I sure have ideas for agenda items for the latter case (which should spawn some plenary items, too). Gruesse, Carsten >From owner-rmt@listserv.lbl.gov Thu Jan 20 15:56:24 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id PAA16368; Thu, 20 Jan 2000 15:55:40 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA16364 for ; Thu, 20 Jan 2000 15:55:37 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA14413 for ; Thu, 20 Jan 2000 15:55:37 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA14402 for ; Thu, 20 Jan 2000 15:55:36 -0800 (PST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (VWALL-IN-ftpbox 2.0) with ESMTP id QAA07328 for ; Thu, 20 Jan 2000 16:55:35 -0700 (MST)] Received: [from homer.arc.corp.mot.com ([217.1.10.38]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id QAA13142 for ; Thu, 20 Jan 2000 16:55:32 -0700 (MST)] Received: from arc.corp.mot.com (everest.arc.corp.mot.com [217.1.10.204]) by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id KAA08242 for ; Fri, 21 Jan 2000 10:50:52 +1100 (EST) Message-ID: <38879F5D.C578D26D@arc.corp.mot.com> Date: Fri, 21 Jan 2000 10:50:53 +1100 From: Roger Kermode Reply-To: Roger.Kermode@motorola.com Organization: Motorola X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: [Fwd: RMT meeting Feb 10 at Aciri] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Ahhh the hazards of copying email... ACIRI's address is 1947 Center St. cheers, Roger -------- Original Message -------- Subject: RMT meeting Feb 10 at Aciri Date: Fri, 21 Jan 2000 10:49:36 +1100 From: Roger Kermode Reply-To: Roger.Kermode@motorola.com Organization: Motorola To: rmt-list Just a reminder. The next RMT meeting is as follows: Date: Thursday, Feb 10, 2000 Venue: ACIRI, Berkeley, CA Address: 947 Center st., Berkeley, CA Time: 9:00am - 5:00pm Hotels: try Shattuck Hotel (510-845-7300) 5 min from ACIRI So far I have not had an overwhelming response from potential participants. If we want to keep moving people will need to step up an work together on defining the various building blocks and protocol instantiations. Please try to contact the other people in the various sub-groups and make some progress. Please contact me ASAP if you wish to present and discuss a draft Roger >From owner-rmt@listserv.lbl.gov Thu Jan 20 15:56:24 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id PAA16362; Thu, 20 Jan 2000 15:54:25 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA16358 for ; Thu, 20 Jan 2000 15:54:23 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA14005 for ; Thu, 20 Jan 2000 15:54:22 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA13994 for ; Thu, 20 Jan 2000 15:54:21 -0800 (PST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (VWALL-IN-ftpbox 2.0) with ESMTP id QAA06504 for ; Thu, 20 Jan 2000 16:54:20 -0700 (MST)] Received: [from homer.arc.corp.mot.com ([217.1.10.38]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id QAA24652 for ; Thu, 20 Jan 2000 16:54:17 -0700 (MST)] Received: from arc.corp.mot.com (everest.arc.corp.mot.com [217.1.10.204]) by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id KAA08206 for ; Fri, 21 Jan 2000 10:49:34 +1100 (EST) Message-ID: <38879F10.81A21BA3@arc.corp.mot.com> Date: Fri, 21 Jan 2000 10:49:36 +1100 From: Roger Kermode Reply-To: Roger.Kermode@motorola.com Organization: Motorola X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: RMT meeting Feb 10 at Aciri Content-Type: multipart/mixed; boundary="------------EF676A36CF60A9D1D1456D53" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------EF676A36CF60A9D1D1456D53 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Just a reminder. The next RMT meeting is as follows: Date: Thursday, Feb 10, 2000 Venue: ACIRI, Berkeley, CA Address: 947 Center st., Berkeley, CA Time: 9:00am - 5:00pm Hotels: try Shattuck Hotel (510-845-7300) 5 min from ACIRI So far I have not had an overwhelming response from potential participants. If we want to keep moving people will need to step up an work together on defining the various building blocks and protocol instantiations. Please try to contact the other people in the various sub-groups and make some progress. Please contact me ASAP if you wish to present and discuss a draft Roger --------------EF676A36CF60A9D1D1456D53 Content-Type: text/x-vcard; charset=us-ascii; name="rkermode.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Roger Kermode Content-Disposition: attachment; filename="rkermode.vcf" begin:vcard n:Kermode;Roger tel;fax:+61-2-9666-0501 tel;home:+61-2-9664-8335 tel;work:+61-2-9666-0558 x-mozilla-html:FALSE url:www.mot.com.au org:Motorola Australian Research Centre;Scalable Commodity Internet Lab version:2.1 email;internet:Roger.Kermode@motorola.com title:Principal Research Engineer SNAIL MAIL: Locked Bag 5028, Botany NSW, 1455=0D=0A;Botany;NSW;2019;Australia adr;quoted-printable:;;PHYSICAL: Level 3, 12 Lord St., Botany, NSW=0D=0A= x-mozilla-cpt:;-1 fn:Roger Kermode end:vcard --------------EF676A36CF60A9D1D1456D53-- >From owner-rmt@listserv.lbl.gov Fri Jan 21 01:39:04 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id BAA17369; Fri, 21 Jan 2000 01:38:14 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA17365 for ; Fri, 21 Jan 2000 01:38:12 -0800 (PST) From: myzhai@990.net Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA21761 for ; Fri, 21 Jan 2000 01:38:11 -0800 (PST) Received: from 990.net ([202.102.13.155]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id BAA21758 for ; Fri, 21 Jan 2000 01:38:08 -0800 (PST) Received: (fmail 29235 invoked by uid 1300); 21 Jan 2000 09:31:11 -0000 Date: 21 Jan 2000 09:31:11 -0000 Message-ID: <20000121093111.29234.fmail@990.net> Reply-To: myzhai@990.net To: rmt@lbl.gov Cc: luby@dfountain.com Subject: about "ALC" Content-Transfer-Encoding: 8bit Sender: owner-rmt@lbl.gov Precedence: bulk Hello,everyone, I am interested in topics about "ALC(Asynchronous Layered Coding)", where can I find more infomation about it? Thx Zjai __________________________________________________ ťśÓ­ĘšÓĂ˝đÁęČČĎßĂâˇŃľç×ÓÓĘźţϾͳhttp://www.990.net >From owner-rmt@listserv.lbl.gov Wed Jan 26 04:15:39 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id EAA12463; Wed, 26 Jan 2000 04:13:52 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA12459 for ; Wed, 26 Jan 2000 04:13:50 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA22993 for ; Wed, 26 Jan 2000 04:13:49 -0800 (PST) Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA22988 for ; Wed, 26 Jan 2000 04:13:48 -0800 (PST) Received: from oleane (dyn-1-1-009.Vin.dialup.oleane.fr [195.25.4.9]) by smtp1.cluster.oleane.net with SMTP id NAA52637; Wed, 26 Jan 2000 13:12:44 +0100 (CET) Message-ID: <008c01bf67f6$3f458680$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: SIP 2000 Call for Papaer Date: Wed, 26 Jan 2000 13:09:46 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0089_01BF67FE.9E62EA60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0089_01BF67FE.9E62EA60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SIP 2000: Beyond H.323? A scientific committe composed of the most = eminent experts in this technology will review the abstracts submitted = from the Call For Papers: http://www.upperside.fr/basip.htm Take a look at the exhibition list. ------=_NextPart_000_0089_01BF67FE.9E62EA60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
SIP 2000: Beyond H.323? A scientific = committe=20 composed of the most eminent experts in this technology will review the=20 abstracts submitted from the Call For Papers:
http://www.upperside.fr/basip.= htm
Take a look at the exhibition=20 list.
 
------=_NextPart_000_0089_01BF67FE.9E62EA60-- >From owner-rmt@listserv.lbl.gov Thu Jan 27 09:57:08 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id JAA23890; Thu, 27 Jan 2000 09:55:01 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA23886 for ; Thu, 27 Jan 2000 09:54:59 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA22036 for ; Thu, 27 Jan 2000 09:54:58 -0800 (PST) Received: from hercules.cs.ucsb.edu (hercules.cs.ucsb.edu [128.111.41.30]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA22033 for ; Thu, 27 Jan 2000 09:54:57 -0800 (PST) Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id JAA22607; Thu, 27 Jan 2000 09:54:40 -0800 (PST) Received: by jackson.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4) id JAA25324 for ; Thu, 27 Jan 2000 09:54:36 -0800 (PST) Date: Thu, 27 Jan 2000 09:54:36 -0800 (PST) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <200001271754.JAA25324@jackson.cs.ucsb.edu> To: almeroth@cs.ucsb.edu Cc: nonnen@eurecom.fr Subject: Reminder, CFP: Integrating Multicast into the Internet Sender: owner-rmt@lbl.gov Precedence: bulk Reminder, DEADLINE February 1, 2000 CALL FOR PAPERS: Special Issue of Computer Communications on Integrating Multicast into the Internet CFP URL: http://www.cs.ucsb.edu/~almeroth/COMCOM:cfp.html Journal URL: http://www.elsevier.com/inca/publications/store/5/2/5/4/4/0/ TOPICS: The amount of bandwidth available in the Internet is increasing dramatically, both in the backbone networks, as well as in the last mile (broadband access). One consequence is that the delivery of high-quality multimedia data will become feasible, and multimedia data, including audio and video, will become the dominant traffic. As more users gain access to broadband services, new applications and services will become possible. The result will be a growing demand for large-scale multimedia applications and services. Multicasting as a pure networking solution to the transport of media is recognized as offering economies-of-scale for large-scale applications. Multicast is also believed to enable applications which provide service to thousands, even millions of customers. While there has been significant research work on multicast, efforts to successfully deploy a production service have lagged. Reasons range from frequently changing protocols, management and engineering problems, legacy hardware limitations, traffic conflicts with unicast, etc.. This special issue focuses on research issues dealing with the challenges of deploying multicast in the network. Specific topics include, but are not limited to: * Multicast Congestion Control * Multicast Overlay Networks * Next-Generation Multicast Routing Algorithms * Multicast Media Transport * Security for Multicast-Based Services * Multicast Traffic Engineering and Management * Multicast Pricing and Quality of Service GUEST EDITORS: Kevin Almeroth Jorg Nonnenmacher Department of Computer Science Network Research Dept, Lucent Technologies University of California 600-700 Mountain Avenue Santa Barbara, CA 93106-5110 Murray Hill, NJ 07974-0636 Phone: +1(805) 893-2777 Phone: +1(908) 582-1707 Fax: +1(805) 893-8553 Fax: +1(908) 582-6632 Email: almeroth@cs.ucsb.edu Email: nonnen@eurecom.fr IMPORTANT DATES: Paper Submission Deadline: February 1, 2000 Feedback to Authors: May 1, 2000 Final Manuscripts Due: June 1, 2000 Publication Date: Fall 2000 SUBMISSION INSTRUCTIONS: Papers should be double spaced, 11pt font, and standard margins. Length should be 20 pages maximum not including figures, tables, and references. Maximum total length is 30 pages. Authors are requested to send e-mail to one or both of the Guest Editors (almeroth@cs.ucsb.edu, nonnen@eurecom.fr) giving a URL from where a postscript or PDF file can be downloaded (papers can also be emailed though this is not the preferred format). Successfully received papers will be acknowledged. AUTHOR INFORMATION: Submissions made to the special issue should not have appeared in, or been submitted to other archival publications. All papers will be subjected to the journal's usual refereeing process. >From owner-rmt@listserv.lbl.gov Fri Jan 28 00:50:53 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id AAA25740; Fri, 28 Jan 2000 00:49:56 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA25736 for ; Fri, 28 Jan 2000 00:49:54 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA29782 for ; Fri, 28 Jan 2000 00:49:53 -0800 (PST) Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.164.217]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA29779 for ; Fri, 28 Jan 2000 00:49:47 -0800 (PST) Received: from sjkoh (sjkoh.etri.re.kr [129.254.164.46]) by pec.etri.re.kr (8.9.1/8.9.1) with SMTP id RAA27055; Fri, 28 Jan 2000 17:43:55 +0900 (KST) Message-ID: <004c01bf696c$845969e0$2ea4fe81@etri.re.kr> From: "Seok J. Koh" To: "Dah Ming Chiu - Sun Microsystems" , References: <200001122049.PAA25668@bcn.East.Sun.COM> Subject: Re: ACK Building Block Date: Fri, 28 Jan 2000 17:48:57 +0900 Organization: ETRI/PEC MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by SpamWall.lbl.gov id AAA25737 Sender: owner-rmt@lbl.gov Precedence: bulk Hi, there, The proposal seems to be one of reasonable inputs for initial draft of ACK building block, even though some addings or modifications are required. For examples, the scope of ACK building block can be explictly described, and some assumptions, including that the tree is given by automatic configurations or can be obtained from external software, may be made. Anyway, I cannot find the item of ACK building block as the drafting work, in the plan of this Mid-Feb RMT meeting. I would like to know why the drafting work of ACK building block has not been inlcuded as a drafting item at the meeting, in spite that NACK and GRA BBs were included. Is that item pre-mature yet ? or overlapped by the other BBs such as tree building or TRACK ? cheers, Seok-Joo, Koh ----- Original Message ----- > Over a month ago, I wrote a short proposal to develop an ACK building > block, and circulated it to a small set of people in RMT for comment. > So far, only Brian Whetten and I have been discussing it; and we have > some different opinions. Since there may be others on the RMT list who > are interested in the (Tree-based) ACK approach, I would like to move > the discussion here. > > Attached is a sketch of an ACK BB (Building Block). I have not updated > it since I wrote it a month ago. It describes the relationship > between a receiver and its repair head (repair node), and some basic > session management functions of the sender, all in terms of an abstract > API. I have also sketched out some algorithms that need to be specified > (such as deciding when to ack and request ack), and some hooks to other > BB's (e.g. congestion control, tree-building). Most importantly, this > is all quite simple. > > I hope this is useful for helping us build the TRACK protocol standards > as we move ahead. Comments are welcome. > > Dah Ming Chiu >From owner-rmt@listserv.lbl.gov Mon Jan 31 05:44:57 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id FAA03747; Mon, 31 Jan 2000 05:43:00 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA03743 for ; Mon, 31 Jan 2000 05:42:57 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA28677 for ; Mon, 31 Jan 2000 05:42:56 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA28671 for ; Mon, 31 Jan 2000 05:42:55 -0800 (PST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (VWALL-IN-motgate2 2.0) with ESMTP id GAA16741 for ; Mon, 31 Jan 2000 06:42:55 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id GAA21000 for ; Mon, 31 Jan 2000 06:42:53 -0700 (MST)] Received: from arc.corp.mot.com ([144.187.5.100]) by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id AAA20062 for ; Tue, 1 Feb 2000 00:42:48 +1100 (EST) Message-ID: <38959155.B284985C@arc.corp.mot.com> Date: Tue, 01 Feb 2000 00:42:45 +1100 From: Roger Kermode Reply-To: Roger.Kermode@motorola.com Organization: Motorola X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: RMT Agenda Update for Feb 10th Content-Type: multipart/mixed; boundary="------------AA49F7503878746450EC11B0" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------AA49F7503878746450EC11B0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear RMT'ers, A quick note to let you know that we haven't forgotten about the agenda for Feb 10th. We're currently, trying to piece together an order for the presentation requests we have received (speak up if you haven't already!) We're particularly keen to take advantage of having an entire day to *REAL* work. To that end we're looking at an agenda that will *minimize* presentation time and involve us breaking up into focus groups to work on individual drafts. Please put your thinking caps on be prepared for detailed discussions!!!! An agenda will appear early next week. The details of the meeting one more time.... Date: Thursday, Feb 10, 2000 Host: ACIRI Venue: ICSI Building, 6th Floor Address: 1947 Center st., Berkeley, CA Time: 9:30am - 5:00pm Hotels: try Shattuck Hotel (510-845-7300) 5 min from ACIRI cheers, Roger Allison Lorenzo --------------AA49F7503878746450EC11B0 Content-Type: text/x-vcard; charset=us-ascii; name="rkermode.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Roger Kermode Content-Disposition: attachment; filename="rkermode.vcf" begin:vcard n:Kermode;Roger tel;cell:+61-408-212-284 tel;fax:+61-2-9666-0501 tel;home:+61-2-9664-8335 tel;work:+61-2-9666-0558 x-mozilla-html:FALSE -mozilla-cpt:;-1;;; url:www.mot.com.au org:Motorola Australian Research Centre;Scalable Commodity Internet Lab version:2.1 email;internet:Roger.Kermode@motorola.com title:Australia adr;quoted-printable:;;PHYSICAL: Level 3, 12 Lord St., Botany, NSW=0D=0A= x-mozilla-cpt:;0 fn:Roger Kermode end:vcard --------------AA49F7503878746450EC11B0-- >From owner-rmt@listserv.lbl.gov Mon Jan 31 09:56:03 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id JAA04951; Mon, 31 Jan 2000 09:54:55 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA04947 for ; Mon, 31 Jan 2000 09:54:53 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA24748 for ; Mon, 31 Jan 2000 09:54:53 -0800 (PST) Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA24743 for ; Mon, 31 Jan 2000 09:54:51 -0800 (PST) Received: from tahoe (ta036.talarian.com [204.147.187.36] (may be forged)) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id JAA02374; Mon, 31 Jan 2000 09:54:31 -0800 (PST) Message-Id: <4.1.20000131092342.0223a6b0@mailhost.talarian.com> X-Sender: bwhetten@mailhost.talarian.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 31 Jan 2000 09:35:19 -0800 To: Roger.Kermode@motorola.com, rmt-list From: Brian Whetten Subject: Re: RMT Agenda Update for Feb 10th In-Reply-To: <38959155.B284985C@arc.corp.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rmt@lbl.gov Precedence: bulk Hi all, I'm looking at the amount of work to do, and am beginning to feel that one day won't be nearly enough. Is there any way that we can extend this to Friday as well? It seems like we really need to lock everyone in a room for about a week...but that is obviously not going to happen given all our frightening schedules. As a second possibility, which I'll just throw out as an open invitation, I have access to a couple free condos in South Lake Tahoe, 5 minutes from Heavenly (some of the best terrain in the country, although our snow isn't quite as good as Utah or Colorado). Would people be tempted (especially the non-west coasters?) in to a combined work/play weekend? I can't think of a better place I'd rather work on writing billions of pages of documents. ;) Brian At 12:42 AM 2/1/2000 +1100, Roger Kermode wrote: >Dear RMT'ers, > >A quick note to let you know that we haven't forgotten about the >agenda for Feb 10th. We're currently, trying to piece together >an order for the presentation requests we have received (speak >up if you haven't already!) We're particularly keen to take >advantage of having an entire day to *REAL* work. To that end >we're looking at an agenda that will *minimize* presentation time >and involve us breaking up into focus groups to work on individual >drafts. Please put your thinking caps on be prepared for detailed >discussions!!!! > >An agenda will appear early next week. > > >The details of the meeting one more time.... > > Date: Thursday, Feb 10, 2000 > Host: ACIRI > Venue: ICSI Building, 6th Floor > Address: 1947 Center st., Berkeley, CA > Time: 9:30am - 5:00pm > Hotels: try Shattuck Hotel (510-845-7300) 5 min from ACIRI > >cheers, > >Roger >Allison >Lorenzo >From owner-rmt@listserv.lbl.gov Mon Jan 31 10:20:52 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id KAA05223; Mon, 31 Jan 2000 10:20:34 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA05209 for ; Mon, 31 Jan 2000 10:20:29 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA04400 for ; Mon, 31 Jan 2000 10:20:28 -0800 (PST) Received: from aardvark.aciri.org (aardvark.aciri.org [192.150.187.20]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA04395 for ; Mon, 31 Jan 2000 10:20:28 -0800 (PST) Received: from aardvark.aciri.org (localhost [127.0.0.1]) by aardvark.aciri.org (8.9.3/8.9.2) with ESMTP id KAA50247; Mon, 31 Jan 2000 10:17:43 -0800 (PST) (envelope-from mjh@aardvark.aciri.org) From: Mark Handley X-Organisation: ACIRI To: Brian Whetten cc: Roger.Kermode@motorola.com, rmt-list Subject: Re: RMT Agenda Update for Feb 10th In-reply-to: Your message of "Mon, 31 Jan 2000 09:35:19 PST." <4.1.20000131092342.0223a6b0@mailhost.talarian.com> Date: Mon, 31 Jan 2000 10:17:43 -0800 Message-ID: <50245.949342663@aardvark.aciri.org> Sender: owner-rmt@lbl.gov Precedence: bulk >I'm looking at the amount of work to do, and am beginning to feel that one >day won't be nearly enough. Is there any way that we can extend this to >Friday as well? It seems like we really need to lock everyone in a room >for about a week...but that is obviously not going to happen given all our >frightening schedules. We're hosting the SMuG RG meeting on Friday 11th, so the lecture room here won't be available, which is the only room that can host 40+ people. We also have a few smaller conference rooms and a number of offices people can use, so it would be possible to continue into Friday. However, I suspect that this is best done only by individual sub-groups that wish to continue working on a specific topic. So, sub-groups: let me know if you want to continue on the Friday (preferably in advance, but we can usually be fairly flexible even without notice) and let me know how many people you expect to be. I'll then try and sort out appropriate rooms. Cheers, Mark BTW, some SMuG people had trouble booking the suggested hotel. There's also a list of hotels at http://www.lbl.gov/Workplace/near-our-shuttle.html All the starred ones are reasonably close to ICSI. >From owner-rmt@listserv.lbl.gov Mon Feb 7 21:12:46 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id VAA18917; Mon, 7 Feb 2000 21:09:36 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA18913 for ; Mon, 7 Feb 2000 21:09:34 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA22212 for ; Mon, 7 Feb 2000 21:09:33 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA22203 for ; Mon, 7 Feb 2000 21:09:32 -0800 (PST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (VWALL-IN-motgate 2.0) with ESMTP id WAA14006 for ; Mon, 7 Feb 2000 22:09:31 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id WAA27013 for ; Mon, 7 Feb 2000 22:09:26 -0700 (MST)] Received: from arc.corp.mot.com (t-il06-w-port2.corp.mot.com [129.188.170.92]) by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id QAA09496 for ; Tue, 8 Feb 2000 16:08:32 +1100 (EST) Message-ID: <389FA4D0.5F79900D@arc.corp.mot.com> Date: Tue, 08 Feb 2000 16:08:32 +1100 From: Roger Kermode Reply-To: Roger.Kermode@motorola.com Organization: Motorola X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: RMT Meeting Agenda, Feb 10 Content-Type: multipart/mixed; boundary="------------F79A41C7056DC60F7258F12F" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------F79A41C7056DC60F7258F12F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear RMT'ers, A tentative agenda for the feb 10 meeting is attached below. Note that we have deliverately kept the presentations short, as we'd like to maximize the time for discussions. Those of you of have replied and have recevied slots should keep your presentations to roughly 5 slides in bullet form and hit the major points you want to bring up for discussion. If you need to convey additional information please do so by posting it to the list prior to the meeting. However, keep in mind that people are unlikely to read long papers before the meeting. See you on Thursday, cheers, Roger Allison Lorenzo ----------------------------------------------------------------- RMT Interim Meeting Thursday Febraruy 10th, ACIRI 1947 Center st., Berkeley, CA Directions to ICSI are at http://www.icsi.berkeley.edu/where.html Tentative Agenda --------------------------------- 09:00 - 09:10 10 mins Agenda Bashing [Roger] 09:10 - 09:10 10 mins WG status update bb + ds drafts Recharter 09:10 - 09:20 10 mins Call to arms/editorship selection update [Roger] 09:20 - 09:40 40 mins Guidelines Draft Update/Discussion [Roger/Lorenzo/Allison] 10 mins draft outline 30 mins discussion 10:00 - 11:20 1hr20mins Congestion Control: [Handley/Flloyd?] 10 mins TFMCC update [Handley/Flloyd] 10 mins ALC implications for CC [Luby] 10 mins TEAR implications for CC [Rhee] 10 mins Generic source-based multicast CC [Kalyanaraman] 40 mins discussion 11:20 - 12:20 1hr NACK: [Bormann & Adamson?] 10 mins BB Update [Borman] 20 mins BB Discussion 10 mins PI Update [Adamson] 20 mins PI Discusion 12:20 - 13:00 1hr Lunch 13:00 - 14:00 1hr Asynchronous Layered Coding: [Luby] 10 mins BB update 10 mins Gemmell? 40 mins discussion 14:00 - 14:30 1hr Tree-Building: [??] 10 mins table of contents update [Chiu] 20 mins discussion 14:30 - 16:00 1hr TRACK progress [Whetten/Chiu] 10 mins [Whetten] 10 mins [Chiu] 40 mins Discussion 16:00 - 16:45 45 mins VACANT 16:45 - 17:00 15 mins Agenda bashing for Adelaide --------------F79A41C7056DC60F7258F12F Content-Type: text/x-vcard; charset=us-ascii; name="rkermode.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Roger Kermode Content-Disposition: attachment; filename="rkermode.vcf" begin:vcard n:Kermode;Roger tel;cell:+61-408-212-284 tel;fax:+61-2-9666-0501 tel;home:+61-2-9664-8335 tel;work:+61-2-9666-0558 x-mozilla-html:FALSE -mozilla-cpt:;0;;; url:www.mot.com.au org:Motorola Australian Research Centre;Scalable Commodity Internet Lab version:2.1 email;internet:Roger.Kermode@motorola.com title:Principal Research Engineer adr;quoted-printable:;;PHYSICAL: Level 3, 12 Lord St., Botany, NSW=0D=0A= x-mozilla-cpt:;0 fn:Roger Kermode end:vcard --------------F79A41C7056DC60F7258F12F-- >From owner-rmt@listserv.lbl.gov Tue Feb 8 22:03:00 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id WAA21640; Tue, 8 Feb 2000 22:00:34 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA21636 for ; Tue, 8 Feb 2000 22:00:32 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA14062 for ; Tue, 8 Feb 2000 22:00:23 -0800 (PST) Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA14059 for ; Tue, 8 Feb 2000 22:00:22 -0800 (PST) Received: from tahoe ([207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id VAA23403; Tue, 8 Feb 2000 21:58:21 -0800 (PST) Message-Id: <4.1.20000208161711.01d31880@mailhost.talarian.com> X-Sender: bwhetten@mailhost.talarian.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 08 Feb 2000 16:24:25 -0800 To: smug@baynetworks.com, rmt@lbl.gov From: Brian Whetten Subject: Security Considerations for TRACK Protocols Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_246435064==_" Sender: owner-rmt@lbl.gov Precedence: bulk --=====================_246435064==_ Content-Type: text/plain; charset="us-ascii" Hello all, Sorry for those who get duplicates of this. Please find attached a draft Thomas Hardjorno and I did to analyze the security considerations for TRACK protocols. This is still rough, isn't formatted correctly, and isn't an official IETF draft yet. We will be discussing this at the SMUG meeting on Friday. Brian --=====================_246435064==_ Content-Type: text/plain; name="draft-ietf-rmt-track-security-xx.txt"; x-mac-type="54455854"; x-mac-creator="74747874" Content-Transfer-Encoding: x-uuencode Content-Disposition: attachment; filename="draft-ietf-rmt-track-security-xx.txt" begin 600 draft-ietf-rmt-track-security-xx.txt M#0I);G1E'@N='AT/@T*#0H-"E-T871U`T*("`@;6]N=&AS M(&%N9"!M87D@8F4@=7!D871E9"P@2!O=&AE<@T*("`@9&]C=6UE;G1S(&%T(&%N>2!T:6UE+B`@270@:7,@:6YA M<'!R;W!R:6%T92!T;R!U2!I2!A M;F0@875T:&5N=&EC871I;VXL(`T*9G)O;2!T2!H879E(&%C8V5S2!R M971R86YS;6ET(&$@;&]S="!D871A('!A8VME="`H=VAI8V@@7!T960@#0IU;F1E7!T:6]N M(&ME>2D@=&\@:71S(&]W;B!C:&EL9')E;B`H82!S970@;V8@#0I296-E:79E M7,@#0IS:&]U;&0@8F4@9&EV:61E M9"!U<"!A;6]N9R!G2P@:70@#0ID;V5S(&YO="!P2!O9B`-"G1H92!S M96YD97(@;V8@=&AI2!S97)V:6-E('1O(&QE9VET:6UA=&4@=7-E2!O9B!R96QI86)L92!M=6QT:6-A2!I;G1O('1H92`-"G1H:7)D(&-A=&5G;W)Y(&]F('!R;V)L96US+B`@ M0V]M<&QE=&4@9&5N:6%L(&]F('-E4+"!A2X@(%-O;64@87!P;&EC871I;VYS(')E<75I M65R2!B92`-"F5M<&QO>65D('=I=&@@9&EF9F5R96YT(&UU;'1I8V%S="!R M;W5T:6YG('!R;W1O8V]L2!P M2!I;G-T86YC97,@=&AE('1O<&]L;V=Y(&]F(%)-(`T*:6YF6UM971R>2!C86YN;W0@ M8F4@87-S=6UE9"!F;W(@86QL(&-A7!T:6]N*2!S:&]U;&0@8F4@&%M<&QE+"`-"G1H92!U2!A="!T:&4@25`@;&%Y97(@=&\@875T:&5N M=&EC871E(&UU;'1I8V%S="`-"G)O=71I;F<@<')O=&]C;VP@8V]N=')O;"UP M86-K971S(&-A;B!A;'-O(&)E('5S960@=&\@875T:&5N=&EC871E(%)-(`T* M8V]N=')O;"UM97-S86=E&-H86YG92!C;VYT2!A2!F'0@;&5V96P@=7`@=&AE(&AI97)A2X@(%1H:7,@<')O M8V5S2!O9B!C;VYT2!M=6QT:6-A2!T M:&4@=6YD97)L>6EN9R!M=6QT:6-A("`@("`@("`@("`@("`@("`@("`@("`@("`@("!\#0H@("`@("`@ M("`@("`@?"`@("`@("`@("`@("`@+R`@?"`@7"`@("`@("`@("`@("`@("`@ M("`@("`@("`@('P-"B`@("`@("!(04-+7B`@("`@("`@("`@(%Y>7B`@("`@("`@("`@(%Y> M("`@("`@("`@("`@("`@?"!$871A#0H@("`@("`@("`@("`@("`O('P@("`@ M("`@("`@("\@?"!<("`@("`@("`@("!\(%P@("`@("`@("`@("`@('P@0VAA M;FYE;`T*("`@("`@("`@("`@("`O("!\("`@("`@("`@("\@('P@(%P@("`@ M("`@("`@?"`@7"`@("`@("`@("`@("!\#0H@("`@("`@("`@("`@+R`@('P@ M("`@("`@("`O("`@?"`@(%P@("`@("`@("!\("`@7"`@("`@("`@("`@('8- M"B`@("`@("`@("`@4DX@("!23B`@("`@("!23B`@(%).("`@4DX@("`@("`@ M(%).("`@4DX@("`\+2TM+2TM#0H@("`@("`@("`@("`@("`@("`@("`@("A2 M96-E:79E2!R97%U:7)E;65N=',@9F]R(%1204-+('!R M;W1O8V]L65R M(&EN('=H:6-H('-E8W5R:71Y(&ES(&%P<&QI960Z#0I4:&4@='=O(&QA>65R M2!M96-H86YI7!I8V%L;'D@=&AE(&YE='=O2!T:&4@6UM M971R:6,I(&-R>7!T;V=R87!H>2!I65D(&%N9"!T:&4@:V5Y M(&ES('-H87)E9"!B>2!M;W)E('1H86X@='=O('!A2!C97)T86EN('1H870@=&AE(&5N=&ET>2!T:&%T('-E;G0@=&AE(`T* M;65S6UM971R:6,M:V5Y M+"!A;F0@:7,@=&AU2X-"@T*26X@=&AE(&9O;&QO=VEN9RP@ M=&AE(%1204-+('-P96-I9FEC(')E<75I2!M96-H86YI2!T;R!D;R!S;RX-"@T* M5'=O('1Y<&5S(&]F(&%U=&AE;G1I8V%T:6]N(&UE8VAA;FES;7,@8V%N(&)E M(&%D;W!T960L(&-O7!T;W-Y2!I7!I8V%L;'D@;V8@:&EG:"!I;7!O6UM971R:6,@8W)Y<'1O9W)A<&AY(&%P M<&5A2!B87-E9"!A=71H96YT M:6-A=&EO;B`-"F%P<&5A2!B87-E9"!A=71H96YT:6-A=&EO;BX@#0I4:&5R92!A7!T;V=R87!H>2!W:&EL92!P65D('5S:6YG('-Y;6UE=')I8R`-"F-R>7!T;V=R M87!H>2X@($%L=&AO=6=H(&$@;G5M8F5R(&]F('1E8VAN;VQO9VEE2X@5&AE($EN=&5R:6]R3F]D94ME M>2!I2`-"FES(&EN9&5P96YD96YT(&]F(&%N>2!D871A('-T M2!B92!D97!L M;WEE9"!D=64@=&\@<&5R9F]R;6%N8V4@2P@2!U65D(&AA2!U7!T:6]N("AW:&5R92!A('-U8V-E'0@:7,@8F]T:"!U;FUO9&EF:65D(&EN('1R86YS M:70@86YD('=A2DN#0H-"DAO=V5V97(L(%1204-+('!R;W1O8V]L2D@ M<')E=F5N=&5D(&9R;VT@2!B M92`-"F%D;6EN:7-T97)E9"!A2!R969U6UM971R M:6,@:V5Y(&9R;VT@9&%T82!A=71H96YT:6-A=&EO;B!U65R+"!W:&EL92!D M871A(&%U=&AE;G1I8V%T:6]N('5S:6YG(&$@2!W:6QL M(&)E(`T*8V]N9'5C=&5D(&%T('1H92!N971W;W)K(&QA>65R+@T*#0HM('-I M;F-E('1H92!$4G,O5$X@;6%Y(&)E("AO<'1I;VYA;&QY*2!P2!C;VUE(&9R;VT@=&AE(`T*;W)I9VEN86P@2!C2!T:&4@ M9&%T82`-"BAI+F4N('!A>6QO860I('5N;6]D:69I960@=&\@=&AE('%U97)Y M:6YG(')E8V5I=F5R2!T:&4@ M9W)O=7`M#0IA=71H96YT:6-A=&EO;BX-"@T*5&%K:6YG(&-A2!T:&4@1%(@:7,@<&5R9F]R M;65D('9I82!U;FEC87-T('1O(&$@#0IR96-E:79E2!F;W(@=&AI&ES=&EN9R`-"F=R;W5P+7-H87)E9"!S M>6UM971R:6,@:V5Y(&]R('5S92!A('-E<&%R871E('-Y;6UE=')I8R!K97D@ M;VYL>2`-"F9O2!A;F0@9F]R($%U M=&AE;G1I8V%T:6]N#0H-"D%S(&UE;G1I;VYE9"!A8F]V92P@=V4@<')O<&]S M92!T:&4@2!U2!F;W(@9&%T82!S=')E86T@8V]N9FED96YT:6%L:71Y(&%T('1H M92`-"F%P<&QI8V%T:6]N(&QA>65R(&%S('1H92!'2!O9B!T:&4@1W)O=7!$871A2V5Y+"!W:&EC:"!I2!-86YA9V5M96YT("A'2TTI('!R;W1O8V]L('1H870@#0II9&5N=&EF:65S M(&%N9"!V97)I9FEE2!M=7-T M(`T*8F4@<')E=F5N=&5D(&)Y('1H92!'2TT@<')O=&]C;VP@9G)O;2!O8G1A M:6YI;F<@=&AE($=R;W5P1&%T84ME>2X-"@T*5V4@9&5N;W1E('1H92!S>6UM M971R:6,@:V5Y(&9O'!L:6-I="!G2X@(%5N;&EK92!T:&4@1W)O M=7!$871A2V5Y+"!T:&4@#0I'7!I8V%L M;'D@82!R96-E:79E2!R97-U;'0@:6X@82!D96YI86P@;V8@2!I;7!A8W0@=&AE('-T871E(&]F('1H92!G7!E2!D:7-T2!A7,@:&%V M92!T:&4@861D2!B86-K=7`@1%(O5$XN("!/<'1I;VYA;&QY+"!I="!M M87D@;F5E9"!T;R!K965P(`T*=&AE(&ME>7,@9F]R(&5A8V@@;V8@=&AE(&)A M8VMU<"!C;VYT7-T96US+"!I="!I'!E8W1E9"!T;R!B96-O;64@82!K97)N M96P@;6]D=6QE+"!A;F0@2!M M=7-T(&%C8V]M;6]D871E(&%L;"!T:')E92!O9B!T:&5S92!O<'1I;VYS+B`@ M#0I4:&ES(')A:7-E65R('-E8W5R:71Y(&9U M;F-T:6]N2X-"BT@2V5R M;F5L($EM<&QE;65N=&%T:6]N2!R96-E:79E2P@=6YI;G1E;G1I;VYA;&QY*2!W:&EC:"!W M;W5L9"!C875S92!D96YI86P@#0IO9B!S97)V:6-E+@T*#0I!2U097(M57-E($1A=&$-"@T*02!C;VUM;VX@2UP97(M=FEE=R!V:61E;R!S:6=N86QS+"!O2!O9B!T:&4@87!P;&EC871I M;VX@;&5V96P@2!W:71H(%1204-+('!R;W1O M8V]L2!A="!T:&4@;F5T=V]R M:R!L87EE2!C86X@ M8F4@=7-E9"!I;G-T96%D+2UA;'1H;W5G:"!T:&ES(&]F(`T*8V]U2!W:71H(&]T:&5R(&EM<&QE;65N=&%T:6]N M2!C;W5P;&5D M('1O('1H92!C:&]I8V4@#0IO9B!R96-O;6UE;F1I;F<@25!S96,@9F]R('1H M92!G2!T:&4@9F]L;&]W:6YG.@T*#0HH82D@3F]N+41E M8VEP:&5R86)I;&ET>2!O9B!D871A(&)Y(&EN=&5R:6]R(&-O;G1R;VP@;F]D M97,Z(&ET(&ES(&$@#0IR97%U:7)E;65N="!O9B!44D%#2R!P6UE;G1S+"!I=',@8V]N=')O;"`-"F5N=&ET M:65S("AE+F2!U2!A;F0@1W)O=7!!=71H2V5Y*2!A;F0@=&\@#0II M;G-T2!S:&]W;B!T:&%T('1H92!I;G1E2!! M2!I65R+@T*#0H-"C4N,B!$:79I2!R97-P;VYS:6)I;&ET:65S(&EN('1O M(&9O=7(@#0IP87)T2!A='1A8VMS+@T*+2!/<'1I;VYA;#H@96YC M2!O9B!D871A+`T* M("!A;F0@<')O=FED92!O<'1I;VYA;"!N;VXM7!T:6]N+2UT;R!P7,@<&5R:6]D:6-A;&QY(&YE960-"B`@=&\@8F4@ M8VAA;F=E9"P@8F]T:"!A9G1E2!A9&1I=&EO;F%L('-E M8W5R:71Y(&%T('1H92!)4"])4"`-"DUU;'1I8V%S="!L979E;"P@86QT:&]U M9V@@=&AI2!F;W(@:71S(&YE='=O2`@("`@('P\+2TM+2T^*R`@("`@("`@("`K+2TM+2TM+2TM M*R`@('PM+3Y\("`@("`@("`@('P-"GP@($UA;F%G96UE;G0@('P@("`@("`@ M?"`@("`@("`@("!\("`@5410("`@?"`@("`@("!\("`@25!S96,@('P-"GP@ M("`@("`@("`@("`@('P@("`@("`@*RTM+2TM+2TM+2TM+2TM+2TM+2TM*R`@ M("`@("!\("`@("`@("`@('P-"GP@("`@("`@("`@("`@('P\/3T]/3T^?"`@ M25`L($E0($UU;'1I8V%S="`@?#P]/3T]/3Y\("`@("`@("`@('P-"BLM+2TM M+2TM+2TM+2TM+2L@("`@("`@*RTM+2TM+2TM+2TM+2TM+2TM+2TM*R`@("`@ M("`K+2TM+2TM+2TM+7P-"@T*("`\/3T]/B!/<'1I;VYA;`T*#0H-"E=H96X@ M82!D871A('!A8VME="!I2P@86YD('1H96X@ M8V]N=&EN=64@#0IT;R!D96-I<&AE2X-"@T*02!$97-I9VYA=&5D(%)E8V5I=F5R($YO M9&4@*$12*2!W:6QL('!O2`H8G5T(&YO M="`-"G1H92!'2!O9B`-"F$@2`H2!S M:&%R960@8GD@82!$4B!A;F0@86QL(&ET2X-"@T*06=A:6XL(&%L=&AO=6=H('1H92!C=7)R96YT('=O2!)4'-E8RP@:6YC;'5D:6YG('!R979E;G1I;VX@;V8@2!!2!T:&4@9W)O=VEN9R`-"F%V86EL M86)I;&ET>2!O9B!)4'-E8R!T:&%T(&UO=&EV871E65R(&%U=&AE M;G1I8V%T:6]N(&9O2!M=7-T(&)E(&%B;&4@=&\@875T:&5N=&EC871E M(`T*:71S96QF('1O('1H92!K97D@;6%N86=E;65N="!E;G1I='DO7,N("!792!A7,Z#0H-"B`M("!'2!I2!A;&P@;65M8F5R7!I8V%L;'DL(&]N92!'2!O9B!T:&4@4V5N9&5R+U-O=7)C92!E M;F-I<&AE2!T:&4@4F5C96EV97)S('=I;&P@8F4@86)L92!T;R!D96-I<&AE M2P@=VAI8V@@9&]E2!I2!I65D(&AA2!I3H@#0I4:&4@26YT97)I;W).;V1E2V5Y(&ES(&$@2!S:&%R960@8GD@86QL(&EN=&5R:6]R(`T*8V]N=')O;"!N;V1E M7!T960I(&QO2X@($ET(&UU2!T:&%T(&-H:6QD+412('1O('!R;W9I9&4@ M#0IA=71H96YT:6-A=&EO;B!F;W(@=&AE(')E=')A;G-M:71T960@9&%T82!P M86-K970N("`-"@T*#0HV+B!,:6UI=&%T:6]N2!K97ES+"!A;F0@=&AE(`T*;F5E M9"!T;R!L;V-A;&EZ92!T:&4@969F96-T2!T:&%T($12+@T*#0HH8RD@4')I=F%C>2X@($EN(&]R9&5R('1O('!R M979E;G0@;F5T=V]R:R!T7,@8V%N(&)E('5S960@=VET:"!)4'-E8R!T;R!E;F-R>7!T M('1H92!P86-K971S('-E;G0@=&\@=&AE(`T*9W)O=7`L(&EN(&%D9&ET:6]N M('1O(&1O:6YG('!A8VME="!A=71H96YT:6-A=&EO;BX@($AO=V5V97(L(&ET M(&UUF5D('1H870@=&AI2!O9B!P87DM<&5R+0T*=7-E('-E2!T:&4@#0IR96-E:79E2!B92!A2`H92YG+B!T:&4@2P@ M:6X@=&AE(&-U2!W:6QL(&)E(&-O M;F1U8W1E9"!A="!T:&4@#0IA<'!L:6-A=&EO;B!L87EE65R(&ES.@T*("`@+2!F;W(@<')O=&5C=&EO;B!O9B!T:&4@ M=')A;G-P;W)T(&%N9"!)4"!H96%D97)S+@T*("`@+2!T;R!A;&QO=R!A($12 M('1O(&%U=&AE;G1I8V%L;'D@2!E;F-R>7!T:6]N('1O(&)E(&%P<&QI M960@#0H@("`@("AA="!T:&4@87!P;&EC871I;VX@;&%Y97(I(&EN(&]R9&5R M('!R979E;G0@=&AE($127!T:6]N(&9O65R('5S:6YG(`T*2!C2`-"BAI;G-T96%D(&]F M('1H92!'2!T:&4@#0IE M;G1I=&EE'0L($YO=B`Q M.3DX+@T*#0I;2$@Y.6%=($@N($AA2!A;F0@12X@2&%R9&5R+"`B1W)O M=7`@4V5C=7)I='D@07-S;V-I871I;VX@2V5Y(`T*36%N86=E;65N="!02US<&%R=&$M M9W-A:VUP+7-E8RT-"C`P+G1X="P@36%Y(#$Y.3DN#0H-"EM+0U=0,#!=($TN M($MA9&%N2UT'0L($9E8B`Q.3DX#0H-"EM-1SDX8ET@0RX@36%D7!T:6]N(%-T86YD87)D(BP@5F]L=6UE,2XU+"`- M"DYO+B`Q.3DS+@T*#0I;5T)033DX72!"+B!7:&5T=&5N+"!-+B!"87-A=F%I M86@L(%,N(%!A=6PL(%0N($UO;G1G;VUEFrom owner-rmt@listserv.lbl.gov Wed Feb 9 09:03:11 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id JAA23285; Wed, 9 Feb 2000 09:02:05 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA23281 for ; Wed, 9 Feb 2000 09:02:02 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA20566 for ; Wed, 9 Feb 2000 09:02:01 -0800 (PST) Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA20546 for ; Wed, 9 Feb 2000 09:01:59 -0800 (PST) Received: from tahoe ([207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id JAA06011; Wed, 9 Feb 2000 09:01:07 -0800 (PST) Message-Id: <4.1.20000209085625.01c8b640@mailhost.talarian.com> X-Sender: bwhetten@mailhost.talarian.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 09 Feb 2000 08:58:01 -0800 To: smug@baynetworks.com, rmt@lbl.gov From: Brian Whetten Subject: Security Considerations for TRACK Protocols Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_286204430==_.ALT" Sender: owner-rmt@lbl.gov Precedence: bulk --=====================_286204430==_.ALT Content-Type: text/plain; charset="us-ascii" Someone reported that the file was corrupted, so it is attached below. Sorry to add to everyone's mailbox! Brian Internet Engineering Task Force T. Hardjono INTERNET-DRAFT Nortel Networks draft-ietf-rmt-track-security-00.txt B. Whetten January 12, 2000 Talarian Security Requirements For TRACK Protocols Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document discusses the security issues within TRee-based ACKnowledgement (TRACK) reliable multicast protocols, and identifies some constraints and requirements for security provisions for these protocols. Based on the constraints and requirements, the document proposes a separation of data packet confidentiality and authentication, from transport layer protection. It proposes that TRACK protocols be primarily concerned with group authentication of control and data packets, to protect against attacks on the transport infrastructure. It proposes that data confidentiality and source authentication be provided separately from this low level group authentication, ideally at the application level. We show that this is particularly important for TRACK protocols, because of the requirement that the interior control nodes only optionally have access to the data packet payload. Specifically, the current work proposes that data and control packet authentication be provided using IPsec-based authentication at the network layer. This approach allows an interior control node to authentically retransmit a lost data packet (which remains encrypted under the separate data-encryption key) to its own children (a set of Receivers), while making use of the IPsec features, such as protection against replay attacks. This document then provides a specific proposal for how group keys should be divided up among group members, for control and data packet authentication. While providing some rationale for divorcing this proposal from that of source authentication and data confidentiality, it does not provide a specific proposal for those pieces. 1. Background: The Multicast Security Problem The problem of multicast security can be divided into three general areas of concern: - Data Encryption and Source Authentication. The method used to encipher or scramble the multicast data, and verify the identity of the sender of this data. - Key Distribution. The method used to securely distribute group keys and keying material to the members of a group, for use in decrypting or authenticating the data or control packets. - Infrastructure protection. Mechanisms used to protect the multicast infrastructure itself, and to minimize the ability of an intruder to deny service to legitimate users. The security of reliable multicast protocols falls primarily into the third category of problems. Complete denial of service protection must start at the network level (i.e. IP Multicast), with controls placed on senders from overloading the network with brute force "spamming", as well as with authentication of control packets, to keep users from corrupting the state of the IP Multicast protocols. A transport protocol needs to address the same issues, checking to make sure that senders are not sending more data than they are allowed (such as with enforceable congestion control), and authenticating control packets, to protect the protocol state. Control packet authentication is particularly important in TRACK protocols, because of their use of interior control nodes (for example, in RMTP-II, DRs and TNs) to increase scalability. An optional extension to the requirement of infrastructure protection is that of infrastructure privacy. Some applications require that the headers of the network packets be encrypted, to provide protection from network analysis attacks. 2. Independence of RM Security The security of reliable multicast (RM) protocols is part of the larger problem of the security of the multicast infrastructure, which also consists of the security of the multicast routing protocols. Since RM protocols and multicast routing protocols exist at different layers in the protocol stack, and since different RM protocols may be employed with different multicast routing protocols, it is useful from a security perspective to treat these two security problems separately. In addition, although in many instances the topology of RM infrastructure may coincide with that of the multicast routing protocol, such symmetry cannot be assumed for all cases. Similarly, from a design perspective, the problem of securing the data stream (e.g. through content encryption) should be separated from the issue of securing reliable multicast protocols. Although we treat RM-security as an independent problem from other multicast security problems, this does not preclude using the solutions in other areas in order to solve the security needs of RM. For example, the use of IPsec technology at the IP layer to authenticate multicast routing protocol control-packets can also be used to authenticate RM control-messages. However, the instance of deploying IPsec in both cases must be distinguished and treated separately. 3. RMTP-II Overview While not necessarily typical of all TRACK protocols (such as TRAM [KCWP00]), we use the RMTP-II protocol as an example for analysis and discussion. The RMTP-II protocol features a number of entities which participate in a logical tree or hierarchy and which exchange control- messages with each other. The entities are the Top Node (TN), the Sender Nodes (SD), the Designated Receiver Nodes (DR) and the Receiver Nodes (RN). RMTP-II places receivers into local regions, where each region is assigned to a DR. These groups are arranged hierarchically as a tree rooted at the TN, with the DRs representing the nodes of the tree, and the receivers as the leaves. The senders connect directly to the top node, at the top layer of the hierarchy. The receivers send their control-messages (ACKs, NACKs, etc.) to the DR of their region. Retransmission of lost packets may be done locally by the DR of a domain, or globally from the sender. Each DR sends their control messages to the DR at the next level up the hierarchy. This process is repeated until the TN, who then forwards the control messages to the appropriate sender. The DRs and TN aggregate the positive acknowledgements from the receivers, and suppress the redundant negative acknowledgements, in order to solve the ACK/NACK implosion problem. A DR maintains a local multicast group to just its children, and subscribes to the local multicast group of its parent. A DR uses this local multicast group for retransmissions to its children. While RMTP- II uses multicast for retransmission from a DR, other TRACK protocols may choose to optionally use unicast. RMTP-II distinguishes between a data channel and a control channel. A data channel is a global multicast group created using the underlying multicast routing protocol. A control channel is the interconnected topology of control nodes, for handling error recovery and positive packet acknowledgements. In order to obtain data packets from the Sender, a Receiver in a given RMTP-II region must join the multicast group (i.e. the data channel). The DR of that region must join every multicast group that its descendants have joined. Note that the DRs are not responsible for forwarding the data packets multicast by the Sender, since that data stream is propagated by the underlying multicast routing protocol. The figure below illustrates an RMTP-II tree with multiple control nodes. HACKs -----------> (Top Node)----------------->(Sender node) ^ ^^^ | | / | \ | HACKs | / | \ | | / | \ | | / | \ (Designated | / | \ Receiver | / | \ node) v Control D R D R D R <------------| Channel ^^ ^^^ ^^ | Data / | / | \ | \ | Channel / | / | \ | \ | / | / | \ | \ v RN RN RN RN RN RN RN <------ (Receiver Nodes) 4. TRACK Protocol Security Issues and Requirements This section details the security requirements for TRACK protocols which are similar to RMTP-II. These requirements include general multicast transport requirements, as well as some requirements specific to TRACK protocols. 4.1 Background In addressing the security issues specific to TRACK protocols, it is useful to consider the general aspects of security relating to reliable multicast. - Layer in which security is applied: The two layers in which security mechanisms are deployed are typically the network layer and the application layer. In the network layer the protocol that is the most commonly used is the IPsec protocol, which provides authentication and/or encryption. In either case, with IPsec the transport headers (and IP headers) are protected. When authentication and/or encryption is applied at the application layer, neither the transport headers nor the IP headers are protected. - Types of authentication: - Source-authentication: If public key (asymmetric) cryptography is deployed, where only the sender knows the secret-half of the public key pair, then unique "source-authentication" can be established. - Group-authentication: If shared key (symmetric) cryptography is deployed and the key is shared by more than two parties, then only "group-authentication" can be established. This means that a receiver in a group is only certain that the entity that sent the message is in possession of the symmetric-key, and is thus assumed to be a member of the group sharing the key. In the following, the TRACK specific requirements are further elaborated. 4.2 Authentication of Control-Messages As stated above, the directly relevant security concern for TRACK protocols is protection of the multicast infrastructure, particularly of the control tree, in order to provide protection against replay or other attacks which seek to corrupt the state of the transport protocol. The authentication of control messages exchanged among TRACK protocol entities represents the minimal security mechanisms necessary to do so. Two types of authentication mechanisms can be adopted, corresponding to the two basic types of cryptosystems. In the context of reliable multicast, throughput and latency is typically of high importance, and group-authentication based on symmetric cryptography appears to be preferable. Given this, the efficiencies of symmetric key based authentication appear to outweigh the benefits of public key based authentication. There are potentially cryptographic schemes that can provide the unique source-authentication of public key cryptography while providing the performance characteristics of symmetric key based authentication (e.g. efficient digital signing of the hash-value of several data packets). However, at the present time, for the general case of infrastructure protection, the complexities of these options appear to outweigh the benefits. Thus, in summary, for TRACK protocol control-messages, explicit group- authentication at the IP layer should be deployed using symmetric cryptography. Although a number of technologies are available, we propose specifically IPsec-based authentication using a keyed-hash function [KA98b,MG98a,MG98b] due to its growing use and availability. We denote the symmetric key used for control message authentication as the InteriorNodeKey. The InteriorNodeKey is a symmetric key shared by all DRs and the TN within a given RMTP-II or TRACK hierarchy. The key is independent of any data stream, and is used to authenticate control packets exchanged among the DRs/TN. 4.3 Non-Decipherability of Data Packets by DRs RMTP-II requires that a Designated Receiver Node (DR) join all of the multicast groups that its descendants have joined. This is also true of the Top Node (TN). For TRACK protocols it is preferable that authentication methods based on a symmetric key be deployed due to performance reasons. This may be achieved explicitly, such as by using a keyed hash function, or implicitly using encryption (where a successful decryption implies the ciphertext is both unmodified in transit and was generated by a holder of the symmetric key). However, TRACK protocols have a further requirement, namely that their repair nodes (i.e. DR and TN) be (optionally) prevented from reading the multicast data. More specifically, we perceive that DRs may be administered as part of a reliability service offered by third parties such as ISPs. These third parties may refuse the ability to decipher data packets in order to avoid the legal ramifications of having access to the data contents. Thus, from the ISP perspective, TRACK protocols must allow them to prove to the content-owner that they do not posses the means to alter the contents transmitted through the multicast groups. Given the above requirement of the DRs/TN and the need for fast authentication, we propose: - the separation of data stream confidentiality using either a symmetric or asymmetric key from data authentication using a symmetric key (i.e. explicit group-authentication). - data stream confidentiality will be conducted at the application layer, while data authentication using a symmetric key will be conducted at the network layer. - since the DRs/TN may be (optionally) prevented from reading the multicast data, two (2) different keys must be deployed corresponding to the needs of data stream confidentiality and data group- authentication. 4.4 Authentication of Data Retransmissions In TRACK protocols, retransmissions of data packets may come from the original source, or from a different (DR) node. This local recovery is an important tool for increasing the scalability and latency of a protocol. In the context of security, it raises the question as to what authentication methods should be used on these packets. (a) If source authentication (using public key cryptography) and data confidentiality (including implicit group authentication) is applied at the application layer, the DR can simply replay the data (i.e. payload) unmodified to the querying receivers, either via unicast or local multicast. (b) If, however, explicit group authentication (using a symmetric key) was applied at the network layer (e.g. using IPsec), then the DR cannot simply replay the packet due to restrictions at the IP layer. Thus, in this case the DR must re-apply the group- authentication. Taking case (b) further, there are two options corresponding to whether retransmission by the DR is performed via unicast to a receiver or via multicast. (i) If the retransmission is unicast to a given receiver, then it is preferred if the DR and the receiver share a separate symmetric key for this purpose. (ii) If the retransmission is via multicast to a subgroup (as is the case in RMTP-II), then the DR can either use the existing group-shared symmetric key or use a separate symmetric key only for the subgroup under the DR. We propose to use the later approach, which means that a DR and its children (receivers) must share a separate symmetric key for explicit group authentication at the IP layer. 4.5 Keys for Data Confidentiality and for Authentication As mentioned above, we propose the separation of data stream confidentiality using a symmetric key encryption (effecting an implicit group-authentication) from data authentication using a symmetric key and a keyed hash function (i.e. explicit group-authentication). We now denote the symmetric key for data stream confidentiality at the application layer as the GroupDataKey. Only the source and valid receivers will have a copy of the GroupDataKey, which is delivered to them through the appropriate Group Key Management (GKM) protocol that identifies and verifies the members individually. In the case where the DRs and the TN are not permitted to read the multicast data, they must be prevented by the GKM protocol from obtaining the GroupDataKey. We denote the symmetric key for explicit group-authentication at the network layer as the GroupAuthKey. The GroupAuthKey is distinct from the GroupDataKey. For TRACK protocols, we propose the use of IPsec with keyed hashing at the network layer to provide explicit group- authentication using the GroupAuthKey. Unlike the GroupDataKey, the GroupAuthKey is known by all entities involved in the multicast. This includes all interior node entities (e.g. TN, DR), the Sender/Source and the Receivers. 4.6 Authenticity of NACK and other Control Packets In TRACK protocols, a DR responds to a NACK from one its children (typically a receiver) by re-transmitting the lost packet via local multicast. This basic behavior can be open to abuse by an attacker who injects spurious NACK messages towards the DR, effecting a local multicast to all children of the DR. In itself this is a waste of bandwidth and may result in a denial of resource to the group members. Other control packets directly impact the state of the group, such as the group membership, and could also be used in denial of service attacks. To counter these types of attack, the control messages themselves must be authenticated by the DR. Digital signatures using public key cryptography could be applied to the control messages. However, this approach would be inefficient due to the high CPU cost of public key encryption. Also, it would require creating a separate security association with each child of the DR. Instead, we propose that NACK and other control messages from a child (receiver) to its DR be protected using symmetric IPsec based authentication. This requires the two parties to first establish a Security Association (SA) and a shared symmetric key. The symmetric key can be unique per child, or be uniform over a subgroup of receivers (i.e. those under the DR). 4.7 Fault Recovery In RMTP-II, if a child's connection to a DR or TN fails, RMTP-II provides automatic mechanisms for failing-over to another DR or backup TN. This reconnection needs to happen quickly, so that the child can rejoin the data stream before too much data has been missed to recover from. If a child needs to get a new key for that DR/TN, this can be a bottleneck. Given that the key distribution infrastructure may be centralized, and a majority of receivers may need to fail over at the same time, this presents a major opportunity for network congestion. The RMTP-II entities are given the address of their backup control node at startup time. While these addresses can change, they are expected to always have the addresses of one or more backup nodes. When implementing security features, each child should be required to keep the key for its primary backup DR/TN. Optionally, it may need to keep the keys for each of the backup control nodes it is using. 4.8 Implementation with Different Levels of OS Protection A TRACK protocol can be implemented in (at least) one of three ways. - Application level. Most implementations of TRACK protocols for the near future are expected to operate in the application level of the OS, running on top of UDP. - Kernel. As TRACK protocols become bundled with standard operating systems, it is expected to become a kernel module, and run directly over IP. - Virtual machine. Some TRACK entities (particularly senders and receivers) will be run in virtual machines, such as when implemented as a Java applet. TRACK protocol security must accommodate all three of these options. This raises the following issues. - Application Level. One advantage of application level implementations is their flexibility. These implementations could use either IPsec routines, the application layer security functions, or both. - Virtual Machines. There are issues trying to use IPsec with virtual machines such as Java, which have to date hindered the support of IPsec through native Java applets. This makes it important for a TRACK protocol to optionally be able to use only application level security. - Kernel Implementations. As a TRACK protocol becomes bundled with operating systems, it is expected that IPsec will also become bundled with the OS. To avoid having to use less trusted software in the application level, the TRACK protocol will have to be able to use a kernel level security system (such as IPsec) for its transport level security needs. 4.9 Separate Regional Protection TRACK protocols are expected to be used for content distribution from a few senders to many receivers. In the case of applications that distribute critical data to many different organizations, it is not enough to trust all receivers. For example, a market data feed provider could be using a TRACK protocol to distribute live market data feeds to competing financial institutions. In this situation, the data feed provider needs to be able to protect individual companies from corrupted control packets from other customers (which could be generated either intentionally, or more likely, unintentionally) which would cause denial of service. As we propose in the next section, a TRACK protocol must provide separate regional keys for the group-authentication of control packets sent from the receivers of different DRs. This allows the authentication of control-messages for each set of receivers (part of one customer) to be done separately (from another set of receivers, as part of different customer). Since for each set of receivers a different key is used, this limits the ability of a customer to perpetrate denial of service attacks against other customers. 4.10 Piracy of Pay-Per-Use Data A common scenario for TRACK protocols involves pay-per-use data distribution, such as live market data, pay-per-view video signals, or paid subscriptions to software updates. In this scenario, a receiver cannot be trusted to not give its group keys to outside entities, who are trying to get free service. We mention this requirement since it is different than point-to-point security. However, this requirement is the responsibility of the application level security. 5. Architecture Recommendations The previous section detailed some of the specific requirements and issues for TRACK protocol security, along with some individual recommendation on handling each one. Given those requirements, we propose the following architecture recommendations for implementing security with TRACK protocols. 5.1 Separation of Security Responsibilities As detailed above, TRACK protocols are primarily concerned with protection of the network infrastructure, rather than with issues such as data confidentiality and source-authentication. Therefore, we recommend that TRACK protocols SHOULD provide: (a) group authentication of control packets, and (b) optional group authentication of data packets Optionally, TRACK protocols MAY choose to provide: (c) optional privacy of data and of control packet headers. To accomplish this, we recommend that TRACK protocols use IPsec technology at the network layer, while letting application level security perform additional functions as needed. For implementations that do not have access to IPsec, and are not implemented as part of the OS, application level security can be used instead--although this of course risks incompatibility with other implementations. The separation of group-authentication of data from both data source- authentication and data-confidentiality is tightly coupled to the choice of recommending IPsec for the group authentication. These two choices are motivated by the following: (a) Non-Decipherability of data by interior control nodes: it is a requirement of TRACK protocols that in some deployments, its control entities (e.g. TN, DR) be unable to decipher the data packet. Thus, the GroupDataKey for data encryption and GroupAuthKey for group- authentication must be distinct. It is not sufficient to simply use an identical key (for the GroupDataKey and GroupAuthKey) and to instruct the TRACK protocol entities to avoid deciphering the data packets. It must be provably shown that the interior control nodes do not have the ability to decipher the data packets (even if they wish to do so). (b) Use of IPsec technologies: considerable effort has been invested in developing the IPsec architecture and protocols [KA98a, KA98b], and a growing number of vendors are supporting IPsec. The IPsec suite offers a number of features, including some protection against replay attacks. (c) Multicast IPsec: the IPsec architecture has intentionally allowed the use of IPsec for IP multicast without changes to the basic constructs within the IPsec suite. Currently, work is proceeding towards the establishment of a standard mechanism to select the Group Security Association (Group SA or GSA) for multicast and a method to disseminate the GSA to the valid members of the group [HCM98,HH99a]. (d) Appropriate Level: since the primary purpose of transport level security is to secure the infrastructure at a transport level, using a network or transport level security protocol allows each to be implemented together--either in the OS, or in the application layer. 5.2 Division of Responsibilities Given this fundamental division between application and transport responsibilities, we divide the security responsibilities in to four parts. Network Responsibilities (IP and IP Multicast) ---------------------------------------------- - Admission controls on senders--to protect against "brute force" spamming attacks. - Authentication of routing control packets--to protect the routing infrastructure from denial of service attacks. Transport Responsibilities (TRACK Protocols) ------------------------------------ - Protection of the control messages from replay attacks and other denial-of-service attacks. - Optional: protection of data packets from replay attacks. - Optional: encryption of control messages to minimize network analysis by attackers. End to End Responsibilities (Application) ----------------------------------------- - Source authentication--to verify the authenticity of data, and provide optional non-repudiation of data. - Data encryption--to provide data confidentiality. Key Management Infrastructure ------------------------------- - Distribution of transport and network layer keys: authentication of individual hosts, and distribution of keys to those hosts - Application level key distribution: authentication of individual processes, and distribution of keys to those processes - Optional: periodic rekeying--group keys periodically need to be changed, both after a certain time limit has expired, and/or after the group membership changes. The figure below shows how these components relate to each other. TRACK protocols can be used without any additional security at the IP/IP Multicast level, although this will not provide full protection from denial of service attacks. TRACK protocols will be able to be used on top of UDP or raw IP/IP Multicast. A TRACK protocol can use either IPsec or application level security for its network security requirements, although we recommend using IPsec wherever possible. +--------------------+ +----------+ +--------------+<----->| Application |<----->| App Sec | | | +--------------------+ |==>| | | | | TRACK |<--| +----------+ | Key |<----->+ +---------+ |-->| | | Management | | | UDP | | IPsec | | | +--------------------+ | | | |<=====>| IP, IP Multicast |<=====>| | +--------------+ +--------------------+ +----------| <===> Optional When a data packet is to be sent to the multicast group, the Sender/Source first (optionally) enciphers the data packet using the GroupDataKey above the RM/transport layer. It is then passed to the RM/transport layer, which attaches the necessary RM headers. The result is then passed down to the IP layer where IPsec authentication is established (using the GroupAuthKey). A Receiver in the multicast group would be in possession of both the GroupDataKey and the GroupAuthKey, and thus will be able to first authenticate the data packet using the GroupAuthKey, and then continue to decipher the data packet using the GroupDataKey. A Designated Receiver Node (DR) will possess the GroupAuthKey (but not the GroupDataKey), and thus will only be able to authenticate the packet using the GroupAuthKey using IPsec. After verifying the authenticity of a received data packet, a DR will be able to retransmit the (enciphered) data packet to its children, either via unicast or region-based local multicast. A retransmission of a lost data packet from a DR will be authenticated using a SubgroupAuthKey (see below) which is a symmetric key shared by a DR and all its children Receivers only. Again, although the current work proposes the use of unicast IPsec and multicast IPsec at the network layer, it does not preclude the use of other authentication technologies at the network layer or at the RM/transport layer. Such technologies, however, will have to address much of the same issues faced by IPsec, including prevention of replays, the creation and maintenance of state (i.e. "Security Associations") associated with the GroupAuthKey, the Sender and Receiver(s), and other features and supporting mechanisms. It is precisely the growing availability of IPsec that motivates the current work to choose IPsec for network layer authentication for both data and control packets. 5.3 TRACK Keys In general, each node in the hierarchy must be able to authenticate itself to the key management entity/server, before it will be allowed to receive any of the below keys. We assume the implementation of a key management infrastructure, which interfaces with the DRs and TNs, as well as the senders and receivers. We propose that this key management system be responsible for distributing the following TRACK protocol keys: - GroupDataKey: The GroupDataKey is the unique symmetric key for data encryption shared by all members of a multicast group, excluding the interior tree entities. Typically, one GroupDataKey is associated with one multicast group. The GroupDataKey is used to provide access control to the data packet by way of the Sender/Source enciphering the data packet. Since only the Receivers hold the copy of the GroupDataKey, only the Receivers will be able to decipher the data packets. This is an optional key, which does not directly concern the TRACK transport. - GroupAuthKey: The GroupAuthKey is the unique symmetric key shared by all members of a multicast group, including the interior control nodes. One GroupAuthKey is associated with one multicast group. The purpose of the GroupAuthKey is to provide authentication of the (possibly enciphered) data packets. In the context of IPsec authentication, this can be achieved using a keyed hash function, such as HMAC-MD5- 96 [MG98a] and HMAC-SHA-1-96 [MG98b]. - SubgroupAuthKey: The SubgroupAuthKey is the unique symmetric key shared only by entities within a given local region, consisting of a DR and its children (consisting of one or more Receivers, and possibly one child DR). The SubgroupAuthKey is used by the parent in a local region to provide group-authentication for the (lost) data packets (still enciphered under the GroupDataKey) which are retransmitted to the Receivers in the region, either via unicast or via subtree- multicast. The SubgroupAuthKey is also used by the entities in a region to group-authenticate control messages that are exchanged with each other. Similar to the GroupAuthKey, we propose the use of IPsec based authentication via keyed hash function. Note that for region-based retransmission of lost packets and for control-packet authentication, the SubgroupAuthKey is used instead of the GroupAuthKey (not both). Note that if a DR happens to be a child within a region and at the same time a parent within its own region, then that DR will hold two distinct SubgroupAuthKeys corresponding to the two regions. In the future, RMTP-II hopes to take advantage of subtree-multicast, where a packet can be sent to a constrained piece of the multicast tree. Ideally, a subtree-multicast only goes to the pieces of the tree that have lost a packet. In this case, additional region keys would have to be distributed, that spanned multiple levels of the hierarchy. We will leave this consideration for a future time, however, since subtree-multicast does not yet exist in a deployable form. - InteriorNodeKey: The InteriorNodeKey is a symmetric key shared by all interior control nodes within a given TRACK hierarchy. The key is independent of any data stream, and is used to authenticate control packets exchanged among the DRs/TN. Should a child-DR request a retransmission of a lost data packet from its parent-DR, then the parent-DR will deliver the (encrypted) lost packet to the child-DR, authenticated using the InteriorNodeKey. Before the child-DR retransmits this lost data packet to its own region, it must first authenticate the packet from the parent-DR using the InteriorNodeKey. It must then use its own SubgroupAuthKey of the region headed/parented by that child-DR to provide authentication for the retransmitted data packet. 6. Limitations The proposed security architecture has certain limitations. These include: (a) Brute Force Attacks. At the transport level, no admission controls can be put in place to throttle a sender which is generating lots of spurious packets to a multicast address. This is the requirement of the network level. At the present time, no accepted standard exists for doing so at the IP Multicast level. (b) Key Corruption. The recommended group key architecture makes a careful tradeoff between the need to distribute many keys, and the need to localize the effects of a node which is compromised. This proposal allows a local receiver to perpetrate denial of service attacks to its local DR, and the receivers served by that DR. (c) Privacy. In order to prevent network traffic analysis attacks, the group keys can be used with IPsec to encrypt the packets sent to the group, in addition to doing packet authentication. However, it must be recognized that this is not a general solution for data privacy. In particular, the group keys can easily be passed from a valid receiver to an unauthorized receiver, to enable piracy of pay-per- use services. This is reasonable, as data privacy is not considered part of the scope of TRACK protocols. (d) Multicast IPsec. Although currently IPsec is generally implemented for pair-wise (one-to-one) communications between one sender and one receiver, the design of IPsec itself allows for usage in IP multicast. Currently the Security Association (SA) definition requires the Security Parameter Index (SPI) to be selected by the receiver [KA98a]. However, since in IP multicast a group address may be associated with multiple receivers, the existing method of selecting the SPI must be re-interpreted. Hence, in the context of "Multicast IPsec", a pre-defined entity (e.g. the source, or the key server/manager) must first create the Group-SA (including selecting the SPI) and deliver the Group-SA to all the members of the group (by either the "push" or "pull" paradigm). Thus rather than being a modification to the IPsec specification, this requirement simply means that additional protocols are needed to establish a shared Group-SA. One possible approach for the Group Key Management (GKM) protocol is to also deliver the Group-SA (and other keying material) to the receiver at the same time it delivers the GroupDataKey [HCM98]. 7. Summary In summary, in the current work we have proposed for TRACK protocols the separation of data stream confidentiality using a symmetric key (i.e. implicit group-authentication) from data authentication using a symmetric key (i.e. explicit group-authentication). Data stream confidentiality using a symmetric key will be conducted at the application layer, while data authentication using a symmetric key will be conducted at the network layer. Since the DRs/TN may be (optionally) prevented from reading the multicast data, two (2) different symmetric keys must be deployed corresponding to the needs of data stream confidentiality and data group-authentication. This proposal follows a number of requirements, some of which are specific to TRACK protocols. The use of group-authentication at the network layer is: - for protection of the transport and IP headers. - to allow a DR to authentically retransmit lost packets to a destination address (unicast or local multicast) different from the original multicast group address. - to allow a separate symmetric key encryption to be applied (at the application layer) in order prevent the DRs/TN from reading the data. We assume encryption for confidentiality (using the GroupDataKey) has been applied above the transport layer by the sender/source, in order to prevent a DR/TN from decrypting the data. The GroupDataKey is only available to the group members, excluding the interior control nodes. We propose the use of another key (GroupAuthKey) to provide group- authentication from the source/sender at the network layer using symmetric key cryptography. The GroupAuthKey is known by the members of the group, as well as the interior control nodes. For the retransmission of lost packets to regions within a group, either via unicast or local multicast, we propose the use of a SubgroupAuthKey (instead of the GroupAuthKey) which is known only to entities within a region (DR and its children). The SubgroupAuthKey is also used by the entities in a region to group-authenticate control messages that are exchanged with each other. 8. References [HCM98] T. Hardjono, B. Cain and I. Monga, "Intra-Domain Group Key Management Protocol", work in progress, draft-ietf-ipsec-intragkm- 00.txt, Nov 1998. [HH99a] H. Harney and E. Harder, "Group Security Association Key Management Protocol", work in progress, draft-harney-sparta-gsakmp-sec- 00.txt, May 1999. [KCWP00] M. Kadansky, D. Chiu, J. Wesley, J. Provino. "Tree-based Reliable Multicast (TRAM)", work in progress, draft-kadansky-tram- 02.txt, January 2000. [KA98a] S. Kent and R. Atkinson, "Security Architecture for the Internet Protocol", IETF, RFC 1825, 1998. [KA98b] S. Kent and R. Atkinson, "IP Authentication Header", work in progress, Internet Draft, July 1998. [MG98a] C. Madson, R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", work in progress, draft-ietf-ipsec-auth-hmac-md5-96-03.txt, Feb 1998 [MG98b] C. Madson, R Glenn, The Use of HMAC-SHA-1-96 within ESP and AH", work in progress, "draft-ietf-ipsec-auth-hmac-sha1-96-03.txt, Feb, 1998. [R92] R. Rivest, "MD5 Digest Algorithm", RFC1321, April 1992. [RSA93] RSA Laboratories, "PKCS#1: RSA Encryption Standard", Volume1.5, No. 1993. [WBPM98] B. Whetten, M. Basavaiah, S. Paul, T. Montgomery, "RMTP-II Specification". Work in progress, draft-whetten-rmtp-ii-00.txt, April 8, 1998. --=====================_286204430==_.ALT Content-Type: text/html; charset="us-ascii" Someone reported that the file was corrupted, so it is attached below.
Sorry to add to everyone's mailbox!
Brian


Internet Engineering Task Force                             T. Hardjono
INTERNET-DRAFT                                          Nortel Networks
draft-ietf-rmt-track-security-00.txt                         B. Whetten
January 12, 2000                                               Talarian




             Security Requirements For TRACK Protocols

              <draft-ietf-rmt-track-security-00.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as
   "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

This document discusses the security issues within TRee-based
ACKnowledgement (TRACK) reliable multicast protocols, and identifies
some constraints and requirements for security provisions for these
protocols.  Based on the constraints and requirements, the document
proposes a separation of data packet confidentiality and authentication,
from transport layer protection.  It proposes that TRACK protocols be
primarily concerned with group authentication of control and data
packets, to protect against attacks on the transport infrastructure.  It
proposes that data confidentiality and source authentication be provided
separately from this low level group authentication, ideally at the
application level.  We show that this is particularly important for
TRACK protocols, because of the requirement that the interior control
nodes only optionally have access to the data packet payload.

Specifically, the current work proposes that data and control packet
authentication be provided using IPsec-based authentication at the
network layer.  This approach allows an interior control node to
authentically retransmit a lost data packet (which remains encrypted
under the separate data-encryption key) to its own children (a set of
Receivers), while making use of the IPsec features, such as protection
against replay attacks. 

This document then provides a specific proposal for how group keys
should be divided up among group members, for control and data packet
authentication.  While providing some rationale for divorcing this
proposal from that of source authentication and data confidentiality, it
does not provide a specific proposal for those pieces.


1. Background: The Multicast Security Problem

The problem of multicast security can be divided into three general
areas of concern:
- Data Encryption and Source Authentication.  The method used to
encipher or scramble the multicast data, and verify the identity of
the sender of this data.
- Key Distribution.  The method used to securely distribute group
keys and keying material to the members of a group, for use in
decrypting or authenticating the data or control packets.
- Infrastructure protection.  Mechanisms used to protect the
multicast infrastructure itself, and to minimize the ability of an
intruder to deny service to legitimate users.

The security of reliable multicast protocols falls primarily into the
third category of problems.  Complete denial of service protection must
start at the network level (i.e. IP Multicast), with controls placed on
senders from overloading the network with brute force "spamming", as
well as with authentication of control packets, to keep users from
corrupting the state of the IP Multicast protocols.  A transport
protocol needs to address the same issues, checking to make sure that
senders are not sending more data than they are allowed (such as with
enforceable congestion control), and authenticating control packets, to
protect the protocol state.  Control packet authentication is
particularly important in TRACK protocols, because of their use of
interior control nodes (for example, in RMTP-II, DRs and TNs) to
increase scalability.

An optional extension to the requirement of infrastructure protection is
that of infrastructure privacy.  Some applications require that the
headers of the network packets be encrypted, to provide protection from
network analysis attacks.


2. Independence of RM Security

The security of reliable multicast (RM) protocols is part of the larger
problem of the security of the multicast infrastructure, which also
consists of the security of the multicast routing protocols.

Since RM protocols and multicast routing protocols exist at different
layers in the protocol stack, and since different RM protocols may be
employed with different multicast routing protocols, it is useful from a
security perspective to treat these two security problems separately. 
In addition, although in many instances the topology of RM
infrastructure may coincide with that of the multicast routing protocol,
such symmetry cannot be assumed for all cases.

Similarly, from a design perspective, the problem of securing the data
stream (e.g. through content encryption) should be separated from the
issue of securing reliable multicast protocols.

Although we treat RM-security as an independent problem from other
multicast security problems, this does not preclude using the solutions
in other areas in order to solve the security needs of RM. For example,
the use of IPsec technology at the IP layer to authenticate multicast
routing protocol control-packets can also be used to authenticate RM
control-messages.  However, the instance of deploying IPsec in both
cases must be distinguished and treated separately.


3. RMTP-II Overview

While not necessarily typical of all TRACK protocols (such as TRAM
[KCWP00]), we use the RMTP-II protocol as an example for analysis and
discussion.  The RMTP-II protocol features a number of entities which
participate in a logical tree or hierarchy and which exchange control-
messages with each other.  The entities are the Top Node (TN), the
Sender Nodes (SD), the Designated Receiver Nodes (DR) and the Receiver
Nodes (RN). 

RMTP-II places receivers into local regions, where each region is
assigned to a DR.  These groups are arranged hierarchically as a tree
rooted at the TN, with the DRs representing the nodes of the tree, and
the receivers as the leaves.  The senders connect directly to the top
node, at the top layer of the hierarchy.  The receivers send their
control-messages (ACKs, NACKs, etc.) to the DR of their region. 
Retransmission of lost packets may be done locally by the DR of a
domain, or globally from the sender.  Each DR sends their control
messages to the DR at the next level up the hierarchy.  This process is
repeated until the TN, who then forwards the control messages to the
appropriate sender.  The DRs and TN aggregate the positive
acknowledgements from the receivers, and suppress the redundant negative
acknowledgements, in order to solve the ACK/NACK implosion problem.

A DR maintains a local multicast group to just its children, and
subscribes to the local multicast group of its parent.  A DR uses this
local multicast group for retransmissions to its children.  While RMTP-
II uses multicast for retransmission from a DR, other TRACK protocols
may choose to optionally use unicast.

RMTP-II distinguishes between a data channel and a control channel.  A
data channel is a global multicast group created using the underlying
multicast routing protocol.  A control channel is the interconnected
topology of control nodes, for handling error recovery and positive
packet acknowledgements.

In order to obtain data packets from the Sender, a Receiver in a given
RMTP-II region must join the multicast group (i.e. the data channel). 
The DR of that region must join every multicast group that its
descendants have joined.  Note that the DRs are not responsible for
forwarding the data packets multicast by the Sender, since that data
stream is propagated by the underlying multicast routing protocol.

The figure below illustrates an RMTP-II tree with multiple control
nodes.

                                          HACKs
              -----------> (Top Node)----------------->(Sender node)
             ^                ^^^                             |
             |              /  |  \                           |
       HACKs |            /    |    \                         |
             |          /      |      \                       |
             |        /        |        \     (Designated     |
                    /          |          \    Receiver       |
                  /            |            \   node)         v
      Control   D R           D R           D R  <------------|
      Channel   ^^            ^^^            ^^               | Data
               / |           / | \           | \              | Channel
              /  |          /  |  \          |  \             |
             /   |         /   |   \         |   \            v
           RN   RN       RN   RN   RN        RN   RN   <------
                       (Receiver Nodes)



4. TRACK Protocol Security Issues and Requirements

This section details the security requirements for TRACK protocols which
are similar to RMTP-II.  These requirements include general multicast
transport requirements, as well as some requirements specific to TRACK
protocols.

4.1 Background

In addressing the security issues specific to TRACK protocols, it is
useful to consider the general aspects of security relating to reliable
multicast.

 - Layer in which security is applied:
The two layers in which security mechanisms are deployed are
typically the network layer and the application layer.  In the
network layer the protocol that is the most commonly used is the
IPsec protocol, which provides authentication and/or encryption.  In
either case, with IPsec the transport headers (and IP headers) are
protected.  When authentication and/or encryption is applied at the
application layer, neither the transport headers nor the IP headers
are protected.

 - Types of authentication:
  - Source-authentication: If public key (asymmetric) cryptography is
deployed, where only the sender knows the secret-half of the
public key pair, then unique "source-authentication" can be
established.
  - Group-authentication: If shared key (symmetric) cryptography is
deployed and the key is shared by more than two parties, then
only "group-authentication" can be established. This means that a
receiver in a group is only certain that the entity that sent the
message is in possession of the symmetric-key, and is thus
assumed to be a member of the group sharing the key.

In the following, the TRACK specific requirements are further
elaborated.


4.2 Authentication of Control-Messages

As stated above, the directly relevant security concern for TRACK
protocols is protection of the multicast infrastructure, particularly of
the control tree, in order to provide protection against replay or other
attacks which seek to corrupt the state of the transport protocol.  The
authentication of control messages exchanged among TRACK protocol
entities represents the minimal security mechanisms necessary to do so.

Two types of authentication mechanisms can be adopted, corresponding to
the two basic types of cryptosystems.  In the context of reliable
multicast, throughput and latency is typically of high importance, and
group-authentication based on symmetric cryptography appears to be
preferable. 

Given this, the efficiencies of symmetric key based authentication
appear to outweigh the benefits of public key based authentication.
There are potentially cryptographic schemes that can provide the unique
source-authentication of public key cryptography while providing the
performance characteristics of symmetric key based authentication (e.g.
efficient digital signing of the hash-value of several data packets). 
However, at the present time, for the general case of infrastructure
protection, the complexities of these options appear to outweigh the
benefits.

Thus, in summary, for TRACK protocol control-messages, explicit group-
authentication at the IP layer should be deployed using symmetric
cryptography.  Although a number of technologies are available, we
propose specifically IPsec-based authentication using a keyed-hash
function [KA98b,MG98a,MG98b] due to its growing use and availability.

We denote the symmetric key used for control message authentication as
the InteriorNodeKey. The InteriorNodeKey is a symmetric key shared by
all DRs and the TN within a given RMTP-II or TRACK hierarchy.  The key
is independent of any data stream, and is used to authenticate control
packets exchanged among the DRs/TN. 


4.3 Non-Decipherability of Data Packets by DRs

RMTP-II requires that a Designated Receiver Node (DR) join all of the
multicast groups that its descendants have joined.  This is also true of
the Top Node (TN).

For TRACK protocols it is preferable that authentication methods based
on a symmetric key be deployed due to performance reasons.  This may be
achieved explicitly, such as by using a keyed hash function, or
implicitly using encryption (where a successful decryption implies the
ciphertext is both unmodified in transit and was generated by a holder
of the symmetric key).

However, TRACK protocols have a further requirement, namely that their
repair nodes (i.e. DR and TN) be (optionally) prevented from reading the
multicast data. More specifically, we perceive that DRs may be
administered as part of a reliability service offered by third parties
such as ISPs.  These third parties may refuse the ability to decipher
data packets in order to avoid the legal ramifications of having access
to the data contents.  Thus, from the ISP perspective, TRACK protocols
must allow them to prove to the content-owner that they do not posses
the means to alter the contents transmitted through the multicast
groups.

Given the above requirement of the DRs/TN and the need for fast
authentication, we propose:

- the separation of data stream confidentiality using either a symmetric
or asymmetric key from data authentication using a symmetric key (i.e.
explicit group-authentication).

- data stream confidentiality will be conducted at the application
layer, while data authentication using a symmetric key will be
conducted at the network layer.

- since the DRs/TN may be (optionally) prevented from reading the
multicast data, two (2) different keys must be deployed corresponding
to the needs of data stream confidentiality and data group-
authentication.


4.4 Authentication of Data Retransmissions

In TRACK protocols, retransmissions of data packets may come from the
original source, or from a different (DR) node.  This local recovery is
an important tool for increasing the scalability and latency of a
protocol.  In the context of security, it raises the question as to what
authentication methods should be used on these packets.

(a) If source authentication (using public key cryptography) and data
confidentiality (including implicit group authentication) is
applied at the application layer, the DR can simply replay the data
(i.e. payload) unmodified to the querying receivers, either via
unicast or local multicast.

(b) If, however, explicit group authentication (using a symmetric key)
was applied at the network layer (e.g. using IPsec), then the DR
cannot simply replay the packet due to restrictions at the IP
layer.  Thus, in this case the DR must re-apply the group-
authentication.

Taking case (b) further, there are two options corresponding to
whether retransmission by the DR is performed via unicast to a
receiver or via multicast.

(i) If the retransmission is unicast to a given receiver, then it
is preferred if the DR and the receiver share a separate
symmetric key for this purpose.

(ii) If the retransmission is via multicast to a subgroup (as is
the case in RMTP-II), then the DR can either use the existing
group-shared symmetric key or use a separate symmetric key only
for the subgroup under the DR.  We propose to use the later
approach, which means that a DR and its children (receivers)
must share a separate symmetric key for explicit group
authentication at the IP layer.


4.5 Keys for Data Confidentiality and for Authentication

As mentioned above, we propose the separation of data stream
confidentiality using a symmetric key encryption (effecting an implicit
group-authentication) from data authentication using a symmetric key and
a keyed hash function (i.e. explicit group-authentication).

We now denote the symmetric key for data stream confidentiality at the
application layer as the GroupDataKey. Only the source and valid
receivers will have a copy of the GroupDataKey, which is delivered to
them through the appropriate Group Key Management (GKM) protocol that
identifies and verifies the members individually.  In the case where the
DRs and the TN are not permitted to read the multicast data, they must
be prevented by the GKM protocol from obtaining the GroupDataKey.

We denote the symmetric key for explicit group-authentication at the
network layer as the GroupAuthKey. The GroupAuthKey is distinct from the
GroupDataKey. For TRACK protocols, we propose the use of IPsec with
keyed hashing at the network layer to provide explicit group-
authentication using the GroupAuthKey.  Unlike the GroupDataKey, the
GroupAuthKey is known by all entities involved in the multicast.  This
includes all interior node entities (e.g. TN, DR), the Sender/Source and
the Receivers.


4.6 Authenticity of NACK and other Control Packets

In TRACK protocols, a DR responds to a NACK from one its children
(typically a receiver) by re-transmitting the lost packet via local
multicast.  This basic behavior can be open to abuse by an attacker who
injects spurious NACK messages towards the DR, effecting a local
multicast to all children of the DR.  In itself this is a waste of
bandwidth and may result in a denial of resource to the group members. 
Other control packets directly impact the state of the group, such as
the group membership, and could also be used in denial of service
attacks.

To counter these types of attack, the control messages themselves must
be authenticated by the DR.  Digital signatures using public key
cryptography could be applied to the control messages.  However, this
approach would be inefficient due to the high CPU cost of public key
encryption.  Also, it would require creating a separate security
association with each child of the DR.

Instead, we propose that NACK and other control messages from a child
(receiver) to its DR be protected using symmetric IPsec based
authentication.  This requires the two parties to first establish a
Security Association (SA) and a shared symmetric key.  The symmetric key
can be unique per child, or be uniform over a subgroup of receivers
(i.e. those under the DR).


4.7 Fault Recovery

In RMTP-II, if a child's connection to a DR or TN fails, RMTP-II
provides automatic mechanisms for failing-over to another DR or backup
TN.  This reconnection needs to happen quickly, so that the child can
rejoin the data stream before too much data has been missed to recover
from.  If a child needs to get a new key for that DR/TN, this can be a
bottleneck.  Given that the key distribution infrastructure may be
centralized, and a majority of receivers may need to fail over at the
same time, this presents a major opportunity for network congestion.

The RMTP-II entities are given the address of their backup control node
at startup time.  While these addresses can change, they are expected to
always have the addresses of one or more backup nodes.  When
implementing security features, each child should be required to keep
the key for its primary backup DR/TN.  Optionally, it may need to keep
the keys for each of the backup control nodes it is using.


4.8 Implementation with Different Levels of OS Protection

A TRACK protocol can be implemented in (at least) one of three ways.
- Application level.  Most implementations of TRACK protocols for the
near future are expected to operate in the application level of the
OS, running on top of UDP.
- Kernel.  As TRACK protocols become bundled with standard operating
systems, it is expected to become a kernel module, and run directly
over IP.
- Virtual machine.  Some TRACK entities (particularly senders and
receivers) will be run in virtual machines, such as when implemented
as a Java applet.

TRACK protocol security must accommodate all three of these options. 
This raises the following issues.
- Application Level.  One advantage of application level
implementations is their flexibility.  These implementations could
use either IPsec routines, the application layer security functions,
or both.
- Virtual Machines.  There are issues trying to use IPsec with
virtual machines such as Java, which have to date hindered the
support of IPsec through native Java applets.  This makes it
important for a TRACK protocol to optionally be able to use only
application level security.
- Kernel Implementations.  As a TRACK protocol becomes bundled with
operating systems, it is expected that IPsec will also become bundled
with the OS.  To avoid having to use less trusted software in the
application level, the TRACK protocol will have to be able to use a
kernel level security system (such as IPsec) for its transport level
security needs.


4.9 Separate Regional Protection

TRACK protocols are expected to be used for content distribution from a
few senders to many receivers.  In the case of applications that
distribute critical data to many different organizations, it is not
enough to trust all receivers.  For example, a market data feed provider
could be using a TRACK protocol to distribute live market data feeds to
competing financial institutions.  In this situation, the data feed
provider needs to be able to protect individual companies from corrupted
control packets from other customers (which could be generated either
intentionally, or more likely, unintentionally) which would cause denial
of service.

As we propose in the next section, a TRACK protocol must provide
separate regional keys for the group-authentication of control packets
sent from the receivers of different DRs.  This allows the
authentication of control-messages for each set of receivers (part of
one customer) to be done separately (from another set of receivers, as
part of different customer). Since for each set of receivers a different
key is used, this limits the ability of a customer to perpetrate denial
of service attacks against other customers.


4.10 Piracy of Pay-Per-Use Data

A common scenario for TRACK protocols involves pay-per-use data
distribution, such as live market data, pay-per-view video signals, or
paid subscriptions to software updates.  In this scenario, a receiver
cannot be trusted to not give its group keys to outside entities, who
are trying to get free service.  We mention this requirement since it is
different than point-to-point security.  However, this requirement is
the responsibility of the application level security.



5. Architecture Recommendations

The previous section detailed some of the specific requirements and
issues for TRACK protocol security, along with some individual
recommendation on handling each one.  Given those requirements, we
propose the following architecture recommendations for implementing
security with TRACK protocols. 


5.1 Separation of Security Responsibilities

As detailed above, TRACK protocols are primarily concerned with
protection of the network infrastructure, rather than with issues such
as data confidentiality and source-authentication.  Therefore, we
recommend that TRACK protocols SHOULD provide:
   (a) group authentication of control packets, and
   (b) optional group authentication of data packets
Optionally, TRACK protocols MAY choose to provide:
   (c) optional privacy of data and of control packet headers. 
To accomplish this, we recommend that TRACK protocols use IPsec
technology at the network layer, while letting application level
security perform additional functions as needed.  For implementations
that do not have access to IPsec, and are not implemented as part of the
OS, application level security can be used instead--although this of
course risks incompatibility with other implementations.

The separation of group-authentication of data from both data source-
authentication and data-confidentiality is tightly coupled to the choice
of recommending IPsec for the group authentication.  These two choices
are motivated by the following:

(a) Non-Decipherability of data by interior control nodes: it is a
requirement of TRACK protocols that in some deployments, its control
entities (e.g. TN, DR) be unable to decipher the data packet.  Thus,
the GroupDataKey for data encryption and GroupAuthKey for group-
authentication must be distinct.  It is not sufficient to simply use
an identical key (for the GroupDataKey and GroupAuthKey) and to
instruct the TRACK protocol entities to avoid deciphering the data
packets.  It must be provably shown that the interior control nodes
do not have the ability to decipher the data packets (even if they
wish to do so).

(b) Use of IPsec technologies: considerable effort has been invested in
developing the IPsec architecture and protocols [KA98a, KA98b], and
a growing number of vendors are supporting IPsec.  The IPsec suite
offers a number of features, including some protection against
replay attacks.

(c) Multicast IPsec: the IPsec architecture has intentionally allowed
the use of IPsec for IP multicast without changes to the basic
constructs within the IPsec suite.  Currently, work is proceeding
towards the establishment of a standard mechanism to select the
Group Security Association (Group SA or GSA) for multicast and a
method to disseminate the GSA to the valid members of the group
[HCM98,HH99a].

(d) Appropriate Level:  since the primary purpose of transport level
security is to secure the infrastructure at a transport level, using
a network or transport level security protocol allows each to be
implemented together--either in the OS, or in the application layer.


5.2 Division of Responsibilities

Given this fundamental division between application and transport
responsibilities, we divide the security responsibilities in to four
parts.

Network Responsibilities (IP and IP Multicast)
----------------------------------------------

- Admission controls on senders--to protect against "brute
  force" spamming attacks.
- Authentication of routing control packets--to protect
  the routing infrastructure from denial of service attacks.

Transport Responsibilities (TRACK Protocols)
------------------------------------
- Protection of the control messages from replay attacks
  and other denial-of-service attacks.
- Optional: protection of data packets from replay attacks.
- Optional: encryption of control messages to minimize
  network analysis by attackers.

End to End Responsibilities (Application)
-----------------------------------------
- Source authentication--to verify the authenticity of data,
  and provide optional non-repudiation of data.
- Data encryption--to provide data confidentiality.

Key Management Infrastructure
-------------------------------
- Distribution of transport and network layer keys: authentication
  of individual hosts, and distribution of keys to those hosts
- Application level key distribution: authentication of
  individual processes, and distribution of keys to those processes
- Optional: periodic rekeying--group keys periodically need
  to be changed, both after a certain time limit has expired,
  and/or after the group membership changes.

The figure below shows how these components relate to each other.  TRACK
protocols can be used without any additional security at the IP/IP
Multicast level, although this will not provide full protection from
denial of service attacks.  TRACK protocols will be able to be used on
top of UDP or raw IP/IP Multicast.  A TRACK protocol can use either
IPsec or application level security for its network security
requirements, although we recommend using IPsec wherever possible.
                       +--------------------+       +----------+
+--------------+<----->|    Application     |<----->|  App Sec |
|              |       +--------------------+   |==>|          |
|              |       |       TRACK        |<--|   +----------+
|     Key      |<----->+          +---------+   |-->|          |
|  Management  |       |          |   UDP   |       |   IPsec  |
|              |       +--------------------+       |          |
|              |<=====>|  IP, IP Multicast  |<=====>|          |
+--------------+       +--------------------+       +----------|

  <===> Optional


When a data packet is to be sent to the multicast group, the
Sender/Source first (optionally) enciphers the data packet using the
GroupDataKey above the RM/transport layer.  It is then passed to the
RM/transport layer, which attaches the necessary RM headers.  The result
is then passed down to the IP layer where IPsec authentication is
established (using the GroupAuthKey).

A Receiver in the multicast group would be in possession of both the
GroupDataKey and the GroupAuthKey, and thus will be able to first
authenticate the data packet using the GroupAuthKey, and then continue
to decipher the data packet using the GroupDataKey.

A Designated Receiver Node (DR) will possess the GroupAuthKey (but not
the GroupDataKey), and thus will only be able to authenticate the packet
using the GroupAuthKey using IPsec.  After verifying the authenticity of
a received data packet, a DR will be able to retransmit the (enciphered)
data packet to its children, either via unicast or region-based local
multicast.  A retransmission of a lost data packet from a DR will be
authenticated using a SubgroupAuthKey (see below) which is a symmetric
key shared by a DR and all its children Receivers only.

Again, although the current work proposes the use of unicast IPsec and
multicast IPsec at the network layer, it does not preclude the use of
other authentication technologies at the network layer or at the
RM/transport layer.  Such technologies, however, will have to address
much of the same issues faced by IPsec, including prevention of replays,
the creation and maintenance of state (i.e. "Security Associations")
associated with the GroupAuthKey, the Sender and Receiver(s), and other
features and supporting mechanisms.  It is precisely the growing
availability of IPsec that motivates the current work to choose IPsec
for network layer authentication for both data and control packets.


5.3 TRACK Keys

In general, each node in the hierarchy must be able to authenticate
itself to the key management entity/server, before it will be allowed to
receive any of the below keys.  We assume the implementation of a key
management infrastructure, which interfaces with the DRs and TNs, as
well as the senders and receivers. 

We propose that this key management system be responsible for
distributing the following TRACK protocol keys:

 -  GroupDataKey:
The GroupDataKey is the unique symmetric key for data encryption
shared by all members of a multicast group, excluding the interior
tree entities.  Typically, one GroupDataKey is associated with one
multicast group.  The GroupDataKey is used to provide access control
to the data packet by way of the Sender/Source enciphering the data
packet.  Since only the Receivers hold the copy of the GroupDataKey,
only the Receivers will be able to decipher the data packets.  This
is an optional key, which does not directly concern the TRACK
transport.

 -  GroupAuthKey:
The GroupAuthKey is the unique symmetric key shared by all members
of a multicast group, including the interior control nodes.  One
GroupAuthKey is associated with one multicast group.  The purpose of
the GroupAuthKey is to provide authentication of the (possibly
enciphered) data packets.  In the context of IPsec authentication,
this can be achieved using a keyed hash function, such as HMAC-MD5-
96 [MG98a] and HMAC-SHA-1-96 [MG98b].

 -  SubgroupAuthKey:
The SubgroupAuthKey is the unique symmetric key shared only by
entities within a given local region, consisting of a DR and its
children (consisting of one or more Receivers, and possibly one
child DR). The SubgroupAuthKey is used by the parent in a local
region to provide group-authentication for the (lost) data packets
(still enciphered under the GroupDataKey) which are retransmitted to
the Receivers in the region, either via unicast or via subtree-
multicast.  The SubgroupAuthKey is also used by the entities in a
region to group-authenticate control messages that are exchanged
with each other. Similar to the GroupAuthKey, we propose the use of
IPsec based authentication via keyed hash function.

Note that for region-based retransmission of lost packets and for
control-packet authentication, the SubgroupAuthKey is used instead
of the GroupAuthKey (not both).

Note that if a DR happens to be a child within a region and at the
same time a parent within its own region, then that DR will hold two
distinct SubgroupAuthKeys corresponding to the two regions.

In the future, RMTP-II hopes to take advantage of subtree-multicast,
where a packet can be sent to a constrained piece of the multicast
tree.  Ideally, a subtree-multicast only goes to the pieces of the
tree that have lost a packet.  In this case, additional region keys
would have to be distributed, that spanned multiple levels of the
hierarchy.  We will leave this consideration for a future time,
however, since subtree-multicast does not yet exist in a deployable
form.

 -  InteriorNodeKey:
The InteriorNodeKey is a symmetric key shared by all interior
control nodes within a given TRACK hierarchy.  The key is
independent of any data stream, and is used to authenticate control
packets exchanged among the DRs/TN.  Should a child-DR request a
retransmission of a lost data packet from its parent-DR, then the
parent-DR will deliver the (encrypted) lost packet to the child-DR,
authenticated using the InteriorNodeKey.

Before the child-DR retransmits this lost data packet to its own
region, it must first authenticate the packet from the parent-DR
using the InteriorNodeKey.  It must then use its own SubgroupAuthKey
of the region headed/parented by that child-DR to provide
authentication for the retransmitted data packet. 


6. Limitations

The proposed security architecture has certain limitations.  These
include:

(a) Brute Force Attacks.  At the transport level, no admission controls
can be put in place to throttle a sender which is generating lots of
spurious packets to a multicast address.  This is the requirement of
the network level.  At the present time, no accepted standard exists
for doing so at the IP Multicast level.

(b) Key Corruption.  The recommended group key architecture makes a
careful tradeoff between the need to distribute many keys, and the
need to localize the effects of a node which is compromised. This
proposal allows a local receiver to perpetrate denial of service
attacks to its local DR, and the receivers served by that DR.

(c) Privacy.  In order to prevent network traffic analysis attacks, the
group keys can be used with IPsec to encrypt the packets sent to the
group, in addition to doing packet authentication.  However, it must
be recognized that this is not a general solution for data privacy. 
In particular, the group keys can easily be passed from a valid
receiver to an unauthorized receiver, to enable piracy of pay-per-
use services.  This is reasonable, as data privacy is not considered
part of the scope of TRACK protocols.

(d) Multicast IPsec.  Although currently IPsec is generally implemented
for pair-wise (one-to-one) communications between one sender and one
receiver, the design of IPsec itself allows for usage in IP
multicast.  Currently the Security Association (SA) definition
requires the Security Parameter Index (SPI) to be selected by the
receiver [KA98a].  However, since in IP multicast a group address
may be associated with multiple receivers, the existing method of
selecting the SPI must be re-interpreted.  Hence, in the context of
"Multicast IPsec", a pre-defined entity (e.g. the source, or the key
server/manager) must first create the Group-SA (including selecting
the SPI) and deliver the Group-SA to all the members of the group
(by either the "push" or "pull" paradigm).  Thus rather than being a
modification to the IPsec specification, this requirement simply
means that additional protocols are needed to establish a shared
Group-SA.  One possible approach for the Group Key Management (GKM)
protocol is to also deliver the Group-SA (and other keying material)
to the receiver at the same time it delivers the GroupDataKey
[HCM98].


7. Summary

In summary, in the current work we have proposed for TRACK protocols the
separation of data stream confidentiality using a symmetric key (i.e.
implicit group-authentication) from data authentication using a
symmetric key (i.e. explicit group-authentication). Data stream
confidentiality using a symmetric key will be conducted at the
application layer, while data authentication using a symmetric key will
be conducted at the network layer.  Since the DRs/TN may be (optionally)
prevented from reading the multicast data, two (2) different symmetric
keys must be deployed corresponding to the needs of data stream
confidentiality and data group-authentication.

This proposal follows a number of requirements, some of which are
specific to TRACK protocols.  The use of group-authentication at the
network layer is:
   - for protection of the transport and IP headers.
   - to allow a DR to authentically retransmit lost packets to
     a destination address (unicast or local multicast) different
     from the original multicast group address.
   - to allow a separate symmetric key encryption to be applied
     (at the application layer) in order prevent the DRs/TN from
     reading the data.

We assume encryption for confidentiality (using the GroupDataKey) has
been applied above the transport layer by the sender/source, in order to
prevent a DR/TN from decrypting the data.  The GroupDataKey is only
available to the group members, excluding the interior control nodes.

We propose the use of another key (GroupAuthKey) to provide group-
authentication from the source/sender at the network layer using
symmetric key cryptography.  The GroupAuthKey is known by the members of
the group, as well as the interior control nodes.

For the retransmission of lost packets to regions within a group, either
via unicast or local multicast, we propose the use of a SubgroupAuthKey
(instead of the GroupAuthKey) which is known only to entities within a
region (DR and its children). The SubgroupAuthKey is also used by the
entities in a region to group-authenticate control messages that are
exchanged with each other.


8. References

[HCM98] T. Hardjono, B. Cain and I. Monga, "Intra-Domain Group Key
Management Protocol", work in progress, draft-ietf-ipsec-intragkm-
00.txt, Nov 1998.

[HH99a] H. Harney and E. Harder, "Group Security Association Key
Management Protocol", work in progress, draft-harney-sparta-gsakmp-sec-
00.txt, May 1999.

[KCWP00] M. Kadansky, D. Chiu, J. Wesley, J. Provino.  "Tree-based
Reliable Multicast (TRAM)", work in progress, draft-kadansky-tram-
02.txt, January 2000.

[KA98a] S. Kent and R. Atkinson, "Security Architecture for the Internet
Protocol", IETF, RFC 1825, 1998.

[KA98b] S. Kent and R. Atkinson, "IP Authentication Header", work in
progress, Internet Draft, July 1998.

[MG98a] C. Madson, R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH",
work in progress, draft-ietf-ipsec-auth-hmac-md5-96-03.txt, Feb 1998

[MG98b] C. Madson, R Glenn, The Use of HMAC-SHA-1-96 within ESP and AH",
work in progress, "draft-ietf-ipsec-auth-hmac-sha1-96-03.txt, Feb, 1998.

[R92] R. Rivest, "MD5 Digest Algorithm", RFC1321, April 1992.

[RSA93]  RSA Laboratories, "PKCS#1: RSA Encryption Standard", Volume1.5,
No. 1993.

[WBPM98] B. Whetten, M. Basavaiah, S. Paul, T. Montgomery, "RMTP-II
Specification".  Work in progress, draft-whetten-rmtp-ii-00.txt, April
8, 1998.



--=====================_286204430==_.ALT-- >From owner-rmt@listserv.lbl.gov Tue Feb 15 15:39:48 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id PAA21877; Tue, 15 Feb 2000 15:36:46 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA21873 for ; Tue, 15 Feb 2000 15:36:44 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA24618 for ; Tue, 15 Feb 2000 15:36:43 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA24577 for ; Tue, 15 Feb 2000 15:36:38 -0800 (PST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (VWALL-IN-motgate2 2.0) with ESMTP id QAA11669 for ; Tue, 15 Feb 2000 16:36:35 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA29203 for ; Tue, 15 Feb 2000 16:36:29 -0700 (MST)] Received: from arc.corp.mot.com (t-il06-x-port9.corp.mot.com [129.188.170.119]) by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id KAA27954 for ; Wed, 16 Feb 2000 10:34:59 +1100 (EST) Message-ID: <38A9E54C.C5B94058@arc.corp.mot.com> Date: Wed, 16 Feb 2000 10:46:20 +1100 From: Roger Kermode Reply-To: Roger.Kermode@motorola.com Organization: Motorola X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: Thank you... Content-Type: multipart/mixed; boundary="------------F4B72D15639A2536D677AC53" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------F4B72D15639A2536D677AC53 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear RMT'ers, thank you all for contributing so much last Thursday. Your efforts were greatly appreciated. The minutes should be out shortly once I've received all the various bits from the scribes and glued them together. One reminder from now on could we please use the subject prefixes below for emails sent to the rmt-list. FEC TREE ALC NACK CONG_{SR,MR} TRACK GRA GUIDE e.g. Subject "TREE: Table of contents" Cheers, Roger --------------F4B72D15639A2536D677AC53 Content-Type: text/x-vcard; charset=us-ascii; name="rkermode.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Roger Kermode Content-Disposition: attachment; filename="rkermode.vcf" begin:vcard n:Kermode;Roger tel;cell:+61-408-212-284 tel;fax:+61-2-9666-0501 tel;home:+61-2-9664-8335 tel;work:+61-2-9666-0558 x-mozilla-html:FALSE -mozilla-cpt:;0;;; url:www.mot.com.au org:Motorola Australian Research Centre;Scalable Commodity Internet Lab version:2.1 email;internet:Roger.Kermode@motorola.com title:Principal Research Engineer adr;quoted-printable:;;PHYSICAL: Level 3, 12 Lord St., Botany, NSW=0D=0A= x-mozilla-cpt:;0 fn:Roger Kermode end:vcard --------------F4B72D15639A2536D677AC53-- >From owner-rmt@listserv.lbl.gov Wed Feb 16 01:40:02 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id BAA22622; Wed, 16 Feb 2000 01:39:36 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA22618 for ; Wed, 16 Feb 2000 01:39:33 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA09312 for ; Wed, 16 Feb 2000 01:39:32 -0800 (PST) Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA09308 for ; Wed, 16 Feb 2000 01:39:30 -0800 (PST) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id KAA69380; Wed, 16 Feb 2000 10:39:23 +0100 (CET) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200002160939.KAA69380@info.iet.unipi.it> Subject: pgm web page in place To: rm@mash.cs.berkeley.edu Date: Wed, 16 Feb 2000 10:39:23 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk [To: rm list, Bcc: rmt list] Just a brief note to inform you that i have put in place the web page containing with a TCP-friendly congestion-controlled PGM implementation (source code, a bootable PicoBSD floppy with lots of good stuff on it so you can actually run it, and a report describing the work). http://www.iet.unipi.it/~luigi/pgm.html cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- >From owner-rmt@listserv.lbl.gov Thu Feb 24 01:31:08 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id BAA23450; Thu, 24 Feb 2000 01:28:59 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA23446 for ; Thu, 24 Feb 2000 01:28:57 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA10879 for ; Thu, 24 Feb 2000 01:28:56 -0800 (PST) Received: from pi4.informatik.uni-mannheim.de (root@pi4.informatik.uni-mannheim.de [134.155.48.96]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA10869 for ; Thu, 24 Feb 2000 01:28:55 -0800 (PST) Received: from pi4.informatik.uni-mannheim.de (mauve@pi4 [134.155.48.96]) by pi4.informatik.uni-mannheim.de (8.9.3/8.9.3) with ESMTP id KAA20015; Thu, 24 Feb 2000 10:28:46 +0100 (MET) Message-ID: <38B4F9CE.17C28427@pi4.informatik.uni-mannheim.de> Date: Thu, 24 Feb 2000 10:28:46 +0100 From: Martin Mauve Organization: University of Mannheim X-Mailer: Mozilla 4.08 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: rem-conf@es.net, rmt@lbl.gov Subject: RTP/I Internet Draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Hi all, please excuse if this mail is slightly off topic. We have submitted an Internet Draft specifying a Real Time Application Level Protocol for Distributed Interactive Media (RTP/I). Here is the abstract of the RTP/I Internet Draft: This document specifies RTP/I, an application level real-time protocol for distributed interactive media. Typical examples of distributed interactive media are shared whiteboards, networked computer games and distributed virtual environments. RTP/I defines a standardized framing for the transmission of data and provides mechanisms that are universally needed for this media class. Thereby RTP/I enables the development of reusable functionality and generic services that can be employed for multiple distributed interactive media. Examples for this kind of functionality are the ability to record sessions, to support late coming participants, and to provide security services. RTP/I is a protocol that follows the ideas of application level framing and integrated layer processing. It has been designed to be independent of the underlying network and transport layers. To a large extend RTP/I has been inspired by the real-time transport protocol (RTP), which is used for continuous non-interactive media. This document is intended to stimulate the discussion on how to transport distributed interactive media over the Internet. There exists an RTP/I mailing list. Instructions on how to subscribe to this list can be found at the RTP/I homepage (http://www.informatik.uni-mannheim.de/informatik/pi4/projects/RTPI/index.html). Feedback on this document should be addressed to the RTP/I mailing list or directly to the authors. The RTP/I Internet Draft can be downloaded from the IETF directory or from our RTP/I homepage (see above for the URL). We would welcome any kind of feedback! cheers, Martin -- --------------------------------------------------------------------------- Martin Mauve University of Mannheim Praktische Informatik IV Phone: +49-621-181-2616 L 15,16 Fax : +49-621-181-2601 68131 Mannheim mauve@pi4.informatik.uni-mannheim.de Germany --------------------------------------------------------------------------- >From owner-rmt@listserv.lbl.gov Sun Mar 5 04:00:02 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA14487; Sun, 5 Mar 2000 03:58:00 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA14483 for ; Sun, 5 Mar 2000 03:57:57 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA02865 for ; Sun, 5 Mar 2000 03:57:56 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA02860 for ; Sun, 5 Mar 2000 03:57:55 -0800 (PST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id EAA21434 for ; Sun, 5 Mar 2000 04:57:54 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id EAA17112 for ; Sun, 5 Mar 2000 04:57:46 -0700 (MST)] Received: from motorola.com ([217.2.31.248]) by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id WAA12101 for ; Sun, 5 Mar 2000 22:54:47 +1100 (EST) Message-ID: <38C24AE1.C9C83844@motorola.com> Date: Sun, 05 Mar 2000 22:54:11 +1100 From: Roger Kermode X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: RMT Meeting Feb 10, minutes draft Content-Type: multipart/mixed; boundary="------------12DAB1FB4EB5F784B0A83607" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------12DAB1FB4EB5F784B0A83607 Content-Type: multipart/alternative; boundary="------------83EEF7F1661A5FD3901798F2" --------------83EEF7F1661A5FD3901798F2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear RMT'ers, First of all please accept my apologies for the tardiness in sending out these minutes/notes. Much thanks must go to Sally Floyd and Bob Quinn for taking them during the meeting Please take a moment to puruse them and point out any errors. thanks! Roger ------------------------------------------------------------ RMT Interim Working Group Meeting Feb 10, 2000 Minutes ----------------------------- Attendees Initials/Name/Interest MH Mark Handley CC, NACK SF Sally Floyd CC DC Dah Ming Chiu ACK, TREE, CC SK Shivkumar Kalyanaraman CC LR Lars Rasmussen ALC BQ Bob Quinn all aspects CB Carsten Borman NACK (and the rest) VO Volkan Ozdemir CC YY Yung Yi CC DA Deb Agarwal all aspects BL Brian Levine tree building, yoga (!) SB Supratek Bhattacharyya tree building IR Injong Rhee CC AC Adam Costello GRA, tree building ML Michael Luby ALC, FEC, CC BLu Bruce Lueckenhoff ALC CP Christos Papadolulos GRA, tree building JM Joe Macker NACK, ALC BA Brian Adamson NACK, ALC TH Thomas Hardjono Security HR Hayder Radha CC/ALC BW Brian Whetten track, CC JG Jim Gemmell ALC, FEC, NACK BC Brad Cain GRA, Tree building TO Tokuop Oishi GR Gursel Taskale all RK Roger Kermode all LV Lorenzo Vicisano all ---------------------------------------------------- Interim Reliable Multicast Transport Working Group Feb. 10 2000, ACIRI, Berkeley CA. [RK: thanks to Sally Floyd] Several people are late, because highway 880 was closed for a while. There is a SMUG (Secure Multicast Research Group) meeting here tomorrow. Intro by Roger: [Add a pointer to Roger's viewgraphs.] Goals of meeting, Overview of agenda. Call to Arms: Building-Block and Design Space drafts are waiting for review by Mark. Mike: Are we on-schedule with the goals listed in our charter? Roger: We are behind schedule. The group will standardize building block and protocol instantiation documents. The Guidelines draft: [Add a pointer to Roger's viewgraphs.] What is missing from here? Mike: What about revision control between the PI (Protocol Instantiation) and the BB (Building Blocks) documents? Do they cross-reference each other? This comes to the API issue: what parts of the BB documents are referenced by the PI documents? The BBs have, not an API, but a higher-level interface description. NACK: There is a BB and a PI. How does this work? Answer: The BB has the more general stuff. And a NACK PI might also use ACK-based stuff. Jim: Can we do an example, with PGM? BBs should discuss design tradeoffs. Building blocks might be more applicable than just bulk transfer, though that is our immediate focus. Mike: There is a danger of designing a BB without a PI in mind. Maybe each PI should write its BBs, and then come together. Mark, Sally: For NACK and TRACK, it is clear that there is a CC (Congestion Control) BB that can be broken out now, in parallel. For ALC, there might not be as many BBs that can be broken out now. FEC is a building block that can be taken out of ALC now. What will go in the NACK BB? Mike: Maybe the BB role can be more informational. >From SMUG: BBs are coarse-grained, and might need more fine-grained components within them. Mark: BBs should not include all possible options, but should narrow down the design space. A call for BBs and PIs to start with overviews first, not the nitty-gritty details. Out of today, perhaps we can end up with overviews of each of the BBs. ------------------------------------------------------ Congestion Control: Mark: TFRC, Unicast TCP-Friendly Rate Control [Add a pointer to Mark's viewgraphs.] Pointer to paper: "http://www.aciri.org/tfrc/". The talk shows results from experiments and simulations with TFRC. For unicast, the performance is very good. Question: Simulations with TFRC: in simulations, TFRC tends to drop to zero with many flows, very high bandwidth? Mark didn't see this, will look at it later. Oscillations from smoothing the roundtrip time, and sending at 1/RTT: For unicast TFRC, we added RTT-based Congestion Avoidance. This is needed more for Drop-Tail than for RED queues, or for high levels of statistical multiplexing. Issues for multicast: timely feedback, measuring RTT. Question: Does this apply to non-sender-based congestion control? Mike Luby: The work on CC for ALC is not finalized. It is interesting to see if sender-based TFRC schemes will apply to receiver-based ALC. VRC: [Viziano, Rizzo, Crowcroft], the RLC protocol. Receivers join a layer and all lower-bandwidth layers. Each layer has twice the bandwidth of the previous layer. Join times are quick, and leave times might now be quick also. In his opinion, the RLC approach has more power than the single-source approach. For TCP-friendly issues, how does the RTT get taken into account? Mark: In small levels of stat mux, increasing the sending rate can dramatically increase the packet drop rate. This is not the case with large-scale stat mux. Mike: There is a lot of interesting work to be done. Remark: Fine-grained video coding is the coming thing. Roger: Is the discussion leading to BBs? Are we going into too much detail? Brian: We have a TRACK architecture overview, that shows how BBs fit together. TEAR: Similar to a TFRC building block. Differs in how to measure a fair TCP throughput. TEAR differs from TFRC in the receiver. Instead of using the TCP-friendly equation, TEAR emulates TCP at the receiver. Takes a weighted average of eight TCP congestion control rounds. TEAR trys to give a more accurate model of TCP. Mark: TEAR is sensitive to the pattern of losses. And they differ in the modeling of retransmit timeouts. Shiv Kalyanaraman: Generic source-based multicast congestion control. [Get a pointer to viewgraphs.] This is sender-based congestion control. No measurement support from the receiver set, except for NACKS or ACKS that are already there. No aggregation support expected in the tree. Congestion periods are broken into congestion epochs, which is a period with a single rate reduction, with time for the rate-reduction to diffuse to the congested sub-tree. Mark: He is assuming a very low level of stat mux? He is assuming that if the sending rate is increased, the packet loss rate increases also? The protocol mimics TCP at every point. They have implemented this in NS, and they have a PGM implementation. ---------------------------------------------- ----------------------------------- RMT Interim Working Group Meeting -- Draft Minutes -- [ RK: thanks to Bob Quinn] Feb 10, /2000 - Hosted by Aciri at ICSI in Berkeley, CA ----------------------------------- Roger Kermode, RMT working group co-chair, started the meeting at AM with 18 people present (we had 28 by 11AM) with a review of the agenda. Tentative Agenda --------------------------------- 09:00 - 09:10 10 mins Agenda Bashing [Roger] 09:10 - 09:10 10 mins WG status update bb + ds drafts Recharter 09:10 - 09:20 10 mins Call to arms/editorship selection update [Roger] 09:20 - 09:40 40 mins Guidelines Draft Update/Discussion [Roger/Lorenzo/Allison] 10 mins draft outline 30 mins discussion 10:00 - 11:20 1hr20mins Congestion Control: [Handley/Flloyd?] 10 mins TFMCC update [Handley/Flloyd] 10 mins ALC implications for CC [Luby] 10 mins TEAR implications for CC [Rhee] 10 mins Generic source-based multicast CC [Kalyanaraman] 40 mins discussion 11:20 - 12:20 1hr NACK: [Bormann & Adamson?] 10 mins BB Update [Borman] 20 mins BB Discussion 10 mins PI Update [Adamson] 20 mins PI Discusion 12:20 - 13:00 1hr Lunch 13:00 - 14:00 1hr Asynchronous Layered Coding: [Luby] 10 mins BB update 10 mins Gemmell? 40 mins discussion 14:00 - 14:30 1hr Tree-Building: [??] 10 mins table of contents update [Chiu] 20 mins discussion 14:30 - 16:00 1hr TRACK progress [Whetten/Chiu] 10 mins [Whetten] 10 mins [Chiu] 40 mins Discussion 16:00 - 16:45 45 mins VACANT 16:45 - 17:00 15 mins Agenda bashing for Adelaide RMT has been rechartered and the new charter--now approved by IESG--is in place on the RMT working group webpage. http://www.ietf.org/html.charters/rmt-charter.html Mark Handley showed the new charter as it appears on the RMT working group webpage. Roger provided status for the existing documents. The charter is agressive and we are a bit behind at this point. Many of the documents are essentially done (though most are not issued as Internet Drafts (I-D). Generic Router Assist (GRA) is the only exception. The Multicast Congestion Control document is due for Apri--after Addelaide--and it is acknowledged as the most difficult problem, and the one that gates all others. Mike Luby asked whether we expect to be doing work on both the BBs or the instantiations, and Roger said, "Yes, both." The Building Block (BB) Guidelines draft has been stalled. That is likely a source of confusion, since many people may not know how to proceed with creating a BB I-D without it. The idea behind the BB is tp create some framework definitions for Reliable multicast transport (RMT) that exist for Real-Time Protocol (RTP) format. Goal: to help people write Building Block (BB) and Protocol Instantiation (PI) drafts - How BBs and PIs fit together - Sections to be included: + applicatiblity statement = where to use and where NOT to use = known failure modes + BB: = bunctional description = abstract API for use by other BBs + PI (protocol instantiation): = core functionality not in BBs = which BBs are used = how they fit together = packet formats Mark Handley and Sally Floyd (MH and SF): PI needs to be specific about the application targets - the PI *may* have some mechanisms that BB doesn't (but not all will) Joe Macker (JM): The BB should describe the trade-offs MH: Some BBs will be more generic as far as being applicable to bulk file transfer alone, and others will not. Mike Luby (ML): doing the BB first and the PI second seems backwards. It would be better to do the PI, then try to derive the commonalities that represent the BB. MH: We alread have a lot of existing protocols that we understand very well. ML: But are these written down? Roger Kermode (RK): Our hope is that people that have the experience with specific protocols need to exchange their experiences. ML: But again, it is written down? MH: We may well do some back-tracking after the fact, but we expect that. ML: I think it is important to do the PI first and write it down. MH: I think that ALC may be one where that is true ML: Why is that? SF: Because there are lots of TRACK and NACK based protocols for which we understand the commonalities so it makes a lot of sense to do the BBs in parallel with PIs. Jim Gemmel (JG): I'm fuzzy about what goes into a BB, is it going to simply say what NAK does or list many different ways it could work. MH: I think that NAK will have suppression mechanisms built into it. JG: Are you going to list the mechanisms/algorithms? MH: We need to pick one and describe it. JG: But there are so many ML: You pick one and it may not be appropriate in all cases. Thomas Hardjono (TH): In SMuG we have picked a number of them RK: We are obviously still struggling with what a BB is, so I tend to agree with Mike that we should concentrate on a PI first. ??: I thought that the BB was supposed to describe what we recommend with Interet health as the focus. SF: It is a good idea to have things that refer to Internet health, but we already have RFC 2357 (?) that describes the requirements for any RM transport. RK: I think we are approaching some concensus. JG: Go write one and lets take a look at it ??: Suggested that we have an overview and functionality description for each BB *first* then move into the other details --- TFRC - TCP-Freindly rate control Mark Handley (Equation based congestion control) - we thought we understood this (for unicast) a year ago, but we did not and we don't know multicast yet. Scripts and paper all available at http://www.aciri.org/tfrc It is fair to TCP in general, although we have seen TCP get beat up because it was too bursty Key measures are loss fraction and round trip time Measuring round trip time, there are oscillations in TCP and with multicast the delays between these is longer. To dampen oscillations but still gain RTT-based congestion avoideance behavior, need inverse dependence on RTT but lower gain. <> The result of this is a smoothing of the oscilllations. - If you fix the RTT time, you get the oscillations, but if you don't (as described above) then they are smoothed. - we've tried these things with a wide variety of Queuing congestion control mechmanisms, and it works well with all (though having RED reduces the need for this mechansism). Issues for Multicast - how to ensure timely feeback? Delay reporting loss event fraction may affect dynamics - How to measure RTT to all receivers quickly? Not a showstopper, but may affect how CCC fits together with other components - RTT-based Congestion Avoidance is difficult (referring to the algorithm described above): It is not clear that this is necessary, but the consequences of not doing it are not yet fully understood. ??: What is the traffic load for reporting congestion control? MH: You really want your NACK or ACK trafffic to report it, and with aggregation points (TRACK or other local/shared recovery points) you have additional delay. None of this applies to ALC though, of course (since it is one-way). ML: Yes, but reading through your paper I got the impression that a lot of it is based on the receiver, so it could well be applicable. ML: If you actually did an experiment with two TCPs then they would not be fair to each other. The one that has longer timeout (say 10 times) would be 100 times more loss. SF: I don't believe that loss rate would be 10 times more Brian Whetten (BW): I don't beleive it would be, either. JM: What about slow-start mechanism for multicast? MH: We may not need one for multicast since the advantage of having one is not clear yet. ---- Asynchronous Layered Coding (ALC) BB Mike Luby The work on ALC CC is not finalized yet, though there has been some great work done so far. - thing about ALC is that you can have different receivers receiving at different rates (determined by the number of groups they have joined, and streams they are receiving in parallel) and we need to take advantage of it. - VRC (authors Lorenzo V. , R. and Crowcroft mechanism is used for this (also referred to as RLC for author names also ...for some unknown reason). - Synchronization points happen more often at the lower layers than at the upper layers. Layers are cumulative. It is now a very course-grained CC, and we should make it more fine-grained (more fine-grained than the synch points can provide). Current one gives a linear increase. SF: A factor involved with whether you couild ramp up send rater slowly is whether you have either small or large-scale statistical multiplexing. Hayder Radha (HR): ALC sounds much like MPEg-4, which provides fine-grained scalability and uses many different multicast groups (roughly 10-20). -- Short talk on TEAR Rhee - TFRC uses equations looking at 8 loss events that have occurred and is based on what it finds from the sender, whereas TEAR emulates TCP within the receiver and how. MH: TEAR is sensitive to the pattern of losses (which may be good or bad) and sensitive to the timeouts. -- Generic Source-Based Mcast Congewstion Control Shivkumar Kalyanaraman (RPI) <> - implosion control needed - need timing info on Sender & Reciever (may need GPS at receivers) - Need to know the (S,G) state "Generic" means - completely implemented at the source - no measurement support from receivers - no extra contol traffic inserted - no extra fields - no aggregation support expected - should work with NAKs, HACKs, ACKs, bit maps or other reverse traffic which provides congestion and timing information Weak requirements on RTT & loss estimation: - suppress NAKs from long RTTs (partial timing info) Basic idea is that they devide congestion time periods into "epochs" where the source reduces the send rate exactly once and enough time is given for rate-reduction to diffuse throughout the congested sub-tree. They do not depend on the loss rate. They have implemented it in their version of PGM. MH: Seems like you are not depending on having large-scale statistical multiplexing rate and that assumes that the competing flows are doing the same thing, which is a flawed assumption. -- Brian Whetten said he has done a description of how the BBs fit together from the perspective of TRACK.* reliability ====== short break ====== RK: This is a new process we've been doing with the BB approach, so we need to describe it in more detail. Boorman: The BB needs to be normative, we need to have it as something that people can reference as opposed to something that is not BW: It should have exact algorithms and abstract APIs SF: BBs need to describe design tradeoffs required for Application- specific variations (e.g. optional feedback). Single Rate CC BB Team: Mark H (leader), Sally F., Injong, Brian W., Shiv, Supratek, Hursel, Joe Macker, Brian A. MultiRate CC BB Team: Mike L (leader), Lorenzo, Hayder, Injong, Jim Gemmel, Luigi Rizzo, Jon Crowcroft ??: I come from a satellite company and I'd like to see some satellite-specific considerations described. RK: We deal with the Big 'I' Internet and this includes the satellite media, so it is included implicitly. MH: It looks like Single Source multicast (e.g. PIM Source Only) will have an earlier deployment than others so it is likely that we will have one-way links as well as two-way, so in that context satellite is not that special despite the fact it has a long fat pipe (long delay and high bandwidth capacity). RK: Can we have a document by Adelaide on Single Rate, Mark? MH: Yes, we can have a *start* on a document. We need at least a first pass of *every* building block by that time. RK: The due date for drafts is March 10 and we should really strive to have something done by this time. MH: We should also submit the names to the RFC editor beforehand so it doesn't get delayed (we should do this on the mailing list). RK: Ok, will do. MH: Should we have discussions in sub-groups or on the main RMT mailing list. <> <> CC Building Block Guidelines ----------------------------- Must be normative - exact specific algorithms and abstract APIs Discussions of tradeoffs - application specific variations (e.g. optional feedback). Cover design space. Purpose: RFC 2357 and Sally Floyd's Congestion Control Principles draft, see http://www.aciri.org/floyd/papers/draft-floyd-cong-01.txt + 2 parts: = Mandatory to satisfy IESG reqs = Application specific Requirements for other BBs: - what messages can be piggy-backed (existing BB msgs and additional msgs) . - loss detection - RTT measurement Two Separate BBs: -> single source (e.g., PIM-SO) -> Others (single rate) - satellite, asymmetric, wireless, GRA Considerations target scale (in terms of number of receivers). <> --- How TRACK fits with other BBs Brian Whetten (( his view of what needs to go into BBs )) Goals - functional decomposition across other BBs - sees TRACK as a superset of NACK Exponential back-off on loss detection Unicast NACK generation - issue: NACK needs multicast NACKS? response to retransmission request GRA signaling Integration with TRACK hierarchy - how do you do this well SF: Why is this included here? BW: We repeat it in both places Question: Since it is a superset of NACK, why have a separate BB? BW: Interesting thought. MH: We need to do suppression so the question is how to do it. You can do it by a tree or not, so the discussion needs to talk about it with that focus MH: One thing missing here is how it interacts with and uses FEC. Lorenzo Vicanso (LV): Yes, FEC is very mixed with suppression. MH: FEC itself is not in there, but a description of its functionality is. ??: Why do you call it NACK when it should really be a generic feedback mechanism? BW: We have differentiated the feedback (for CC) and the NACK for data loss and the TRACK since it has to deal with hierarchy. Brad Cain: What do you think the biggest issue is? BW: The issue of how and when you deal with the NACKs. FEC BB: - input of a (sub) window of data packets + issue: packet nameing - creating parity packet + issue: exhaustion of parity packets + proactive parity (which block owns it)? - flush data stream with only a small sub-window - FEC decode - Bind to different codecs LV: It seems that some of these issues (like flush) belong in the protocol instantiation. BW: This is a highlight of the functions and not specifications of what they are doing ML: I would just talk about the protocol and not how it will work in all protocol instantiations. That cannot work. RK: The model to look at for this framework is RTP, where there is enough generality to allow a common, versatile framework. LV: You need an API for making state available ML: There is a way to describe FECs in general without going into detail with exactly how to use them. ??: This has actually been done in the AVT RFCs that deal with codecs (may still be I-Ds at this point). They may not be exact, but it is a good thing to start with. LV: You can define blocks and when you can reveal the blocks and deal with them. TFMCC BB: - Initialization - Receiver measuraments + issue: RTT measurements - Receiver feedback (on TRACK/NACK) + Issue: how to bias NACK timers? - hierarchical aggregation - sender rate control MH: There's no requirement for interoperability until you get into a PI. The packet formats are defined in terms of funcionatlity rather than generically as "feedback" to be efficient in terms of size used. GRA BB (draft-ietf-rmt-gra-arch-00.txt): - Core, simple router functionality + issue: how to instantiate this? - signaling guidelines - NACK Brad Cain (co-author): we will have a separate document that will include feedback mechanism defined and we will define packet format. It will be incrementally deployable (as spec already says). We will be dealing with server-to-server traffic, which is the auto-tree configuration. Auto-Tree Configuration BB: - Discover hierarchy that matches the multicast topology - works in all environments - provides children with an address list of candidates + if/when first fails you go to second one BC: You need to discover namers, create hierarchy (some sort of routing protocols where you abstract away who is closest to the root). JM: Is this going to be a routing-ish shared tree? BC: We are not doing that level of detail ...we are not creating PIM over a mesh. Once you abstract away what a possible root could be (source, RP, etc.), then there has to be a route from whatever it is. Then that has to be...??? I wouldn't touch that one with a ten-foot pole. There will be packets between servers, and there will need to be a way to measure distance between server to source and you can do that LOTS of different ways. You need to know what the metric means. BW: Yes, I agree that the problem is not yet well defined ====== lunch break ====== << Brian Whetten, on TRACK BB Requirements, continued >> Common Packet Headers - Data Naming + sequence number, FEC offset + issues: Add object ID? Need sequential packet numbering. Need to support application level multicast - Session naming + stream ID + TRACK may need a Tree ID - Also issues with Application Level Framing (Talarian, TIBCO and FastForward are three examples), since you are multiplexing at a different level MH: There seems to be three sequence spaces: - packets within FEC block - FEC blocks themselves - Object ID itself You might be able to build over to create frames over that, but it must be at the object level to get reliability. I think it might be worthwhile to go down this path to see what comes out, what meta-information we need. BW: The other consideration that is important is the number of bits we add to support this. MH: My view on bits is don't worry about it, since it is only on low-bandwidth links that it is a concern Security BB - Really SMuG's area and our area - Transports only job is to protect itself - Interface to key managerment is what we need - IPSec for lightweight version TRACK functions - hierarchy creation and maintenance + join, leave, falure recovery, keepalives + local multicast groups for control, retransmission - parameter initializeation/distribution + server and tree-wide - source ordered, unordered, time bounded (?) - network management JM: Is there a new security consideration for ACK Aggregation TH: At last IETF I talked about a mechanism whereby an intermediate point that received a NACK would have to forward them upstream for signing (so intermediate point does not need to be a trusted participant). Authentication and trust models are the issues. LV: The NACK authentication is an end-to-end issue TH: Yes, but NACKS are from routers BW: Routers don't issue NACKs, however. Routers create the tree (for TRACK). MH: Tree-based protocols help you to generate round trip times. TRACK Issues - Kill TN and Aggregators? + shared tree versus per-source tree? - Can we have dynamic DR/receivers - Multicast address sharing BW: Is top of the tree always co-located with the sender? MH: There are lots of different ways to build trees BW: You can have multiple data sources for a single tree BC: It would be good if anyone desiging NACKs talk to him and BL about how to define them for each of the BB type (e.g. NACK, TRACK, ALC), specifically in terms of application interface and packet formats. ====== We then had break-out meetings for separate sub-groups: "ALC", ""NACK," and "Tree Building" (in quotes since these are very loosely defined). Here are the topics discussed: "ALC": - FEC - PI for ALC - Congestion Control "NACK": - PI versus BB - NACK - Congestion Control "Tree Building" - Auto Tree config ========= Wrap Up ========= Roger Kermode on Auto-Tree Creation BB discussion: - Preconfigured solution + assumes the existence of a mesh of delivery servers (which may be statically configured or dynamically generated): + requires existing infrastructure on internal nodes - Ad hoc solution + does not require predeployment + assumes mesh discovery protocol + no GRA + no TTL scoping (needs to support PIM_SO) + no static config info in hosts MH: Do you have any reference implementations for these models? I'd like to see some running code. Mike Luby on ALC: - we had lots of concensus and progress - We also took on the FEC BB TRACK: - what identifies a source or a receiver? NACK: - We also discussed FEC a lot too since it is tied in Rather than having different mailing lists for each subgroup, Roger proposed that everything go to RMT and we preface subjects with what the topic is relevant to (and add "PI" as a suffix if that's the topic) FEC, TREE, ALC, NACK, CONG_{SR | MR}, TRACK, GRA, or GUIDE. He will send a message to the RMT mailing list describing this. <> ========================================= Notes from TRACK sub-group Discussions RMT Working Group Meeting 2/6/00 ========================================= blame bob quinn for any innaccuracies Motivation for creating a tree - Good for error control and congestion control - Distributed aggregation (caching hierarchies, e.g., for use in a Content Distribution Network (CDN)) - Anycast - Security, group key management - Distributed gaming/simulations All have similar requirements Why is it useful? 1) hierarchical construction assists with load balancing 2) topologically aware aggregation 3) topologically aware subcasting First is sufficient (2nd and 3rd are efficient). Why by aware of topography? - topologically based structures have dramatic performance benefits + localized aggregation + subcasts that are focused towards downstream logical descendants + allow use of subcast, period. + ensures reduced latency between pairs Applications - local aggregation + error, congestion control, CDN, security - focused subcasts + error, congestion, security - reduced latency between pairs + gaming, anycast BW: So is the goal topological congruency? Brian Levine (BL): Yes BW: Would anyone debate that? BL: yes. You can't do it now without difficulty, but that does not mean it is not something we should *try* to do. BC: That is something we should strive for. BW: There are some that would say it is better for error control BL: I don't agree with that BW: I just want to talk about it since it is relevant to asymmetric routing, among other thigns. BC: That is a really tricky issue and the other reason is inter-domain BW: Exactly, which is why single-AS is going to rule BC: Exactly. BW: Should we scope it to a single domain? "Easy" way to do topo-aware - use GRA!! - Source periodically multicast packets with GRA and router alert (MD5 Auth) + They go down the tree from a parent + I'm assuming we are doing Express mode stuff - GRA routers with their IP address in the payload of the packet (perhaps both in and out interfaces ...?) + Each hop adds as packet traverses + As there are more routers, you get a better idea - Receivers subcast from last revised router announcing their path strings - Receivers pick parents, send unicast to confirm - Or...new mtrace messages (added by Brad Cain) + This would trace down the tree (though we have not yet figured out the format ...though many don't like mtrace since it gathers statistics, has latency and adds overhead) ??: There was a guy at MCast2000 who said that the hyperqueue could build a tree very quickly BC: There is part of this that people can use to do other tricky things. For example how do you find out how close you are to a source or an intermediate routers and there are lots of ways to do it. Two problems with finding a metric that's good: congruency and how best to announce to the group Breaking Up the Problem: - Neighbor Discovery - routing-like protocol + who is closest to the "source" (for mcast) + who is closest to other point (e.g. server) - How to find distance to server or seoruce? - How to make it generic? + can we do it for others than reliable multicast, such as the content delivery people. - Fault tolerance BC: Looking at a graph or mesh of servers and over the top of that there is some sort of protocol that you use to build a hierarchy in the server to server protocol itself. To do so you need to have some sort of metric, such as who is closest to data source or RP. You discover a set of neighbors within a scope (that's how the mesh is built), then over that mesh you establish the tree. BW: That is basically what we are looking at but that could be a heavy weight protocol. BC: You can statically configure the mesh (which will most often be the case anyway ...that's the way these content distribution network guys are doing already). RK: We have to be able to exist where GRA doesn't already exist. BL: If we didn't bring up topological awareness then we woudln't have any issue with non-GRA implementations. We are being passed-by and need to do *something*: - companies can do non-topo aware without us, though standards are nice - eventually they *will* do topo-aware without us - As IETF'ers we should make recommendations BW: The barriers to getting GRA into all the routing infrastructure is so high that from a practical standpoint we should be able to use it without GRA. BL: I think it will take 3 years to get GRA widely available BW: I think that is really wishful, which is why we should think about new mtrace messages. BC: The mtrace command needs access control (password, maybe?) since it reveals the tree which can be very dangerous. RK: If you are going to use mtrace, think about a network with 10000 nodes BC: MTrace would not scale to that many receivers BC: you can try to match receivers with nearest server or make tree closest to source. The content delivery is focused on making caches close by to receivers. ??: Seems a question of how tall you want to make the tree with respect to how much fan-out there is (the optimality of the tree). BC: Yes, that all relates to how you build the tree Miriam Kadansky did a doc that relates to requirements BL referenced this and created slides from the TOC. Dah Ming (DM): How the the tree is formed and then used. This was a strawman for generating discussions. We have lots of information about tree optimization and maintenance as well as tree building and what I'd like to see is a discussion of how much of this belongs in the BB. BW: I think only the building of the tree is important. BC: I think there should be two layers: a base layer that can be useful for a lot of things and the second that is specific to reliable multicast. RK: Auto-Tree Requirements (RM specific) -------------------------- 1) Aggregation of things like ACKs, NACKS, congestion control 2) Subcasting - parent to child unicast (application level) - parent to all descendents local multicast group - parent to child (GRA) 3) Others (non-RM specific) - group membership - list of GRA-capable routers - billing RK: It has to be spelled-out in the draft what is RM-specific and what is not. TH: Some mechanisms used to design the tree are exactly the same that is needed to deliver some of the services that the tree is supposed to support. BW: So, for example, you could use subcast to do auto tree configuration. TH: Good examplee BW: Goals: - Perfect topology congruence - failing that, do something not stupid - list of parents BC: Where does the metric fit in? How do you determine a "perfect tree?" What does the API give you? BW: These are the list of parents and the metric(s). There are other interactions to prevent loops (for example). We may be able to pick one metric. BL: we should have one metric in mind. BC: There are a number of different possibilities. RK: You are building a tree to do what, connect sources with receivers or with end-points?? DM: The DR could be either the source or the distribution head. BW: The head of the tree is always the source BC: the problem is that if you are given just a list of neighbors and metrics, then you could construct a tree that has loops. BW: I was assuming it was at least an ordered list so there are no loops. BL: you can always override this, so we must assume that it has no loops. Congurence is the goal and besides, it is not even a tree if it has loops. DM: There are diffferent ways to make sure you don't have a loop, BW: Yes, but if you just know the depth of the tree then this is enough information to create a non-looped system. DH: That implies the tree is built top-down BW: The issue comes down to work BC: right. BW: Who has to do the job BC: The loop protection depends on what info is exchnaged between nodes. Requirements (according to BW) - Universally deployable + multi-AS + All multicast routing + GRA - Safe - Receiver auto-config + e.g. receivers can find their nearest server - Keep it Simple BC: I think the receiver auto-config is DONE: DNS (though Anycast or a web-page or other out-of-band mechanism could be used also) BW: I am just defining high-level requirements without considering solutions BC: We need to be able to "prune protocols" (to quote Steve Deering) to make it simple BC: Do we want to get into Policy metrics when considering inter-AS (inter-domain)? BW: I really don't think we want to go there. BC: All protocols are source based now BW: Huh? Applications don't have a way to specify the source. ??: the tree building protocol is running all the time? BW: Yes, so you can ask anytime for what parents are RK: It sounds like you are trying to punt things away, so if it does not get done here where does it get done? BW: In TRACK BC: We still need to determine the line between TRACK and here. BW: The issue is that keep-alives, HACK packets, get generated. It is control path versus data path issue. RK: I like that separation between control and data paths. This document should be sufficient to create a control path and that control path is used to deliver data. BW: There is realistic three peices here: all error packets are part of data. We want auto-tree config information. BC: I agree they are separate, but think there is anough commonality to keep them together. BW: I am abstracting out configuration information for control RK: Can we separate out like: - Ctrl path: tree creation and maintainenace - Data path: "repair" PI specific control << short diversion into discussing whether it is possible to create a generic BB or whether we have to start with a PI ...the challenge being whether we can have something generic without getting into protocol details >> BC: You can do something really simple, but if it is going to be that minimal, there is some question about whether it is useful. TH: It has to work, so it can't be that thin. The thing is that to be useful, we need to agree on some common elements. BW: I think the NACK BB is going to be very short (deal with retry timer and action) and I suspect that we can make this Tree Building BB just as small. BC: CDN people want all these things. I don't know where the line is between generic BB and PI. ??: There are two main things: discovery and maintenance. DM: Yes, but it is more complex since there are different scenarios (e.g. late joins). RK: Tree "functions" - Discovery: learning *possible* parents (manually or auto) - Construction: Joining the tree + BC: e.g. applying Dijkstra and creating link-state - Maintenance: Fail over, leaving - Service Hooks (sub-cast, aggregation, etc.) BW: Problem is you can't discover parents without considering where the source is. BC: What is the signal for generating a tree, is it that a receiver joined or that a source is there? BW: I would say when receiver joins BC: I would agree with that RK: Discovery: - who starts the process? + source: top-down tree generation + receiver: bottom up tree generation BW: The way the world actually works is you have a collection of Sources, a collection of potential DR's (intermediates) and receivers (he illustrated on board with three layers). BC: We are not dealing with the receivers to servers in this tree building (which is a server location problem ...and we can safely assume that DNS solves this). Most of the time the configuration of the mesh of intermediates is statically configured (99% of the time) ...call it "the Mesh." At this point there are NO TREES yet (an important point), so there's no concept of loops at this point since nothing is source specific. BW: Mesh: 1) neighbor disovery 2) senders announce 3) receivers initiate join BC: Alternately, the source finds a server DM: Yes, there may be many servers that are not relevant to a source BC: Ok, yes, so let's assume that the source does NOT announce to the servers. We already know how to do this and it's called multicast routing (using PIM). It requires that each server knows the metric distance to the source(s). BW: Ok, so we're done! We will just run another routing protocol (along with the one below us at the IP layer that we cannot access and the one that may be above at the application level). ??: Ok, this assumes that there is a mesh, but what if we don't assume this? BC: I disagree, since if you look at anything on the net it is formed as a mesh and there are a lot of administrative issues about who can talk to who. Lots of discussion/debate about whether we can assume that the mesh is avilable as preconfigured infrastructure. To do auto configuration we cannot assume many-to-many SRM-like discovery. Dah Ming and BL agreed that having the intermediate mesh assumed makes having the receivers going directly to senders impossible (e.g. so the receivers can organize into a tree without having an intermediate layer). BL: Could send from source with IP list, as I described earlier. DM: Yes. BC: Ok, if source sends magic packet then each receiver picks a receiving parent. DM: Yes. This should be allowed and the static intermediate layer could be optional. BL: Yes, and then any intermediate node can declare that they don't want to be part of the tree. -> Some disagreement about which of the two models should be the primary requirement. RK: My dream protocol that I want - Doesn't require GRA (but be compatible with GRA) - Doesn't use TTL scoping - Needs to work in PIM source only (PIM-SO) - Doesn't require config info in hosts - Doesn't require statically deployed mesh BC: You may want to determine your tree with metrics other than hops (e.g., server load, geographic location, etc.). BL (and others): the one where receivers can be DRs makes the static mesh possible, but the converse is NOT true. BC: I disagree. Since not all receivers can send, it becomes an access control issue that assumes many-to-many multicast is possible. Summary of differences between the two models: > Dynamic Discovery version sends a probe from the source and each *logical* hop adds its addres and the metric you end up using is a router-like distance metric that uses the number of hops. In that model also, any receiver can (potentially) be a repair node, which Brad and BW both say is not realistic since that assumes many-to-many (like SRM) and that is simply not available in the real world. In this model only the members in the mesh can be repair nodes. Brad pointed out that this is how all of the CDN folk do things. > Other version assumes the creation/existence of a mesh which can use *any* number of different metrics for distance (not just a router-like "number of hops", which would have to count virtual hops, since it counts servers rather than routers). The first model can co-exist with the second, but the first cannot exist if the existence of the mesh in the first is assumed. <> --------------83EEF7F1661A5FD3901798F2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear RMT'ers,

First of all please accept my apologies for the tardiness
in sending out these minutes/notes. Much thanks must go to
Sally Floyd and Bob Quinn for taking them during the meeting
Please take a moment to puruse them and point out any errors.

thanks!

Roger
 

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

RMT Interim Working Group Meeting Feb 10, 2000
Minutes
-----------------------------

Attendees

Initials/Name/Interest
MH  Mark Handley            CC, NACK
SF  Sally Floyd             CC
DC  Dah Ming Chiu           ACK, TREE, CC
SK  Shivkumar Kalyanaraman  CC
LR  Lars Rasmussen          ALC
BQ  Bob Quinn               all aspects
CB  Carsten Borman          NACK (and the rest)
VO  Volkan Ozdemir          CC
YY  Yung Yi                 CC
DA  Deb Agarwal             all aspects
BL  Brian Levine            tree building, yoga (!)
SB  Supratek Bhattacharyya  tree building
IR  Injong Rhee             CC
AC  Adam Costello           GRA, tree building
ML  Michael Luby            ALC, FEC, CC
BLu Bruce Lueckenhoff       ALC
CP  Christos Papadolulos    GRA, tree building
JM  Joe Macker              NACK, ALC
BA  Brian Adamson           NACK, ALC
TH  Thomas Hardjono         Security
HR  Hayder Radha            CC/ALC
BW  Brian Whetten           track, CC
JG  Jim Gemmell             ALC, FEC, NACK
BC  Brad Cain               GRA, Tree building
TO  Tokuop Oishi
GR  Gursel Taskale          all

RK  Roger Kermode           all
LV  Lorenzo Vicisano        all
 

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

Interim Reliable Multicast Transport Working Group
Feb. 10 2000, ACIRI, Berkeley CA.
[RK: thanks to Sally Floyd]

Several people are late, because highway 880 was closed for a while.

There is a SMUG (Secure Multicast Research Group) meeting here
tomorrow.

Intro by Roger:
[Add a pointer to Roger's viewgraphs.]
Goals of meeting,
Overview of agenda.
Call to Arms:
Building-Block and Design Space drafts are waiting for review by Mark.
Mike: Are we on-schedule with the goals listed in our charter?
Roger: We are behind schedule.
The group will standardize building block and protocol instantiation
  documents.

The Guidelines draft:
[Add a pointer to Roger's viewgraphs.]
What is missing from here?
Mike: What about revision control between the PI (Protocol
  Instantiation) and the BB (Building Blocks) documents?  Do they
  cross-reference each other?
This comes to the API issue: what parts of the BB documents are
  referenced by the PI documents?  The BBs have, not an API, but
  a higher-level interface description.
NACK: There is a BB and a PI.  How does this work?
Answer: The BB has the more general stuff.  And a NACK PI
  might also use ACK-based stuff.
Jim: Can we do an example, with PGM?
BBs should discuss design tradeoffs.
Building blocks might be more applicable than just bulk transfer,
  though that is our immediate focus.
Mike: There is a danger of designing a BB without a PI in mind.
Maybe each PI should write its BBs, and then come together.
Mark, Sally: For NACK and TRACK, it is clear that there
  is a CC (Congestion Control) BB that can be broken out now, in
  parallel.  For ALC, there might not be as many BBs that can
  be broken out now.
FEC is a building block that can be taken out of ALC now.
What will go in the NACK BB?
Mike: Maybe the BB role can be more informational.
>From SMUG: BBs are coarse-grained, and might need more
  fine-grained components within them.
Mark: BBs should not include all possible options, but should
  narrow down the design space.
A call for BBs and PIs to start with overviews first, not the
  nitty-gritty details.  Out of today, perhaps we can end up
  with overviews of each of the BBs.

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

Congestion Control:

Mark:
TFRC, Unicast TCP-Friendly Rate Control
[Add a pointer to Mark's viewgraphs.]
Pointer to paper: "http://www.aciri.org/tfrc/".
The talk shows results from experiments and simulations with TFRC.
For unicast, the performance is very good.
Question: Simulations with TFRC: in simulations, TFRC tends to drop to
  zero with many flows, very high bandwidth?  Mark didn't see this, will
  look at it later.
Oscillations from smoothing the roundtrip time, and sending at 1/RTT:
  For unicast TFRC, we added RTT-based Congestion Avoidance.
  This is needed more for Drop-Tail than for RED queues, or for
  high levels of statistical multiplexing.
Issues for multicast:  timely feedback, measuring RTT.
Question: Does this apply to non-sender-based congestion control?

Mike Luby:
The work on CC for ALC is not finalized.
It is interesting to see if sender-based TFRC schemes will apply
  to receiver-based ALC.
VRC: [Viziano, Rizzo, Crowcroft], the RLC protocol.  Receivers join
  a layer and all lower-bandwidth layers.  Each layer has twice
  the bandwidth of the previous layer.
Join times are quick, and leave times might now be quick also.
In his opinion, the RLC approach has more power than the
  single-source approach.
For TCP-friendly issues, how does the RTT get taken into account?
Mark:  In small levels of stat mux, increasing the sending rate can
  dramatically increase the packet drop rate.  This is not the
  case with large-scale stat mux.
Mike: There is a lot of interesting work to be done.
Remark: Fine-grained video coding is the coming thing.

Roger:  Is the discussion leading to BBs?  Are we going into
  too much detail?
Brian:  We have a TRACK architecture overview, that shows how BBs
  fit together.

TEAR:
Similar to a TFRC building block.  Differs in how to measure a
  fair TCP throughput.
TEAR differs from TFRC in the receiver.  Instead of using the
  TCP-friendly equation, TEAR emulates TCP at the receiver.
  Takes a weighted average of eight TCP congestion control
  rounds.  TEAR trys to give a more accurate model of TCP.
Mark:  TEAR is sensitive to the pattern of losses.  And they
  differ in the modeling of retransmit timeouts.

Shiv Kalyanaraman:
Generic source-based multicast congestion control.
[Get a pointer to viewgraphs.]
This is sender-based congestion control.
No measurement support from the receiver set, except for NACKS or ACKS
  that are already there.
No aggregation support expected in the tree.
Congestion periods are broken into congestion epochs, which is
  a period with a single rate reduction, with time for the
  rate-reduction to diffuse to the congested sub-tree.
Mark: He is assuming a very low level of stat mux?  He is assuming that
  if the sending rate is increased, the packet loss rate increases also?
The protocol mimics TCP at every point.
They have implemented this in NS, and they have a PGM implementation.

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

-----------------------------------
 RMT Interim Working Group Meeting

      -- Draft Minutes --
 [ RK: thanks to Bob Quinn]

    Feb 10, /2000 - Hosted by Aciri
     at ICSI in Berkeley, CA
-----------------------------------

Roger Kermode, RMT working group co-chair, started the meeting
at AM with 18 people present (we had 28 by 11AM) with a review
of the agenda.

Tentative Agenda
---------------------------------
09:00 - 09:10   10 mins   Agenda Bashing
                          [Roger]
09:10 - 09:10   10 mins   WG status update
                          bb + ds drafts
                          Recharter
09:10 - 09:20   10 mins   Call to arms/editorship selection update
                          [Roger]
09:20 - 09:40   40 mins   Guidelines Draft Update/Discussion
                         [Roger/Lorenzo/Allison]
                10 mins  draft outline
                30 mins  discussion
10:00 - 11:20   1hr20mins Congestion Control: [Handley/Flloyd?]
                10 mins  TFMCC update [Handley/Flloyd]
                10 mins  ALC implications for CC [Luby]
                10 mins  TEAR implications for CC [Rhee]
                10 mins  Generic source-based multicast CC
                         [Kalyanaraman]
                40 mins  discussion
11:20 - 12:20   1hr       NACK: [Bormann & Adamson?]
                10 mins  BB Update [Borman]
                20 mins  BB Discussion
                10 mins  PI Update [Adamson]
                20 mins  PI Discusion
12:20 - 13:00   1hr       Lunch
13:00 - 14:00   1hr       Asynchronous Layered Coding: [Luby]
                10 mins  BB update
                10 mins  Gemmell?
                40 mins  discussion
14:00 - 14:30   1hr       Tree-Building: [??]
                10 mins  table of contents update [Chiu]
                20 mins  discussion
14:30 - 16:00   1hr       TRACK progress [Whetten/Chiu]
                10 mins   [Whetten]
                10 mins   [Chiu]
                40 mins   Discussion
16:00 - 16:45   45 mins   VACANT
16:45 - 17:00   15 mins   Agenda bashing for Adelaide

RMT has been rechartered and the new charter--now approved
by IESG--is in place on the RMT working group webpage.
http://www.ietf.org/html.charters/rmt-charter.html
Mark Handley showed the new charter as it appears on
the RMT working group webpage.

Roger provided status for the existing documents.  The charter
is agressive and we are a bit behind at this point.  Many of
the documents are essentially done (though most are not issued
as Internet Drafts (I-D).  Generic Router Assist (GRA) is the
only exception.  The Multicast Congestion Control document is
due for Apri--after Addelaide--and it is acknowledged as the
most difficult problem, and the one that gates all others.

Mike Luby asked whether we expect to be doing work on both the
BBs or the instantiations, and Roger said, "Yes, both."

The Building Block (BB) Guidelines draft has been stalled.
That is likely a source of confusion, since many people may not
know how to proceed with creating a BB I-D without it.  The idea
behind the BB is tp create some framework definitions for Reliable
multicast transport (RMT) that exist for Real-Time Protocol (RTP)
format.

Goal: to help people write Building Block (BB)
and Protocol Instantiation (PI) drafts
- How BBs and PIs fit together
- Sections to be included:
 + applicatiblity statement
  = where to use and where NOT to use
  = known failure modes
 + BB:
  = bunctional description
  = abstract API for use by other BBs
 + PI (protocol instantiation):
  = core functionality not in BBs
  = which BBs are used
  = how they fit together
  = packet formats

Mark Handley and Sally Floyd (MH and SF): PI needs to be
specific about the application targets
- the PI *may* have some mechanisms that BB doesn't
  (but not all will)

Joe Macker (JM): The BB should describe the trade-offs

MH: Some BBs will be more generic as far as being applicable
to bulk file transfer alone, and others will not.

Mike Luby (ML): doing the BB first and the PI second seems
backwards. It would be better to do the PI, then try to
derive the commonalities that represent the BB.

MH: We alread have a lot of existing protocols that we
understand very well.

ML: But are these written down?

Roger Kermode (RK): Our hope is that people that have the
experience with specific protocols need to exchange their
experiences.

ML: But again, it is written down?

MH: We may well do some back-tracking after the fact, but
we expect that.

ML: I think it is important to do the PI first and write it
down.

MH: I think that ALC may be one where that is true

ML: Why is that?

SF: Because there are lots of TRACK and NACK based protocols
for which we understand the commonalities so it makes a lot
of sense to do the BBs in parallel with PIs.

Jim Gemmel (JG): I'm fuzzy about what goes into a BB, is it
going to simply say what NAK does or list many different
ways it could work.

MH: I think that NAK will have suppression mechanisms built
into it.

JG: Are you going to list the mechanisms/algorithms?

MH: We need to pick one and describe it.

JG: But there are so many

ML: You pick one and it may not be appropriate in all cases.

Thomas Hardjono (TH): In SMuG we have picked a number of them

RK: We are obviously still struggling with what a BB is, so
I tend to agree with Mike that we should concentrate on a PI
first.

??: I thought that the BB was supposed to describe what we
recommend with Interet health as the focus.

SF: It is a good idea to have things that refer to Internet
health, but we already have RFC 2357 (?) that describes the
requirements for any RM transport.

RK: I think we are approaching some concensus.

JG: Go write one and lets take a look at it

??: Suggested that we have an overview and functionality
description for each BB *first* then move into the  other
details

---
TFRC - TCP-Freindly rate control      Mark Handley
(Equation based congestion control)

- we thought we understood this (for unicast) a year ago,
but we did not and we don't know multicast yet.

Scripts and paper all available at http://www.aciri.org/tfrc

It is fair to TCP in general, although we have seen TCP
get beat up because it was too bursty

Key measures are loss fraction and round trip time

Measuring round trip time, there are oscillations in TCP
and with multicast the delays between these is longer.

To dampen oscillations but still gain RTT-based congestion
avoideance behavior, need inverse dependence on RTT but
lower gain.  <<see equation>>  The result of this is a
smoothing of the oscilllations.

- If you fix the RTT time, you get the oscillations, but
  if you don't (as described above) then they are smoothed.

- we've tried these things with a wide variety of Queuing
  congestion control mechmanisms, and it works well with
  all (though having RED reduces the need for this mechansism).

Issues for Multicast
- how to ensure timely feeback?  Delay reporting loss event
  fraction may affect dynamics
- How to measure RTT to all receivers quickly? Not a showstopper,
  but may affect how CCC fits together with other components
- RTT-based Congestion Avoidance is difficult (referring to
  the algorithm described above): It is not clear that this is
  necessary, but the consequences of not doing it are not yet
  fully understood.

??: What is the traffic load for reporting congestion control?

MH: You really want your NACK or ACK trafffic to report it,
and with aggregation points (TRACK or other local/shared
recovery points) you have additional delay.  None of this
applies to ALC though, of course (since it is one-way).

ML: Yes, but reading through your paper I got the impression
that a lot of it is based on the receiver, so it could well
be applicable.

ML: If you actually did an experiment with two TCPs then they
would not be fair to each other.  The one that has longer
timeout (say 10 times) would be 100 times more loss.

SF: I don't believe that loss rate would be 10 times more

Brian Whetten (BW): I don't beleive it would be, either.

JM: What about slow-start mechanism for multicast?

MH: We may not need one for multicast since the advantage
of having one is not clear yet.

----
Asynchronous Layered Coding (ALC) BB       Mike Luby

The work on ALC CC is not finalized yet, though there has
been some great work done so far.

- thing about ALC is that you can have different receivers
  receiving at different rates (determined by the number
  of groups they have joined, and streams they are receiving
  in parallel) and we need to take advantage of it.

- VRC (authors Lorenzo V. , R. and Crowcroft mechanism
  is used for this (also referred to as RLC for author names
  also ...for some unknown reason).

- Synchronization points happen more often at the lower
  layers than at the upper layers.  Layers are cumulative.

It is now a very course-grained CC, and we should make it
more fine-grained (more fine-grained than the synch points
can provide).  Current one gives a linear increase.

SF: A factor involved with whether you couild ramp up send
rater slowly is whether you have either small or large-scale
statistical multiplexing.

Hayder Radha (HR): ALC sounds much like MPEg-4, which provides
fine-grained scalability and uses many different multicast
groups (roughly 10-20).

--
Short talk on TEAR                      Rhee

- TFRC uses equations looking at 8 loss events that have
  occurred and is based on what it finds from the sender,
  whereas TEAR emulates TCP within the receiver and how.

MH: TEAR is sensitive to the pattern of losses (which
may be good or bad) and sensitive to the timeouts.

--
Generic Source-Based Mcast Congewstion Control
Shivkumar Kalyanaraman (RPI) <<missed the URL>>

- implosion control needed
- need timing info on Sender & Reciever (may need GPS at
  receivers)
- Need to know the (S,G) state

"Generic" means
- completely implemented at the source
- no measurement support from receivers
- no extra contol traffic inserted
- no extra fields
- no aggregation support expected
- should work with NAKs, HACKs, ACKs, bit maps or other
  reverse traffic which provides congestion and timing
  information

Weak requirements on RTT & loss estimation:
 - suppress NAKs from long RTTs (partial timing info)

Basic idea is that they devide congestion time periods
into "epochs" where the source reduces the send rate
exactly once and enough time is given for rate-reduction
to diffuse throughout the congested sub-tree.

They do not depend on the loss rate.

They have implemented it in their version of PGM.

MH: Seems like you are not depending on having large-scale
statistical multiplexing rate and that assumes that the
competing flows are doing the same thing, which is a flawed
assumption.

--
Brian Whetten said he has done a description of how the
BBs fit together from the perspective of TRACK.* reliability

======
short break
======

RK: This is a new process we've been doing with the BB approach,
so we need to describe it in more detail.

Boorman: The BB needs to be normative, we need to have it as
something that people can reference as opposed to something
that is not

BW: It should have exact algorithms and abstract APIs

SF: BBs need to describe design tradeoffs required for Application-
specific variations (e.g. optional feedback).

  Single Rate CC BB Team:
   Mark H (leader), Sally F., Injong, Brian W., Shiv, Supratek, Hursel,
   Joe Macker, Brian A.

  MultiRate CC BB Team:
   Mike L (leader), Lorenzo, Hayder, Injong, Jim Gemmel, Luigi Rizzo,
   Jon Crowcroft

??: I come from a satellite company and I'd like to see some
satellite-specific considerations described.

RK: We deal with the Big 'I' Internet and this includes the
satellite media, so it is included implicitly.

MH: It looks like Single Source multicast (e.g. PIM Source Only)
will have an earlier deployment than others so it is likely that
we will have one-way links as well as two-way, so in that context
satellite is not that special despite the fact it has a long fat
pipe (long delay and high bandwidth capacity).

RK: Can we have a document by Adelaide on Single Rate, Mark?

MH: Yes, we can have a *start* on a document.  We need at least
a first pass of *every* building block by that time.

RK: The due date for drafts is March 10 and we should really
strive to have something done by this time.

MH: We should also submit the names to the RFC editor beforehand
so it doesn't get delayed (we should do this on the mailing list).

RK: Ok, will do.

MH: Should we have discussions in sub-groups or on the main RMT
mailing list.  <<A number of people responded that they would
prefer having this traffic on the main RMT mailing list>>

<<begin from whiteboard>>
CC Building Block Guidelines
-----------------------------
Must be normative - exact specific algorithms and abstract APIs

Discussions of tradeoffs - application specific variations (e.g.
optional feedback).  Cover design space.

Purpose: RFC 2357 and Sally Floyd's Congestion Control Principles
draft, see http://www.aciri.org/floyd/papers/draft-floyd-cong-01.txt
  + 2 parts:
    = Mandatory to satisfy IESG reqs
    = Application specific

Requirements for other BBs:
 - what messages can be piggy-backed (existing BB msgs and
    additional msgs) .
 - loss detection
 - RTT measurement

Two Separate BBs:
 -> single source (e.g., PIM-SO)
 -> Others (single rate)
   - satellite, asymmetric, wireless,

GRA Considerations

target scale (in terms of number of receivers).
<<end from whiteboard>>

---
How TRACK fits with other BBs                 Brian Whetten
(( his view of what needs to go into BBs ))

Goals
- functional decomposition across other BBs
- sees TRACK as a superset of NACK

Exponential back-off on loss detection

Unicast NACK generation
 - issue: NACK needs multicast NACKS?

response to retransmission request
GRA signaling
Integration with TRACK hierarchy
 - how do you do this well

SF: Why is this included here?

BW: We repeat it in both places

Question: Since it is a superset of NACK, why have a separate BB?

BW: Interesting thought.

MH: We need to do suppression so the question is how to do it.
You can do it by a tree or not, so the discussion needs to talk
about it with that focus

MH: One thing missing here is how it interacts with and uses FEC.

Lorenzo Vicanso (LV): Yes, FEC is very mixed with suppression.

MH: FEC itself is not in there, but a description of its
functionality is.

??: Why do you call it NACK when it should really be a generic
feedback mechanism?

BW: We have differentiated the feedback (for CC) and the
NACK for data loss and the TRACK since it has to deal with
hierarchy.

Brad Cain: What do you think the biggest issue is?

BW: The issue of how and when you deal with the NACKs.

FEC BB:
- input of a (sub) window of data packets
 + issue: packet nameing
- creating parity packet
 + issue: exhaustion of parity packets
 + proactive parity (which block owns it)?
- flush data stream with only a small sub-window
- FEC decode
- Bind to different codecs

LV: It seems that some of these issues (like flush) belong
in the protocol instantiation.

BW: This is a highlight of the functions and not specifications
of what they are doing

ML: I would just talk about the protocol and not how it will
work in all protocol instantiations.  That cannot work.

RK: The model to look at for this framework is RTP, where
there is enough generality to allow a common, versatile
framework.

LV: You need an API for making state available

ML: There is a way to describe FECs in general without going
into detail with exactly how to use them.

??: This has actually been done in the AVT RFCs that deal
with codecs (may still be I-Ds at this point).  They may not
be exact, but it is a good thing to start with.

LV: You can define blocks and when you can reveal the blocks
and deal with them.

TFMCC BB:
- Initialization
- Receiver measuraments
 + issue: RTT measurements
- Receiver feedback (on TRACK/NACK)
 + Issue: how to bias NACK timers?
- hierarchical aggregation
- sender rate control

MH: There's no requirement for interoperability until you get
into a PI.  The packet formats are defined in terms of funcionatlity
rather than generically as "feedback" to be efficient in terms of
size used.

GRA BB (draft-ietf-rmt-gra-arch-00.txt):
- Core, simple router functionality
 + issue: how to instantiate this?
- signaling guidelines
- NACK

Brad Cain (co-author): we will have a separate document that will
include feedback mechanism defined and we will define packet
format.  It will be incrementally deployable (as spec already
says).  We will be dealing with server-to-server traffic, which
is the auto-tree configuration.

Auto-Tree Configuration BB:
- Discover hierarchy that matches the multicast topology
- works in all environments
- provides children with an address list of candidates
 + if/when first fails you go to second one

BC: You need to discover namers, create hierarchy (some sort
of routing protocols where you abstract away who is closest
to the root).

JM: Is this going to be a routing-ish shared tree?

BC: We are not doing that level of detail ...we are not creating
PIM over a mesh.  Once you abstract away what a possible root
could be (source, RP, etc.), then there has to be a route from
whatever it is.  Then that has to be...???  I wouldn't touch that
one with a ten-foot pole.  There will be packets between servers,
and there will need to be a way to measure distance between server
to source and you can do that LOTS of different ways.  You need
to know what the metric means.

BW: Yes, I agree that the problem is not yet well defined

======
lunch break
======

<< Brian Whetten, on TRACK BB Requirements, continued >>

Common Packet Headers
- Data Naming
 + sequence number, FEC offset
 + issues: Add object ID? Need sequential packet numbering.
   Need to support application level multicast
- Session naming
 + stream ID
 + TRACK may need a Tree ID
- Also issues with Application Level Framing (Talarian,
  TIBCO and FastForward are three examples), since you are
  multiplexing at a different level

MH: There seems to be three sequence spaces:
 - packets within FEC block
 - FEC blocks themselves
 - Object ID itself

 You might be able to build over to create frames over
 that, but it must be at the object level to get reliability.
 I think it might be worthwhile to go down this path to see
 what comes out, what meta-information we need.

BW: The other consideration that is important is the number
of bits we add to support this.

MH: My view on bits is don't worry about it, since it is only
on low-bandwidth links that it is a concern

Security BB
- Really SMuG's area and our area
- Transports only job is to protect itself
- Interface to key managerment is what we need
- IPSec for lightweight version

TRACK functions
- hierarchy creation and maintenance
 + join, leave, falure recovery, keepalives
 + local multicast groups for control, retransmission
- parameter initializeation/distribution
 + server and tree-wide
- source ordered, unordered, time bounded (?)
- network management

JM: Is there a new security consideration for ACK Aggregation

TH: At last IETF I talked about a mechanism whereby an intermediate
point that received a NACK would have to forward them upstream
for signing (so intermediate point does not need to be a trusted
participant).  Authentication and trust models are the issues.

LV: The NACK authentication is an end-to-end issue

TH: Yes, but NACKS are from routers

BW: Routers don't issue NACKs, however.  Routers create the tree
(for TRACK).

MH: Tree-based protocols help you to generate round trip times.

TRACK Issues
- Kill TN and Aggregators?
 + shared tree versus per-source tree?
- Can we have dynamic DR/receivers
- Multicast address sharing

BW: Is top of the tree always co-located with the sender?

MH: There are lots of different ways to build trees

BW: You can have multiple data sources for a single tree

BC: It would be good if anyone desiging NACKs talk to
him and BL about how to define them for each of the
BB type (e.g. NACK, TRACK, ALC), specifically in terms
of application interface and packet formats.

======
We then had break-out meetings for separate sub-groups:
"ALC", ""NACK," and "Tree Building" (in quotes since these
are very loosely defined).  Here are the topics discussed:

"ALC":
 - FEC
 - PI for ALC
 - Congestion Control

"NACK":
 - PI versus BB
 - NACK
 - Congestion Control

"Tree Building"
 - Auto Tree config

=========
 Wrap Up
=========
Roger Kermode on Auto-Tree Creation BB discussion:
- Preconfigured solution
 + assumes the existence of a mesh of delivery servers
    (which may be statically configured or dynamically
    generated):
 + requires existing infrastructure on internal nodes

- Ad hoc solution
 + does not require predeployment
 + assumes mesh discovery protocol
 + no GRA
 + no TTL scoping (needs to support PIM_SO)
 + no static config info in hosts

MH: Do you have any reference implementations for these models?
I'd like to see some running code.

Mike Luby on ALC:
 - we had lots of concensus and progress
 - We also took on the FEC BB

TRACK:
 - what identifies a source or a receiver?

NACK:
 - We also discussed FEC a lot too since it is tied in

Rather than having different mailing lists for each subgroup,
Roger proposed that everything go to RMT and we preface subjects
with what the topic is relevant to (and add "PI" as a suffix if
that's the topic) FEC, TREE, ALC, NACK, CONG_{SR | MR}, TRACK,
GRA, or GUIDE.  He will send a message to the RMT mailing list
describing this.

<<end>>
 
 
 

=========================================
 Notes from TRACK sub-group Discussions
 RMT Working Group Meeting 2/6/00
=========================================
blame bob quinn <rcq@stardust.com> for any innaccuracies

Motivation for creating a tree
- Good for error control and congestion control
- Distributed aggregation (caching hierarchies, e.g., for
  use in a Content Distribution Network (CDN))
- Anycast
- Security, group key management
- Distributed gaming/simulations

All have similar requirements

Why is it useful?
1) hierarchical construction assists with load balancing
2) topologically aware aggregation
3) topologically aware subcasting

First is sufficient (2nd and 3rd are efficient).

Why by aware of topography?
- topologically based structures have dramatic performance benefits
 + localized aggregation
 + subcasts that are focused towards downstream logical descendants
 + allow use of subcast, period.
 + ensures reduced latency between pairs

Applications
- local aggregation
 + error, congestion control, CDN, security
- focused subcasts
 + error, congestion, security
- reduced latency between pairs
 + gaming, anycast

BW: So is the goal topological congruency?
Brian Levine (BL): Yes
BW: Would anyone debate that?
BL: yes.  You can't do it now without difficulty, but that
  does not mean it is not something we should *try* to do.
BC: That is something we should strive for.
BW: There are some that would say it is better for error
  control
BL: I don't agree with that
BW: I just want to talk about it since it is relevant to
  asymmetric routing, among other thigns.
BC: That is a really tricky issue and the other reason
  is inter-domain
BW: Exactly, which is why single-AS is going to rule
BC: Exactly.
BW: Should we scope it to a single domain?
  <general disagreement>

"Easy" way to do topo-aware
- use GRA!!
- Source periodically multicast packets with GRA and
 router alert (MD5 Auth)
 + They go down the tree from a parent
 + I'm assuming we are doing Express mode stuff
- GRA routers with their IP address in the payload of
the packet (perhaps both in and out interfaces ...?)
 + Each hop adds as packet traverses
 + As there are more routers, you get a better idea
- Receivers subcast from last revised router announcing
  their path strings
- Receivers pick parents, send unicast to confirm
- Or...new mtrace messages (added by Brad Cain)
 + This would trace down the tree (though we have not
  yet figured out the format ...though many don't like
  mtrace since it gathers statistics, has latency and
  adds overhead)

??: There was a guy at MCast2000 who said that the hyperqueue
  could build a tree very quickly
BC: There is part of this that people can use to do other
  tricky things.  For example how do you find out how close
  you are to a source or an intermediate routers and there
  are lots of ways to do it.

Two problems with finding a metric that's good: congruency
and how best to announce to the group

Breaking Up the Problem:
- Neighbor Discovery
- routing-like protocol
 + who is closest to the "source" (for mcast)
 + who is closest to other point (e.g. server)
- How to find distance to server or seoruce?
- How to make it generic?
  + can we do it for others than reliable multicast, such
   as the content delivery people.
- Fault tolerance

BC: Looking at a graph or mesh of servers and over the top
  of that there is some sort of protocol that you use to build
  a hierarchy in the server to server protocol itself.  To do
  so you need to have some sort of metric, such as who is
  closest to data source or RP.

You discover a set of neighbors within a scope (that's how
the mesh is built), then over that mesh you establish the
tree.

BW: That is basically what we are looking at but that could
  be a heavy weight protocol.

BC: You can statically configure the mesh (which will most
  often be the case anyway ...that's the way these content
  distribution network guys are doing already).

RK: We have to be able to exist where GRA doesn't already
  exist.

BL: If we didn't bring up topological awareness then
  we woudln't have any issue with non-GRA implementations.

We are being passed-by and need to do *something*:
- companies can do non-topo aware without us, though
 standards are nice
- eventually they *will* do topo-aware without us
- As IETF'ers we should make recommendations

BW: The barriers to getting GRA into all the routing
  infrastructure is so high that from a practical standpoint
  we should be able to use it without GRA.

BL: I think it will take 3 years to get GRA widely available
BW: I think that is really wishful, which is why we should
  think about new mtrace messages.
BC: The mtrace command needs access control (password, maybe?)
  since it reveals the tree which can be very dangerous.
RK: If you are going to use mtrace, think about a network
  with 10000 nodes
BC: MTrace would not scale to that many receivers
BC: you can try to match receivers with nearest server
  or make tree closest to source.  The content delivery is
  focused on making caches close by to receivers.
??: Seems a question of how tall you want to make the tree
  with respect to how much fan-out there is (the optimality
  of the tree).
BC: Yes, that all relates to how you build the tree

  Miriam Kadansky did a doc that relates to requirements
   BL referenced this and created slides from the TOC.

Dah Ming (DM): How the the tree is formed and then used.
  This was a strawman for generating discussions.  We have
  lots of information about tree optimization and maintenance
  as well as tree building and what I'd like to see is a
  discussion of how much of this belongs in the BB.

BW: I think only the building of the tree is important.

BC: I think there should be two layers: a base layer that
  can be useful for a lot of things and the second that is
  specific to reliable multicast.

RK: Auto-Tree Requirements (RM specific)
--------------------------
1) Aggregation of things like ACKs, NACKS, congestion control
2) Subcasting
 - parent to child unicast (application level)
 - parent to all descendents local multicast group
 - parent to child (GRA)
3) Others (non-RM specific)
 - group membership
 - list of GRA-capable routers
 - billing

RK: It has to be spelled-out in the draft what is RM-specific
  and what is not.

TH: Some mechanisms used to design the tree are exactly the
  same that is needed to deliver some of the services that the
  tree is supposed to support.
BW: So, for example, you could use subcast to do auto tree
  configuration.
TH: Good examplee

BW: Goals:
 - Perfect topology congruence
 - failing that, do something not stupid
 - list of parents

BC: Where does the metric fit in?  How do you determine a
  "perfect tree?"  What does the API give you?
BW: These are the list of parents and the metric(s). There
  are other interactions to prevent loops (for example).  We
  may be able to pick one metric.
BL: we should have one metric in mind.
BC: There are a number of different possibilities.
RK: You are building a tree to do what, connect sources with
  receivers or with end-points??
DM: The DR could be either the source or the distribution head.
BW: The head of the tree is always the source

BC: the problem is that if you are given just a list of neighbors
  and metrics, then you could construct a tree that has loops.
BW: I was assuming it was at least an ordered list so there are
  no loops.
BL: you can always override this, so we must assume that it
  has no loops.  Congurence is the goal and besides, it is not even
  a tree if it has loops.
DM: There are diffferent ways to make sure you don't have a loop,
BW: Yes, but if you just know the depth of the tree then this is
  enough information to create a non-looped system.
DH: That implies the tree is built top-down
BW: The issue comes down to work
BC: right.
BW: Who has to do the job
BC: The loop protection depends on what info is exchnaged between
  nodes.

Requirements (according to BW)
- Universally deployable
 + multi-AS
 + All multicast routing
 + GRA
- Safe
- Receiver auto-config
 + e.g. receivers can find their nearest server
- Keep it Simple

BC: I think the receiver auto-config is DONE: DNS
  (though Anycast or a web-page or other out-of-band
  mechanism could be used also)
BW: I am just defining high-level requirements without
  considering solutions

BC: We need to be able to "prune protocols" (to quote
  Steve Deering) to make it simple

BC: Do we want to get into Policy metrics when considering
  inter-AS (inter-domain)?
BW: I really don't think we want to go there.

BC: All protocols are source based now
BW: Huh?  Applications don't have a way to specify the
  source.

??: the tree building protocol is running all the time?
BW: Yes, so you can ask anytime for what parents are

RK: It sounds like you are trying to punt things away, so
  if it does not get done here where does it get done?
BW: In TRACK
BC: We still need to determine the line between TRACK and
  here.
BW: The issue is that keep-alives, HACK packets, get generated.
  It is control path versus data path issue.
RK: I like that separation between control and data paths.
  This document should be sufficient to create a control path
  and that control path is used to deliver data.
BW: There is realistic three peices here: all error packets
  are part of data.  We want auto-tree config information.
BC: I agree they are separate, but think there is anough
  commonality to keep them together.
BW: I am abstracting out configuration information for control

RK: Can we separate out like:
 - Ctrl path: tree creation and maintainenace
 - Data path: "repair" PI specific control

<< short diversion into discussing whether it is possible to
create a generic BB or whether we have to start with a PI
...the challenge being whether we can have something generic
without getting into protocol details >>

BC: You can do something really simple, but if it is going
  to be that minimal, there is some question about whether
  it is useful.
TH: It has to work, so it can't be that thin.  The thing is
  that to be useful, we need to agree on some common elements.
BW: I think the NACK BB is going to be very short (deal with
  retry timer and action) and I suspect that we can make this
  Tree Building BB just as small.
BC: CDN people want all these things.  I don't know where
  the line is between generic BB and PI.

??: There are two main things: discovery and maintenance.
DM: Yes, but it is more complex since there are different
 scenarios (e.g. late joins).

RK: Tree "functions"
- Discovery: learning *possible* parents (manually or auto)
- Construction: Joining the tree
 + BC: e.g. applying Dijkstra and creating link-state
- Maintenance: Fail over, leaving
- Service Hooks (sub-cast, aggregation, etc.)

BW: Problem is you can't discover parents without considering
  where the source is.
BC: What is the signal for generating a tree, is it that a
receiver joined or that a source is there?
BW: I would say when receiver joins
BC: I would agree with that

RK: Discovery:
- who starts the process?
 + source: top-down tree generation
 + receiver: bottom up tree generation

BW: The way the world actually works is you have a collection
  of Sources, a collection of potential DR's (intermediates)
  and receivers (he illustrated on board with three layers).
BC: We are not dealing with the receivers to servers in this
  tree building (which is a server location problem ...and we
  can safely assume that DNS solves this).  Most of the time
  the configuration of the mesh of intermediates is statically
  configured (99% of the time) ...call it "the Mesh."  At this
  point there are NO TREES yet (an important point), so there's
  no concept of loops at this point since nothing is source
  specific.

BW: Mesh:
1) neighbor disovery
2) senders announce
3) receivers initiate join

BC: Alternately, the source finds a server
DM: Yes, there may be many servers that are not relevant
  to a source
BC: Ok, yes, so let's assume that the source does NOT
  announce to the servers.  We already know how to do this
  and it's called multicast routing (using PIM).  It requires
  that each server knows the metric distance to the source(s).
BW: Ok, so we're done!  We will just run another routing
  protocol (along with the one below us at the IP layer that
  we cannot access and the one that may be above at the
  application level).

??: Ok, this assumes that there is a mesh, but what if
  we don't assume this?
BC: I disagree, since if you look at anything on the net
  it is formed as a mesh and there are a lot of administrative
  issues about who can talk to who.

Lots of discussion/debate about whether we can assume that
the mesh is avilable as preconfigured infrastructure.  To do
auto configuration we cannot assume many-to-many SRM-like
discovery.

Dah Ming and BL agreed that having the intermediate mesh
assumed makes having the receivers going directly to senders
impossible (e.g. so the receivers can organize into a tree
without having an intermediate layer).

BL: Could send from source with IP list, as I described earlier.
DM: Yes.
BC: Ok, if source sends magic packet then each receiver
  picks a receiving parent.
DM: Yes.  This should be allowed and the static intermediate
  layer could be optional.
BL: Yes, and then any intermediate node can declare that
  they don't want to be part of the tree.

-> Some disagreement about which of the two models should be
   the primary requirement.

RK: My dream protocol that I want
- Doesn't require GRA (but be compatible with GRA)
- Doesn't use TTL scoping
- Needs to work in PIM source only (PIM-SO)
- Doesn't require config info in hosts
- Doesn't require statically deployed mesh

BC: You may want to determine your tree with metrics other
  than hops (e.g., server load, geographic location, etc.).

BL (and others): the one where receivers can be DRs makes
  the static mesh possible, but the converse is NOT true.
BC: I disagree.  Since not all receivers can send, it becomes
  an access control issue that assumes many-to-many multicast
  is possible.

Summary of differences between the two models:

> Dynamic Discovery version sends a probe from the source and
  each *logical* hop adds its addres and the metric you end up
  using is a router-like distance metric that uses the number
  of hops.  In that model also, any receiver can (potentially)
  be a repair node, which Brad and BW both say is not realistic
  since that assumes many-to-many (like SRM) and that is simply
  not available in the real world.  In this model only the members
  in the mesh can be repair nodes.  Brad pointed out that this
  is how all of the CDN folk do things.

> Other version assumes the creation/existence of a mesh
  which can use *any* number of different metrics for distance
  (not just a router-like "number of hops", which would have
  to count virtual hops, since it counts servers rather than
  routers).

The first model can co-exist with the second, but the first
cannot exist if the existence of the mesh in the first is
assumed.

<<end>> --------------83EEF7F1661A5FD3901798F2-- --------------12DAB1FB4EB5F784B0A83607 Content-Type: text/x-vcard; charset=us-ascii; name="Roger.Kermode.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Roger Kermode Content-Disposition: attachment; filename="Roger.Kermode.vcf" begin:vcard n:Kermode;Roger tel;cell:+61-408-212-284 tel;fax:+61-2-966-0501 tel;work:+61-2-9666-0558 x-mozilla-html:FALSE url:www.motorola.com.au/arc/ org:Communications And Networking Lab;Motorola Australian Research Centre adr:;;Locked Bag 5028;Botany;NSW;1455;Australia version:2.1 email;internet:Roger.Kermode@motorola.com title:Principal Research Engineer/Lab Manager fn:Roger Kermode end:vcard --------------12DAB1FB4EB5F784B0A83607-- >From owner-rmt@listserv.lbl.gov Sun Mar 5 04:26:30 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id EAA14554; Sun, 5 Mar 2000 04:26:25 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA14550 for ; Sun, 5 Mar 2000 04:26:23 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA04788 for ; Sun, 5 Mar 2000 04:26:23 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA04784 for ; Sun, 5 Mar 2000 04:26:22 -0800 (PST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id FAA25363 for ; Sun, 5 Mar 2000 05:26:21 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id FAA21864 for ; Sun, 5 Mar 2000 05:26:19 -0700 (MST)] Received: from motorola.com ([217.2.31.248]) by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id XAA12338 for ; Sun, 5 Mar 2000 23:23:23 +1100 (EST) Message-ID: <38C25197.2B860A5D@motorola.com> Date: Sun, 05 Mar 2000 23:22:47 +1100 From: Roger Kermode X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: RMT Call for agenda items for Adelaide Content-Type: multipart/mixed; boundary="------------372261E48FE8926E5CBF5D96" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------372261E48FE8926E5CBF5D96 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear RMTers, The draft ietf-draft deadline is rapdily approaching...so it's time that we start to put together an agenda for Adelaide. Let's keep the momemtum going from the interim meeting, please send items for disucssion to the chairs as soon as you can cheers, Roger FYI ...We have two chunks of time booked, so there should be plenty of time for discussion: Tuesday 1545-1645, 1700-1800 Wednesday 0900-1130 --------------372261E48FE8926E5CBF5D96 Content-Type: text/x-vcard; charset=us-ascii; name="Roger.Kermode.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Roger Kermode Content-Disposition: attachment; filename="Roger.Kermode.vcf" begin:vcard n:Kermode;Roger tel;cell:+61-408-212-284 tel;fax:+61-2-966-0501 tel;work:+61-2-9666-0558 x-mozilla-html:FALSE url:www.motorola.com.au/arc/ org:Communications And Networking Lab;Motorola Australian Research Centre adr:;;Locked Bag 5028;Botany;NSW;1455;Australia version:2.1 email;internet:Roger.Kermode@motorola.com title:Principal Research Engineer/Lab Manager fn:Roger Kermode end:vcard --------------372261E48FE8926E5CBF5D96-- >From owner-rmt@listserv.lbl.gov Mon Mar 6 01:47:06 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id BAA16647; Mon, 6 Mar 2000 01:43:23 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA16642 for ; Mon, 6 Mar 2000 01:43:19 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA04675 for ; Mon, 6 Mar 2000 01:43:19 -0800 (PST) Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA04668 for ; Mon, 6 Mar 2000 01:43:17 -0800 (PST) Received: from oleane (dyn-1-1-132.Vin.dialup.oleane.fr [195.25.4.132]) by smtp2.cluster.oleane.net with SMTP id KAA78930; Mon, 6 Mar 2000 10:42:56 +0100 (CET) Message-ID: <00f401bf874f$be56f800$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: SIP 2000 International Conference Date: Mon, 6 Mar 2000 10:38:24 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F1_01BF8758.19B928A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00F1_01BF8758.19B928A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Unknown and even rejected by many vendors and operators only a few = months ago, SIP is on the brink of making a definitive name for itself.=20 Visit the SIP 2000 International Conference programme: http://www.upperside.fr/basip.htm =20 ------=_NextPart_000_00F1_01BF8758.19B928A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Unknown and even rejected by many vendors and operators only a few = months=20 ago, SIP is on the brink of making a definitive name for itself.
Visit the SIP 2000 International Conference programme:
http://www.upperside.fr/basip.= htm
 
 
------=_NextPart_000_00F1_01BF8758.19B928A0-- >From owner-rmt@listserv.lbl.gov Wed Mar 8 16:37:01 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id QAA01920; Wed, 8 Mar 2000 16:35:05 -0800 (PST) Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id QAA01916 for ; Wed, 8 Mar 2000 16:35:03 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id QAA21004 for ; Wed, 8 Mar 2000 16:35:03 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id QAA21000 for ; Wed, 8 Mar 2000 16:35:02 -0800 (PST) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [171.69.65.85]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA11874 for ; Wed, 8 Mar 2000 16:34:31 -0800 (PST) Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA29554 for ; Wed, 8 Mar 2000 16:35:09 -0800 (PST) Message-Id: <200003090035.QAA29554@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.0.2 2/24/98 To: rmt@lbl.gov Subject: FEC BB draft Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_-17452598970" Date: Wed, 08 Mar 2000 16:35:09 -0800 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk This is a multipart MIME message. --==_Exmh_-17452598970 Content-Type: text/plain; charset=us-ascii Dear RTM-ers, As established, the ALC subgroup has worked on the attached FEC BB draft. We intend to submit it by Friday. As this BB also interests other subgroups, we are circulating it to collect comments. This draft addresses the following: - gives a general description/classification of the FEC codes pertinent to RMT. - discusses FEC-related information needed in packet fields. - addresses security issues. Please note that this is only the 1-st draft. Things can be changed later. In particular my guess is that section 3, that describes packets fields, will be expanded and detailed in the next revision of this spec. cheers, Lorenzo Vicisano --==_Exmh_-17452598970 Content-Type: text/plain ; name="draft-ietf-rmt-bb-fec-00.txt"; charset=us-ascii Content-Description: draft-ietf-rmt-bb-fec-00.txt Content-Disposition: attachment; filename="draft-ietf-rmt-bb-fec-00.txt" RMT Working Group M. Luby INTERNET DRAFT L. Vicisano Expires 8 September 2000 L. Rizzo J. Gemmell J. Crowcroft B. Lueckenhoff 8 March 2000 Reliable Multicast Transport Building Block: Forward Error Correction Codes Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo describes the use of Forward Error Correction (FEC) codes within the context of reliable IP multicast transport and provides an introduction to some commonly-used FEC codes. 1. Rationale and Overview Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 1] Internet Draft RMT BB, Forward Error Correction Codes March 2000 There are many ways to provide reliability for transmission proto- cols. A common method is to use ARQ, automatic request for retransmission. With ARQ, receivers use a back channel to the sender to send requests for retransmission of lost packets. ARQ works well for one-to-one reliable protocols, as evidenced by the pervasive suc- cess of TCP/IP. ARQ has also been an effective reliability tool for one-to-many reliability protocols, and in particular for some reli- able IP multicast protocols. However, for one-to-very many reliabil- ity protocols, ARQ has limitations, including the feedback implosion problem because many receivers are transmitting back to the sender, and the need for a back channel to send these requests from the receiver. Another limitation is that receivers may experience dif- ferent loss patterns of packets, and thus receivers may be delayed by retransmission of packets that other receivers have lost that but they have already received. This may also cause wasteful use of bandwidth used to retransmit packets that have already been received by many of the receivers. In environments where ARQ is either costly or impossible because there is either a very limited capacity back channel or no back chan- nel at all, such as satellite transmission, a Data Carousel approach to reliability is sometimes used [AFZ95]. With a Data Carousel, the sender partitions the object into equal length source symbols, places them into packets, and then continually cycles through and sends these packets. Receivers continually receive packets until they have received a copy of each packet. Data Carousel has the advantage that it requires no back channel because there is no data that flows from receivers to the sender. However, Data Carousel also has limita- tions. For example, if a receiver loses a packet in one round of transmission it must wait an entire round before it has a chance to receive that packet again. This may also cause wasteful use of bandwidth, as the sender continually cycles through and transmits the packets until no receiver is missing a packet. FEC codes provide a reliability method that can be used to augment or replace other reliability methods, especially for one-to-many relia- bility protocols such as reliable IP multicast. Ideally, FEC codes in the context of IP multicast can be used to encode an object into packets in such a way that each received packet is fully useful to a receiver to reassemble the object regardless of previous packet reception patterns. Thus, if some packets are lost in transit between the sender and the receiver, instead of asking for retransmission using ARQ or waiting till the packets are resent using Data Carousel, the receiver can use any other subsequent equal number of packets that arrive to reassemble the object. This implies that the same packet is fully useful to all receivers to reassemble the object, even though the receivers may have previously experienced different packet loss patterns. This property can reduce or even eliminate the Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 2] Internet Draft RMT BB, Forward Error Correction Codes March 2000 problems mentioned above associated with ARQ and Data Carousel and thereby dramatically increase the scalability of the protocol to ord- ers of magnitude more receivers. For some reliable IP multicast protocols, FEC codes are used in con- junction with ARQ to provide reliability. For example, in a first round all of the source symbols could be transmitted, and then receivers could report back to the sender the number of symbols they are missing from each block. Then, the sender could compute the max- imum number of missing symbols from each block among all receivers, and then transmit that number of redundant symbols for each block. In this case, even if different receivers are missing different sym- bols in different blocks, transmitted redundant symbols for a given block are useful to all receivers missing symbols from that block. For others, FEC codes are used in a Data Carousel fashion to provide reliability, by cycling through and transmitting the encoding symbols instead of the source symbols. For example, suppose an FEC code is applied to the entire object consisting of k source symbols to gen- erate n encoding symbols with the property that the entire object can be reassembled from any k encoding symbols, and the sender cycles through and transmits the n encoding symbols in the same order in each round. Then, a receiver can join the transmission at any point in time, and as long as the receiver receives at least k encoding symbols during the transmission of n encoding symbols then the receiver can completely recover the object. This is true even if the receiver joins the data carousel in the middle of a round. For yet other reliable IP multicast protocols the sole method to obtain reliability is to use FEC codes. For example, the sender can decide a priori how many encoding symbols it will transmit, use an FEC code to generate that number of encoding symbols from the object, and then transmit the encoding symbols to all receivers. This method is for example applicable to streaming protocols, where the stream is partitioned into objects, each object is encoded into encoding sym- bols using an FEC code, and then the sets of encoding symbols for each object are transmitted one after the other using IP multicast. The large on demand codes described below have the property that the FEC encoder can generate sequentially as many encoding symbols as are desired on demand. Thus, reliable IP multicast protocols that use large on demand codes generally rely solely on these codes for relia- bility. In the general literature, FEC refers to the ability to overcome both erasures (losses) and bit-level corruption. However, in the case of IP multicast, lower network layers will detect corrupted packets and discard them. Therefore, an IP multicast protocol need not be con- cerned with corruption; the focus is solely on erasure codes. The Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 3] Internet Draft RMT BB, Forward Error Correction Codes March 2000 payloads are generated and processed using an FEC erasure encoder and objects are reassembled from reception of packets using the corresponding FEC erasure decoder. The primary purpose of using FEC codes is to ensure that minimal number of packets need be received in order for a receiver to reassemble an object. Reception overhead is used to measure how close a protocol comes to achieving this minimum. Reception overhead is the aggregate length of packets needed to recover the object beyond the object length, measured as a percentage of the object length. For example, if it takes 15 MB of packets in order to recover a 10 MB object, then the reception overhead is (15 10)/10 times 100, or 50%. The minimal reception overhead possible is 0%. 2. FEC Codes 2.1. Simple codes There are some very simple codes that are effective for repairing packet loss under very low loss conditions. For example, one simple way to provide protection from a single loss is to partition the object into fixed size source symbols and then add a redundant symbol that is the parity (XOR) of all the source symbols. The size of a source symbol is chosen so that it fits perfectly into the payload of a packet, i.e. if the packet payload is 512 bytes then each source symbol is 512 bytes. The header of each packet contains enough information to identify the payload. In this case, this includes a symbol ID. The symbol IDs are numbered consecutively starting from zero independently for the source symbols and for the redundant sym- bol. Thus, the packet header also contains an encoding flag that indicates whether they symbol in the payload is a source symbol or a redundant symbol, where 1 indicates source symbol and 0 indicates redundant symbol. For example, if the object consists of four source symbols that have values a, b, c and d, then the value of the redun- dant symbol is e = a XOR b XOR c XOR d. Then, the packets carrying these symbols look like (0, 1: a), (1, 1: b), (2, 1: c), (3, 1: d), (0, 0: e). In this example, the first two fields are in the header of the packet, where the first field is the symbol ID and the second field is the encoding flag. The portion of the packet after the colon is the payload. Any single symbol of the object can be recovered as the parity of all the other symbols. For example, if packets (0, 1: a), (1, 1: b), (3, 1: d), (0, 0: e) are received then the symbol value for the missing source symbol with ID 2 can be recovered by computing a XOR b XOR d XOR e = c. When the number of source symbols in the object is large, a simple block code variant of the above can be used. In this case, the source symbols are grouped together into source blocks of k Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 4] Internet Draft RMT BB, Forward Error Correction Codes March 2000 consecutive symbols each, and then for each block of source symbols a redundant symbol is added to form encoding blocks of k+1 symbols each. Then, a source block can be recovered from any k of the k+1 symbols from the associated encoding block. Slightly more sophisticated ways of adding redundant symbols using parity can also be used. For example, one can group the k source sym- bols in the object into a p x p square matrix, where p = sqrt(k). Then, for each row a redundant symbol is added that is the parity of all the source symbols in the row. Similarly, for each column a redundant symbol is added that is the parity of all the source sym- bols in the column. Then, Any row of the matrix can be recovered from any p of the p+1 symbols in the row, and similarly for any column. Higher dimensional product codes using this technique can also be used. However, one must be wary of using these constructions without some thought towards the possible loss patterns of symbols. Ideally, the property that one would like to obtain is that if k source symbols are encoded into n encoding symbols (the encoding sym- bols consist of the source symbols and the redundant symbols) then the k source symbols can be recovered from any k of the n encoding symbols. Using the simple constructions described above does not yield codes that come close to obtaining this ideal behavior. 2.2. Small block codes Reliable IP multicast protocols may use a block (n, k) FEC erasure code [BLA94]. For such a code, k source symbols are encoded into n > k encoding symbols, such that any k of the encoding symbols can be used to reassemble the original k source symbols. Thus, these codes have 0% reception overhead when used to encode the entire object directly. Block codes are usually systematic, which means that the n encoding symbols consist of the k source symbols and n-k redundant symbols generated from these k source symbols, where the size of a redundant symbol is the same as that for a source symbol. For exam- ple, the first simple code (XOR) described in the previous subsection is a (k+1, k) code. In general, the freedom to choose n larger than k+1 is desirable, as this can provide much better protection against losses. Codes of this sort are often based on algebraic methods using finite fields. Some of the most popular such codes are based on linear block codes. Implementations of (n, k) FEC erasure codes are efficient enough to be used by personal computers [RIZ97c, NON97]. For example, [Riz97b] describes an implementation where the encoding and decoding speeds decay as C/j, where the constant C is on the order of 10 to 80 Mbytes/second for Pentium class machines of various vintages and j is upper bounded by min(k, n-k). In practice, the values of k and n must be small for these codes as large values make encoding and decoding prohibitively expensive. As Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 5] Internet Draft RMT BB, Forward Error Correction Codes March 2000 many objects are longer than k symbols for reasonable values of k and the symbol length (e.g. larger than 16 KB for k = 16 using 1 KB sym- bols), they are divided into m source blocks consisting of k source symbols each. An erasure code is used to encode each source block into an encoding block consisting of n encoding symbols. For a receiver to completely recover the object, k distinct encoding sym- bols (i.e., with different symbol IDs) must be received for each of the encoding blocks. For some encoding blocks, more than k encoding symbols may be received, in which case any additional encoding sym- bols are discarded. An example encoding structure is shown in Figure 1. | source symbols | source symbols | | of source block 0 | of source block 1 | | | v v +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |0 |1 |2 |3 |4 |5 |6 |7 |0 |1 |2 |3 | 4|5 |6 |7 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | encode | v +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |0 |1 |2 |3 | 4| 5| 6| 7| 8| 9| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ ^ ^ | | | encoding symbols | encoding symbols | | of encoding block 0 | of encoding block 1 | Figure 1. Encoding structure for object divided into m = 2 source blocks, k = 8 and n = 10 When using small block codes for objects that are larger than k source symbols in length, the source symbols in the object are assigned to blocks. Typically, each k contiguous source symbols of the object is assigned to a block, i.e., block c consists of the range of source symbols [ck, (c+1)k-1]. This ensures that memory reference are local when the sender reads source symbols to encode, and when the receiver reads encoding symbols to decode.Locality of reference is particularly important when the object is stored on disk, as it reduces the disk seeks required. The block number and the source symbol ID within that block can be used to uniquely specify a source symbol within the object. If the Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 6] Internet Draft RMT BB, Forward Error Correction Codes March 2000 size of the object is not a multiple of k source symbols, then the last source block will contain less than k symbols. Encoding symbols can be uniquely identified by block number and encoding symbol ID. The block numbers can be numbered consecutively starting from zero. One way of identifying encoding symbols within a block are to use symbol IDs and an encoding flag that is used to specify whether an encoding symbol is a source symbol or a redundant symbol, where for example 1 indicates source symbol and 0 indicate redundant symbol. The symbol IDs can be numbered consecutively starting from zero for each block independently for the source sym- bols and for the redundant symbols. Thus, an encoding symbol can be identified by its block number, the encoding flag, and the symbol ID. For example, if the object consists 10 source symbols with values a, b, c, d, e, f, g, h, i, and j, and k = 5 and n = 8, then there are two source blocks consisting of 5 symbols each, and there are two encoding blocks consisting of 8 symbols each. Let p, q and r be the values of the redundant symbols for the first encoding block, and let x, y and z be the values of the redundant symbols for the second encoding block. Then the encoding symbols together with their iden- tifiers are (0, 0, 1:a), (0, 1, 1: b), (0, 2, 1: c), (0, 3, 1: d), (0, 4, 1: e), (0, 0, 0: p), (0, 1, 0: q), (0, 2, 0: r), (1, 0, 1: f), (1, 1, 1: g), (1, 2, 1: h), (1, 3, 1: i), (1, 4, 1: j), (1, 0, 0: x), (1, 1, 0: y) and (1, 2, 0: z). In this example, the first three fields identify the encoding symbol, where the first field is the block number, the second field is the symbol ID and the third field is the encoding flag. The value of the encoding symbol is written after the colon. Each block can be recovered from any 5 of the 8 encoding symbols associated with that block. For example, reception of (0, 1, 1: b), (0, 2, 1: c), (0, 3, 1: d), (0, 0, 0: p) and (0, 1, 0: q) are sufficient to recover the first source block and reception of (1, 0, 1: f), (1, 1, 1: g), (1, 0, 0: x), (1, 1, 0: y) and (1, 2, 0: z) are sufficient to recover the second source block. 2.3. Large block codes Tornado codes [LUB97] are block FEC erasure codes that provide an alternative to small block codes. A (n, k) Tornado code requires slightly more than k out of n encoding symbols to reassemble k source symbols. However, the advantage is that the value of k may be on the order of tens of thousands and still run efficiently. Because of memory considerations, in practice the value of n is restricted to be a small multiple of k, e.g., n = 2k. For example, [BYE98] describes an implementation of Tornado codes where the encoding and decoding speeds are proportional to 10 Mbytes/second to 80 Mbytes/second for Pentium class machines of various vintages when k is in the tens of thousands and n = 2k. The reception overhead for such values of k and n is in the 5-10% range. Tornado codes require a large amount of Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 7] Internet Draft RMT BB, Forward Error Correction Codes March 2000 out of band information to be communicated to all senders and receivers for each different object length, and require an amount of memory on the encoder and decoder which is proportional to the object length times 2n/k. Tornado codes are designed to have low reception overhead on average with respect to reception of a random portion of the encoding pack- ets. Thus, to ensure that a receiver can reassemble the object with low reception overhead, the packets are permuted into a random order before transmission. 2.4. On demand codes All of the FEC erasure codes described up to this point are block codes. There is a different type of FEC erasure code that we call on demand codes. Like block codes, an on demand encoder operates on an object of known size that is partitioned into equal length source symbols. Unlike block codes, there is no predetermined number of encoding symbols that can be generated for on demand codes. Instead, an on demand encoder can generate as few or as many encoding symbols as required on demand. Also unlike block codes, optimal on demand codes have the additional attractive property that encoding symbols for the same object can be generated and transmitted from multiple servers and concurrently received by a receiver and yet the receiver incurs a 0% reception overhead. LT codes are an example of a large on demand FEC code. An LT encoder uses randomization to generate each encoding symbol randomly and independently of all other encoding symbols. An LT encoder satisfies the on demand property, as it can generate as few or as many encoding symbols as required on demand. Let k be the number of source symbols that the object is partitioned into. An LT decoder has the property that with very high probability the receipt of any set of slightly more than k encoding symbols is sufficient to reassemble the object. Like Tornado codes, the value of k may be very large, i.e., on the order of tens or hundreds of thousands, and the encoder and decoder run efficiently in software. For example the encoding and decoding speeds for LT codes are proportional to 3 Mbytes/second to 20 Mbytes/second for Pentium class machines of various vintages when k is in the high tens of thousands. The reception overhead for such values of k is in the 2-4% range. When a new encoding symbol is to be generated, it is based on a key that uniquely describes how the encoding symbol is to be generated. Because encoding symbols are randomly and independently generated, LT codes have the property that encoding symbols for the same object can be generated and transmitted from multiple servers and concurrently received by a receiver with no more reception overhead than if all Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 8] Internet Draft RMT BB, Forward Error Correction Codes March 2000 the encoding symbols were generated by a single sender. There is a tradeoff between the number of source symbols and the reception overhead, and the larger the number of source symbols the smaller the reception overhead. Thus, for shorter objects, it is sometimes advantageous to include multiple symbols in each packet. Normally, and in the discussion below, there is only one symbol per packet. Like small block codes, there is a point when the object is large enough that it makes sense to partition it into blocks when using LT codes. Generally the object is partitioned into blocks whenever the number of source symbols times the packet payload length is less than the size of the object. Thus, if the packet payload is 1024 bytes and the number of source symbols is 64,000 then any object over 64 MB will be partitioned into more than one block. One can choose the number of source symbols to partition the object into, depending on the desired encoding and decoding speed versus reception overhead tradeoff desired. Encoding symbols can be uniquely identified by a block number (when the object is large enough to be partitioned into more than one block) and an encoding symbol ID. The block numbers, if they are used, are generally numbered consecutively starting from zero within the object. The range of possible values for an encoding symbol ID is orders of magnitude larger than the number of source symbols in a block, i.e., on the range of possible values is gen- erally in the billions. The block number and the encoding symbol ID are both chosen uniformly and randomly from their range when an encoding symbol is to be generated and transmitted. For example, suppose the number of source symbols is 64,000 and the number of blocks is 2. Then, each packet generated by the LT encoder could be of the form (b, x: y). In this example, the first two fields iden- tify the encoding symbol, where the first field is the block number b = 0 or 1 and the second field is the randomly chosen encoding symbol ID x. The value y after the colon is the value of the encoding sym- bol. 3. Passing FEC coding information to receivers There are two basic methods for passing FEC coding information to receivers in order to decode an object: within the IP multicast packet headers or through out of band methods. A description of the variety of out of band methods is outside the scope of this document. The FEC coding information can be classified as three types. FEC ses- sion information is information needed by the FEC decoder that may remain fixed for the transmission of many objects. FEC object transmission information is information particular to the object transmission session needed by the FEC decoder. The FEC payload ID identifies the symbols in the payload of the ALC packet. Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 9] Internet Draft RMT BB, Forward Error Correction Codes March 2000 FEC coding information include the FEC codec type, the source block length, the symbol length, the object length, the encoding block number, the encoding symbol ID, and an encoding flag indicating whether the encoding symbol is a source symbol or a redundant symbol. The FEC codec type, the source block length and the symbol length are often FEC session information, although they may classified as FEC object transmission information for some protocols. Thus, sometimes this information is passed to the receiver out of band, although they can equally well be included in each IP multicast packet header as long as the amount of space they take within each packet is minimal. The object length is part of FEC object transmission information. Depending on the protocol, the object length is passed to the receiver out of band or included within each IP multicast packet header. The FEC payload ID consists of the encoding block number (if used), the encoding symbol ID and the encoding flag. The FEC payload ID must be contained within each IP multicast packet header. 4. Security Considerations The use of FEC, in and of itself, imposes no additional security con- siderations versus sending the same information without FEC. How- ever, just like for any transmission system, a malicious sender may intentionally transmit bad symbols. If a receiver accepts one or more bad symbols in place of authentic ones then such a receiver will have its entire object download corrupted by the bad symbol. Application-level transmission object authentication can detect the corrupted transfer, but the receiver must then discard the transferred object. Thus, transmitting false symbols is at least an effective denial of service attack. At worst, a malicious sender could add, delete, or replace arbitrary data within the transmitted object. In light of this possibility, FEC receivers may screen the source address of a received symbol against a list of authentic transmitter addresses. Since source addresses may be spoofed, FEC transport pro- tocols may provide mechanisms for robust source authentication of each encoded symbol. Multicast routers along the path of a FEC transfer may provide the capability of discarding multicast packets that originated on that subnet, and whose source IP address does not correspond with that subnet. 5. Intellectual Property Disclosure Both Tornado codes and LT codes have patents pending. 6. References [AFZ95] Acharya, S., Franklin, M., and Zdonik, S., ``Dissemination- Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 10] Internet Draft RMT BB, Forward Error Correction Codes March 2000 Based Data Delivery Using Broadcast Disks'', IEEE Personal Communications, pp.50-60, Dec 1995. [BLA94] Blahut, R.E., ``Theory and Practice of Error Control Codes'', Addison Wesley, MA 1984. [BYE98] Byers, J.W., Luby, M., Mitzenmacher, M., and Rege, A., ``A Digital Fountain Approach to Reliable Distribution of Bulk Data'', Proceedings ACM SIGCOMM '98, Vancouver, Canada, Sept 1998. [DEE88] Deering, S., ``Host Extensions for IP Multicasting'', RFC 1058, Stanford University, Stanford, CA, 1988. [GEM99] Gemmell, J., Schooler, E., and Gray, J., ``ALC Scalable Multicast File Distribution: Caching and Parameters Optimizations'' Technical Report MSR-TR-99-14, Microsoft Research, Redmond, WA, April, 1999. [HAN98] Handley, M., and Jacobson, V., ``SDP: Session Description Protocol'', RFC 2327, April 1998. [HAN96] Handley, M., ``SAP: Session Announcement Protocol'', Internet Draft, IETF MMUSIC Working Group, Nov 1996. [LUB97] Luby, M., Mitzenmacher, M., Shokrollahi, A., Spielman, D., Stemann, V., ``Practical Loss-Resilient Codes'' 29th STOC'97. [LUB99] Luby, M., Vicisano, L., Speakman, T. ``Heterogeneous multicast congestion control based on router packet filtering'', presented at RMT meeting in Pisa, March 1999. [R2068] Fielding, R., Gettys, J., Mogul, J. Frystyk, H., Berners-Lee, T., Hypertext Transfer Protocol HTTP/1.1 (IETF RFC2068) http://www.rfc-editor.org/rfc/rfc2068.txt [R2119] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels (IETF RFC 2119) http://www.rfc-editor.org/rfc/rfc2119.txt [RIZ97a] Rizzo, L, and Vicisano, L., ``Reliable Multicast Data Distribution protocol based on software FEC techniques'', Proceedings of the Fourth IEEES Workshop on the Architecture and Implementation of High Performance Communication Systems, HPCS-97, Chalkidiki, Greece, June 1997. [RIZ97b] Rizzo, L., and Vicisano, L., ``Effective Erasure Codes for Reliable Computer Communication Protocols'', ACM SIGCOMM Computer Communication Review, Vol.27, No.2, pp.24-36, Apr 1997. Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 11] Internet Draft RMT BB, Forward Error Correction Codes March 2000 [RIZ97c] Rizzo, L., ``On the Feasibility of Software FEC'', DEIT Tech Report, http://www.iet.unipi.it/~luigi/softfec.ps, Jan 1997. [RUB99] Rubenstein, Dan, Kurose, Jim and Towsley, Don, ``The Impact of Multicast Layering on Network Fairness'', Proceedings of ACM SIGCOMM'99. [VIC98A] L.Vicisano, L.Rizzo, J.Crowcroft, ``TCP-like Congestion Control for Layered Multicast Data Transfer'', IEEE Infocom '98, San Francisco, CA, Mar.28-Apr.1 1998. [VIC98B] Vicisano, L., ``Notes On a Cumulative Layered Organization of Data Packets Across Multiple Streams with Different Rates'', University College London Computer Science Research Note RN/98/25, Work in Progress (May 1998). 7. Authors' Addresses Michael Luby luby@dfountain.com Digital Fountain 600 Alabama Street San Francisco, CA, USA, 94110 Lorenzo Vicisano lorenzo@cisco.com cisco Systems, Inc. 170 West Tasman Dr., San Jose, CA, USA, 95134 Luigi Rizzo luigi@iet.unipi.it Dip. di Ing. dell'Informazione Universita` di Pisa via Diotisalvi 2, 56126 Pisa, Italy Jim Gemmell jgemmell@microsoft.com Microsoft Research 301 Howard St., #830 San Francisco, CA, USA, 94105 Jon Crowcroft J.Crowcroft@cs.ucl.ac.uk Department of Computer Science University College London Gower Street, London WC1E 6BT, UK Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 12] Internet Draft RMT BB, Forward Error Correction Codes March 2000 Bruce Lueckenhoff brucelu@cadence.com [address here] Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 13] --==_Exmh_-17452598970-- >From owner-rmt@listserv.lbl.gov Fri Mar 10 13:01:28 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id MAA19330; Fri, 10 Mar 2000 12:59:30 -0800 (PST) Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA19326 for ; Fri, 10 Mar 2000 12:59:28 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA13719 for ; Fri, 10 Mar 2000 12:59:27 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA13716 for ; Fri, 10 Mar 2000 12:59:27 -0800 (PST) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [171.69.65.85]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA16103; Fri, 10 Mar 2000 12:58:55 -0800 (PST) Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA04438; Fri, 10 Mar 2000 12:59:35 -0800 (PST) Message-Id: <200003102059.MAA04438@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.0.2 2/24/98 To: Dah Ming Chiu - Sun Microsystems cc: sob@harvard.edu, vern@aciri.org, mankin@EAST.ISI.EDU, ark008@email.mot.com, rcoltun@siara.com, oran@cisco.com, brian@cs.umass.edu, bcain@nortelnetworks.com, mjh@aciri.org, whetten@talarian.com, Radia.Perlman@east.sun.com, Miriam.Kadansky@east.sun.com, rmt@lbl.gov Subject: Re: PIM-SO and RMT In-reply-to: Your message of "Fri, 10 Mar 2000 15:22:53 EST." <200003102022.PAA00543@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Mar 2000 12:59:35 -0800 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk Dah, The charter does not state that a "single source" model should be assumed, however it is very likely that the future multicast deployment will be largely based on single source. Moreover, the current heterogeneity of multicast deployment does not allow to assume the presence of multicast feedback (mainly because providers do not allow "normal" customers to source multicast). Nor it does allow to assume the presence of "dense mode" protocols only (and most of the techniques you mentioned only work with dense mode). For the above reasons, in the last meeting (at ACIRI) the group agreed (I think) to assume no multicast back-channel (protocols can still take advantage of it, if present, as an optimization). Note that this does not exactly mean "assume Single Source". I also have two personal remark: - establishing multicast distribution trees is much more expensive than using unicast, hence, I think, we should not abuse this --precious-- resource if possible. - most of the techniques you mentioned do not work well with multicast back-channel, unless you assume the presence of a dense mode protocol (and this is not the case). E.g. expanding ring search is broken (most of the times) in PIM-SM because, it common cases, packets have to reach the RP first. On the other side there are application level algorithms that make *all* these techniques work without multicast back channels. cheers, Lorenzo Vicisano > In the recent RMT Interim meeting in Berkeley, I learned from Brad Cain > that we have to assume the IP multicast infrastructure is PIM-SourceOnly > (or PIM-SO) and IGMPv3. In particular, this means we must assume that > only one host can multicast to a given group. This is confirmed by Mark > Handley and Roger Kermode (see the meeting minutes under "My dream protocol" > for example). > > Later in separate discussions in the TREE BB subgroup, some stated that > the PIM-SO (hence only one host can multicast per multicast address) > is part of the RMT working group charter. > > I am seeking a clear statement regarding this requirement. I don't see > "must assume PIM-SO" are part of the charter. If it is, can it be stated? > Is it mandated as a requirement for the RMT? Can someone succinctly > summarize what is the PIM-SO requirement on RMT, and justify it? > > I am pressing for this because the lack of many-to-many IP multicast > capability means a lot of techniques/algorithms reported in the literature > will not work any more. For example: > - A NACK protocol depends on the NACK be sent via multicast to suppress > redundant NACKs that cause implosion. > - Some tree building protocols use Expanding Ring Search (ERS) to nearby > servers. Although ERS is considered costly in terms of message overheads, > it can still be a useful autoconfiguration technique for many scenarios. > - In a tree-based ACK protocol (TRACK), the repair heads should be able to > share multicast addresses for sending out multicast repairs. This would > not be possible if only one host can send on a multicast address. > > I understand that in the current public Internet, limiting multicast to a > single sender fits certain business models of ISPs who can charge for > multicast. But this constraint is not needed in many intranet environments. > > I understand many people support the Simple Multicast model, under which > there is no single-source constraint. Is that proposal still being studied > by IETF? Also, what is happening to the BGMP model that allows dense mode > multicast in administrative domains? Is the PIM-SO requirement premature? > > Dah Ming Chiu > Sun Labs > > >From owner-rmt@listserv.lbl.gov Fri Mar 10 17:38:00 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id RAA21038; Fri, 10 Mar 2000 17:37:31 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA21034 for ; Fri, 10 Mar 2000 17:37:30 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA01804 for ; Fri, 10 Mar 2000 17:37:28 -0800 (PST) Received: from virtualworkshop.com (IDENT:root@dino.virtualworkshop.com [208.14.33.1]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA01801 for ; Fri, 10 Mar 2000 17:37:27 -0800 (PST) Received: from virtualworkshop.com (barney.virtualworkshop.com [208.14.33.4]) by virtualworkshop.com (8.9.1/8.8.7) with ESMTP id UAA16595; Fri, 10 Mar 2000 20:33:06 -0500 Message-ID: <38C9A253.D6D46902@virtualworkshop.com> Date: Fri, 10 Mar 2000 20:33:07 -0500 From: "Michael D. Myjak" Reply-To: mmyjak@virtualworkshop.com Organization: The Virtual Workshop, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Lorenzo Vicisano CC: Dah Ming Chiu - Sun Microsystems , sob@harvard.edu, vern@aciri.org, mankin@EAST.ISI.EDU, ark008@email.mot.com, rcoltun@siara.com, oran@cisco.com, brian@cs.umass.edu, bcain@nortelnetworks.com, mjh@aciri.org, whetten@talarian.com, Radia.Perlman@east.sun.com, Miriam.Kadansky@east.sun.com, rmt@lbl.gov Subject: Re: PIM-SO and RMT References: <200003102059.MAA04438@lorenzo-u10.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Lorenzo Vicisano wrote: > Dah, > > The charter does not state that a "single source" model should > be assumed, however it is very likely that the future multicast > deployment will be largely based on single source. I take issue with this statement; Its about as far-sighted as next week. How can you possibly say, with any assurance or credibility, that future multicast deployment will largely be based on single sources?? Are you not familiar with any of the on-going work in NASA's Integrated Synthetic Environments? DoEs Shared Collaboratories? or DoEd's Advanced Distributed Learning? Certainly to date, the predominate model has been point-to-multipoint. But this statement is as reassuring as "Certainly... 32-bits is more than enough address space." Oh Please... -- All the best - _ ___|0|_|___ Michael D. Myjak, Vice President R&D and CTO | N & W | The Virtual Workshop, Inc. = oo---oo = P.O. Box 98 Titusville Fl 32781 email: voice&fax: 321.264.0440 >From owner-rmt@listserv.lbl.gov Fri Mar 10 18:09:29 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id SAA21158; Fri, 10 Mar 2000 18:09:19 -0800 (PST) Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA21154 for ; Fri, 10 Mar 2000 18:09:18 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA05648 for ; Fri, 10 Mar 2000 18:09:17 -0800 (PST) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA05642 for ; Fri, 10 Mar 2000 18:09:16 -0800 (PST) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [171.69.65.85]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id RAA20398; Fri, 10 Mar 2000 17:56:58 -0800 (PST) Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA05057; Fri, 10 Mar 2000 18:09:24 -0800 (PST) Message-Id: <200003110209.SAA05057@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.0.2 2/24/98 To: mmyjak@virtualworkshop.com cc: Dah Ming Chiu - Sun Microsystems , sob@harvard.edu, vern@aciri.org, mankin@EAST.ISI.EDU, ark008@email.mot.com, rcoltun@siara.com, oran@cisco.com, brian@cs.umass.edu, bcain@nortelnetworks.com, mjh@aciri.org, whetten@talarian.com, Radia.Perlman@east.sun.com, Miriam.Kadansky@east.sun.com, rmt@lbl.gov Subject: Re: PIM-SO and RMT In-reply-to: Your message of "Fri, 10 Mar 2000 20:33:07 EST." <38C9A253.D6D46902@virtualworkshop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Mar 2000 18:09:24 -0800 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk > > The charter does not state that a "single source" model should > > be assumed, however it is very likely that the future multicast > > deployment will be largely based on single source. > > I take issue with this statement; Its about as far-sighted as next week. How > can > you possibly say, with any assurance or credibility, that future multicast > deployment will largely be based on single sources?? Are you not familiar wit >h any > of the on-going work in NASA's Integrated Synthetic Environments? DoEs Shared > Collaboratories? or DoEd's Advanced Distributed Learning? Michael, the context of my statement was in the RMT framework, which is bulk-data transfer for IP multicast (as currently specified). Moreover there was more in my email beside the statement that you are quoting... I agree with you that interactive applications work much better with a symmetric Multicast service and that this is probably the main the reason why we should keep working on its deployment. However this is out of the scope of RMT (please check the WG charter). Lorenzo Vicisano > > Certainly to date, the predominate model has been point-to-multipoint. But t >his > statement is as reassuring as "Certainly... 32-bits is more than enough addre >ss > space." Oh Please... > > > -- > All the best - > _ > ___|0|_|___ Michael D. Myjak, Vice President R&D and CTO > | N & W | The Virtual Workshop, Inc. > = oo---oo = P.O. Box 98 Titusville Fl 32781 > email: voice&fax: 321.264.0440 > > > >From owner-rmt@listserv.lbl.gov Fri Mar 10 19:04:55 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id TAA21297; Fri, 10 Mar 2000 19:04:32 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id TAA21293 for ; Fri, 10 Mar 2000 19:04:30 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id TAA10266 for ; Fri, 10 Mar 2000 19:04:29 -0800 (PST) Received: from virtualworkshop.com (IDENT:root@dino.virtualworkshop.com [208.14.33.1]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id TAA10258 for ; Fri, 10 Mar 2000 19:04:28 -0800 (PST) Received: from virtualworkshop.com (barney.virtualworkshop.com [208.14.33.4]) by virtualworkshop.com (8.9.1/8.8.7) with ESMTP id WAA16747; Fri, 10 Mar 2000 22:04:24 -0500 Message-ID: <38C9B7B9.4DD89566@virtualworkshop.com> Date: Fri, 10 Mar 2000 22:04:25 -0500 From: "Michael D. Myjak" Reply-To: mmyjak@virtualworkshop.com Organization: The Virtual Workshop, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Lorenzo Vicisano CC: RMT Subject: Re: PIM-SO and RMT References: <200003110209.SAA05057@lorenzo-u10.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Lorenzo, I read what you wrote... I'm just trying to earmark what's on the horizon. And I do understand that the RMT charter is highly focused toward a narrow-cast solution space. Be that as it may, the issue in my mind irrespective of that, is that that the prevailing mind set in this arena seems to be just as you stated - it prefers a closed, unidirectional, asymmetrical point-to-multipoint communications path which has little to no regard for application(s) performance (i.e., real-time). (In fact, the preferred application may be little more than a file or web site mirror.) Further, applications which are sufficiently "different" or fall outside of this groups perceived "mainstream" scope may yet evolve and attempt to utilize the approach developed here, whether we perceive it as applicable or not. (Ex. Distributed Interactive Simulation [IEEE-1278] used subnet broadcasting to accomplish what it could not using IP Multicast. Clearly, subnet broadcasting was never designed with such a (multipoint-to-multipoint) application in mind.) In short, all I'm trying to say is that we cannot assume that this (or any) specific application will be the only one(s) to use RMT. -- All the best - _ ___|0|_|___ Michael D. Myjak, Vice President R&D and CTO | N & W | The Virtual Workshop, Inc. = oo---oo = P.O. Box 98 Titusville Fl 32781 email: voice&fax: 321.264.0440 Lorenzo Vicisano wrote: > > > The charter does not state that a "single source" model should > > > be assumed, however it is very likely that the future multicast > > > deployment will be largely based on single source. > > > > I take issue with this statement; Its about as far-sighted as next week. How > > can > > you possibly say, with any assurance or credibility, that future multicast > > deployment will largely be based on single sources?? Are you not familiar wit > >h any > > of the on-going work in NASA's Integrated Synthetic Environments? DoEs Shared > > Collaboratories? or DoEd's Advanced Distributed Learning? > > Michael, > > the context of my statement was in the RMT framework, which is > bulk-data transfer for IP multicast (as currently specified). > Moreover there was more in my email beside the statement that > you are quoting... > > I agree with you that interactive applications work much better > with a symmetric Multicast service and that this is probably the > main the reason why we should keep working on its deployment. However > this is out of the scope of RMT (please check the WG charter). > > Lorenzo Vicisano > > > > > Certainly to date, the predominate model has been point-to-multipoint. But t > >his > > statement is as reassuring as "Certainly... 32-bits is more than enough addre > >ss > > space." Oh Please... > > > > > > -- > > All the best - > > _ > > ___|0|_|___ Michael D. Myjak, Vice President R&D and CTO > > | N & W | The Virtual Workshop, Inc. > > = oo---oo = P.O. Box 98 Titusville Fl 32781 > > email: voice&fax: 321.264.0440 > > > > > > >From owner-rmt@listserv.lbl.gov Sun Mar 12 23:24:00 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id XAA03052; Sun, 12 Mar 2000 23:21:14 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id XAA03048 for ; Sun, 12 Mar 2000 23:21:12 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id XAA21669 for ; Sun, 12 Mar 2000 23:21:10 -0800 (PST) Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id XAA21665 for ; Sun, 12 Mar 2000 23:21:10 -0800 (PST) Received: from tahoe (talarian32-66.talarian.com [207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id XAA26353; Sun, 12 Mar 2000 23:17:53 -0800 (PST) Message-Id: <4.1.20000312131129.0a957aa0@mailhost.talarian.com> X-Sender: bwhetten@mailhost.talarian.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 12 Mar 2000 15:51:34 -0800 To: mmyjak@virtualworkshop.com, Lorenzo Vicisano From: Brian Whetten Subject: Re: PIM-SO and RMT Cc: Dah Ming Chiu - Sun Microsystems , sob@harvard.edu, vern@aciri.org, mankin@EAST.ISI.EDU, ark008@email.mot.com, rcoltun@siara.com, oran@cisco.com, brian@cs.umass.edu, bcain@nortelnetworks.com, mjh@aciri.org, Radia.Perlman@east.sun.com, Miriam.Kadansky@east.sun.com, rmt@lbl.gov In-Reply-To: <38C9A253.D6D46902@virtualworkshop.com> References: <200003102059.MAA04438@lorenzo-u10.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rmt@lbl.gov Precedence: bulk >I take issue with this statement; Its about as far-sighted as next week. >How can >you possibly say, with any assurance or credibility, that future multicast >deployment will largely be based on single sources?? Are you not familiar >with any >of the on-going work in NASA's Integrated Synthetic Environments? DoEs Shared >Collaboratories? or DoEd's Advanced Distributed Learning? > >Certainly to date, the predominate model has been point-to-multipoint. But >this >statement is as reassuring as "Certainly... 32-bits is more than enough address >space." Oh Please... Mike, Even if a significant piece of multicast deployment eventually support many-many, there will still be a big piece that does NOT. We have to design to the least common denominator. As a side note, we'd all love to see many-many worldwide multicast, but I think there is growing consensus that it is extremely difficult to justify it economically. The costs are too high (the inter-domain issue is just too much) and the benefits too low (there are much easier way to implement many-many apps on top of 1-many multicast...Talarian has customers deployed with 10K client many-many environments). This does NOT mean that there are no compelling, scaleable many-many apps...just that we don't necessarily need to support them with true many-many multicast. Brian >From owner-rmt@listserv.lbl.gov Mon Mar 13 01:02:18 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id BAA03223; Mon, 13 Mar 2000 01:02:03 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA03219 for ; Mon, 13 Mar 2000 01:02:01 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA26984 for ; Mon, 13 Mar 2000 01:01:57 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id BAA26981 for ; Mon, 13 Mar 2000 01:01:56 -0800 (PST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 13 Mar 2000 08:57:11 +0000 To: Brian Whetten cc: mmyjak@virtualworkshop.com, Lorenzo Vicisano , Dah Ming Chiu - Sun Microsystems , sob@harvard.edu, vern@aciri.org, mankin@EAST.ISI.EDU, ark008@email.mot.com, rcoltun@siara.com, oran@cisco.com, brian@cs.umass.edu, bcain@nortelnetworks.com, mjh@aciri.org, Radia.Perlman@east.sun.com, Miriam.Kadansky@east.sun.com, rmt@lbl.gov Subject: Re: PIM-SO and RMT In-reply-to: Your message of "Sun, 12 Mar 2000 15:51:34 PST." <4.1.20000312131129.0a957aa0@mailhost.talarian.com> Date: Mon, 13 Mar 2000 08:57:09 +0000 Message-ID: <2208.952937829@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk >>environments). This does NOT mean that there are no compelling, scaleable >>many-many apps...just that we don't necessarily need to support them with >>true many-many multicast. Brian yes... i think another argument can show that we have a deployment credibility problem with the internet standard multicast service model ....we're already having a lot of ISPs clamp down on source addresses for unicast traffic so that they can rapidly respond to Denial of Service attacks - whatever the pro many=-to=many multicast people say (and i am one of them, believe me), its at least n-fold harder to audit n sources than 1... in fact ,there is going to be at least a BOF in adelaide on this topic - i wonder if any multicast considerations are going to be represented there? cheers jon >From owner-rmt@listserv.lbl.gov Mon Mar 13 03:20:18 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA03412; Mon, 13 Mar 2000 03:19:29 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA03408 for ; Mon, 13 Mar 2000 03:19:27 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA04064 for ; Mon, 13 Mar 2000 03:19:26 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA04061 for ; Mon, 13 Mar 2000 03:19:25 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15271; Mon, 13 Mar 2000 06:19:22 -0500 (EST) Message-Id: <200003131119.GAA15271@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rmt@lbl.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rmt-pi-alc-00.txt Date: Mon, 13 Mar 2000 06:19:21 -0500 Sender: owner-rmt@lbl.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Multicast Transport Working Group of the IETF. Title : Asynchronous Layered Coding A scalable reliable multicast protocol Author(s) : M. Luby, L. Vicisano et.al Filename : draft-ietf-rmt-pi-alc-00.txt Pages : 28 Date : 10-Mar-00 This document describes Asynchronous Layered Coding, a scalable reli- able multicast protocol, hereafter referred to as ALC. ALC can be used to reliably transmit objects to multiple receivers. An object can be any well-defined piece of data. Examples include any type of file such as a group of pictures in an MPEG stream, a MP3 music file, a JPEG image, and a collection of files that are zipped into one file. In addition, the ALC delivery model is fairly flexible, e.g., on demand or a push delivery. When using ALC, the payload of the packets that flow from senders to receivers in no way depend on net- work conditions or the reaction of receivers to these conditions, although the rate of flow of the packets in various parts of the net- work does depend on network conditions. Receivers may join or leave an existing packet stream in an asynchronous manner independent of other receivers. Congestion control is achieved by sending several packet streams ordered in a layered fashion and delivering only a subset of these to individual receivers. The number of streams received is dictated by the local bandwidth availability and network conditions. A possible way to achieve this is by using a distinct multicast address for each stream. Receivers join the lowest layer stream they are not currently joined to at coordinated points in time when there is more available bandwidth between those receivers and the sender. Similarly, receivers leave one or more highest layer streams they are currently joined to as soon as they feel congestion (typically as evidenced by packet loss). Another possibility to achieve this form of congestion control is through router-assisted schemes. Reliability is achieved via FEC coding only, i.e. there is no request for feedback for retransmission from receivers that miss packets for whatever reason. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-alc-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rmt-pi-alc-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmt-pi-alc-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000310135058.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-pi-alc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-pi-alc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000310135058.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Mon Mar 13 03:20:18 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA03418; Mon, 13 Mar 2000 03:19:35 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA03414 for ; Mon, 13 Mar 2000 03:19:33 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA04080 for ; Mon, 13 Mar 2000 03:19:32 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA04076 for ; Mon, 13 Mar 2000 03:19:31 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15339; Mon, 13 Mar 2000 06:19:28 -0500 (EST) Message-Id: <200003131119.GAA15339@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rmt@lbl.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rmt-bb-fec-00.txt Date: Mon, 13 Mar 2000 06:19:28 -0500 Sender: owner-rmt@lbl.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Multicast Transport Working Group of the IETF. Title : Reliable Multicast Transport Building Block: Forward Error Correction Codes Author(s) : M. Luby, L. Vicisano et.al Filename : draft-ietf-rmt-bb-fec-00.txt Pages : 14 Date : 10-Mar-00 This memo describes the use of Forward Error Correction (FEC) codes within the context of reliable IP multicast transport and provides an introduction to some commonly-used FEC codes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-fec-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rmt-bb-fec-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmt-bb-fec-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000310135108.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-fec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-fec-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000310135108.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Wed Mar 15 03:27:44 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA13025; Wed, 15 Mar 2000 03:25:32 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA13021 for ; Wed, 15 Mar 2000 03:25:29 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA27008 for ; Wed, 15 Mar 2000 03:25:29 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA27000 for ; Wed, 15 Mar 2000 03:25:26 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29694; Wed, 15 Mar 2000 06:25:25 -0500 (EST) Message-Id: <200003151125.GAA29694@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rmt@lbl.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rmt-gra-arch-01.txt Date: Wed, 15 Mar 2000 06:25:24 -0500 Sender: owner-rmt@lbl.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Multicast Transport Working Group of the IETF. Title : Generic Router Assist (GRA) Building Block Motivation and Architecture Author(s) : B. Cain, T. Speakman, D. Towsley Filename : draft-ietf-rmt-gra-arch-01.txt Pages : 21 Date : 14-Mar-00 Generic Router Assist (GRA) is a network-based service that enables end-to-end multicast transport protocols to take advantage of infor- mation distributed across the network elements in a given multicast distribution tree. The service consists of a canonical set of simple functions which network elements may apply to selected packets in the transport session as they traverse the distribution tree. The choice of function and the packet parameters to which it is applied can be defined and customized for a given transport session in a highly con- trolled fashion that still permits enough flexibility for GRA to be used to address a wide range of multicast transport problems not amenable to end-to-end solution. This document provides the motiva- tion and an architecture for GRA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-gra-arch-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rmt-gra-arch-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmt-gra-arch-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000314133149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-gra-arch-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-gra-arch-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000314133149.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Thu Mar 16 13:25:29 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id NAA24737; Thu, 16 Mar 2000 13:21:10 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA24733 for ; Thu, 16 Mar 2000 13:21:08 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA08479 for ; Thu, 16 Mar 2000 13:21:07 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA08472 for ; Thu, 16 Mar 2000 13:21:06 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24101; Thu, 16 Mar 2000 16:21:02 -0500 (EST) Message-Id: <200003162121.QAA24101@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rmt@lbl.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rmt-buildingblocks-02.txt Date: Thu, 16 Mar 2000 16:21:01 -0500 Sender: owner-rmt@lbl.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Multicast Transport Working Group of the IETF. Title : Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer Author(s) : B. Whetten, M. Handley, S. Floyd, R. Kermode, L. Vicisano, M. Luby Filename : draft-ietf-rmt-buildingblocks-02.txt Pages : 21 Date : 15-Mar-00 This document describes a framework for the standardization of bulk-data reliable multicast transport. It builds upon the experience gained during the deployment of several classes of contemporary reliable multicast transport, and attempts to pull out the commonalities between these classes of protocols into a number of building blocks. To that end, this document recommends that certain components that are common to multiple protocol classes be standardized as 'building blocks.' The remaining parts of the protocols, consisting of highly protocol specific, tightly intertwined functions, shall be designated as 'protocol cores.' Thus, each protocol can then be constructed by merging a 'protocol core' with a number of 'building blocks' which can be re-used across multiple protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-buildingblocks-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rmt-buildingblocks-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmt-buildingblocks-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000315132959.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-buildingblocks-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-buildingblocks-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000315132959.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Thu Mar 16 13:25:29 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id NAA24743; Thu, 16 Mar 2000 13:21:15 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA24739 for ; Thu, 16 Mar 2000 13:21:13 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA08503 for ; Thu, 16 Mar 2000 13:21:13 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA08496 for ; Thu, 16 Mar 2000 13:21:12 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24145; Thu, 16 Mar 2000 16:21:08 -0500 (EST) Message-Id: <200003162121.QAA24145@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rmt@lbl.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rmt-design-space-01.txt Date: Thu, 16 Mar 2000 16:21:08 -0500 Sender: owner-rmt@lbl.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Multicast Transport Working Group of the IETF. Title : The Reliable Multicast Design Space for Bulk Data Transfer Author(s) : M. Handley, S. Floyd, B. Whetten, R. Kermode, L. Vicisano Filename : draft-ietf-rmt-design-space-01.txt Pages : 21 Date : 15-Mar-00 The design space for reliable multicast is rich, with many possible solutions having been devised. However, application requirements serve to constrain this design space to a relatively small solution space. This document provides an overview of the design space and the ways in which application constraints affect possible solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-design-space-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rmt-design-space-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmt-design-space-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000315133011.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-design-space-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-design-space-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000315133011.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Fri Mar 17 13:18:21 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id NAA29378; Fri, 17 Mar 2000 13:17:24 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA29374 for ; Fri, 17 Mar 2000 13:17:22 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA19329 for ; Fri, 17 Mar 2000 13:17:21 -0800 (PST) Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA19322 for ; Fri, 17 Mar 2000 13:17:20 -0800 (PST) Received: from [132.250.92.151] (manimac.itd.nrl.navy.mil [132.250.92.151]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA23979 for ; Fri, 17 Mar 2000 16:17:17 -0500 (EST) Mime-Version: 1.0 X-Sender: adamson@pop.itd.nrl.navy.mil Message-Id: Date: Fri, 17 Mar 2000 16:17:15 -0500 To: RMT From: Brian Adamson Subject: Initial draft of NACK-Oriented Reliable Multicast Building Blocks Content-Type: multipart/mixed; boundary="============_-1258794657==_============" Sender: owner-rmt@lbl.gov Precedence: bulk --============_-1258794657==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" RMT: We go bounced on the draft submission deadline, but since we will probably provide an update on it in Adeleide, attached is an initial cut at a Building Blocks document for NACK-oriented Reliable Multicast. best regards, --============_-1258794657==_============ Content-Id: Content-Type: text/plain; name="draft-ietf-rmt-norm-bb-00.txt"; charset="us-ascii" ; format="flowed" Content-Disposition: attachment; filename="draft-ietf-rmt-norm-bb-00.txt" ; modification-date="Fri, 17 Mar 2000 14:40:08 -0500" RMT Working Group B. Adamson INTERNET-DRAFT C. Borman draft-ietf-rmt-norm-bb-00.txt S. Floyd Expires: Jul 2000 M. Handley J. Macker 15 March 2000 NACK-Oriented Reliable Multicast (NORM) Protocol Building Blocks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other docu- ments at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo describes issues related to the creation of NACK-oriented reliable multicast protocols (NORM). The general goals and assump- tions for NORM are defined. Some issues related to NACK-oriented (and in some cases general) reliable multicast protocol design are identified. These issues are resolved into a number of "building block" components which are described in further detail. It is anticipated that these building block components (as they are fur- ther refined and defined in future revisions of this document) will be useful in generating different instantiations of NACK-oriented reliable multicast protocols. Adamson, Borman, et al. Expires September 2000 [Page 1] Internet Draft NORM Building Blocks March 2000 1.0 Background Reliable multicast transport is a desirable technology for the efficient and reliable distribution of data to a group on the Internet. The complexity of group communication paradigms necessi- tates the creation of different protocol types and instantiations to meet the range of performance and scalability requirements of different potential reliable multicast applications and users [Mankin98]. Properly designed negative acknowledgement (NACK) based reliable multicast protocols offer scalability advantages for applications and/or network topologies where, for various reasons, it is prohibitive to construct a higher order delivery infrastruc- ture above the basic Layer 3 IP multicast service (e.g. unicast or hybrid unicast/multicast data distribution trees). Additionally, the scalability property of NACK-oriented protocols [Pingali93, Levine96] may be applicable where broad "fanout" is expected for a single network hop (e.g. cable-TV data delivery, satellite, or other broadcast communication communication services). Further- more, the simplicity of a protocol based on "flat" group-wide mul- ticast distribution may offer advantages for a broad range of dis- tributed services or dynamic networks and applications. While different protocol instantiations may be required to meet specific application and network architecture demands [Clark90], there are a number of fundamental components which may be common to these different instantiations. This document describes the frame- work and common "building block" components relevant to multicast protocols based primarily on NACK operation for reliable transport. 2.0 Goals and Assumptions Each potential protocol instantiation derived from the building blocks presented here (and other applicable building block docu- ments) will have specific criteria which will influence individual protocol design. To support the development of applicable building blocks, it is useful to define the categories of these driving pro- tocol design goals and assumptions. Some general categories which are likely to impact protocol instantiation design are described in the sections below. These are areas which each protocol instantia- tion will need to address. 2.1 Data content model The implicit goal of a reliable multicast protocol is the reliable delivery of "data" among a group of participants communicating through IP multicast datagram service. However, the nature of the data content and the service the application is attempting to pro- vide can impact design decisions. The service model may range from Adamson, Borman, et al. Expires September 2000 [Page 2] Internet Draft NORM Building Blocks March 2000 long-lived transfer sessions of bulk quantities of data (file broadcast) to more interactive exhanges of small messages (e.g. white-boarding, text chat). And within those different models there are other issues such as the sender's ability to cache trans- mitted data (or state referencing it) for retransmission or repair. The need for ordering and/or causality in the sequence of transmis- sions/receptions among participants in the group can be a function of the data content. The group communication paradigm differs sig- nificantly from the point-to-point model in that, depending upon the data content type, some receivers may complete reception of a portion of data content and be able to act upon it before other participants have received the content. This may be acceptable (or even desirable) for some applications but not for others. These varying requirements drives the need for a number of different pro- tocol instantiation designs. A significant challenge in developing generally useful building block mechanisms is accommodating even a limited range of these capabilities without defining specific application-level details. Note that this particular building block "guideline" may be gener- ally applicable beyond the realm of NACK-oriented reliable multi- cast. 2.2) Group membership dynamics Group communication can differ from point-to-point communications with respect to the fact that even if the composition of the group changes, the "thread" of communication can still exist. This con- trasts with the point-to-point communication model where, if either of the two parties leave, the communication process (exchange of data) is terminated (or at least paused). Depending upon applica- tion goals, senders and receivers participating in a reliable mul- ticast transport "session" may be able to join late, leave, and/or potentially rejoin while the ongoing group communication "thread" still remains functional and useful. Also note that this can impact protocol message content. If "late joiners" are supported, some amount of additional information may be placed in message headers to accommodate this functionality. Alternatively, the information may be sent in its own message (on demand or intermittently) if the impact to the overhead of typical message transmissions is deemed too great. Group dynamics can also impact other protocol mechanisms such as NACK or other timing, con- gestion control operation, etc. 2.3) Sender/receiver relationships The relationship of senders and receivers among group participants Adamson, Borman, et al. Expires September 2000 [Page 3] Internet Draft NORM Building Blocks March 2000 requires consideration. In some applications, there may be a sin- gle sender multicasting to a group of receivers. In other cases, there may be more than one sender or the potential for everyone in the group to be a sender _and_ receiver of data may exist. 2.4) Group size Native IP multicast [Deering89] may scale to extremely large group sizes. It may be desirable for some applications to be able to scale along with the multicast infrastructure's ability to scale. In its simplest form, there are limits to the group size to which a NACK-oriented protocol can apply without NACK implosion problems, but with the potential for router assistance or other non-linear NACK suppression mechanisms, these protocols may scale to very large group sizes. In large scale cases, it may be prohibitive for participants to maintain state on all other participants (in par- ticular, other receivers) in the group. The impact of group size needs to be considered in the development of generally applicable building blocks. 2.5) Data delivery performance There is a trade-off between scalability and data delivery latency when designing NACK-oriented protocols. If NACK suppression is to be used, there will be some delays built into the NACK generation and repair transmission process to allow suppression to occur and for the sender of data to identify appropriate content for effi- cient repair transmission. For example, backoff timeouts can be used to ensure efficient NACK suppression and repair transmission, but this comes at a cost of increased delivery latency and increased buffering requirements for both senders and receivers. The building blocks should allow applications to establish bounds for data delivery performance. Note that application designers must be aware of the scalabilty trade-off which is made when such bounds are applied. 2.6) Network topology The Internet Protocol has historically assumed a role of providing service across heterogeneous network topologies. It is desirable that a reliable multicast protocol be capable of effectively oper- ating across a wide range of the networks to which general purpose IP service applies. Recently, a number of asymmetric network ser- vices including 56K/ADSL modems, CATV Internet service, satellite and other wireless communication services have begun to prolifer- ate. Many of these are inherently broadcast media with potentially large "fanouts" to which IP multicast service is highly applicable. Adamson, Borman, et al. Expires September 2000 [Page 4] Internet Draft NORM Building Blocks March 2000 Additionally, policy and/or technical issues may result in topolo- gies where multicast connectivity is limited to a single logical direction from a specific source or set of sources to the group at large. Receivers in the group may be restricted to unicast feed- back for NACKs and other messages. Consideration must be given, in building block development and protocol design, to the nature of the underlying networks over which the protocols may be operating. 2.7) Router/Intermediate System Assistance While intermediate assistance from devices/systems with direct knowledge of the underlying network topology may used to leverage the performance and scalability of reliable multicast protocols, there will continue to be a number of instances where this is not available or practical. Any building block components for NACK- oriented reliable multicast should be capable of operating without such assistance but should also be capable of utilizing these fea- tures when available. 3.0 Building Block Areas (Aside: OK. We've presented in general what building blocks are intended to be and some of the critera which may affect building block identification/ design. So now let's list possible building blocks. Some of these may be unique to NACK-oriented protocols while some may be more generally applicable) This section describes different building block areas applicable to NACK-oriented reliable multicast protocols. Some of these areas are specific to NACK-oriented protocols. Detailed descriptions of such areas are provided below. In other cases, the areas (e.g. node identifiers, FEC, etc) may be generally applicable to other forms of reliable multicast. In those cases, the discussion below describes requirements placed on those other general building block areas from the standpoint of NACK-oriented reliable multicast. For the individual building blocks to be incorporated as part of a specific protocol instantiation, it expected that a description of some notional "interface" to the building blocks' functionality be provided. For example, a building block component may require some form of "input" from another building block component or other source in order to perform its function. Any "inputs" required by each building block component and/or any resultant "output" pro- vided by the building block will be defined and described as the building block component's interface definition. The following building block areas are described below: Adamson, Borman, et al. Expires September 2000 [Page 5] Internet Draft NORM Building Blocks March 2000 (NACK-Oriented Components) 1) Sender transmission 2) NACK-oriented Repair Process 3) "Late-joining" Receiver Policies and Mechanisms (Generally-applicable Conponents) 4) Participant Identification 5) Data Content Identification 6) Forward Error Correction 7) Round-trip Timing Collection 8) Group Size Determination/Estimation 9) Congestion Control Operation 10) Router/Intermediate System Assistance 11) Additional Protocol Mechanisms 3.1 Sender transmission Senders will transmit data content to the multicast session. The data content will be application dependent. The sender will trans- mit data content at a rate and with packet sizes determined by application and/or network architecture requirements. When conges- tion control mechanisms are used (recommended), the transmission rate will be controlled by the congestion control mechanism. It is recommended that all data transmissions from senders be subject to rate limitations determined by the application or congestion con- trol algorithm. The sender's transmissions should make good utl- ization of the available capacity (either application or congestion control specified). As a result, it is expected there will be overlap and multiplexing of new data content transmission with repair content. Other sender messages or commands may be employed as part of proto- col operation. For NACK-oriented operation, the reliability of any such commands may depend upon redundant transmission. Other fac- tors related to NACK-oriented operation may determine sender trans- mission formats and methods. Some consideration may need to be given to the sender's behavior during intermittent idle periods when it has no data to transmit. While many aspects may be proto- col-specific, there are techniques which may be generally applica- ble to NACK-oriented reliable multicast. For example, the period- icity of redundant transmission of command messages issued by a sender should be dependent upon the greatest round trip timing estimate and the resultant NACK operation. More specifically, a command message might be redundantly transmitted by a sender to indicate that it is temporarily (or permanently) halting transmis- sion. At this time, it may be appropriate for receivers to respond with NACKs for any outstanding repairs they require following the rules of the NACK process described below. For efficiency, the Adamson, Borman, et al. Expires September 2000 [Page 6] Internet Draft NORM Building Blocks March 2000 sender whould allow sufficient time between redundant transmissions to receive any NACK-oriented responses from the receiver set to this command. Other protocol components may benefit from a similar approach. Inputs: 1) Data content 2) Segmentation size 3) Transmission rate Outputs: 1) Rate-controlled stream of packets with headers uniquely identifying data or repair content within the context of the reliable multicast session. 3.2 NACK-oriented repair process The most critical component of the NACK-oriented reliable multicast protocol building block is the NACK repair process. There are four primary elements of a general NACK repair process: 1) Method for determining when receivers will initiate the NACK process in response to sender transmission for which they need repair. 2) NACK message content. 3) NACK suppression mechanisms to promote scalability of the protocol. 4) Sender NACK reception, aggregation, and repair response. 3.2.1 NACK Process Initiation The NACK process (cycle) will be initiated by receivers who detect they require repair transmissions from a specific sender at defined opportunities. When FEC is applied, a NACK cycle should only be initiated when it is known by the receiver that its repair require- ments exceed the amount of FEC pending transmission for a given coding block of packets. This may be determined by the receiver if the sender's transmission advertises the quantity of repair packets it is already planning to send for a block, and/or at the end of the current transmission block (if it is indicated) or at the start of subsequent coding block for packets transmitted within the con- text of a designed data content set (See object/stream data content identifier discussion below). Allowing receivers to initiate NACK cycles at any time they detect Adamson, Borman, et al. Expires September 2000 [Page 7] Internet Draft NORM Building Blocks March 2000 their repair needs have exceeded pending repair transmissions may result in slightly quicker repair cycles. However, it may be use- ful to limit the initiation opportunities to specific events such as at the end-of-transmission of an FEC coding block (or alterna- tively at detection of subsequent coding blocks). This can allow for a degree of synchronization among receivers requesting repair and may increase the effectiveness of timer-based NACK suppression mechanisms. In either case, the NACK cycle should begin with receivers observing backoff timeouts to facilitate NACK suppression as described below. Interface Description Inputs: 1) Object/stream data content and sequencing identifiers from sender transmissions. Outputs: 1) NACK Process Initiation Decision 3.2.2 NACK Content (TBD - Note this will be driven by the data content identification means used. Certainly, FEC repair counts will be needed, but encoding of more explicit repair information may be useful for other purposes (e.g. decorrelating loss clusters to help congestion control mechanism identify bottlenecks.) 3.2.3 NACK Suppression Mechanisms A primary NACK suppression mechanism is the use of initial backoff timeouts by receivers wishing to transmit NACK messages[Floyd95]. Upon expiration of the timeout, a receiver will transmit a NACK unless the content of his pending repair request is completely superseded by NACK messages heard from other receivers (when receivers are multicasting NACKs) or from some indicator from the sender . (Note: When receivers are unicasting NACK messages, the sender may facilitate NACK suppression by forwarding appropriate NACKs it has received to the group at large or provide some other indicator of repair information it will be subsequently transmit- ting). The backoff timeout periods used by receivers should be indepen- dently, randomly picked by receivers with an exponential distribu- tion [Nonnemacher98]. This results in the bulk of the receiver set holding off transmission of NACK messages under the assumption that Adamson, Borman, et al. Expires September 2000 [Page 8] Internet Draft NORM Building Blocks March 2000 the smaller number of "early NACKers" will supersede the repair needs of the remainder of the group. The mean of the distribution should be determined as a function of the current estimate of sender<->group greatest round trip time (GRTT) and a group size estimate which could be determined by other mechanisms within the protocol (See discussion below) or preset by the multicast applica- tion. (This function TBD) For small group sizes (and even for large group sizes) the tail of the distribution should be hard-limited so that repair requests are deterministically transmitted within some desirable interval. Additionally, the buffering limitations of sender and receiver applications may dictate some bound on the time limits for receiver NACK backoff timeouts (and sender repair aggre- gation holdoff timeouts). Note that these factors affect scalabil- ity of the protocol to large group sizes due to increased potential for NACK implosion. There are some secondary NACK suppression mechanisms which can be considered. For example, the sender's transmissions follow some ordinal sequence of transmission (observed through data/repair con- tent and/or ) which is "rewound" during repair transmissions. Receivers may wish to limit transmission of their NACKs only when the sender's current sequence of transmission passes the point at which the receiver has incomplete transmis- sions, thus reducing premature requests for repair of data the sender may be providing in response to other receiver requests. This mechanism can be very effective for protocol convergence in high loss conditions when transmissions of NACKs from other receivers (or indicators from the sender) are lost. Another mecha- nism (particularly applicable when FEC is used) is for the server to embed an indication of impending repair transmissions in current packets sent. For example, the indication may be as simple as an advertisment of the number of FEC packets to be sent for the cur- rent applicable coding block. Finally, some consideration might be given to using the NACKing history of receivers to weight their selection of NACK backoff timeout intervals. For example, if a receiver has historically been experiencing the greatest degree of loss, it may promote itself to statistically NACK sooner than other receivers. Note this assumes there is some degree of correlation over successive intervals of time in the loss experienced by receivers. This adjustment of backoff timeout selection may require the creation of an "early NACK" slot for these historical NACKers. This additional slot in the NACK backoff window will result in a longer repair cycle process which may not be desirable for some applications. The resolution of these trade-offs may be dependent upon the protocol's target application set or network. Interface Description Adamson, Borman, et al. Expires September 2000 [Page 9] Internet Draft NORM Building Blocks March 2000 Inputs: 1) Group greatest round trip time estimate (GRTT). 2) Group size estimate. 3) Application-defined bound on backoff timeout period. 4) NACKs from other receivers. 5) Pending repair indication from sender (may be forwarded NACKs). 6) Current sender transmission position. Outputs: 1) Yes/no decision to generate NACK message upon backoff timer expiration. 3.2.4 Sender NACK Processing and Repair Response Upon reception of a repair request from a receiver in the group, the sender will initiate a repair response procedure. The sender may wish to delay transmission of repair content until it has had sufficient time to accumulate potentially multiple NACKs from the receiver set. This allows the sender to determine the most effi- cient repair strategy for a given transport stream/object or FEC coding block. Depending upon the approach used, some protocols may find it beneficial for the sender to provide an indicator of pend- ing repair transmissions as part of the its current transmitted message content. This can aid some NACK suppression mechanisms. Alternatively, in the case of unicast feedback from the receiver set, it may be useful for the sender to forward (via multicast) superseding NACK messages to the group to allow for NACK suppres- sion when there is not multicast connectivity among the receiver set. When FEC is used, it is beneficial that the sender transmit previ- ously untransmitted parity content whenever possible. This maxi- mizes the receiving nodes' ability to reconstruct the entire trans- mitted content from their individual subsets of received messages. The transmitted he object and/or stream content will be marked with monotonically increasing sequence numbers (within a reasonably large ordinal space). If the sender observes the discipline of transmitting repair for the earliest content first, the receivers can use a strategy of witholding repair requests for later content until the sender once again returns to that point in the object/stream transmission sequence. This can increase overall message efficiency among the group and help work to keep repair cycles relatively synchronized without dependence upon strict tim- ing. This also helps minimize the buffering requirements of Adamson, Borman, et al. Expires September 2000 [Page 10] Internet Draft NORM Building Blocks March 2000 receivers and senders and reduces redundant transmission of data to the group at large. Interface Description Inputs: 1) Receiver NACKs 1) Group timing information Outputs: 1) Repair messages (FEC and/or Data content retransmission) 3.3 Group "Join" Policy/ Procedure (TBD - What does the protocol need to do accommodate group member- ship dynamics? For example, what policies do receivers need to abide by to join a group and begin NACKing? What information needs to be advertised in protocol message headers so that a receiver can efficiently join a session in progress? etc) Inputs: 1) Current object/stream data/repair content and sequencing identifiers from sender transmissions. Outputs: 1) Receiver yes/no decision to begin receiving and NACKing for reliable reception of data 3.4 Reliable multicast participant identification In a NACK-based reliable multicast protocol (or other multicast protocols) where there is the potential for multiple sources of data, it is necessary to provide some mechanism to uniquely iden- tify the sources (and possibly some or all receivers in some cases) within the group. Identity based on arriving packet source addresses is insufficient for several reasons. These reasons include routing changes for hosts with multiple interfaces which result different packet source addresses for a given host over time, network address translation (NAT) or firewall devices, or other transport/network bridging approaches. As a result, some type of unique source identifier (sourceId) field should be present in packets transmitted by reliable multicast session participants. 3.5 Data content identification Adamson, Borman, et al. Expires September 2000 [Page 11] Internet Draft NORM Building Blocks March 2000 The data content transmitted by the multicast sender requires some form of identification in the protocol header fields. This identi- fication is required to facilitate the reliable NACK-based repair process. These identifiers will be used in NACK messages gener- ated. There are two very general types of data which may comprise bulk transfer session content. These data types are static objects of finite size and continuous non-finite streams. A given application may wish to reliably multicast data content using either one or both of these data models. While it may be possible for some applications to further generalize this model and provide mecha- nisms to encapsulate static objects as content embedded within a stream, there are advantages to many applications to provide dis- tinct support for static bulk objects and messages with the context of a reliable multicast session. These applications may include content caching servers, file transfer or collaborative tools with bulk content. Applications with requirements for these static object types can then take advantage of transport layer mechanisms (i.e. segmentation/reassembly, caching, integrated forward error correction coding, etc) rather than being required to provide their own mechanisms for these functions at the application layer. As noted, some applications may alternatively desire to transmit bulk content in the form of one or more streams of non-finite size. Example streams include continuous quasi-realtime message broad- casts (e.g. stock ticker) or some content types which are part of collaborative tools or other more complex applications. And, as indicated above, some applications may wish to encapsulate other bulk content (e.g. files) into one more streams within a multicast session. Additionally, multiple streams can allow for parallized transmission within the context of a single multicast session. The components described within this building block draft document are envisioned to be applicable to both of these models with the potential for a mix of both types within a single multicast ses- sion. To support this requirement, the normal data content identi- fication should include a field to uniquely identify the object or stream within some reasonable temporal or ordinal interval. Note that it is _not_ expected that this data content identification will be globally unique. It is expected that the object/stream identifier will be unique with respect to a given sender within the reliable multicast session. Since the "bulk" object/stream content will generally require seg- mentation, some form of segment identification must also be pro- vided. This segment identifier will be relative to any object or stream identifier which has been provided. Thus, in some cases, Adamson, Borman, et al. Expires September 2000 [Page 12] Internet Draft NORM Building Blocks March 2000 NACK-based protocol instantiations may be able to receive transmis- sions of and NACK for repair of multiple streams and one (or possi- bly more) sets of static objects in parallel. Additionally, flags to determine the usage of the content identi- fier fields (e.g. stream vs. object) may be applicable. Flags may also serve other purposes in data content identification. It is expected that any flags defined will be dependent upon individual protocol instantiations. In summary, the following data content identifiers may be required to NACK-based protocols: 1) Object/Stream identifier () 2) Segment identifier () 3) Flags to differentiate interpretation of identifier fields or identifier structure which implicitly indicates usage. These fields have been identified since any generated NACK messages will use these identifiers in requesting repair or retransmission of data. NACK-based protocols are expected to greatly benefit from interaction with other reliable multicast building blocks (Generic Router Assist(GRA), in particular) and those other building blocks will need to appropriately consider these anticipated requirements. 3.6 Forward Error Correction Multiple forward error correction (FEC)approaches have be identi- fied which can provide great performance enhancements to the repair process of NACK-based and other reliable multicast protocols [Met- zner84, Macker97]. NACK-based protocols can reap additional bene- fits since FEC-based repair does not _generally_ require explicit knowledge of repair content within the bounds of its coding block size (in packets). Generally, repair packets generated using FEC algorithms with good erasure filling properties (e.g. Reed-Solomon) will be transmitted only in response to NACK repair requests from receiving nodes. However, there are benefits in some network environments for trans- mitting some predetermined quantity of FEC repair packets multi- plexed with the regular data segment transmissions [Gossink98]. This can reduce the amount of NACK traffic generated with rela- tively little overhead cost when group sizes are very large or the network connectivity has a large delay*bandwidth product with some nominal level of expected packet loss. While the application of FEC is not unique to NACK-based protocols, these cumulative requirements may dictate the types of algorithms and protocol approaches applicable to NACK-based protocols. Adamson, Borman, et al. Expires September 2000 [Page 13] Internet Draft NORM Building Blocks March 2000 A specific issue related to the use of FEC with NACK-based proto- cols is the mechanism used to identify which portion(s) of trans- mitted data content to which specific FEC packet are applicable. It is expected that FEC algorithms will be based on generating a set of parity repair packets for a corresponding block of transmit- ted data packets. Since data content packets are uniquely identi- fied by the concatenation of during transport, it is expected that FEC packets will be identified in a similar manner. It may be sufficient to identify FEC packets using the of the first segment of the block of data content packets for which the FEC repair packet is applica- ble and add an additional FEC identifier field to its posi- tion within the set of FEC packets for the block. The size of the field can potentially be small (8 or 16 bits) relative to other identifier fields since its size is limited by the FEC coding algorithm used. 3.7 Round-trip Timing Collection (TBD - There are tradeoffs here ... one-to-many vs. many-to-many protocol operation, etc) 3.8 Group Size Determination/Estimation (TBD) 3.9 Congestion Control Operation (TBD - A NACK-oriented protocol may place limitations/requirements on collection of information to facilitate congestion control of senders. There are a number of specific issues of TCP-Friendly Multicast Congestion Control (TFMCC)which must be addressed.) 3.10 Router/Intermediate System assistance (TBD - NACK-oriented protocols can potentially benefit greatly from router assistance. In particular, additional NACK suppression would be beneficial (This may impact how synchronized receiver NACK cycles are, sender advertisement of NACK-cycle parameters (i.e. GRTT, group size, etc), NACK content, others) 3.11 Additional protocol mechanisms (TBD- e.g. positive acknowledgement collection, performance statis- tics collection, session management, etc) 4.0 Security Considerations (TBD) Adamson, Borman, et al. Expires September 2000 [Page 14] Internet Draft NORM Building Blocks March 2000 5.0 References [Mankin98] A. Mankin, A. Romanow, S. Bradner, V. Paxson, "IETF Cri- teria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998. [Pingali93] S. Pingali, D. Towsley, J. Kurose. "A Comparison of Sender-Initiated and Receiver-Initiated Reliable Multicast Proto- cols". In Proc. INFOCOM, San Francisco, CA, October 1993. [Levine96] B.N. Levine, J.J. Garcia-Luna-Aceves. "A Comparison of Known Classes of Reliable Multicast Protocols", Proc. International Conference on Network Protocols (ICNP-96), Columbus, Ohio, Oct 29--Nov 1, 1996. [Clark90] D. Clark, D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols". In Proc. ACM SIGCOMM, pages 201--208, September 1990. [Deering89] S. Deering. "Host Extensions for IP Multicasting". Internet RFC1112, August 1989. [Floyd95] S. Floyd, V. Jacobson, S. McCanne, C. Liu, and L. Zhang. "A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing", Proc. ACM SIGCOMM, August 1995. [Nonnenmacher98] J. Nonnenmacher and E. W. Biersack, "Optimal mul- ticast feedback," in IEEE Infocom , (San Francisco, California), p. 964, March/April 1998. [Gossink98] D. Gossink, J. Macker, "Reliable Multicast and Inte- grated Parity Retransmission with Channel Estimation", IEEE GLOBE- COM 98'. [Metzner84] J. Metzner, "An Improved Broadcast Retransmission Pro- tocol", IEEE Transactions on Communications, Vol. Com-32, No.6, June 1984. [Macker97a] J. Macker, "Integrated Erasure-Based Coding for Reli- able Multicast Transmission", IRTF Meeting presentation, March 1997. [Macker97b] J. Macker, "Reliable Multicast Transport and Integrated Erasure-based Forward Error Correction", Proc. IEEE MILCOM 97, Oct 1997. Adamson, Borman, et al. Expires September 2000 [Page 15] Internet Draft NORM Building Blocks March 2000 6.0 Authors' Addresses Brian Adamson adamson@itd.nrl.navy.mil Newlink Global Engineering Corporation 8580 Cinder Bed Road, Suite 1000 Newington, VA, USA, 22122 Dr. Carsten Borman cabo@tzi.org Universit"^Hat Bremen Postfach 330 440 D - 28334 Bremen, Germany Sally Floyd floyd@aciri.org 1947 Center Street, Suite 600 Berkeley, CA 94704 Mark Handley mjh@aciri.org 1947 Center Street, Suite 600 Berkeley, CA 94704 Joe Macker macker@itd.nrl.navy.mil Naval Research Laboratory Washington, DC, USA, 20375 Adamson, Borman, et al. Expires September 2000 [Page 16] --============_-1258794657==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Brian __________________________________ Brian Adamson --============_-1258794657==_============-- >From owner-rmt@listserv.lbl.gov Mon Mar 20 04:43:35 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id EAA05155; Mon, 20 Mar 2000 04:41:36 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA05151 for ; Mon, 20 Mar 2000 04:41:34 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA11834 for ; Mon, 20 Mar 2000 04:41:34 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA11831 for ; Mon, 20 Mar 2000 04:41:33 -0800 (PST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id FAA07320; Mon, 20 Mar 2000 05:41:32 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id FAA08893; Mon, 20 Mar 2000 05:41:29 -0700 (MST)] Received: from motorola.com ([217.2.31.112]) by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id XAA21291; Mon, 20 Mar 2000 23:41:26 +1100 (EST) Message-ID: <38D61C51.36C0EDA@motorola.com> Date: Mon, 20 Mar 2000 23:40:49 +1100 From: Roger Kermode X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list CC: Allison Mankin , Lorenzo Vicisano Subject: Draft RMT agenda: PLS send comments Content-Type: multipart/mixed; boundary="------------FA190BEEAD9367C8B094B307" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------FA190BEEAD9367C8B094B307 Content-Type: multipart/alternative; boundary="------------406FE68B19589A6083E9D5C9" --------------406FE68B19589A6083E9D5C9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Everyone, below is a first pass at the Agenda for Adelaide. If we just do presentations with minimal discussions, we'll just about fill one of our two sessions. If there are additional items please let me know ASAP. We will adjust the agenda to include the additional items and to allow for more discussions in a couple of days time. cheers, Roger ---------------------------------------------------------------- Reliable Multicast Transport WG (rmt) Tuesday, March 28 at 0900-1130 Wednesday, March 29 at 0900- 1130 ================================= CHAIRS: Roger Kermode Lorenzo Vicisano Allison Mankin AGENDA: Tuesday 28th March 2000, 09:00-11:30 - Introduction and Agenda Bashing Kermode (5 mins) - Design Space/Building Blocks draft progress Vicisano (5 mins) draft-ietf-rmt-design-space-01.txt draft-ietf-rmt-buildingblocks-02.txt - Guidelines Draft progress Kermode (15 mins) draft-ietf-rmt-author-guidelines-xx.txt - FEC Building Block Luby (20 mins) draft-ietf-rmt-bb-fec-00.txt - ALC Protocol Instantiation Luby (20 mins) draft-ietf-rmt-pi-alc-00.txt - Track Archictecure Whetten (20 mins) draft-ietf-rmt-track-arch-xx.txt - Tree Building Levine ?? (20 mins) - NACK-Oriented Reliable multicast Buoilding Block Adamson (20 mins) draft-ietf-rmt-norm-bb-00.tx Wednesday 29th March 2000, 09:00-11:30 --------------406FE68B19589A6083E9D5C9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Everyone,

below is a first pass at the Agenda for Adelaide.
If we just do presentations with minimal discussions,
we'll just about fill one of our two sessions. If there
are additional items please let me know ASAP. We will
adjust the agenda to include the additional items and
to allow for more discussions in a couple of days time.

cheers,

Roger
 
 
 

----------------------------------------------------------------
Reliable Multicast Transport WG (rmt)

Tuesday, March 28 at 0900-1130
Wednesday, March 29 at 0900- 1130
=================================

CHAIRS: Roger Kermode <Roger.Kermode@motorola.com>
        Lorenzo Vicisano <lorenzo@cisco.com>
        Allison Mankin <mankin@ isi.edu>

AGENDA:

Tuesday 28th March 2000, 09:00-11:30

- Introduction and Agenda Bashing
  Kermode (5 mins)

- Design Space/Building Blocks draft progress
  Vicisano (5 mins)
  draft-ietf-rmt-design-space-01.txt
  draft-ietf-rmt-buildingblocks-02.txt

- Guidelines Draft progress
  Kermode (15 mins)
  draft-ietf-rmt-author-guidelines-xx.txt

- FEC Building Block
  Luby (20 mins)
  draft-ietf-rmt-bb-fec-00.txt

- ALC Protocol Instantiation
  Luby (20 mins)
  draft-ietf-rmt-pi-alc-00.txt

- Track Archictecure
  Whetten (20 mins)
  draft-ietf-rmt-track-arch-xx.txt

- Tree Building
  Levine ?? (20 mins)

- NACK-Oriented Reliable multicast Buoilding Block
  Adamson (20 mins)
  draft-ietf-rmt-norm-bb-00.tx
 

Wednesday 29th March 2000, 09:00-11:30 --------------406FE68B19589A6083E9D5C9-- --------------FA190BEEAD9367C8B094B307 Content-Type: text/x-vcard; charset=us-ascii; name="Roger.Kermode.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Roger Kermode Content-Disposition: attachment; filename="Roger.Kermode.vcf" begin:vcard n:Kermode;Roger tel;cell:+61-408-212-284 tel;fax:+61-2-966-0501 tel;work:+61-2-9666-0558 x-mozilla-html:FALSE url:www.motorola.com.au/arc/ org:Communications And Networking Lab;Motorola Australian Research Centre adr:;;Locked Bag 5028;Botany;NSW;1455;Australia version:2.1 email;internet:Roger.Kermode@motorola.com title:Principal Research Engineer/Lab Manager fn:Roger Kermode end:vcard --------------FA190BEEAD9367C8B094B307-- >From owner-rmt@listserv.lbl.gov Mon Mar 20 06:58:58 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id GAA06205; Mon, 20 Mar 2000 06:57:03 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA06201 for ; Mon, 20 Mar 2000 06:57:01 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA22991 for ; Mon, 20 Mar 2000 06:57:00 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA22985 for ; Mon, 20 Mar 2000 06:57:00 -0800 (PST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id HAA07710 for ; Mon, 20 Mar 2000 07:56:58 -0700 (MST)] Received: [from s-il02-e.comm.mot.com (s-il02-e.comm.mot.com [145.1.204.15]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA24003 for ; Mon, 20 Mar 2000 07:56:56 -0700 (MST)] Received: by s-il02-e.comm.mot.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Mar 2000 08:44:33 -0600 Message-ID: <57B7E404C641D211A39A0008C7A4FBA701C05045@s-il02-q.comm.mot.com> From: Avasthi Pradeep-CCOF59 To: rmt-list Subject: remove Date: Mon, 20 Mar 2000 08:44:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rmt@lbl.gov Precedence: bulk -----Original Message----- From: Roger Kermode [mailto:Roger.Kermode@motorola.com] Sent: Monday, March 20, 2000 6:41 AM To: rmt-list Cc: Allison Mankin; Lorenzo Vicisano Subject: Draft RMT agenda: PLS send comments Dear Everyone, below is a first pass at the Agenda for Adelaide. If we just do presentations with minimal discussions, we'll just about fill one of our two sessions. If there are additional items please let me know ASAP. We will adjust the agenda to include the additional items and to allow for more discussions in a couple of days time. cheers, Roger ---------------------------------------------------------------- Reliable Multicast Transport WG (rmt) Tuesday, March 28 at 0900-1130 Wednesday, March 29 at 0900- 1130 ================================= CHAIRS: Roger Kermode Lorenzo Vicisano Allison Mankin AGENDA: Tuesday 28th March 2000, 09:00-11:30 - Introduction and Agenda Bashing Kermode (5 mins) - Design Space/Building Blocks draft progress Vicisano (5 mins) draft-ietf-rmt-design-space-01.txt draft-ietf-rmt-buildingblocks-02.txt - Guidelines Draft progress Kermode (15 mins) draft-ietf-rmt-author-guidelines-xx.txt - FEC Building Block Luby (20 mins) draft-ietf-rmt-bb-fec-00.txt - ALC Protocol Instantiation Luby (20 mins) draft-ietf-rmt-pi-alc-00.txt - Track Archictecure Whetten (20 mins) draft-ietf-rmt-track-arch-xx.txt - Tree Building Levine ?? (20 mins) - NACK-Oriented Reliable multicast Buoilding Block Adamson (20 mins) draft-ietf-rmt-norm-bb-00.tx Wednesday 29th March 2000, 09:00-11:30 >From owner-rmt@listserv.lbl.gov Mon Mar 20 11:59:32 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id LAA07263; Mon, 20 Mar 2000 11:58:28 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA07259 for ; Mon, 20 Mar 2000 11:58:26 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA26846 for ; Mon, 20 Mar 2000 11:58:26 -0800 (PST) Received: from pi4.informatik.uni-mannheim.de (root@pi4.informatik.uni-mannheim.de [134.155.48.96]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA26836 for ; Mon, 20 Mar 2000 11:58:25 -0800 (PST) Received: from pi4.informatik.uni-mannheim.de (mauve@pi4 [134.155.48.96]) by pi4.informatik.uni-mannheim.de (8.9.3/8.9.3) with ESMTP id UAA06905; Mon, 20 Mar 2000 20:58:16 +0100 (MET) Message-ID: <38D682D8.39604EE8@pi4.informatik.uni-mannheim.de> Date: Mon, 20 Mar 2000 20:58:16 +0100 From: Martin Mauve Organization: University of Mannheim X-Mailer: Mozilla 4.08 [en] (X11; U; SunOS 5.6 sun4u) MIME-Version: 1.0 To: Brian Adamson CC: RMT Subject: Re: Initial draft of NACK-Oriented Reliable Multicast Building Blocks References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Hi Brian, hi all, I have read the NORM draft and I like it. There are two minor questions I would like to ask: 1. How is the unique source ID supposed to be determined? I assume that a collision would be unacceptable and that the ID should be small? 2. How long does the sender have to be prepared to retransmit any given packet? I do understand that these two questions might be out of scope for the draft. However, I assume that a building block implementation would have to worry about these things? thanks, Martin -- --------------------------------------------------------------------------- Martin Mauve University of Mannheim Praktische Informatik IV Phone: +49-621-181-2616 L 15,16 Fax : +49-621-181-2601 68131 Mannheim mauve@pi4.informatik.uni-mannheim.de Germany --------------------------------------------------------------------------- >From owner-rmt@listserv.lbl.gov Wed Mar 22 14:30:32 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id OAA18141; Wed, 22 Mar 2000 14:28:40 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA18137 for ; Wed, 22 Mar 2000 14:28:38 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA24981 for ; Wed, 22 Mar 2000 14:28:37 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA24968 for ; Wed, 22 Mar 2000 14:28:35 -0800 (PST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA06818 for ; Wed, 22 Mar 2000 14:28:33 -0800 (PST) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA01645; Wed, 22 Mar 2000 17:28:30 -0500 (EST) Received: from bridge (bridge [129.148.75.125]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id RAA09211; Wed, 22 Mar 2000 17:28:26 -0500 (EST) Message-Id: <200003222228.RAA09211@bcn.East.Sun.COM> Date: Wed, 22 Mar 2000 17:28:20 -0500 (EST) From: Dah Ming Chiu - Sun Microsystems Reply-To: Dah Ming Chiu - Sun Microsystems Subject: TRACK: Draft of TRACK architecture To: rmt@lbl.gov Cc: whetten@talarian.com, sanjoy@edgix.com, Miriam.Kadansky@east.sun.com MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Brace_of_Greyhounds_614_000 X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-rmt@lbl.gov Precedence: bulk --Brace_of_Greyhounds_614_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 6kPLopFrZC4PeG3SsrmZcA== Hi, Attached is a draft of the TRACK architecture document. We ran out of time to resolve all the issues. The remaining issues are listed in an "open issues" section at the end of the document. This is published for discussion at the Adelaide meeting. Hopefully shortly after that we will be able to put together a draft ID. I apologize for not having managed to get the document in the correct ID format. I think it is more important for me to send this out now so that people going to adelaide can get a chance to look at it, rather and delaying it. I'd like to thank all for working hard on this, specially Brian Whetten for putting the initial draft together, and Miriam for helping me get the attached document ready. Regards Dah Ming --Brace_of_Greyhounds_614_000 Content-Type: TEXT/plain; name="draft-whetten-track-architecture-xxrev06.txt"; charset=ISO-8859-1; x-unix-mode=0644 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Description: draft-whetten-track-architecture-xxrev06.txt Content-MD5: rlWTzw5/bnx7WCJaB7+dYg== Reliable Multicast Transport (RMT) WG B. Whetten Internet Draft Talarian Document: draft-ietf-rmt-track-arch-xx.txt D.Chiu Sun Microsystems S.Paul Edgix March 22, 2000 TRACK ARCHITECTURE A SCALEABLE REAL-TIME RELIABLE MULTICAST PROTOCOL Status of this Memo This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of RFC2026 [1].=20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of=20 six months and may be updated, replaced, or obsoleted by other=20 documents at any time. It is inappropriate to use Internet- Drafts=20 as reference material or to cite them other than as "work in=20 progress."=20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html. 1. Abstract One of the protocol instantiations the RMT WG is chartered to create=20 is a TRee-based ACKnowledgement protocol (TRACK). Rather than=20 create a set of monolithic protocol specifications, the RMT WG has=20 chosen to break the reliable multicast protocols in to Building=20 Blocks (BB) and Protocol Instantiations (PI). A Building Block is a=20 specification of the algorithms of a single component, with an=20 abstract interface to other BBs and PIs. A PI combines a set of=20 BBs, adds in the additional required functionality not specified in=20 any BB, and specifies the specific instantiation of the protocol.=20 For more information, see the Reliable Multicast Transport Building=20 Blocks and Reliable Multicast Design Space documents [2][3]. The TRACK protocol instantiation (TRACK for short) is designed to=20 reliably and efficiently send data from a single sender to large=20 groups of simultaneous recipients. It provides functions similar to=20 the NACK PI, and adds in support for a tree-based hierarchy (in its=20 simplest form may consist of only the sender as the Repair Head) of=20 Repair Heads, which increases scalability by providing aggregation=20 of control traffic and local retransmission of lost packets. In=20 addition to using negative acknowledgements (NACKs) and forward=20 error correction (FEC) for efficient reporting and retransmission of=20 lost packets, it also provides tree-based ACKnowledgements (ACKs). =20 ACKs provide the Sender with confirmation of delivery of data=20 packets to the Receivers. Like the NACK PI, it may also take=20 advantage of Generic Router Assist where available. This document proposes a design rationale for the TRACK PI, an=20 architecture for TRACK, and a set of functional requirements TRACK=20 has of other Building Blocks. =20 2. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in RFC-2119 [4]. 3. Design Rationale and Protocol Requirements This section discusses many of the requirements imposed on the=20 design of the TRACK PI, as well as a design rationale which guides=20 the aspects where there is flexibility in selecting from different=20 potential design decisions. 3.1 Private and Public Networks TRACK is designed to work in both private, controlled networks and=20 in the public Internet. A controlled network typically has a single=20 administrative domain, has more homogenous network bandwidth, and is=20 more easily managed and controlled. These networks have the fewest=20 barriers to IP multicast deployment and the most immediate need for=20 reliable multicast services. Deployment in the Internet requires a=20 protocol to span multiple administrative domains, over vastly=20 heterogeneous networks. The IETF is specifically chartered with=20 producing standards for the Internet, so this must be the primary=20 target network type. However, robust transport protocols are grown,=20 not created, and most of the short term deployment experience will=20 likely come from controlled networks. Therefore, TRACK is designed=20 to support both. 3.2 Manual vs. Automatic Controls Some networks can take advantage of manual or centralized tools for=20 configuring and controlling the usage of a reliable multicast group. =20 In the public Internet, these tools have to fully distributed, and=20 preferably automatic, because they have to deal with the need to=20 span multiple AS=92s, each with their own policies. To address these=20 requirements, TRACK supports both manual and automatic algorithms=20 for monitoring, management, and configuration. 3.3 Heterogeneous Networks While the majority of controlled networks are symmetrical and=20 support many-to-many multicast, in designing a protocol for the=20 Internet, it must deal with virtually all major network types. =20 These include asymmetrical networks, satellite networks, networks=20 where only a single node may send to a multicast group, and wireless=20 networks. TRACK takes this into account by not requiring any many- to-many multicast services. In addition, the congestion control=20 component used in TRACK will specifically deal with the high=20 bandwidth-delay product faced in many satellite networks and the=20 high link level loss rate faced by some wireless networks. Finally,=20 TRACK does not assume that the topology used for sending control=20 packets has any congruence to the topology of the multicast address=20 used for sending data packets. 3.4 Use of Network Infrastructure=20 There is wide consensus that in order to scale a real-time reliable=20 multicast protocol, there must be some use made of the network=20 infrastructure (the routers and servers inside the network). New=20 software that supports the transport layer typically would run in=20 either the routers or the servers in the network, or both. =20 Deployment of router software (such as that in the Generic Router=20 Assist BB) is a powerful solution, but typically requires very long=20 time cycles, is of necessity limited in functionality, and requires=20 a graceful upgrade path. Server software (such as the Repair Head=20 control tree) is much easier to deploy, but may require new hardware=20 to be added to the network. =20 In controlled networks, particularly during the first deployment=20 phases of reliable multicast, it is reasonable to deploy servers=20 that only support a single application, or even to use selected end=20 clients themselves to perform the functions necessary for=20 scalability. For widely deployed Internet infrastructure=20 components, the server infrastructure is usually dedicated to just=20 the single protocol, but supports all instances of that protocol=20 running across that piece of the network. Examples of this usage=20 model include DNS, DHCP, NNTP, and HTTP. Therefore, the control=20 nodes used in TRACK are primarily designed to be run on dedicated=20 network servers, and support hundreds or thousands of simultaneous=20 data sessions over each server. Optionally, these components MAY=20 run on an end user computer. =20 A number of extensions to IP multicast, such as subtree multicast,=20 NACK suppression, ACK aggregation, tree configuration discovery, and=20 higher fidelity congestion control reports, have been proposed which=20 can run in the routers. If deployed widely, these would make=20 reliable multicast protocols easier to configure and to scale more=20 readily. Some or all of these features are being standardized as=20 part of the Generic Router Assist (GRA) component. TRACK is=20 designed to take advantage of GRA as it becomes available, but not=20 to require it. Ubiquitous deployment of GRA would likely reduce the=20 number of dedicated TRACK servers needed for large scale (i.e. more=20 than 1000 Receiver) deployments, and improve the performance of the=20 protocol. 3.5 Targeted Application Types Multicast applications can be divided into two classes, few-to-many =20 and many-to-many. Many-to-many applications include server=20 replication, multi-user games, small group conferencing, and=20 computer supported collaborative work. These applications typically=20 treat all members in a group as peers, require special semantics=20 such as total ordering of messages from multiple Senders, and often=20 have moderate scalability requirements. Other protocols, such as=20 RMP [WMK94], have been designed to support these many-many=20 applications. In line with the charter for RMT, TRACK focuses on one to many bulk=20 data distribution applications, such as multicast file transfer,=20 electronic software distribution, real time news and financial=20 market data distribution, "push" applications, audio/video/data=20 streaming, distance learning, and some types of server replication. =20 In order to meet these requirements, TRACK treats each Sender as an=20 independent entity, and provides no ordering or other shared state=20 across data sessions, although multiple data sessions can share the=20 same control infrastructure. The protocol is designed to scale to=20 at least many thousands of simultaneous Receivers. TRACK provides a=20 strong, but fully distributed membership protocol, which supports=20 scaling to many thousands of simultaneous Receivers while providing=20 confirmed delivery on messages. Similar to TCP, TRACK continuously=20 streams data to receivers, performing acknowledgement and=20 retransmission of older data packets at the same time that new data=20 packets are being sent. It also provides some special support for=20 real-time applications such as audio/video/data streaming and live=20 financial market data distribution. TRACK meets a requirement of synchronous streaming applications with=20 a new reliability level called Time Bounded Reliability. Time=20 Bounded Reliability restricts recovery of packets to a limited time=20 interval. This keeps dropped packets from blocking the rest of a=20 synchronous data stream and helps prevent a failed Receiver from=20 affecting other Receivers. 3.6 IETF Mandated Criteria In addition to the requirements imposed by the targeted network and=20 application types, TRACK is designed to meet all of the requirements=20 proposed by the IETF in RFC2357. - Congestion Control. TRACK includes provably safe and TCP-friendly=20 congestion control algorithms that also scale to large groups.=20 - Well-controlled, Scaleable Behavior. TRACK includes carefully=20 analyzed algorithms that manage and smooth the control traffic and=20 retransmissions. These are key to avoiding NACK implosion, ACK=20 implosion, and retransmission implosion (the local recovery=20 pathology). - Security. TRACK supports protection of the transport=20 infrastructure, through the use of lightweight authentication of=20 control and data packets. 3.7 Graceful Evolution Creating robust, universally applicable standard protocols takes a=20 great deal of time and protocol evolution. While TRACK is being=20 written as a standard, it will have to continue to evolve as real=20 world experience is gained with the protocol, similar to how TCP has=20 been tuned over almost 20 years of research and development. TRACK=20 addresses this through its use of Building Blocks, which allow=20 particular algorithms to be broken out in to separate components=20 with well defined interfaces. This allows evolution of these=20 components, hopefully with little or no changes required to the rest=20 of the protocol. =20 TRACK also addresses this through its use of session parameters. =20 TRACK is presently dependent on a number of parameters which MUST be=20 configured throughout the tree for optimal operation. TRACK=20 provides mechanisms to automatically distribute these parameters to=20 all members of the group, and OPTIONALLY provides mechanisms to=20 dynamically change some of these parameters during group operation. It also provides SNMP management and monitoring tools. Over time,=20 deployment experiences will provide input on which values work best=20 for most deployments, leading to further refinements of the=20 standard.=20 3.8 Algorithm Selection The above design criteria applies to the general architecture of the=20 protocol. Additional criteria were used for selecting the optimal=20 algorithms for different sets of functions. These rationales are=20 described below, along with the individual functions they apply to. 4. Architectural Overview 4.1 TRACK Entities=20 4.1.1 Node Types TRACK divides the operation of the protocol in to three major=20 entities: Sender, Receiver, and Repair Head. It is assumed that=20 Senders and Receivers typically run as part of an application on an=20 end host client. It is assumed that Repair Heads are components in=20 the network infrastructure, managed by different network managers as=20 part of different administrative domains. A Repair Head MAY be run=20 on an end host client, in which case it functions as both a Receiver=20 and a Repair Head. Absent of any automatic tree configuration, it=20 is assumed that the Repair Heads have relatively static=20 configurations, which consist of a list of nearby possible Repair=20 Heads. Senders and Receivers, on the other hand, are transient=20 entities, which typically only exist for the duration of a single=20 data session. Again, these entities MAY be used in other ways than=20 this, but this is the primary design rationale for TRACK. In=20 addition to these core components, applications that use TRACK are=20 expected to interface with other services that reside in other=20 network entities, such as multicast address allocation, session=20 advertisement, network management consoles, DHCP, DNS, server level=20 multicast, and multicast key management. 4.1.2 Multicast Group Address A multicast group address is a pair consisting of an IP multicast=20 address and a UDP port number. It may optionally have a Time To=20 Live (TTL) value, although this value MUST only be used for=20 providing a global scope to a Data Session.=20 4.1.3 Data Session A Data Session is the unit of reliable delivery of TRACK. It=20 consists of a sequence of sequentially numbered Data packets, which=20 are sent by a single Sender over a single Data Multicast Address. =20 They are delivered reliably, with acknowledgements and=20 retransmissions occurring over the Control Tree. It is uniquely=20 identified by a combination of a Session ID, senders address and=20 port, and the multicast address and port.=20 A given Data Session is received by a set of zero or more Receivers,=20 and a set of zero or more of Repair Heads. One or more Data=20 Sessions MAY share the same Data Multicast Address (although this is=20 not recommended). Each TRACK node can simultaneously participate in=20 multiple Data Sessions. A receiver MUST join all the Data Multicast=20 Addresses and Control Trees corresponding to the Data Streams it=20 wishes to receive. 4.1.4 Control Tree A Control Tree is a hierarchical communication path used to send=20 control information from a set of Receivers, through zero or more=20 Repair Heads (RHs), to a Sender. It forms a tree, allowing the=20 interior nodes to aggregate this control information as it moves up=20 the tree. Each Data Session uses a Control Tree. Each RH in the control tree uses a separate multicast address for=20 communicating with its children. Optionally, these RH multicast=20 addresses may be the same as the multicast address of the Data=20 Channel. 4.1.5 Session ID A Session ID is a 32-bit number (to be formally defined in the=20 Common Packet Header BB) chosen either by the application that=20 creates the session or selected by TRACK. Senders and Receivers use=20 the Session ID to distinguish Data Streams. A Sender may specify a=20 Session ID in the range from (2^31) to (2^32)-1. Numbers in the=20 range from 0 to (2^31)-1 are reserved. If a sender specifies 0 as=20 the Stream ID, then TRACK randomly assigns a Stream ID in the range=20 from 1 to (2^31)-1. If a Session ID is selected that is already in=20 use on a Control Tree, the new stream will fail, and will need to=20 select a new Session ID. A session is uniquely identified by its Session ID, its sender=92s=20 address/port, and its Data Multicast Address and port. 4.1.6 Packet Sequence Numbers A packet sequence number is a 32 bit number in the range from 1=20 through 2^32 =96 1, which is used to specify the sequential order of a=20 Data packet in a Data Stream. A sender node assigns consecutive=20 sequence numbers to the Data packets provided by the Sender=20 application. Zero is reserved to indicate that the data session has=20 not yet started. =20 4.1.7 Data Queue A Data Queue is a buffer, maintained by a Sender or a Repair Head,=20 for transmission and retransmission of the Data packets provided by=20 the Sender application. New Data packets are added to the data=20 queue as they arrive from the sending application, up to a specified=20 buffer limit. The admission rate of packets to the network is=20 controlled by flow and congestion control algorithms. Once a packet=20 has been received by the Receivers of a Data Stream, it may be=20 deleted from the buffer. 4.1.8 Packet Types TRACK defines a set of packets, which can be implemented either on=20 top of UDP or directly on top of IP. All TRACK packets will conform=20 to the Common Packet Headers BB. Each TRACK packet definition=20 consists of a fixed header, zero or more option headers, followed by=20 data or control information. Data is carried in Data packets. The same packet type is used both=20 to transmit Data the first time and for retransmissions of lost=20 packets (see open issue). Each Data packet has a Session ID and a=20 sequence number, which identify the packet and allow a receiver=20 application to reconstruct the data stream from the Data packets. =20 When a Data packet has been received by all Receivers, it is said to=20 have gone stable. Receivers and Repair Heads unicast periodic status packets to their=20 parents. An ACK is sent regularly to indicate the status of the=20 Data packets which have arrived and to furnish congestion control=20 statistics about the state of data reception at the node. An ACK=20 requests retransmission of Data packets that have not been received. =20 An ACK also acknowledges packets that have become stable. A packet=20 becomes stable when it has been received by enough Repair Heads and=20 Receivers that the sender is no longer required to hold the packet=20 for retransmission. A NACK is an ACK that is used to request=20 immediate recovery of lost Data packets. ACKs and NACKs have the=20 same format, but ACKs are passed all the way up the tree, while=20 NACKs are only sent as far as needed to find a node which can=20 provide all the requested retransmissions. A child will also send=20 an ACK in response to a NullData or Heartbeat packet if it has not=20 sent an ACK within a certain time interval. When a Receiver or Repair Head wishes to establish a repair service=20 relationship, it uses a Bind packet to bind to a parent Repair Head.=20 A parent sends an Accept or Reject after it processes a Bind packet. The Reject message comes with a reason code that explains the reason=20 for rejection. The reason may indicate that the parent is not=20 connected into the tree yet, so that the receiver can try again=20 later (see open issue). When a Receiver or Repair Head wishes to leave a session, it sends a=20 Leave request to its parent. The parent replies with a LeaveConfirm=20 packet, at which time the child is allowed to leave. A Repair Head or Sender periodically sends Heartbeat packets to=20 notify its child nodes that it is alive.=20 If a Sender has no data to send for a session, it periodically multicasts a NullData packet on the Data Multicast Address. =20 NullData packets inform receivers about the state of the Data Stream=20 and the Sender. =20 If a child node is not operating normally, or a parent node restarts after a failure and receives a packet from a child not in its child=20 list, then the parent node sends an Eject packet to the child node. =20 4.2 Basic Operation of the Protocol For each Data Session, TRACK provides sequenced, reliable delivery=20 of data from a single Sender to up to tens of thousands of=20 Receivers. A TRACK Data Session consists of a network that has=20 exactly one Sender node, zero or more Receiver nodes and zero or=20 more Repair Heads. The figure below illustrates a TRACK Data Session with multiple=20 Repair Heads. =20 A Sender joins the TRACK tree and multicasts data packets on the=20 Data Multicast Address. All of the nodes in the session subscribe=20 to the class D IP multicast address and UDP port associated with the=20 Data Multicast Address.=20 There is no assumption of congruence between the topology of the=20 Data Multicast Address and the topology of the Control Tree. -------> SD (Sender node)----->| ^^^ | ACKs / | \ Control | and / | \ Tree | NACKs / | \ | / | \ (Repair | / | \ Head | / | \ nodes) v RH RH RH <------------| ^^ ^^^ ^^ | Data / | / | \ | \ |=20 Channel / | / | \ | \ | / | / | \ | \ v R R R R R R R <--------- (Receiver Nodes) A Receiver joins a Data Multicast Address to receive data. A=20 Receiver periodically informs its parent about the packets that it=20 has or has not received by unicasting an ACK packet to the parent. =20 Each parent node aggregates the ACKs from its child nodes and (if it=20 is not the Sender) unicasts a single aggregated ACK to its parent. =20 For lower latency recovery in low loss networks, Receivers can also=20 generate NACKs upon detection of losses. These have the same format=20 as a ACK, but are only passed up the tree as far as necessary in=20 order to find a Repair Head that can retransmit the packet. The=20 Repair Heads provide NACK suppression, which provides traffic=20 minimization benefits similar to ACK aggregation. The Sender and each Repair Head have a multicast Local Control=20 Channel to their children. This is used for transmitting Heartbeat=20 packets that inform their child nodes that the parent node is still=20 functioning. This channel is also used to perform local=20 retransmission of lost data packets to just these children. TRACK=20 will still provide correct operation even if multicast addresses are=20 reused across multiple Data Sessions or multiple Local Control=20 Channels. It is NOT RECOMMENDED to use the same multicast address=20 for multiple Local Control Channels serving any given Data Session. A tree forms a loop from the Sender to the Receivers, to the Repair=20 Heads, and back to the Sender. Data and NullData packets regularly=20 exercise the downward data direction. Heartbeat packets exercise=20 the downward control direction. ACKs, NACKs, and HeartbeatResponse=20 packets regularly exercise the control tree in the upward direction. =20 This combination constantly checks that all of the nodes in the tree=20 are still functioning correctly, and initiates fault recovery when=20 required. In addition to using ACKs, NACKs, and Repair Heads for scaleable=20 loss notification and retransmission, TRACK also supports the=20 optional use of Generic Router Assist (GRA) and integrated Forward=20 Error Correction (FEC). Two of the major functions of GRA are NACK=20 suppression and dynamically scoped local retransmission. These=20 functions, if enabled, are independently deployed between each=20 parent and its children. For the purpose of GRA NACK functions,=20 each parent is considered to be a Sender and the children of that=20 parent are considered as the Receivers. Retransmission requests, both NACKs and ACKs, contain selective=20 bitmaps indicating which packets need to be retransmitted. If FEC=20 is enabled, these bitmaps provide enough information to determine=20 the number of parity packets to be sent rather than sending=20 individual retransmissions. 4.3 Session Creation Before a data session starts delivering data, the tree for the Data=20 Session needs to be created. This process binds each Receiver to=20 either a Repair Head or the Sender, and binds the participating=20 Repair Heads in to a loop-free tree structure with the Sender as the=20 root of the tree. This process requires tree configuration=20 knowledge, which can be provided with some combination of manual=20 and/or automatic configuration. The actual algorithms for tree=20 configuration will be part of the Automatic Tree Configuration BB,=20 and are discussed in the next section. To start a data session, a Sender communicates to the Receivers, via=20 either an external service or through the application itself, the=20 Data Multicast Address that will be used for the Data Session. It=20 may advertise other relevant session information such as whether or=20 not Repair Heads should be used, whether manual or automatic tree=20 configuration should be used, and the time at which the session will=20 start. It may also advertise certain hints for the tree=20 configuration algorithms.=20 After receiving this out of band communication, the Receivers join=20 the Data Multicast Address, and attempt to bind to either the Sender=20 or a local Repair Head. The tree configuration algorithms are=20 responsible for providing the Receiver with a list of one or more=20 nodes which it will attempt to bind to. It will attempt to bind to=20 the first node in the list, and if this fails, it will move to the=20 next one. A Receiver only binds to a single Repair Head or Sender,=20 at a time, for each Data Session.=20 When a Repair Head has a Receiver bind to it for a given Data=20 Session, it then also binds to another Repair Head or to the Sender,=20 depending on the list given to it by the tree configuration=20 algorithms. The tree configuration algorithms are responsible for=20 ensuring that the tree is formed without loops.=20 Once the bind process has traversed from the Receivers up to the=20 Sender, it then repeats the process in the reverse direction. In=20 this confirmation phase, the Sender enforces a set of uniform=20 Session Configuration Parameters on all members of the session, and=20 verifies that no loops have formed in the tree. The Session=20 Configuration Parameters include values for certain protocol=20 constants, and indicate the set of optional algorithms which will be=20 used for this Data Session, and which each member must support in=20 order to be a member of the tree. Any failures to create a loop=20 free tree, or among members unable to support all the required=20 features, are handled as failures of those particular members. At the same time as the Sender initiates the second half of the tree=20 binding, it is also free to start sending Data packets on the Data=20 Multicast Address. Repair Heads and Receivers may start receiving=20 these packets, but may not request retransmission or deliver data to=20 the application until they receive confirmation that they have=20 successfully bound to the group. Some of the Session Configuration Parameters MAY be changed=20 dynamically by the Sender by advertising the changed values as part=20 of the keep-alive control packets periodically sent through the=20 tree. If a given Session Configuration Parameter must be the same=20 at all nodes in order to provide safe operation, it MUST NOT be=20 dynamically changed once the Data Session has started.=20 4.4 Tree Configuration TRACK is designed to work either with manual configuration of the=20 tree, or with optional automatic tree configuration. Tree=20 configuration is responsible for providing each Receiver and Repair=20 Head with a list of one or more appropriate parents to attempt to=20 bind to. =20 The goals of automatic tree configuration are: ? allow Receivers to automatically locate their best Repair Head(s). ? provide automatic configuration of the Repair Head with the=20 assumption that Repair Heads are servers operating in the network. ? dynamically select which receivers become repair heads. These algorithms are specified in the Tree Configuration BB. In=20 order to make sure that TRACK can be standardized in a timely=20 fashion, the automatic tree configuration algorithms need to be=20 separate from the rest of the TRACK protocol, so that TRACK can be=20 deployed even without these algorithms. When these algorithms from=20 the Tree Configuration BB are not available, TRACK will use static=20 configuration. 4.5 Data Transmission and Retransmission Data is multicast by a Sender on the Data Multicast Address. =20 Retransmissions of data packets may be multicast by the Sender on=20 the Data Multicast Address or be multicast on a Local Control=20 Channel by a Repair Head. In order to provide NACK suppression and=20 to work with proactive FEC, retransmissions are always multicast. =20 If Generic Router Assist is enabled, the routers may provide NACK=20 suppression and allow dynamically scoped retransmission to just the=20 subset of Receivers and Repair Heads that have missed a packet. =20 A Repair Head joins all of the Data Multicast Addresses that any of=20 its descendants have joined. A Repair Head is responsible for=20 receiving and buffering all data packets using the reliability=20 semantics configured for a stream. As a simple to implement option,=20 a Repair Head MAY also function as a Receiver, and pass these data=20 packets to an attached application. For additional fault tolerance, a Receiver MAY subscribe to the=20 multicast address associated with the Local Control Channel of one=20 or more Repair Heads in addition to the multicast address of its=20 parent. In this case it does not bind to this Repair Head or=20 Sender, but will process Retransmission packets sent to this=20 address. If the Receiver=92s Repair Head fails and it transfers to=20 another Repair Head, this minimizes the number of data packets it=20 needs to recover after binding to the new Repair Head.=20 There are three types of retransmissions: local retransmission,=20 global retransmission, and dynamically scoped retransmission. 4.5.1 Local Retransmission If a Repair Head determines from its child node's ACKs or NACKs that=20 a Data packet was missed, the Repair Head retransmits the Data=20 packet or, if FEC is enabled, an FEC parity packet. The Repair Head=20 multicasts the Retransmission packet on its multicast Local Control=20 Channel. In the event that a Repair Head receives a retransmission=20 and knows that its children need this repair, it re-multicasts the=20 retransmission to its children. The scope of retransmission is considered part of the Control=20 Channel=92s multicast address, and is derived during tree=20 configuration. 4.5.2 Global Retransmission If a Sender node receives an ACK or NACK that indicates missing=20 packets, the Sender MAY support an option for global retransmission. (Note: the Sender is always a Repair Head for its own Control=20 Channel, which is irrespective of whether Global Retransmission is=20 selected). In this case, the Sender multicasts the requested=20 packets on the Data Multicast Address. Again, if FEC is enabled,=20 the Sender will transmit one or more parity packets instead of the=20 actual data packets. This is an optional feature, used as an=20 optimization for some environments such as asymmetrical networks. =20 It MUST NOT be enabled if Generic Router Assist is being used. 4.5.3 Dynamically Scoped Retransmission On a network whose routers support dynamically scoped=20 retransmissions through Generic Router Assist, then this may be=20 used. Dynamically Scoped Retransmissions use soft state kept in the=20 routers to constrain the Retransmission to only the children that=20 have requested them through a NACK. Dynamically Scoped=20 Retransmissions are known to be susceptible to router topology=20 changes. Therefore, only the first retransmission of a packet is=20 sent via this mechanism. Thereafter, only the above two mechanisms=20 should be used. This will allow the protocol to provide=20 connectivity even during router topology changes, albeit with less=20 efficiency. 4.6 Control Traffic Management One of the largest challenges for scaleable reliable multicast=20 protocols has been that of controlling the potential explosion of=20 control traffic. There is a fundamental tradeoff between the=20 latency with which losses can be detected and repaired, and the=20 amount of control traffic generated by the protocol. In conjunction=20 with the dynamic global tree parameters, TRACK provides a set of=20 algorithms that carefully control and manage this traffic,=20 preventing control traffic explosion. Despite their different names, ACKs and NACKs both function as=20 selective acknowledgements of the window of contiguous sequence=20 numbers that have not yet been fully acknowledged. The only=20 difference between the packet headers is a single flag. ACKs are controlled by setting a number of tree wide parameters=20 controlling their maximum rate of generation. The primary parameter=20 is the ratio parameter, R, for the maximum number of ACK packets to=20 be generated per data packet sent. The higher R is, the faster=20 positive acknowledgements will be generated all the way back to the=20 sender, but the more traffic that is generated. =20 ACKs MUST be enabled for any Data Session. NACKs SHOULD be=20 implemented as part of any implementation, and MAY be enabled for=20 any given Data Session. If enabled, then on detection of a lost=20 packet, a Receiver waits a random interval before sending a NACK. =20 If the Receiver receives the retransmitted data before the NACK=20 timer expires, the Receiver cancels the NACK. This reduces the=20 chance that multiple Receivers generate a NACK for the same packet. A Repair Head node multicasts a Data packet to its children as soon=20 as it gets a NACK request for that packet, unless it recently=20 retransmitted that packet. If it does not have the missing packet,=20 it forwards the NACK to its parent, and multicasts a control packet=20 to its children to suppress any further NACKs for that packet from=20 them. The Repair Head forwards only one NACK for a missing Data=20 packet within a specified period of time. If more than one packet=20 has been detected as missing before the NACK is sent, the NACK will=20 request all of the missing packets. NACKs are particularly good for providing real-time data=20 distribution in networks with low loss rates and short to moderate=20 RTT times. See [5] for comparisons on the tradeoffs between ACKs=20 and NACKs for low latency recovery of lost packets. 4.7 Integrated Forward Error Correction Work [6][7][8] has shown the benefits of incorporating reactive=20 forward error correction (FEC) into reliable multicast protocols. =20 This feature encodes data packets with FEC algorithms, but does not=20 transmit the parity packets until a loss is detected. The parity=20 packets are then transmitted and are able to repair different lost=20 packets at different Receivers. This is a powerful tool for=20 providing scalability in the face of independent loss. When=20 implemented, it is a simple matter to also provide proactive FEC=20 which automatically transmits a certain percentage of parity packets=20 along with the data. This is particularly useful when a high=20 minimum error rate is expected, or when low latency is particularly=20 important. Both of these are optionally supported in TRACK. FEC is organized around windows of packets. TRACK Data packets=20 include an FEC offset window field, which identifies the offset of a=20 given packet within an FEC window. Combined with the FEC session=20 configuration parameters, this allows receivers to decode a=20 combination of Data and parity packets, to generate each window of=20 Data packets. Proactive FEC packets are parity packets sent as=20 global retransmissions at the same time a window of Data packets are=20 sent. Reactive FEC packets are sent either from a Repair Head or a=20 Sender, in response to requests for retransmissions. If using=20 reactive FEC, a Repair Head must first have all the packets in a=20 window before it can respond to any request for retransmission. The=20 ACK and NACK bitmaps, combined with the information in the headers=20 of the Data packets, provides each Repair Head with enough=20 information to determine which parity packets the RH must compute=20 and send in response to requests for retransmission. 4.8 Flow and Congestion Control Flow and congestion control algorithms act to prevent the Senders=20 from overflowing the Receivers=92 buffers and to force them to share=20 the network fairly and safely with other TCP and RM connections. =20 TRACK uses a combination of a transmission window for flow control,=20 and the dynamic rate control algorithms specified in the Congestion=20 Control (CC) BB for congestion control. These algorithms have been=20 proven to meet all the requirements for flow and congestion control,=20 including being safe for use in a general Internet environment, and=20 provably fair with TCP. The Sender application provides the minimum and maximum rate limits=20 as part of the global parameters. A Sender will not transmit at=20 lower than the minimum rate (except possibly during short periods of=20 time when certain slow receivers are being ejected), or higher than=20 the maximum rate. If a Receiver is not able to keep up with the=20 minimum rate for a period of time, the CC BB algorithms will cause=20 it to leave the group. Receivers that leave the group MAY attempt to=20 rejoin the group at a later time, but SHOULD NOT attempt an=20 immediate reconnection. 4.9 Membership TRACK provides a simple counted membership for each session,=20 available at the Sender node. This counted membership is a simple=20 count of the Receiver nodes that have joined a session as well as=20 any Repair Heads that are also acting as Receivers. A failure=20 report is also provided, which will notify a Sender of any Receivers=20 or Repair Heads that have been detected as having failed or being=20 forced to leave the group. Both the counted membership and failure=20 reports are piggybacked on ACK and NACK packets that are sent=20 towards the Sender, and aggregated together at each Repair Head. A=20 failure report is bounded in size, and so may not be able to report=20 all failures if many occur at once. =20 Each Repair Head and Sender also keeps track of the list of=20 currently attached children, and makes this information available to=20 authorized entities through an SNMP interface. An external=20 membership server could be used to periodically poll the full per=20 session membership from all the Repair Heads and Senders. Combined=20 with the real-time counted membership and failure reports, this=20 enables an application to keep accurate track of global group=20 membership. 4.10 Fault Detection and Recovery 4.10.1 Sender node failure detection A Sender node that has no data to send will periodically send=20 NullData packets on the Data Multicast Address. If a Receiver or a=20 Repair Head fails to receive Data packets or NullData packets for a=20 session sent by the Sender, the Receiver detects a Sender failure. 4.10.2 Receiver node failure detection A Receiver node sends ACKs and (optionally) NACKs for each of the=20 active sessions that it has joined. If none of the sessions are=20 active, then the Receiver sends HeartbeatResponse packets to its=20 parent. If a Receiver's parent node does not receive a ACK, NACK or a=20 HeartbeatResponse within a specified time interval, the parent=20 detects the failure of the Receiver and removes the child from its=20 child list. 4.10.3 Repair Head failure detection Each Repair Head node sends Heartbeat packets to its child nodes on=20 its multicast Control Tree. If the child nodes do not receive any=20 Heartbeats from their parent Repair Head, they detect failure of the=20 parent. 4.10.4 Repair Head discovery TRACK supports an option which allows the nodes in the TRACK tree to=20 acquire the addresses and location of its ancestors in the control=20 tree and the addresses of its parent's siblings. If a TRACK node's=20 parent fails, then the node can use the acquired information to join=20 an alternate control node. 4.10.5 Message Stability Semantics To successfully recover from a failed Repair Head, the children of=20 that Repair Head need to be able to recover the packets they missed=20 while transferring over to a new parent. TRACK provides two levels=20 of message stability, pessimistic and optimistic, to assist in this. =20 With pessimistic stability, a parent may only release a packet from=20 its Data Queue when it has been acknowledged by all of its=20 descendants. With optimistic stability, a parent may release a=20 packet from its Data Queue when each of its direct children have=20 acknowledged it. Pessimistic stability allows a child to recover by=20 switching to any node in the tree, since the Sender will still have=20 a copy of all that child=92s missing packets. Optimistic stability=20 requires less buffer space and may provide higher throughput, but=20 does not provide strong assurances that children will be able to=20 always recover from a failure of their parent. 4.10.6 Recovery When a child node detects failure of its parent node, it can try to=20 reconnect to an alternate Repair Head of the TRACK tree, or it can=20 try to reconnect directly to the Sender. The failure detection=20 timeouts, coupled with the use of pessimistic stability semantics=20 (if enabled), provide reasonable assurances that a single node=20 failure can be handled without any Receivers losing any of the data=20 packets in a session. 4.11 Ordering Semantics TRACK offers three levels of delivery ordering semantics: Unordered=20 Reliable, Time Bounded Reliable, and Source Ordered Reliable. These=20 are selected on a per session basis as part of the Session=20 Configuration Parameters. =20 Unordered Reliable provides a reliable stream of packets, without=20 duplicates, and delivers them in the order received. This allows=20 the lowest latency delivery for extremely time sensitive=20 applications. If a packet in the session can not be delivered for=20 some reason, a failure is declared for the session. Source Ordered Reliable provides TCP semantics on delivery. All=20 packets are delivered in the order sent, without duplicates, and=20 without losses. If a loss occurs, a failure is declared for the=20 session. Time Bounded Reliable provides bounded TCP semantics on delivery. A=20 specific time period is associated with the session, and this is the=20 maximum time allowed for recovery of a packet at the Receiver after=20 it is detected as lost. If recovery of all lost packets happen=20 within this time bound, then the session will have Source Ordered=20 Reliable semantics. For any packets that take longer than the time=20 bound to recover, the Receiver declares them as lost, notifies the=20 application of this, and then will deliver any packets that have=20 been pending due to the packets now declared as lost. =20 4.12 SNMP Support The Repair Heads and the Sender are designed to interact with SNMP=20 management tools. This allows network managers to easily monitor=20 and control the sessions being transmitted. All TRACK nodes have=20 SNMP MIBs defined. SNMP support is optional for Receiver nodes, but=20 is required for all other nodes. 5. Functional Specification for TRACK Requirements of Building Blocks=20 Work [2] provides a rationale for decomposing the RMT protocols in=20 to Building Blocks and Protocol Instantiations. This section=20 provides a simple specification of the functions that TRACK requires=20 from each of the Building Blocks. It also provides some basic=20 description of the interfaces between these components. Since the following overlaps with what is done in the BBs, all of=20 section 5 is for discussion purposes only, and is not meant to=20 replace what is specified in the supporting BBs. The BBs will=20 define the actual algorithms. 5.1 NACK-based Reliability This building block defines NACK-based loss detection/notification=20 and recovery. The major issues it addresses are implosion=20 prevention (suppression) and NACK semantics (i.e. how packets to be=20 retransmitted should be specified, both in the case of selective and=20 FEC loss repair). The NACK suppression mechanisms used by TRACK are unicast NACKs with=20 multicast confirmation and exponentially distributed timers. These=20 suppression mechanisms primarily need to both minimize delay while=20 also minimizing redundant messages. They may also need to have=20 special weighting to work with Congestion Feedback. 5.1.1 NACK BB Algorithms Exponential Back Off. When a packet is detected as lost, an=20 exponentially distributed timer is set, based on the algorithms in=20 [9]. This timer is biased based on the input congestion weighting=20 factor. If either a packet or an explicit suppression message with=20 the same sequence number is detected before the timer goes off, the=20 timer is cancelled. NACK Generation. When a timer goes off, the protocol instantiation=20 is notified to generate a NACK for that sequence number. The=20 protocol instantiation may, at its discretion, group multiple NACK=20 notifications in to a single NACK packet. For TRACK, NACKs are=20 implemented as a unicast packet with a multicast confirmation=20 response. Response to a Retransmission Request. When a Repair Head or other=20 possible retransmission agent receives the first NACK from another=20 group member for a given packet, it notifies the protocol=20 instantiation to send either a data retransmission or, if it doesn=92t=20 have the packet for retransmission, an optional suppression message. =20 It then sets an embargo timeout, tied to the RTT to the furthest=20 Receiver, during which other requests for the same packet will be=20 ignored. The length of this embargo doubles each time that a=20 retransmission is sent. This algorithm should also work with=20 requests for retransmissions that come in the form of ACKs, as the=20 algorithms and packet formats for both are identical, with the=20 exception of the suppression mechanisms used. GRA Signaling. A primary function of GRA is to do NACK=20 elimination/suppression and subcasting of repairs. In order to do=20 this, the transport need to signal the GRA-enabled routers to turn=20 on the appropriate algorithms. This algorithm has to deal with=20 issues such as router topology changes. While not dealt with in=20 detail here, this is a very subtle issue, which will have to be=20 dealt with carefully. 5.1.2 NACK BB Parameters Congestion Weighting. From Congestion Control BB. This is a=20 weighting parameter for NACK suppression timers. The exact=20 algorithms for this are still to be determined. Loss Notification. From TRACK protocol instantiation. Notification=20 at a Sender that a packet has been detected as lost, and the=20 sequence number of that packet. Retransmission Request. From TRACK protocol instantiation. When a=20 NACK or ACK with a request for retransmission is received, this=20 needs to be passed to the BB for handling retransmission requests. =20 GRA Enabled. From PI. Is GRA enabled in the network? 5.2 FEC Repair BB This building block is concerned with packet level FEC repair. It=20 specifies the FEC codec selection and the FEC packet naming=20 (indexing) for both reactive FEC and proactive FEC. 5.2.1 FEC BB Algorithms FEC Input. Receive a window of packets (not necessarily all at=20 once), and store pointers to them for use in the FEC Create Parity=20 algorithm. FEC Create Parity. Given a window of packets, create and return a=20 parity packet. If a window is not yet full, first call the FEC=20 Flush function. If there are no more parity packets that can be=20 generated for this window, then return an error or else return a=20 parity packet that has already been generated. This uses one of a=20 set of codecs, specified through the use of codepoints. For TRACK,=20 it is expected that the codecs will operate over relatively small=20 windows, to work with real-time applications and congestion control. FEC Flush. For a window that needs a parity packet, but is not yet=20 full, FEC flush creates all-zero packets for the rest of the packets=20 in the window. No more calls to FEC input can be made for this=20 window after FEC flush has been called. FEC Decode. Given a set of received data and/or parity packets,=20 decode the window using the specified FEC codec. 5.2.2 FEC BB Parameters Codec Code Point Index. What is the codec being used for encoding=20 and decoding? This is a fixed parameter per data stream. FEC Window Size. What is the number of packets in an FEC window? =20 This is a fixed parameter per data stream. FEC Maximum Parity. This is the maximum number of parity packets=20 that can be generated over a given window size. This is a fixed=20 parameter per data stream. Data Packet Sequence Number. This is the sequence number of a data=20 packet. This is input to FEC Input from the PI. =20 FEC Window Offset. For a given packet, what is the offset in to an=20 FEC window? This is associated with each Data packet that uses FEC. =20 It is a header field on each Data packet sent. It is sequential=20 over each packet in a window, unless a Flush occurs on a partially=20 full window. In that case, the window offset of this last packet is=20 set to FEC Window Size=961. For parity packets, the FEC Window Offset=20 starts at FEC Window Size, and goes up to FEC Window Size + FEC=20 Maximum Parity=961. This is returned from FEC Input and from FEC=20 Create Parity. 5.3 Congestion Control BB TRACK uses a source-based rate regulation algorithm, with a single=20 rate provided to all the Receivers in the session. The following set of algorithms and parameters is a subset of those=20 needed for a full implementation, but give an idea of what is=20 required.=20 5.3.1 Congestion Control BB Algorithms Initialization. A number of transport-wide parameters must be fed=20 to each of the nodes in the group, such as minimum rate, maximum=20 rate, data segment size, etc. Receiver Measurements. The Receiver must keep track of its average=20 loss rate, and RTT to the Sender. We will call these measures=20 =93congestion reports=94. Receiver Feedback. The Receivers must feed these congestion back=20 to the Sender, piggybacked on both NACKs and ACKs. =20 Hierarchical Aggregation. Restricted worst edge aggregation should=20 be used to aggregate the congestion reports in the ACKs and/or NACKs=20 being fed up the tree [10]. Every time that an ACK or NACK is=20 generated, this algorithm should be called to fill in the=20 appropriate fields. Every time an ACK or NACK is received, this=20 algorithm should be called to process the congestion control fields=20 in the packet. This algorithm must also be notified every time a=20 new child joins or leaves at a Repair Head or Sender. Sender Rate Control. Based on the congestion reports received, the=20 Sender must change its sending rate. TCP Friendly Equation. Given values for RTT, DataSize, and=20 LossRate, this generates a target throughput rate according to a=20 modified version of the complex TCP model given in [11]. 5.3.2 Congestion Control BB Parameters Initialization Parameters. A set of different options, some of=20 which can be permanent constants, but others are selected by either=20 the Sender or a network manager. =20 Lost Packet. Every time a packet is detected as lost, the Senders=20 must be notified of this. RTT Measurement. Every time a RTT measurement is generated, either=20 between Sender and Receiver(s), or between one level of the tree and=20 another, the CC BB must be notified. Highest Allowed Sequence Number (HASN). This is used to implement=20 =93receiver-driven=94 window control [13]. Each receiver can keep track=20 of a congestion window and compute the HASN to be included in each=20 ACK. A Repair Head aggregates the HASNs by computing the minimum=20 value from all its children and forwards that as its own HASN up the=20 tree. 5.4 Generic Router Assist BB The task of designing scaleable RM protocols can be made easier by=20 the presence of some specific support in routers. In some=20 application- specific cases, the increased benefits afforded by the=20 addition of special router support can justify the resulting=20 additional complexity and expense. Functional components which can take advantage of router support=20 include feedback aggregation/suppression (both for loss notification=20 and congestion control) and constrained retransmission of repair=20 packets. =20 The process of designing and deploying these mechanisms inside=20 routers can be much slower than the one required for end-host=20 protocol mechanisms. Therefore, it would be highly advantageous to=20 define these mechanisms in a generic way that multiple protocols can=20 use if it is available, but do not necessarily need to depend on. This component has two halves, a signaling protocol and actual=20 router algorithms. The signaling protocol allows the transport=20 protocol to request from the router the functions that it wishes to=20 perform, and the router algorithms actually perform these functions.=20 An important component of the signaling protocol is some level of=20 commonality between the packet headers of multiple protocols, which=20 allows the router to recognize and interpret the headers. This is=20 covered in the section on common packet headers, below. 5.4.1 GRA BB Algorithms NACK Suppression. NACKs are sent towards the parent Repair Head or=20 Sender, with a Router Alert option on. GRA enabled routers detect=20 these packets and suppress redundant NACKs. It then updates a soft=20 state table so that it knows to retransmit the requested packet to=20 the requesting children, using Dynamic Selective Retransmission. The=20 NACK suppression algorithm needs to work with both ACKs and NACKs,=20 in order for Dynamic Selective Retransmission to work with TRACK. =20 This means that GRA can not suppress ACKs but must still use them to=20 update its state for retransmissions. It also means that GRA must=20 work with ACK and NACK selective bitmaps, not just NACKs that=20 request a single packet. Dynamic Selective Retransmission. When a retransmission occurs, it=20 is only forwarded to the interfaces of each router that have=20 signaled through the use of NACKs that they need to see that packet. Nearest Repair Head Hint. The router is made aware of the nearest=20 Repair Heads, and is able to tell a child which is the best=20 candidate for it to use. This must only be used as a hint to=20 children. Fine Grained Loss Reports. A major limitation of TFMCC is its=20 limitation of only getting 1-bit loss reports (i.e. a packet is=20 lost, or it is not) from the routers. A 8 or 16 bit report,=20 piggybacked on to data packets, with the cumulative loss detected=20 across all interfaces of GRA enabled routers the data packet=20 crossed, would allow TRACK to become much more responsive to changes=20 in network conditions. These reports can only be used as hints. Signaling Protocol. The functions for GRA need to be requested by=20 the protocol ahead of time, and then the run time packet headers=20 need to be decipherable by the router. =20 5.4.2 GRA BB Parameters GRA Enabled. Is GRA enabled in any of the routers in the network? =20 Which functions do the deployed version of GRA support? Packet Format. Which type of packet format is GRA to operate over? =20 It is likely that different protocol instantiations will require=20 differences in the packet headers they send to the router. This is=20 tied to the common packet header BB, below. 5.5 Automatic Tree Configuration BB TRACK takes advantage of hierarchical Repair Heads, to greatly=20 increase the theoretical scalability of the protocol. These Repair=20 Heads are used to form a tree with the source at the root, the=20 Receivers at the leaves of the tree, and the Repair Heads in the=20 middle. The Repair Heads can either be dedicated server software=20 for this task, or they may be application nodes that are performing=20 dual duty. The effectiveness of these agents to assist in the delivery of data=20 is highly dependent upon how well the logical tree they use to=20 communicate matches the underlying routing topology. The purpose of=20 this building block is to construct and manage the logical tree=20 connecting the agents. Ideally, this building block will perform=20 these functions in a manner that adapts to changes in session=20 membership, routing topology, and network availability. 5.5.1 Auto Tree BB Algorithms These are discussed in section 3.3. They are not yet mature enough=20 to break down in to component parts. 5.5.2 Auto Tree BB Parameters These are discussed in section 3.3. The algorithms are not yet=20 mature enough to break down in to the parameters needed. 5.6 Security As specified in [12], the primary security requirement for a TRACK=20 protocol is protection of the transport infrastructure. This is=20 accomplished through the use of lightweight group authentication of=20 the control and, optionally, the data packets sent to the group. =20 These algorithms use IPsec and shared symmetric keys. For TRACK,=20 [12] recommends that there be one shared key for the Data Session=20 and one for each Local Control Channel. These keys are distributed=20 through a separate key manager component, which may be either=20 centralized or distributed. Each member of the group is responsible=20 for contacting the key manager, establishing a pair-wise security=20 association with the key manager, and obtaining the appropriate=20 keys. The TRACK protocol then provides options for piggy-backing=20 key update messages on the Data Session and each Local Control=20 Channel of the protocol. These can either include a new shared=20 group key (encrypted with the old group key) or a notification that=20 the group key(s) are being changed and that the group members should=20 contact the key manager to get the new key(s). The former typically=20 occurs on a periodic basis, while the latter may occur when a group=20 member leaves. The exact algorithms for this BB is presently the subject of=20 research within the IRTF Secure Multicast Group (SMuG). Solutions=20 for these requirements will be standardized within the IETF when=20 ready. 5.7 Common Headers BB As pointed out in the generic router support section, it is=20 important to have some level of commonality across packet headers. =20 It may also be useful to have common data header formats for other=20 reasons. This building block consists of recommendations on fields=20 in their packet headers that protocols should make common across=20 themselves. TRACK needs to implement these recommendations in the=20 TRACK PI. 5.7.1 Common Header BB Fields GRA Signaling. The Retransmission, NACK and ACK packet headers need=20 to provide a means for signaling their existence to GRA. For NACK=20 and ACK headers, the selective bitmap needs to be specified in a=20 common way across all protocols so that the GRA component can=20 interpret these fields and determine the sequence numbers of the=20 packets that are being requested. For the Retransmission packets,=20 the sequence number of the packet needs to be in a standard position=20 so that GRA can interpret it. For both NACK, ACK and Retransmission=20 packets, the Session ID needs to be specified in a standard way=20 across protocols. Data Packets. The identification of data packets within a stream=20 should be common across all protocols, both to aid in commonality of=20 application semantics across protocols and to aid in GRA signaling.=20 A Data Packet is identified by three fields: the Session ID, the=20 Sequence Number, and the FEC Window Offset. The Session ID may=20 include the multicast address and/or a unique ID. The sequence=20 number starts at 1 and increments with each Data packet sent in the=20 Session. Sequence numbers are always sequentially generated,=20 without gaps. The FEC Window Offset specifies the offset of a Data=20 packet in to an FEC window. For a window of W generated packets, a=20 maximum window size of M, and a maximum parity size of P, the=20 packets are numbered as follows. The first W-1 packets are numbered=20 as 0 through W-2, with W never to exceed M. Packet W is always=20 numbered as M-1, so that Receivers and Repair Heads can detect a=20 partially filled window. The P parity packets are numbered M=20 through M+P-1. IP and UDP. It is easiest to implement protocols in the application=20 space using UDP packets, but eventual kernel implementations will=20 have TRACK implemented directly on top of IP. Other protocols share=20 this requirement, and the way that this transition is done should be=20 specified across all protocols. 6. Security Considerations 7. Open Issues 1. At various places in the document (e.g. Section 1, 3.5), different=20 flavors of reliability services are described. We need to define=20 them and describe how they are selected/configured. It seems=20 there are at least three flavors of reliability: ? ACK-to-sender (also known as pessimistic) ? ACK-to-RH (also known as optimistic) ? Time-bounded (useful for supporting real-time applications) It is argued that the pessimistic flavor should be optional (for=20 implementation) as it is less useful. Currently, Time-bounded is included in 4.11 as a kind of ordering=20 semantics, which does not seem appropriate. 2. Receivers talk to their parents with three kinds of messages:=20 ACKs, NACKs and heartbeatResponse. They can all be the same=20 message. The recipient of the message can always tell from the=20 packet content and recipient=92s local state the message=92s intent. 3. Control Tree. TreeId has been removed. It is not clear how to=20 refer to a subset of a control tree (a set of RHs bind with each=20 other, without a sender as a root) to be re-used/shared. Since=20 half of the Session Id is not controlled by TRACK, it seems that=20 they can be used to identify such sharable control (sub)trees when=20 appropriate. 4. It is suggested that a different type be used to distinguish=20 retransmission Data Packets from original Data Packets. The=20 ability to distinguish retransmission from the original packet=20 helps quickly determine if the packet came from the sender or a=20 Repair Head. 5. Section 4.1.8. Originally, there was a AcceptPending packet, used=20 to indicate that the Bind is successful pending further=20 confirmation. This has been removed in favor of using a Reject=20 with a reason code. The reason for this change is that the=20 AcceptPending approach leaves state at the RH that becomes=20 difficult to clean up. If not careful, it may be open to Denial- of-service attack. The simple reject and retry approach is=20 considered more robust. The change, however, has not been agreed=20 to by all authors, and becomes an open issue. 6. Section 4.1.8 and 4.10.2. The descriptions of how heartbeat and=20 heartbeatResponses are generated are lacking. There is a proposal=20 to allow heartbeat to contain mechanism to prompt for=20 heartbeatResponse. Such prompting can reduce the need for regular=20 heartbeatResponses from receivers. These algorithms need further=20 agreements. 7. Section 4.3 describes a 2-pass =93bottom-up=94 tree construction=20 algorithm. It has been suggested that if the Binding is done=20 =93top-down=94 there is no need for a 2-pass process and hence the=20 whole algorithm can be simpler. Furthermore, these algorithms=20 should be debated and worked out in the Tree Configuration BB. 8. TRACK depends on being able to configure a Control Tree. The Tree=20 Configuration BB must deliver some standard base-level mechanism,=20 even if completely static. Otherwise, some static configuration=20 mechanisms need to be specified in the TRACK PI. 9. Section 4.10.4 describes a mechanism for a receiver to find RH=20 information from its current RH, to serve as backup RHs. This is=20 really a requirement for the Tree Configuration BB to supply such=20 a mechanism. If one is not available from the Tree BB, then the=20 described mechanism would be used. 10. Need to add discussion of Late Join support 11. Need to add discussion of how session can gracefully close 12. In section 4.6, a number of other tactics for controlling ACK=20 and NACK traffic are possible, for instance, having receivers=20 stagger NACK production on different window boundaries. 13. Need to specify how RH determines the retransmission rate. 8. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP=20 9, RFC 2026, October 1996. 2 Whetten, B., et. al. =93Reliable Multicast Transport Building=20 Blocks for One-to-Many Bulk-Data Transfer.=94 Internet Draft,=20 draft-ietf-rmt-buildingblocks-02.txt, Work in Progress. 3 Handley, M., et. al. =93The Reliable Multicast Design Space for=20 Bulk Data Transfer.=94 Internet Draft, draft-ietf-rmt-design- space-01.txt, Work in Progress.=20 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement=20 Levels", BCP 14, RFC 2119, March 1997 5 Whetten, B., Taskale, G. =93Overview of the Reliable Multicast=20 Transport Protocol II (RMTP-II).=94 IEEE Networking, Special Issue=20 on Multicast, February 2000. 6 Nonnenmacher, J., Biersack, E. "Reliable Multicast: Where to use Forward Error Correction", Proc. 5th. Workshop on=20 Protocols for High Speed Networks, Sophia Antipolis, France, Oct.=20 1996. 7 Nonnenmacher, J., et. al. "Parity-Based Loss Recovery for=20 Reliable Multicast Transmission", In Proc. of ACM SIGCOMM '97,=20 Cannes, France, September 1997. 8 Rizzo, L. "Effective erasure codes for reliable computer communications protocols", DEIT Technical Report LR-970115. 9 Nonnenmacher, J., Biersack, E. "Optimal Multicast Feedback",=20 Proc. IEEE INFOCOM 1998, March 1998. 10 Whetten, B., Conlan, J. =93A Rate Based Congestion Control Scheme=20 for Reliable Multicast=94, GlobalCast Communications Technical=20 White Paper, November 1998. http://www.talarian.com/rmtp-ii 11 Padhye, J., et. al. =93Modeling TCP Throughput: A Simple Model=20 and its Empirical Validation=94. University of Massachusetts=20 Technical Report CMPSCI TR 98-008. 12 Hardjorno, T., Whetten, B. =93Security Requirements for TRACK=20 Protocols.=94 Work in Progress. 13 Golestani, J., =93Fundamental Observations on Multicast Congestion=20 Control in the Internet=94, Bell Labs, Lucent Technology, paper=20 presented at the July 1998 RMRG meeting. 14 Kadansky, M., D. Chiu, J. Wesley, J. Provino, =93Tree-based=20 Reliable Multicast (TRAM)=94, draft-kadansky-tram-02.txt, Work in=20 Progress. 15 Whetten, B., M. Basavaiah, S. Paul, T. Montgomery, =93RMTP-II=20 Specification=94, draft-whetten-rmtp-ii-00.txt, April 8, 1998. Work=20 in Progress. 8. Acknowledgments Special thanks goes to the following individuals, who have=20 contributed to the design and review of this document. Supratik Bhattacharyya, Sprint Labs Miriam Kadansky, Sun Microsystems Seok Koh, ETRI Korea Joseph Wesley, Sun Microsystems 9. Author's Addresses Brian Whetten Talarian Corporation 333 Distel Circle Los Altos CA 94022 whetten@talarian.com Dah Ming Chiu Sun Microsystems Laboratories 1 Network Drive Burlington, MA 01803 dahming.chiu@sun.com Sanjoy Paul Edgix Corporation 130 W. 42nd Street, Suite 850 New York, NY 10036 sanjoy@edgix.com Full Copyright Statement Copyright (C) The Internet Society, 2000. All Rights Reserved. This=20 document and translations of it may be copied and furnished to=20 others, and derivative works that comment on or otherwise explain it=20 or assist in its implementation may be prepared, copied, published=20 and distributed, in whole or in part, without restriction of any=20 kind, provided that the above copyright notice and this paragraph=20 are included on all such copies and derivative works. However, this=20 document itself may not be modified in any way, such as by removing=20 the copyright notice or references to the Internet Society or other=20 Internet organizations, except as needed for the purpose of=20 developing Internet standards in which case the procedures for=20 copyrights defined in the Internet Standards process must be=20 followed, or as required to translate it into other languages. =09TRACK ARCHITECTURE=09March 2000 =20 B. Whetten=09Internet Draft =96 Expires September 2000=0925 =20 B. Whetten=09Internet Draft =96 Expires September 2000=091 --Brace_of_Greyhounds_614_000-- >From owner-rmt@listserv.lbl.gov Sat Apr 29 01:23:25 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id BAA08684; Sat, 29 Apr 2000 01:21:30 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA08680 for ; Sat, 29 Apr 2000 01:21:29 -0700 (PDT) From: jeffallen@spotbuy.com Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA27401 for ; Sat, 29 Apr 2000 01:21:28 -0700 (PDT) Received: from spotbuy.com (host-209-214-98-67.sav.bellsouth.net [209.214.98.67]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id BAA27382; Sat, 29 Apr 2000 01:21:21 -0700 (PDT) Subject: Would you like to save 30% on your phone bills and... Date: Sat, 29 Apr 2000 04:27:40 Message-Id: <845.90767.552162@spotbuy.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rmt@lbl.gov Precedence: bulk To be removed from this mailing list immediately press reply and enter REMOVE on the subject line. Would you like some information on saving 30% on your Phone bills each month and how to get up to 8% back each month on your Utilities including phone. This service works for both business and residential, domestic and international. Sign up is FREE Reply with "MORE INFO" in the subject field >From owner-rmt@listserv.lbl.gov Sun Apr 30 22:56:39 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id WAA12919; Sun, 30 Apr 2000 22:54:48 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA12915 for ; Sun, 30 Apr 2000 22:54:46 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA22558 for ; Sun, 30 Apr 2000 22:54:45 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA22555 for ; Sun, 30 Apr 2000 22:54:45 -0700 (PDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id WAA21332; Sun, 30 Apr 2000 22:54:44 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id WAA24949; Sun, 30 Apr 2000 22:54:41 -0700 (MST)] Received: from motorola.com (mccoy.arc.corp.mot.com [217.1.10.204]) by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id PAA13919; Mon, 1 May 2000 15:54:38 +1000 (EST) Message-ID: <390D1C1E.9452CBAB@motorola.com> Date: Mon, 01 May 2000 15:54:38 +1000 From: Roger Kermode Organization: Motorola Austrlian Research Centre X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list , Scott Bradner Subject: RMT WG Last CALL: Content-Type: multipart/mixed; boundary="------------8F38AEAC6FB5130BE03D6DE9" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------8F38AEAC6FB5130BE03D6DE9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please be advised that the Design Space and Building Blocks drafts: http://www.ietf.org/internet-drafts/draft-ietf-rmt-design-space-01.txt http://www.ietf.org/internet-drafts/draft-ietf-rmt-buildingblocks-02.txt are now officially in WG Last Call that will expire 15 May 2000. Please address any comments/requests for clarification to the document authors, regards, Roger Kermode Allison Mankin Lorenzo Vicisano --------------8F38AEAC6FB5130BE03D6DE9 Content-Type: text/x-vcard; charset=us-ascii; name="Roger.Kermode.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Roger Kermode Content-Disposition: attachment; filename="Roger.Kermode.vcf" begin:vcard n:Kermode;Roger tel;cell:+61-408-212-284 tel;fax:+61-2-9666-0501 tel;work:+61-2-9666-0558 x-mozilla-html:FALSE url:http://www.arc.corp.mot.com org:Motorola Australian Research Centre;Communications and Networks Laboratory version:2.1 email;internet:ark008@email.mot.com title:Principal Research Engineer / Manager adr;quoted-printable:;;12 Lord St. Level 3=0D=0A=0D=0A;Botany;NSW;2019;Australia x-mozilla-cpt:;-27712 fn:Roger Kermode end:vcard --------------8F38AEAC6FB5130BE03D6DE9-- >From owner-rmt@listserv.lbl.gov Thu May 11 17:42:49 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id RAA04247; Thu, 11 May 2000 17:38:35 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA04243 for ; Thu, 11 May 2000 17:38:33 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA10613 for ; Thu, 11 May 2000 17:38:32 -0700 (PDT) Received: from hercules.cs.ucsb.edu (hercules.cs.ucsb.edu [128.111.41.30]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA10606 for ; Thu, 11 May 2000 17:38:32 -0700 (PDT) Received: from duke.cs.ucsb.edu (duke [128.111.49.49]) by hercules.cs.ucsb.edu (8.9.3+Sun/8.8.6) with ESMTP id RAA19567 for ; Thu, 11 May 2000 17:38:30 -0700 (PDT) Received: by duke.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4) id RAA14135 for rmt@lbl.gov; Thu, 11 May 2000 17:38:30 -0700 (PDT) Date: Thu, 11 May 2000 17:38:30 -0700 (PDT) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <200005120038.RAA14135@duke.cs.ucsb.edu> To: rmt@lbl.gov Subject: NGC 2000 Call for Papers Sender: owner-rmt@lbl.gov Precedence: bulk C A L L F O R P A P E R S D U E : J U N E 5 T H The 2nd International Workshop on Networked Group Communication (NGC 2000) November 8-10, 2000 Stanford University Palo Alto, California, USA Organized by Sprint and COST 264 in cooperation with ACM Sigcomm --------------------------------- Scope of the Conference ----------------------- The aim of the Workshop is to allow researchers and practioners to present the design and implementation techniques for networked group communication. The focus of the Workshop is strictly on multicast and networked group communication. This Workshop is the second and only international event in this area (first workshop was in Pisa, Italy, in November 1999). The workshop will start with half day tutorials on the 8th. The technical program will include two keynotes and invited talks on the 9th and the 10th of November 2000. Authors are invited to submit papers on any issue related to networked group communication, including but not limited to: multicast congestion control multicast routing, naming, address allocation scalability in multicast services reliable and semi-reliable multicast protocols novel multicast architectures multicast security multicast deployment related issues multicast over heterogeneous media multipeer applications (distributed interactive apps, games, DIS) QoS issues with multicast Pricing and economic model for multicast traffic group management techniques network engineering for multicast services Paper Submission Guidelines --------------------------- Papers must be less than 20 double-spaced pages long, have an abstract of 100-150 words, and be original material that has not been previously published nor is currently under review by another conference or journal. Authors must submit papers electronically, using the instructions at http://www.cs.ucsb.edu/ngc2000/ (NOTE: paper submission will be available starting May 15th). The Proceedings of the Workshop will be published by ACM and papers will be available on-line prior to the workshop. Important Dates --------------- Paper Submission: June 5, 2000 Author Notification: August 28, 2000 Camera Ready: September 11, 2000 ----------------------------------------------- For more information, visit the workshop WWW page at: http://www.cs.ucsb.edu/ngc2000/ >From owner-rmt@listserv.lbl.gov Mon May 15 22:20:49 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id WAA16879; Mon, 15 May 2000 22:19:08 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA16875 for ; Mon, 15 May 2000 22:19:06 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA06501 for ; Mon, 15 May 2000 22:19:05 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA06498 for ; Mon, 15 May 2000 22:19:04 -0700 (PDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id WAA28192; Mon, 15 May 2000 22:19:03 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id WAA05110; Mon, 15 May 2000 22:19:01 -0700 (MST)] Received: from motorola.com (mccoy.arc.corp.mot.com [217.1.10.204]) by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id PAA02204; Tue, 16 May 2000 15:18:54 +1000 (EST) Message-ID: <3920DA3E.D26D177A@motorola.com> Date: Tue, 16 May 2000 15:18:54 +1000 From: Roger Kermode Organization: Motorola Austrlian Research Centre X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Roger Kermode CC: rmt-list , Scott Bradner Subject: Last chance RMT WG Last CALL on DS and BB drafts References: <390D1C1E.9452CBAB@motorola.com> Content-Type: multipart/mixed; boundary="------------809E6C4B4FD0D879DF73BA76" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------809E6C4B4FD0D879DF73BA76 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Absolute last chance for comments. If none are received within the next 24hours then I will send these two drafts up for IESG last call, cheers, Roger Roger Kermode wrote: > Please be advised that the Design Space and Building Blocks > drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-rmt-design-space-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-rmt-buildingblocks-02.txt > > are now officially in WG Last Call that will expire 15 May 2000. > > Please address any comments/requests for clarification to the > document authors, > > regards, > > Roger Kermode > Allison Mankin > Lorenzo Vicisano --------------809E6C4B4FD0D879DF73BA76 Content-Type: text/x-vcard; charset=us-ascii; name="Roger.Kermode.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Roger Kermode Content-Disposition: attachment; filename="Roger.Kermode.vcf" begin:vcard n:Kermode;Roger tel;cell:+61-408-212-284 tel;fax:+61-2-9666-0501 tel;work:+61-2-9666-0558 x-mozilla-html:FALSE url:http://www.arc.corp.mot.com org:Motorola Australian Research Centre;Communications and Networks Laboratory version:2.1 email;internet:ark008@email.mot.com title:Principal Research Engineer / Manager adr;quoted-printable:;;12 Lord St. Level 3=0D=0A=0D=0A;Botany;NSW;2019;Australia x-mozilla-cpt:;-27712 fn:Roger Kermode end:vcard --------------809E6C4B4FD0D879DF73BA76-- >From owner-rmt@listserv.lbl.gov Thu Jun 1 08:00:37 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id HAA06821; Thu, 1 Jun 2000 07:55:14 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA06817 for ; Thu, 1 Jun 2000 07:55:12 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA03291 for ; Thu, 1 Jun 2000 07:55:11 -0700 (PDT) Received: from hercules.cs.ucsb.edu (hercules.cs.ucsb.edu [128.111.41.30]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA03286 for ; Thu, 1 Jun 2000 07:55:10 -0700 (PDT) Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10]) by hercules.cs.ucsb.edu (8.9.3+Sun/8.8.6) with ESMTP id HAA25603; Thu, 1 Jun 2000 07:55:03 -0700 (PDT) Received: by jackson.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4) id HAA18411 for ; Thu, 1 Jun 2000 07:55:01 -0700 (PDT) Date: Thu, 1 Jun 2000 07:55:01 -0700 (PDT) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <200006011455.HAA18411@jackson.cs.ucsb.edu> To: almeroth@cs.ucsb.edu, cdiot@sprintlabs.com Subject: NGC CFP (Deadline June 5th) Sender: owner-rmt@lbl.gov Precedence: bulk The paper submission deadline is June 5th. C A L L F O R P A P E R S The 2nd International Workshop on Networked Group Communication (NGC 2000) November 8-10, 2000 Stanford University Palo Alto, California, USA Organized by Sprint, Cisco Systems, and COST 264 in cooperation with ACM Sigcomm --------------------------------- Scope of the Conference ----------------------- The aim of the Workshop is to allow researchers and practioners to present the design and implementation techniques for networked group communication. The focus of the Workshop is strictly on multicast and networked group communication. This Workshop is the second and only international event in this area (first workshop was in Pisa, Italy, in November 1999). The workshop will start with half day tutorials on the 8th. The technical program will include two keynotes and invited talks on the 9th and the 10th of November 2000. Authors are invited to submit papers on any issue related to networked group communication, including but not limited to: multicast congestion control multicast routing, naming, address allocation scalability in multicast services reliable and semi-reliable multicast protocols novel multicast architectures multicast security multicast deployment related issues multicast over heterogeneous media multipeer applications (distributed interactive apps, games, DIS) QoS issues with multicast Pricing and economic model for multicast traffic group management techniques network engineering for multicast services The Proceedings of the Workshop will be published by ACM and papers will be available on-line prior to the workshop. Paper Submission Guidelines --------------------------- Papers must be less than 20 double-spaced pages long, have an abstract of 100-150 words, and be original material that has not been previously published nor is currently under review by another conference or journal. Authors must submit papers electronically, using the instructions at http://www.cs.ucsb.edu/ngc2000/ Important Dates --------------- Paper Submission: June 5, 2000 Author Notification: August 28, 2000 Camera Ready: September 11, 2000 ----------------------------------------------- For more information, visit the workshop WWW page at: http://www.cs.ucsb.edu/ngc2000/ >From owner-rmt@listserv.lbl.gov Thu Jun 8 09:39:29 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id JAA02605; Thu, 8 Jun 2000 09:35:09 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA02601 for ; Thu, 8 Jun 2000 09:35:07 -0700 (PDT) From: zainprov@swbell.net Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA07041 for ; Thu, 8 Jun 2000 09:35:06 -0700 (PDT) Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA07034 for ; Thu, 8 Jun 2000 09:35:06 -0700 (PDT) Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FVU00BB0FA6SN@mta5.rcsntx.swbell.net> for rmt@lbl.gov; Thu, 8 Jun 2000 11:06:12 -0500 (CDT) Date: Thu, 08 Jun 2000 11:06:12 -0500 (CDT) Date-warning: Date header was inserted by mta5.rcsntx.swbell.net Subject: Shocking LOSE 10-100lbs. DESTINY To: rmt@lbl.gov Message-id: <0FVU00BLUFEASN@mta5.rcsntx.swbell.net> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Sender: owner-rmt@lbl.gov Precedence: bulk Hello From Destiny, You will LOOSE 20-100 pounds easy! Do to Such a high demand for Destiny, we are able To Dramatically reduce our price for the entire System! You will LOVE our incredible offer on this Scientific Breakthrough in Weight Loss. Now with a 105% Money Back Guarantee! LOOK! http://home.swbell.net/zainprov/destiny.htm We hope things are going well for you. Good luck, God Bless, and HAVE A GREAT DAY! Either you are someone else subscribed to our list. To be removed Simply reply with a blank email. Thank you, Sherry Wilson >From owner-rmt@listserv.lbl.gov Fri Jun 9 19:04:06 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id TAA13155; Fri, 9 Jun 2000 19:02:15 -0700 (PDT) Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id TAA13151 for ; Fri, 9 Jun 2000 19:02:13 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id TAA07431 for ; Fri, 9 Jun 2000 19:02:12 -0700 (PDT) Received: from gslacks.cs.umass.edu (gslacks.cs.umass.edu [128.119.245.66]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id TAA07428 for ; Fri, 9 Jun 2000 19:02:11 -0700 (PDT) Received: from localhost (brian@localhost) by gslacks.cs.umass.edu (8.9.3/8.9.3) with SMTP id VAA28314; Fri, 9 Jun 2000 21:57:06 -0400 X-Authentication-Warning: gslacks.cs.umass.edu: brian owned process doing -bs Date: Fri, 9 Jun 2000 21:57:06 -0400 (EDT) From: Brian Levine cc: brian@cs.umass.edu Subject: SIGCOMM Student Travel Grants due June 22 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rmt@lbl.gov Precedence: bulk The application deadline for Sigcomm 2000 Student Travel Grants is fast approaching. This year, we are fortunate and expect to receive funding from the NSF, ACM SIGCOMM, and the Nokia Corporation! Thanks to our generous benefactors, we are expecting to fund quite a large number of students. The committee strongly prefers to give grants to students who are not paper authors, though such students are welcome to apply. Other criteria will include evidence of a serious interest in networking, as demonstrated by coursework and project experience. ACM SIGCOMM encourages participation of women and under-represented minorities. The amount of support provided to each student is intended to cover the student's travel, food and lodging for four nights. Students throughout the world are encouraged to apply, however, funding from NSF is limited solely to US students. The recipients of the travel grants will be decided by a committee including Brian Neil Levine, U. Massachusetts Amherst, USA Ellen Zegura, Georgia Tech, USA Roch Guerin, U. Pennsylvania, USA Luigi Rizzo, Universit di Pisa, Italy An application for a travel grant will consist of a letter from the student and a recommendation letter from the student's advisor. Please see the conference web site for important details regarding each letter. Send application and recommendation letters by email to Brian Levine, brian@cs.umass.edu, in ASCII, Postscript or PDF format. Use the same email address also for questions on the ACM SIGCOMM travel grant program. Important Dates: Application deadline: June 22, 2000 Notification date: July 6, 2000 http://www.acm.org/sigcomm/sigcomm2000 Please accept my apologies if you receive this message from multiple sources or if I have disrupted your mailing list. Sincerely, Brian Neil Levine Department of Computer Science UMass Amherst >From owner-rmt@listserv.lbl.gov Wed Jun 14 11:21:53 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id LAA02681; Wed, 14 Jun 2000 11:19:35 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA02677 for ; Wed, 14 Jun 2000 11:19:33 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA05968 for ; Wed, 14 Jun 2000 11:19:32 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA05943 for ; Wed, 14 Jun 2000 11:19:31 -0700 (PDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA17668 for ; Wed, 14 Jun 2000 11:19:19 -0700 (PDT) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA29334 for ; Wed, 14 Jun 2000 14:18:44 -0400 (EDT) Received: from maple (maple [129.148.75.29]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id OAA18484 for ; Wed, 14 Jun 2000 14:18:43 -0400 (EDT) Message-Id: <200006141818.OAA18484@bcn.East.Sun.COM> Date: Wed, 14 Jun 2000 14:18:43 -0400 (EDT) From: Miriam Kadansky - SUN Microsystems Reply-To: Miriam Kadansky - SUN Microsystems Subject: Tree Configuration and TRACK Design team meeting To: rmt@lbl.gov MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: f+IZQv8vuZR7VCc39TJHdw== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-rmt@lbl.gov Precedence: bulk Hello, Brian Whetten suggested that those of us signed up to work on the tree-building BB and the TRACK PI get together in person before the Pittsburgh IETF and get our drafts done. Dah Ming Chiu and I will be hosting the meeting here at Sun's Burlington MA office from June 26th through June 29th. The other attendees so far are Brad Cain Brian Levine Brian Whetten Other contributors are certainly welcome to attend, but rest assured that the RMT group will have ample time to review and comment on our results before and during the IETF meeting. You won't miss anything unless you have something to contribute that you haven't already sent to the list. If you'd like to attend, please email both Dah Ming and I (miriam.kadansky@sun.com dahming.chiu@sun.com) and we'll let you know the details. ----------------------------- Miriam Kadansky Senior Staff Engineer Sun Microsystems Labs 781-442-0750 miriam.kadansky@sun.com Dah Ming Chiu Senior Staff Engineer Sun Microsystems Labs office: 781-442-0525 cell: 617-283-6261 dahming.chiu@sun.com >From owner-rmt@listserv.lbl.gov Fri Jun 16 10:05:09 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id KAA12959; Fri, 16 Jun 2000 10:02:53 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA12955 for ; Fri, 16 Jun 2000 10:02:51 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA06388 for ; Fri, 16 Jun 2000 10:02:50 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA06373 for ; Fri, 16 Jun 2000 10:02:49 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17241; Fri, 16 Jun 2000 13:02:46 -0400 (EDT) Message-Id: <200006161702.NAA17241@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: rmt@lbl.gov From: The IESG Subject: Document Action: The Reliable Multicast Design Space for Bulk Data Transfer to Informational Date: Fri, 16 Jun 2000 13:02:46 -0400 Sender: owner-rmt@lbl.gov Precedence: bulk The IESG has approved the Internet-Draft 'The Reliable Multicast Design Space for Bulk Data Transfer' as an Informational RFC. This document is the product of the Reliable Multicast Transport Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. >From owner-rmt@listserv.lbl.gov Fri Jun 23 05:21:33 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id FAA20063; Fri, 23 Jun 2000 05:18:56 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA20059 for ; Fri, 23 Jun 2000 05:18:53 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA02797 for ; Fri, 23 Jun 2000 05:18:53 -0700 (PDT) Received: from nilla.aciri.org (p25.stsn.com [208.32.226.25] (may be forged)) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA02794 for ; Fri, 23 Jun 2000 05:18:51 -0700 (PDT) Received: from nilla.aciri.org (localhost [127.0.0.1]) by nilla.aciri.org (8.9.3/8.9.3) with ESMTP id FAA02122; Fri, 23 Jun 2000 05:38:17 -0700 (PDT) (envelope-from mjh@nilla.aciri.org) Message-Id: <200006231238.FAA02122@nilla.aciri.org> From: Mark Handley X-Organisation: ACIRI To: rmt@lbl.gov, rm@mash.cs.berkeley.edu Subject: RMRG Meeting Jul 28 in Arlington, VA Date: Fri, 23 Jun 2000 05:38:17 -0700 Sender: owner-rmt@lbl.gov Precedence: bulk We didn't get back very many responses saying people were interested in an RMRG meeting before the IETF. Thus, the plan now is to have a one-day meeting on Friday July 28th, at ISI-East in Arlington, VA. See http://www.east.isi.edu for details of the location. The focus of the meeting will be purely on multicast congestion control, with the aim of understanding where we stand with regard to allowing some of this work to move into the IETF for standardization. The room at ISI is rather small, so we need people who wish to attend to RSVP to both Allison and me so we can tell if we will have enough space. Also, please mail us with agenda items. - Mark and Allison >From owner-rmt@listserv.lbl.gov Fri Jun 23 09:29:28 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id JAA21737; Fri, 23 Jun 2000 09:27:17 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA21733 for ; Fri, 23 Jun 2000 09:27:15 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA22635 for ; Fri, 23 Jun 2000 09:27:14 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id JAA22623 for ; Fri, 23 Jun 2000 09:27:13 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 23 Jun 2000 10:26:21 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 23 Jun 2000 10:26:17 -0600 From: "Sukanta Ganguly" To: , , Subject: Re: RMRG Meeting Jul 28 in Arlington, VA Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by SpamWall.lbl.gov id JAA21734 Sender: owner-rmt@lbl.gov Precedence: bulk Mark, Since the IETF is just a couple of days after this scheduled meeting, wouldn't it be possible to reschedule this sometime during the week of the IETF. Due to other work assignments it may be difficult for many to attend. Atleast in my case, though I am a newbie to this, I would eagerly want to attend it but won't be in the position to be physically present at the ISI-east Arlington site on the specified day. I can't say anything about others. Though this is not a formal IETF WG, people could always schedule informal get togethers. As far as IETF is concerned they should not have any objection such informal evening technical discussion. Is it feasible? If not then unlucky but interested individuals like can always go though the meeting notes, conclusions, minutes etc. Would appreciate your response Thanks >>> Mark Handley 06/23/00 06:38AM >>> We didn't get back very many responses saying people were interested in an RMRG meeting before the IETF. Thus, the plan now is to have a one-day meeting on Friday July 28th, at ISI-East in Arlington, VA. See http://www.east.isi.edu for details of the location. The focus of the meeting will be purely on multicast congestion control, with the aim of understanding where we stand with regard to allowing some of this work to move into the IETF for standardization. The room at ISI is rather small, so we need people who wish to attend to RSVP to both Allison and me so we can tell if we will have enough space. Also, please mail us with agenda items. - Mark and Allison >From owner-rmt@listserv.lbl.gov Fri Jun 23 09:55:11 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id JAA21858; Fri, 23 Jun 2000 09:54:52 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA21854 for ; Fri, 23 Jun 2000 09:54:50 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA02744 for ; Fri, 23 Jun 2000 09:54:49 -0700 (PDT) Received: from nilla.aciri.org ([18.170.2.5]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA02730 for ; Fri, 23 Jun 2000 09:54:48 -0700 (PDT) Received: from nilla.aciri.org (localhost [127.0.0.1]) by nilla.aciri.org (8.9.3/8.9.3) with ESMTP id KAA03040; Fri, 23 Jun 2000 10:14:48 -0700 (PDT) (envelope-from mjh@nilla.aciri.org) Message-Id: <200006231714.KAA03040@nilla.aciri.org> From: Mark Handley X-Organisation: ACIRI To: "Sukanta Ganguly" cc: rmt@lbl.gov, rm@mash.cs.berkeley.edu Subject: Re: RMRG Meeting Jul 28 in Arlington, VA In-reply-to: Your message of "Fri, 23 Jun 2000 10:26:17 MDT." Date: Fri, 23 Jun 2000 10:14:48 -0700 Sender: owner-rmt@lbl.gov Precedence: bulk > Since the IETF is just a couple of days after this scheduled meeting, >wouldn't it be possible to reschedule this sometime during the week of >the IETF. I'm afraid not - there's no way to schedule a full-day meeting during the IETF without clashing with sessions that Allison and I have to attend. Cheers, Mark >From owner-rmt@listserv.lbl.gov Thu Jun 29 02:24:37 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id CAA07252; Thu, 29 Jun 2000 02:21:25 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA07248 for ; Thu, 29 Jun 2000 02:21:23 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA27706 for ; Thu, 29 Jun 2000 02:21:23 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA27703 for ; Thu, 29 Jun 2000 02:21:22 -0700 (PDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id CAA21991 for ; Thu, 29 Jun 2000 02:21:18 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id CAA24587 for ; Thu, 29 Jun 2000 02:21:16 -0700 (MST)] Received: from arc.corp.mot.com ([217.1.10.142]) by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id e5T9L4e26237 for ; Thu, 29 Jun 2000 19:21:14 +1000 (EST) Message-ID: <395B14FD.48D489E6@arc.corp.mot.com> Date: Thu, 29 Jun 2000 19:21:01 +1000 From: Roger Kermode Reply-To: Roger.Kermode@motorola.com Organization: Motorola X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: RMT Call for agenda items for Pittsburgh Content-Type: multipart/mixed; boundary="------------B2C981EF2CFFF2D0D02E55AA" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------B2C981EF2CFFF2D0D02E55AA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear RMTers, The draft ietf-draft deadline is rapdily approaching...so it's time that we start to put together an agenda for Adelaide. Let's keep the momemtum going from the interim meeting, please send items for disucssion to the chairs as soon as you can cheers, Roger FYI ...Lorenzo and I have been working on the guidelines draft, we will post what we have to the list by the end of the week. --------------B2C981EF2CFFF2D0D02E55AA Content-Type: text/x-vcard; charset=us-ascii; name="rkermode.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Roger Kermode Content-Disposition: attachment; filename="rkermode.vcf" begin:vcard n:Kermode;Roger tel;cell:+61-408-212-284 tel;fax:+61-2-9666-0501 tel;home:+61-2-9664-8335 tel;work:+61-2-9666-0558 x-mozilla-html:FALSE url:www.mot.com.au org:Motorola Australian Research Centre;Communications and Networking Lab version:2.1 email;internet:Roger.Kermode@motorola.com title:Principal Research Engineer, Manager adr;quoted-printable:;;Level 3,=0D=0A12 Lord St.;Botany;NSW;2019;Australia fn:Roger Kermode end:vcard --------------B2C981EF2CFFF2D0D02E55AA-- >From owner-rmt@listserv.lbl.gov Thu Jun 29 02:29:44 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id CAA07304; Thu, 29 Jun 2000 02:29:41 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA07300 for ; Thu, 29 Jun 2000 02:29:39 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA28061 for ; Thu, 29 Jun 2000 02:29:39 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA28058 for ; Thu, 29 Jun 2000 02:29:38 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id CAA28276 for ; Thu, 29 Jun 2000 02:29:02 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id CAA23141 for ; Thu, 29 Jun 2000 02:29:04 -0700 (MST)] Received: from arc.corp.mot.com ([217.1.10.142]) by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id e5T9Sue26280 for ; Thu, 29 Jun 2000 19:28:56 +1000 (EST) Message-ID: <395B16D5.4E5C096@arc.corp.mot.com> Date: Thu, 29 Jun 2000 19:28:53 +1000 From: Roger Kermode Reply-To: Roger.Kermode@motorola.com Organization: Motorola X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: Re: RMT Call for agenda items for Pittsburgh References: <395B14FD.48D489E6@arc.corp.mot.com> Content-Type: multipart/mixed; boundary="------------C4BA31062458B8CA05C39E91" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------C4BA31062458B8CA05C39E91 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Roger Kermode wrote: > Dear RMTers, > > The draft ietf-draft deadline is rapdily approaching...so it's > time that we start to put together an agenda for Adelaide. Ahh the joys of cut and paste and hitting the send key to early at the end of a long day...make that Pittsburgh *sigh*! > Let's keep the momemtum going from the interim meeting, Groan ...make that the last meeting > please send items for disucssion to the chairs as soon as > you can > > cheers, > > Roger > > FYI ...Lorenzo and I have been working on the guidelines > draft, we will post what we have to the list by the end of > the week. --------------C4BA31062458B8CA05C39E91 Content-Type: text/x-vcard; charset=us-ascii; name="rkermode.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Roger Kermode Content-Disposition: attachment; filename="rkermode.vcf" begin:vcard n:Kermode;Roger tel;cell:+61-408-212-284 tel;fax:+61-2-9666-0501 tel;home:+61-2-9664-8335 tel;work:+61-2-9666-0558 x-mozilla-html:FALSE url:www.mot.com.au org:Motorola Australian Research Centre;Communications and Networking Lab version:2.1 email;internet:Roger.Kermode@motorola.com title:Principal Research Engineer, Manager adr;quoted-printable:;;Level 3,=0D=0A12 Lord St.;Botany;NSW;2019;Australia fn:Roger Kermode end:vcard --------------C4BA31062458B8CA05C39E91-- >From owner-rmt@listserv.lbl.gov Tue Jul 11 04:26:20 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id EAA21218; Tue, 11 Jul 2000 04:20:12 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA21214 for ; Tue, 11 Jul 2000 04:20:09 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA20532 for ; Tue, 11 Jul 2000 04:20:08 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA20529 for ; Tue, 11 Jul 2000 04:20:07 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id EAA05440 for ; Tue, 11 Jul 2000 04:20:07 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id EAA05344 for ; Tue, 11 Jul 2000 04:20:04 -0700 (MST)] Received: from arc.corp.mot.com ([217.2.31.106]) by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id e6BBK1e23046 for ; Tue, 11 Jul 2000 21:20:02 +1000 (EST) Message-ID: <396B02DF.E80DB2F8@arc.corp.mot.com> Date: Tue, 11 Jul 2000 21:19:59 +1000 From: Roger Kermode Reply-To: Roger.Kermode@motorola.com Organization: Motorola X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: RMT Author Guidelines Draft Content-Type: multipart/mixed; boundary="------------E7C941D9DE1B05428797AEE5" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------E7C941D9DE1B05428797AEE5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear patient RMT Working Group members, please find attached the first pass on the long awaited guidelines draft: "Author Guidelines for RMT Building Blocks and Protocol Instantiation documents" The draft should appear on the Internet Drafts archive shortly. Please take the time to read through the draft and to provide feedback to the list. We'd like to rev this document through to RFC as soon as we can. regards, Roger Kermode Lorenzo Vicisano Allison Mankin --------------E7C941D9DE1B05428797AEE5 Content-Type: text/plain; charset=us-ascii; name="draft-ietf-rmt-author-guidelines-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-rmt-author-guidelines-00.txt" RMT Working Group R.Kermode/Motorola Internet Engineering Task Force L.Vicisano/Cisco INTERNET-DRAFT draft-ietf-rmt-author-guidelines-00.txt 29 June 2000 Expires 29 December 2000 Author Guidelines for RMT Building Blocks and Protocol Instantiation documents Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as a "work in progress". To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This document provides general guidelines to assist the authors of reliable multicast transport (RMT) building block and protocol instantiation definitions. The purpose of these guidelines is to ensure that any building block and protocol instantiation definitions produced contain sufficient information to fully explain their operation and use. If followed these guidelines will result in clearly defined RMT building blocks and protocol instantiation definitions that can be refined and augmented to create new protocols for use in new scenarios for which any existing protocols were not designed. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Draft RMT Draft Author Guidelines 29 June 2000 1. Introduction Reliable Multicast Transport (RMT) protocols can be constructed in a variety of ways, some of which will work better for certain situations then others. It is believed that the requirements space for reliable multicast transport is sufficiently diverse that no one protocol can meet all the requirements [RMT-DS]. However, it is also believed that there is sufficient commonality between the various approaches that it should be possible to define a number of building blocks [RMT-BB] from which the various RMT protocols can be constructed. One key benefit of this approach is that the same building block can be used multiple times in different protocol instantiations. Another key benefit is that building blocks may be upgraded as experience and understanding is gained. For this operation to be possible the building block needs to be clearly defined in terms of what it does, how interacts with other building blocks and how fits into the overall architecture of a protocol instantiation. This description should also be sufficiently detailed so that those wishing to improve upon a particular building block or protocol instantiation can do with a full understanding of the design decisions and tradeoffs were made earlier. The building block approach presents also some dangers that must be well understood in order to avoid potential specification flaws. The most important danger is related to inappropriate usage of building blocks. Although any effort should be made in order to produce a modular and reusable specification of building blocks, for practical reasons this goal is not always fully achievable. This results in the specification of building blocks whose applicability is context dependent. In order to avoid mis-usage of the building blocks, any external dependency must be highlighted in the building block specification. Furthermore, the specification must contain a precise applicability statement for the building block. Conversely, any protocol instantiation specification must state how any building block being used in it meets the protocol instantiation's applicability requirements. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and"OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Expires 29 December 2000 [Page 2] Draft RMT Draft Author Guidelines 29 June 2000 2. The Guidelines This document provides guidelines for authors of the two main kinds of RMT drafts; building block drafts and protocol instantiation drafts. The guidelines for each are as follows. 2.1. Building Block Draft Guidelines All RMT Building block drafts MUST contain sections that cover the following. 2.1.1. Rationale Individual building blocks SHOULD be reusable within multiple protocols and MUST provide functionality not present within other building blocks. If a building block is currently used in a single protocol instantiation, then it MUST specify some functionality that is likely to be reused in another (future) protocol instantiation. The rational section of a building block draft must clearly define why the particular level of granularity for the functional decomposition that resulted in the building block was chosen. If the granularity is too small it is highly likely that the building blocks will be trivial, and therefore require excessive additional effort to realize a working protocol. Conversely, if the level of granularity is too large building blocks will only usable within a single protocol instantiation. This section MUST show that level of granularity is appropriate so that neither problem occurs. 2.1.2. Functionality The functionality section within a building block draft MUST describe all algorithms and functions contained within the building block. In addition, the external interfaces for accessing these algorithms and functions must be fully specified so that the building block can be combined with other building blocks and any additional functionality specified within a protocol instantiation draft to realize a working protocol. Expires 29 December 2000 [Page 3] Draft RMT Draft Author Guidelines 29 June 2000 2.1.3. Applicability Statement One of the most important sections of a building block draft will be the Applicability Statement. The purpose of this section is to provide sufficient details about the intended use of the building block so that potential authors of protocol instantiation will be able to use the building block in conformance to its applicability constraints. Also the Applicability Statement section will enable future building blocks drafts authors to quickly be able to determine whether or not their particular need can be met with an existing building block. For this to be possible the Applicability Statement MUST describe o Intended scenarios for the building block's use o The building blocks known failure modes, why they occur, and how they can be detected. o A list of environmental considerations that includes but is not limited to whether the building block requires multi-source multicast or can be used in single-source only multicast networks, satellite networks, asymmetric networks, and wireless networks. 2.1.4. Packet-Header Fields If a building block implements a functionality whose realization requires an exchange of protocol messages between multiple agents, then the building block specification MUST state what kind of information is required and how this is exchanged. This includes detailed description the data format and various communication requirements, such as timing constraints, and network requirement (e.g. multicast vs. unicast delivery). Typically the data format specification is at the level of "generic header fields" without a full bit-level header specification. Generic header fields MAY specify additional requirement, such as representation precision or preferred position within the packet header (this last constraint might be dictated by efficiency concerns). A building block specification MAY specify "abstract messages" that carry particular information for exclusive use within the building block, however, more frequently, it will rely on the protocol messages specified in the protocol instantiation to carry the information it needs. Expires 29 December 2000 [Page 4] Draft RMT Draft Author Guidelines 29 June 2000 The building block that provides Generic Router Assist functionality is and exception to the rule state above. For efficiency reason, this building block may fully specify header fields and position of these fields within the packet-header. 2.1.5. Requirements from other Building Blocks Each building block will encapsulate a specific well defined piece of functionality that is common to multiple protocol instantiations. However, this does not mean that building block definitions will be generated in isolation from other building blocks. For example, a congestion control building block will have specific requirements regarding loss notification from either a NACK or ACK building block. The "Requirements from other Building Blocks" section is included to capture these requirements so that the authors of related building blocks can determine what functionality they need to provide in order to use a particular building block. Specifically, the "Requirements from other Building Blocks section" MUST provide a complete and exhaustive enumeration of all the requirements that will be made upon other building blocks in order for the building block being specified to operate in its intended manner. Requirements that SHOULD be enumerated include but are not limited to o Event generation for and responses to other building blocks o Message ordering relative to messages from other building blocks. 2.1.6. Security Considerations Protocol instantiations have the ultimate responsibility of addressing security requirements, in conformance to RFC2357. Security consideration may not be applicable to generic building blocks other than a specific "security" building block. Some building blocks, however, may rise special security issues, either due to the nature of communication required by the building block or due to the intended usage of the building block in a protocol instantiation. When special security issues are present in a building block, its specification MUST address them explicitly. An example of this might be a building block that involves exchange of data that is particularly sensitive to security attacks. Expires 29 December 2000 [Page 5] Draft RMT Draft Author Guidelines 29 June 2000 2.1.7. Codepoint Considerations Certain Building Blocks will specify general frameworks for describing functionality while leaving the detail open for implementation specific algorithms. One example of such a building block is the Forward Error Correction (FEC) building block which describes how the framing aspects for FEC message fragments but not the algorithms used to generate the redundant data. 2.1.8. Summary Checklist Rationale _ Provide justification for the building block's existence _ Provide rationale for the building block's granularity Functionality _ Functionality contained within the building block _ External interfaces Applicability Statement _ Intended usage _ Failure modes (including means of detection if known) _ Environmental considerations Packety Header Fields _ Specification of logical packet-header fields (*) _ Abstract messages specifications (*) Requirements from other building blocks; _ Mandatory needs from other building blocks Security Considerations _ Specify as much as possible (w.r.t. procedures, algorithms and data encoding), without affecting the general applicability of the building block. (*) May not be applicable to some building blocks. Expires 29 December 2000 [Page 6] Draft RMT Draft Author Guidelines 29 June 2000 2.2. Protocol Instantiation Draft Guidelines Protocol Instantiation drafts have one purpose: to specify how one can combine multiple building blocks to construct a new fully specified working protocol. To that end RMT Protocol Instantiation drafts MUST contain the following four sections. 2.2.1. Applicability Statement The applicability statement's purpose is to frame the design space in which the fully realized protocol will operate and to thereby enable subsequent would be RMT protocol designers to determine whether or not an existing protocol already meets their needs. For this to be possible the applicability statement MUST adhere to the following guidelines 1) The target application space for which the protocol is intended MUST be clearly identified. For example; is the protocol to be used for real-time delivery or not, or non-real time file transfer. 2) The target scale, in terms of maximum number of receivers per session, for which the protocol is intended MUST be clearly specified. If the protocol has an architectural limitation resulting from the optimization of another feature, say per packet acknowledgment, this SHOULD be included. 3) The applicability statement MUST identify the intended environment's for the protocols use AND list any environments in which the protocol should not be used. Example environments that should be considered include asymmetric networks, wireless networks, and satellite networks. 4) Finally, all protocols have inherent weaknesses that stem from the optimization for a specific feature. These weaknesses can manifest in spectacular failure modes when certain conditions occur. When known these conditions and the nature of how the subsequent failure can be detected MUST be included in the applicability statement. 2.2.2. Architecture Definition Protocol Instantiations define how to combine one or more building blocks to create a working protocol. The Architecture Definition lays out the framework for how this take place. For this framework to be complete, it MUST contain the following information: Expires 29 December 2000 [Page 7] Draft RMT Draft Author Guidelines 29 June 2000 1) An overview of the major facets of the protocols operation. 2) Full enumeration and overview of which Building Blocks with explicit references to their documents that define them. 3) An overview of how the aforementioned building blocks are to be joined. 4) A discussion of the design tradeoffs made in the selection of the chosen architecture. 2.2.3. Conformance Statement The conformance statement below MUST be included and adhered to "This Protocol Instantiation document, in conjunction with the following Building Block documents identified in [list of relevant building block references] completely specifies a working reliable multicast transport protocol that conforms to the requirements described in RFC 2357." Protocol instantiation document authors are specifically reminded that RFC2357 requires that any RMT protocol put forward for standardization with the IETF is required to protect the network in as much as is possible. This does not mean that RMT protocols will be held to a higher standard than unicast transport protocols, merely that they should be designed to perform at least as well as unicast transport protocols when it comes to the possibility of protocol failure. 2.2.4. Functionality Definition Building Block documents will be incomplete in that they will specify an abstract framework of a building block's functionality. Complete algorithmic specifications for each building block along with any additional functionality MUST provided within the Protocol Instantiation document's functionality definition. Furthermore, this description must show that each building block is used in accordance with its respective applicability statement. Finally the functionality description must provide a description of the abstract programming interface for interfacing the protocol instantiation with the applications that will use it. Expires 29 December 2000 [Page 8] Draft RMT Draft Author Guidelines 29 June 2000 2.2.5. Packet Formats Once all the functionality has been fully defined, the Protocol Instantiation document must defined the packet formats that will be used by the protocol. Each message part and the rules for their concatenation MUST be specified for both IPv4 [RFC791] and IPv6 [RFC2460]. Support for IPSEC [RFC2401] MUST be explicitly shown. In recognition of the fact that protocols will evolve and that IP protocol numbers are a scarce resource, protocol instantiations MUST initially define packet formats for use over UDP [RFC768]. [RK: Open issue about general purpose RMT protocol number] 2.2.6. Summary Checklist Applicability Statement _ Target application space _ Target scale _ Intended environment _ Weaknesses and known failure modes Architecture Definition _ Operational overview _ Building blocks used _ Details on how building blocks are joined Conformance Statement _ Inclusion of mandatory paragraph Functionality Definition _ Building block algorithmic specification _ Addition functionality specification _ Compliance with building block applicability statements _ Abstract program interface Packet Formats _ IPv4 message parts _ IPv6 message parts _ IPSEC support _ Message ordering Expires 29 December 2000 [Page 9] Draft RMT Draft Author Guidelines 29 June 2000 3. IANA Considerations General RMT protocol number? [RK: need to talk with ADs about this] 4. Acknowledgments This document represents an overview of the mandatory elements required for the specification of building blocks and protocol instantiations within the the for RMT working group. The requirements presented are a summarization of discussions held between the RMT Working Group chairs and the participants in the IRTF Reliable Multicast Research Group. Although the name of these participants are too numerous to list here, the Working Group chairs would like to thank everyone who has participated in these discussions for their contributions. 5. References [HWKFV99] M. Handley, B.Whetten, R. Kermode, S.Floyd, L. Vicisano, and M. Luby, "The Reliable Multicast Design Space for Bulk Data Transfer," Internet Draft, Internet Engineering Task Force, March 1999. [WLKHFL99] B.Whetten, L. Vicisano, R. Kermode, M. Handley, S.Floyd, and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer," Internet Draft, Internet Engineering Task Force, March 1999. [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", RFC2401, November 1998. [RFC791] J. Postel, "Darpa Internet Protocol Specification", ST5, RFC791, September 1981. [RFC2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC2460, December 1998. [RFC768] J. Postel, "User Datagram Protocol", RFC768, August 1980. Expires 29 December 2000 [Page 10] Draft RMT Draft Author Guidelines 29 June 2000 6. Authors' Addresses Roger Kermode Motorola Australian Research Centre Locked Bag 5028 Botany NSW 1455, Australia. Roger.Kermode@motorola.com Lorenzo Vicisano Cisco Systems, 170 West Tasman Dr. San Jose, CA 95134, USA lorenzo@cisco.com 7. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Expires 29 December 2000 [Page 11] Draft RMT Draft Author Guidelines 29 June 2000 Table of Contents 1 Introduction .................................................... 2 1.1 Terminology ................................................... 2 2 The Guidelines .................................................. 3 2.1 Building Block Draft Guidelines ............................... 3 2.1.1 Rationale ................................................... 3 2.1.2 Functionality ............................................... 3 2.1.3 Applicability Statement ..................................... 4 2.1.4 Packet-Header Fields ........................................ 4 2.1.5 Requirements from other Building Blocks ..................... 5 2.1.6 Security Considerations ..................................... 5 2.1.7 Codepoint Considerations .................................... 6 2.1.8 Summary Checklist ........................................... 6 2.2 Protocol Instantiation Draft Guidelines ....................... 7 2.2.1 Applicability Statement ..................................... 7 2.2.2 Architecture Definition ..................................... 7 2.2.3 Conformance Statement ....................................... 8 2.2.4 Functionality Definition .................................... 8 2.2.5 Packet Formats .............................................. 9 2.2.6 Summary Checklist ........................................... 9 3 IANA Considerations ............................................. 10 4 Acknowledgments ................................................. 10 5 References ...................................................... 10 6 Authors' Addresses .............................................. 11 7 Full Copyright Statement ........................................ 11 Expires 29 December 2000 [Page 12] --------------E7C941D9DE1B05428797AEE5 Content-Type: text/x-vcard; charset=us-ascii; name="rkermode.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Roger Kermode Content-Disposition: attachment; filename="rkermode.vcf" begin:vcard n:Kermode;Roger tel;cell:+61-408-212-284 tel;fax:+61-2-9666-0501 tel;home:+61-2-9664-8335 tel;work:+61-2-9666-0558 x-mozilla-html:FALSE url:www.mot.com.au org:Motorola Australian Research Centre;Communications and Networking Lab version:2.1 email;internet:Roger.Kermode@motorola.com title:Principal Research Engineer, Manager adr;quoted-printable:;;Level 3,=0D=0A12 Lord St.;Botany;NSW;2019;Australia fn:Roger Kermode end:vcard --------------E7C941D9DE1B05428797AEE5-- >From owner-rmt@listserv.lbl.gov Wed Jul 12 02:01:01 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id BAA25535; Wed, 12 Jul 2000 01:58:44 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA25531 for ; Wed, 12 Jul 2000 01:58:41 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA05685 for ; Wed, 12 Jul 2000 01:58:41 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id BAA05681 for ; Wed, 12 Jul 2000 01:58:40 -0700 (PDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 12 Jul 2000 09:58:24 +0100 To: Roger.Kermode@motorola.com cc: rmt-list , J.Crowcroft@cs.ucl.ac.uk Subject: Re: RMT Author Guidelines Draft In-reply-to: Your message of "Tue, 11 Jul 2000 21:19:59 +1000." <396B02DF.E80DB2F8@arc.corp.mot.com> Date: Wed, 12 Jul 2000 09:58:22 +0100 Message-ID: <2313.963392302@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk In message <396B02DF.E80DB2F8@arc.corp.mot.com>, Roger Kermode typed: >> >>"Author Guidelines for RMT Building Blocks and >> Protocol Instantiation documents" Roger et al, typo in 2.1.6 security considerations - 3rd sentance - "some building blocks, however, may rise"... - should be "raise" meanwhile, i would say you need another section - the building block approach brings in a new risk compared with other transport protocol efforts:- that of feature interactions - you could have blocks A+B go together ok and B+C, but not A+B+C ....i can't think of an exact example, but i am sure there's one in the area of multirate congestion control, router supprt, and security, for example:-) cheers jon >From owner-rmt@listserv.lbl.gov Wed Jul 12 03:34:04 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA25671; Wed, 12 Jul 2000 03:32:22 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA25667 for ; Wed, 12 Jul 2000 03:32:20 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA12351 for ; Wed, 12 Jul 2000 03:32:19 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA12347 for ; Wed, 12 Jul 2000 03:32:18 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15232; Wed, 12 Jul 2000 06:32:17 -0400 (EDT) Message-Id: <200007121032.GAA15232@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rmt@lbl.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rmt-author-guidelines-00.txt Date: Wed, 12 Jul 2000 06:32:17 -0400 Sender: owner-rmt@lbl.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Multicast Transport Working Group of the IETF. Title : Author Guidelines for RMT Building Blocks and Protocol Instantiation documents Author(s) : R. Kermode, L. Vicisano Filename : draft-ietf-rmt-author-guidelines-00.txt Pages : 12 Date : 11-Jul-00 This document provides general guidelines to assist the authors of reliable multicast transport (RMT) building block and protocol instantiation definitions. The purpose of these guidelines is to ensure that any building block and protocol instantiation definitions produced contain sufficient information to fully explain their operation and use. If followed these guidelines will result in clearly defined RMT building blocks and protocol instantiation definitions that can be refined and augmented to create new protocols for use in new scenarios for which any existing protocols were not designed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-author-guidelines-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rmt-author-guidelines-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmt-author-guidelines-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000711135128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-author-guidelines-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-author-guidelines-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000711135128.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Wed Jul 12 08:33:41 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id IAA27260; Wed, 12 Jul 2000 08:31:50 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA27256 for ; Wed, 12 Jul 2000 08:31:48 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA15677 for ; Wed, 12 Jul 2000 08:31:47 -0700 (PDT) Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id IAA15644 for ; Wed, 12 Jul 2000 08:31:44 -0700 (PDT) Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id <3JZBJW0Q>; Wed, 12 Jul 2000 17:31:21 +0200 Message-ID: From: =?iso-8859-1?Q?BABONNEAU_G=E9rard_FTRD/DMI/REN?= To: "'ietf-rmt-list'" Subject: Building Blocks Date: Wed, 12 Jul 2000 17:31:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by SpamWall.lbl.gov id IAA27257 Sender: owner-rmt@lbl.gov Precedence: bulk Hello, I'm modeling multicast protocols, and I'm currently working on PGM. Many networks works better when senders have a constant or limited throughput. Do you intend to include a function to control the throughput in the congestion control block, or to create a new BB to control the sender rate? In this second case, it could receive information from congestion control to adapt the rate, if necessary. Best regards, Salutations, Gérard BABONNEAU >From owner-rmt@listserv.lbl.gov Wed Jul 12 12:10:53 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id MAA28025; Wed, 12 Jul 2000 12:10:17 -0700 (PDT) Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA28021 for ; Wed, 12 Jul 2000 12:10:15 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA03251 for ; Wed, 12 Jul 2000 12:10:14 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA03244 for ; Wed, 12 Jul 2000 12:10:14 -0700 (PDT) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [171.69.65.85]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA23449; Wed, 12 Jul 2000 12:09:58 -0700 (PDT) Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA04222; Wed, 12 Jul 2000 12:09:43 -0700 (PDT) Message-Id: <200007121909.MAA04222@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.0.2 2/24/98 To: =?iso-8859-1?Q?BABONNEAU_G=E9rard_FTRD/DMI/REN?= cc: "'ietf-rmt-list'" Subject: Re: Building Blocks In-Reply-To: Your message of "Wed, 12 Jul 2000 17:31:25 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Wed, 12 Jul 2000 12:09:43 -0700 From: Lorenzo Vicisano Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by SpamWall.lbl.gov id MAA28022 Sender: owner-rmt@lbl.gov Precedence: bulk Gerard, > I'm modeling multicast protocols, and I'm currently working on PGM. > Many networks works better when senders have a constant or limited > throughput. Do you intend to include a function to control the throughput in > the congestion control block, or to create a new BB to control the sender > rate? In this second case, it could receive information from congestion > control to adapt the rate, if necessary. If the issue is "using a fixed rate instead of doing congestion control", it's only acceptable in privately controlled network, not in the Internet (RFC2357). If instead you are proposing to add an upper bound to the sender rate and still perform congestion control without crossing the upper limit, I believe that you can just go ahead and implement this (it doesn't require specification). It is true that you might end up using less than your fair share and hence you should be allowed to customize you CC algorithm (e.g. making it more aggressive), however I believe that is a complex issue to be dealt with carefully. Lorenzo >From owner-rmt@listserv.lbl.gov Wed Jul 12 17:19:54 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id RAA00136; Wed, 12 Jul 2000 17:19:10 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA00132 for ; Wed, 12 Jul 2000 17:19:08 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA08177 for ; Wed, 12 Jul 2000 17:19:07 -0700 (PDT) Received: from vedatel.com (root@[216.207.224.25]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA08167 for ; Wed, 12 Jul 2000 17:19:00 -0700 (PDT) Received: from vedatel.com (adsl-77.dacor.net [205.133.74.77]) by vedatel.com (8.9.3/8.9.3) with ESMTP id UAA68613; Wed, 12 Jul 2000 20:53:40 -0400 (EDT) (envelope-from tscott@vedatel.com) Message-ID: <396D0C23.574BB3AF@vedatel.com> Date: Wed, 12 Jul 2000 20:24:03 -0400 From: Telecom Tom Organization: Vedatel X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4m) X-Accept-Language: en-US, es, de, fr MIME-Version: 1.0 To: rmt@lbl.gov Subject: Re: I-D ACTION:draft-ietf-rmt-author-guidelines-00.txt References: <200007121032.GAA15232@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Internet-Drafts@ietf.org wrote: > Title : Author Guidelines for RMT Building Blocks and Protocol > Instantiation documents > Author(s) : R. Kermode, L. Vicisano > Filename : draft-ietf-rmt-author-guidelines-00.txt > Pages : 12 > Date : 11-Jul-00 > > This document provides general guidelines to assist the authors of > reliable multicast transport (RMT) building block and protocol > instantiation definitions. The purpose of these guidelines is to ensure > that any building block and protocol instantiation definitions produced > contain sufficient information to fully explain their operation and use. > If followed these guidelines will result in clearly defined RMT building > blocks and protocol instantiation definitions that can be refined and > augmented to create new protocols for use in new scenarios for which any > existing protocols were not designed. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-rmt-author-guidelines-00.txt Would you consider adding two references at the end of the draft: [Boecking00] S. Boecking, "Object-Oriented Network Protocols," London: Addison-Wesley, 2000. [Gouda98] M. Gouda, "Elements of Network Protocol Design," New York: Wiley, 1998. I can't resist the temptation to explicitly mention the O-word. These building blocks resemble objects. Is that the intention of the RMT WG? -- TT --------------------------------------------------- Tom Nelson Scott Vedatel Co 1411 Sheffield Dr. Bowling Green OH 43402 "In IP We Trust" "Java Rules" "E Pluribus Unix" --------------------------------------------------- >From owner-rmt@listserv.lbl.gov Wed Jul 12 17:34:32 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id RAA00236; Wed, 12 Jul 2000 17:34:05 -0700 (PDT) Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA00232 for ; Wed, 12 Jul 2000 17:34:03 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA11620 for ; Wed, 12 Jul 2000 17:34:02 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA11615 for ; Wed, 12 Jul 2000 17:34:02 -0700 (PDT) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [171.69.65.85]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA01581; Wed, 12 Jul 2000 17:33:46 -0700 (PDT) Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA04784; Wed, 12 Jul 2000 17:33:31 -0700 (PDT) Message-Id: <200007130033.RAA04784@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.0.2 2/24/98 To: Jon Crowcroft cc: Roger.Kermode@motorola.com, rmt-list Subject: Re: RMT Author Guidelines Draft In-Reply-To: Your message of "Wed, 12 Jul 2000 09:58:22 BST." <2313.963392302@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Jul 2000 17:33:31 -0700 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk > meanwhile, i would say you need another section - the building block > approach brings in a new risk compared with other transport protocol > efforts:- that of feature interactions - you could have blocks A+B > go together ok and B+C, but not A+B+C ....i can't think of an exact > example, but i am sure there's one in the area of > multirate congestion control, router supprt, and security, > for example:-) Jon, 2.1.3 (Applicability Statement) addresses this in part, but we should make it more explicit. Thanks for your comments, Lorenzo >From owner-rmt@listserv.lbl.gov Thu Jul 13 17:40:55 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id RAA04492; Thu, 13 Jul 2000 17:39:13 -0700 (PDT) Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA04488 for ; Thu, 13 Jul 2000 17:39:11 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA02891 for ; Thu, 13 Jul 2000 17:39:10 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA02876 for ; Thu, 13 Jul 2000 17:39:09 -0700 (PDT) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [171.69.65.85]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA20089 for ; Thu, 13 Jul 2000 17:38:52 -0700 (PDT) Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA07084 for ; Thu, 13 Jul 2000 17:38:38 -0700 (PDT) Message-Id: <200007140038.RAA07084@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.0.2 2/24/98 To: rmt-list Subject: draft-ietf-rmt-pi-alc-01.txt and draft-ietf-rmt-bb-fec-01.txt Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_924555160" Date: Thu, 13 Jul 2000 17:38:38 -0700 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk This is a multipart MIME message. --==_Exmh_924555160 Content-Type: text/plain; charset=us-ascii Dear RMT-ers, Please find attached the latest revisions of the FEC-BB and ALC-PI drafts, just submitted to the IETF directory. The FEC-BB draft is in "tune" with the ALC-PI one and we (the document editors) have tried to accommodate the NORM PI needs as well (FEC+ARQ in general). We believe, however, that the FEC BB needs more work in this direction. It would be great if NORM PI editors, or any other interested party could provide feedback (or oven better written text) on this. Also, in the FEC draft we had to face the issue of how to designate FEC encoders that cannot be (or are not) formally specified. Our (proposed) solution is in sections 3 and 4 of the draft. We would really like to get some feedback on this important issue as well. Regards, Lorenzo Vicisano --==_Exmh_924555160 Content-Type: text/plain ; name="draft-ietf-rmt-pi-alc-01.txt"; charset=us-ascii Content-Description: draft-ietf-rmt-pi-alc-01.txt Content-Disposition: attachment; filename="draft-ietf-rmt-pi-alc-01.txt" RMT Working Group M.Luby/Digital Fountain Internet Engineering Task Force J.Gemmell/Microsoft INTERNET-DRAFT L.Vicisano/Cisco draft-ietf-rmt-pi-alc-01.txt L.Rizzo/U. of Pisa 13 July 2000 J. Crowcroft/UCL B. Lueckenhoff/Cadence Expires 13 January 2000 Asynchronous Layered Coding A massively scalable reliable multicast protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as a "work in progress". To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This document describes Asynchronous Layered Coding, a massively scalable reliable multicast protocol, hereafter referred to as ALC. ALC can be used to reliably deliver content to multiple receivers. The content can be any well-defined object. Examples include any type of file such as a group of pictures in an MPEG stream, a MP3 music file, a JPEG image, and a collection of files that are archived into one file. In addition, the delivery service model that can be provided with ALC is fairly flexible, e.g., an on demand service model and a push service model. A session is initiated by a single sender to transmit packets that contain data about a particular object. Receivers may join or Draft RMT PI, Asynchronous Layered Coding 13 July 2000 leave an existing session in an asynchronous manner independent of other receivers. Reliability is achieved via FEC coding only, i.e. all packets in a session contain FEC coded information about the object to be delivered. The crucial point is that there is no request for retransmission of individual packets from receivers that miss packets in order to assure reliable reception of the object, and the packets and their rate of transmission out of the sender are independent of the number and the individual reception experiences of the receivers. In some delivery service models, e.g, a push delivery model, it is appropriate that receivers send messages to the sender (either in or out of band) to either continue the session if receivers have not yet received enough packets or to terminate the session when receivers have received enough packets. To be able to track usage of the system, receivers can also send messages out of band to the sender that contain statistics on their reception experience. ALC, however, does not require nor specify such messages, with the aim of avoiding unnecessary limitation to the scalability of the protocol. Congestion control is achieved by sending packets in the session to several ALC groups. Receivers increase and decrease their session reception rate in reaction to network conditions by joining and leaving ALC groups associated with the session in a manner that is network friendly, similar to how TCP is network friendly. The congestion control algorithm is receiver driven, i.e., signals are placed into packets by the sender to indicate to receivers how to react to changing network conditions, and receivers adjust their reception rate in response to these signals and packet loss. Thus, each receiver experiences a reception rate appropriate to that receiver independent of other receivers. ALC has the following properties: o To each receiver, it appears as if though there is a dedicated unicast session from the sender to the receiver, where the reception rate adjusts to congestion along the path from sender to receiver in a manner similar to TCP. o To the sender, there is no difference in load or outgoing rate if one receiver is joined to the session or a million (or any number of) receivers are joined to the session, independent of when the receivers join and leave. Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 2] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 o On each link in the network, the packet traffic from the session and its reaction to competing traffic is the same whether there is one receiver or a million receivers beyond the link, and this reaction is similar to how a TCP session reacts. Thus, ALC provides a massively scalable content delivery system that is network friendly. 1. Introduction This document describes a massively scalable reliable protocol for content delivery using IP multicast. IP multicast, while powerful and efficient, is a "best effort" service [DEE88]. It does not guarantee packet reception, or reception order. Many reliable multicast protocols have been built on top of multicast. However, scalability is not a design goal for many reliable multicast protocols. Even among those reliable multicast protocols that target improved scalability, many still fall far short of the scalability of IP multicast itself. Others, while as scalable as IP multicast, require changes to routers or other infrastructure, making their deployment unlikely in the near term. One of the key difficulties in scaling reliable multicast is dealing with the amount of data that flows from receivers back to the sender. Protocols that avoid any such feedback can be massively scalable. The data carousel [AFZ95] approach is a simple protocol that avoids any feedback from the receivers. The sender simply loops repeatedly through the symbols of the object to be delivered, places the symbols into packets, and transmits the packets (a symbol is a small fixed size portion of data). If the receiver misses any symbol, it simply waits for the symbol to be sent again in the next loop. However, a receiver has to wait for the full loop to repeat to receive a symbol that is missed if the packet carrying it is lost. Forward error correction (FEC) coding can be used to improve the data carousel approach [RIZ97a], [GEM99], [VIC98A], [BYE98], [LUB00]. Using a FEC codec, i.e., a FEC encoder at the sender to generate packets from an object and the corresponding FEC decoder at the receivers to process packets in order to recover the object, can dramatically reduce the number of packets a given receiver needs to receive in order to recover the object. ALC relies exclusively on a FEC codec to achieve reliability, thereby avoiding non-scalable reliability mechanisms that rely on receiver feedback to the sender to trigger retransmission of missing packets. A description of FEC codes with packet content specification and considerations for their use in reliable IP multicast can be found in [FEC00]. This document utilizes the terminology and concepts introduced in it. Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 3] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 An attractive feature of ALC is the ability for different receivers to join and leave a session and ALC groups within the session asynchronously without adversely affecting the reception experience of other receivers and without affecting the scalability of the protocol. ALC congestion control is achieved by sending packets associated with a given session to several ALC groups and individual receivers only join to a subset of these groups. The set of ALC groups a receiver joins is determined by the receiver based on signals placed into packets by the sender and by loss measured by the receiver along the path from the sender to that receiver. Receivers that can receive packets at a rate higher than their current rate are allowed to increase their reception rate, and receivers that are receiving packets at a higher rate than they have the capacity for (as evidenced by packet loss) MUST reduce their rate. A detailed description of this type of multi-rate congestion control can be found in [MRCC00]. Another possibility to implement congestion control is through a router- assisted scheme where the selection of which ALC groups to forward is performed by routers. Having routers select which groups to forward allows finer grain congestion control and a faster reaction to network congestion. A limitation of this approach is that it potentially requires changes to the hardware router infrastructure. See [CAI99, LUB99] for a preliminary design description. We do not discuss this approach further in this document. One of the attractions of ALC is that it is multicast routing independent and that it does not require multicast reverse connectivity, i.e. ALC receivers do not send multicast traffic. In particular, ALC works with the original multicast model introduced in [DEE88], which we call Internet Standard Multicast (ISM) in this document, and with the Source Specific Multicast (SSM) model that is based on [HOL99]. The definition of an ALC group used throughout this document is slightly different with ISM and with SSM. When using ISM, packets of an ALC group are sent to a multicast group address G. When using SSM, packets of an ALC group are sent to a channel address (S,G), where S is the IP address of the sender and G is a multicast group address. SSM is more attractive to ALC than ISM for a few reasons. First, ALC may use more than one ALC group in a session, and ALC may be used to deliver a large number of objects in different sessions over time that use different sets of ALC groups for the transmission. With ISM, the multicast group address G that corresponds to an ALC group must be allocated so that it is unique across the Internet. With SSM, the multicast group address G can be allocated locally by the sender with Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 4] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 the only requirement that it is unique to the sender, because it is the (S,G) channel that corresponds to the ALC group that a receiver joins. Second, ALC supports an unlimited number of dynamically changing receivers. Changes in the multicast tree topology with SSM are light weight operations (a new branch from the receiver towards S grows when a receiver joins, and the branch is deleted when the receiver leaves), and with ISM changes can be heavier weight (involving transitions from a (*,G)-tree rooted at an RP to the tree rooted at S). Third, ALC is scalable to an unlimited number of receivers that may span the global Internet. Thus, the light weight mechanisms that SSM uses to cross ISP boundaries (standard BGP+ routing tables) is distinct advantage over the heavier weight mechanisms used by ISM (the MSDP and BGMP protocols, both of which are not needed by SSM). Finally, a receiver joins an ALC group by joining a channel (S,G) with SSM, and thus the receiver will only receive packets sent from the sender S. With ISM, the receiver joins an ALC group by joining a multicast group G, and all packets sent to G, regardless of their origin sender, will be received by the receiver. Thus, SSM has compelling security advantages over ISM for prevention of denial of service attacks. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [R2119]. 2. Related Documents This specification is based on the "Forward Error Correction" building block specified in [FEC00] and on the "Multi-Rate Congestion Control" building block ([MRCC00], yet to be specified). ALC can use any FEC coder that complies to the specifications in [FEC00] and that is either specified in [FEC00] or in one of its companion documents. ALC refers to specifications and general description provided in [FEC00]. ALC uses FEC without feedback from receivers, in the 'proactive' form described in [FEC00]. The present document complements [FEC00] by providing an actual instantiation header-fields that are described in abstract terms in [FEC00]. ALC does not specify congestion control directly, but relies in the specification given in [MRCC00]. This specification of ALC reserves opaque header fields that can be used by [MRCC00] to transport information related to congestion control. Implementors of ALC MUST also implement [MRCC00] or an equivalent that provide congestion control in accordance to RFC2357 ([MRBP98]). Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 5] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 3. Applicability ALC is intended for reliable delivery of objects. ALC is most applicable for delivery of objects of substantial length, i.e., objects that range in length from hundreds of kilobytes to many gigabytes. ALC is directly applicable to all multicast enabled networks, including asymmetric networks, wireless networks, and satellite networks. Thus, the inherent raw scalability of ALC is unlimited. However, when other specific applications are built on top of ALC, then these applications by their very nature may limit scalability. For example, if an application requires receivers to request out of band information in order to join a session, or an application allows receivers to send requests back to the sender in order to extend an ongoing session, then the scalability of the application is limited by the ability to send, receive, and process this additional data. The particular FEC coder and congestion control protocols used by ALC to provide a complete protocol have an impact on the applicability of ALC. For example, some FEC coders are inherently limited in the size of the object they can encode, and for objects larger than this size the reception overhead on the receivers can grow substantially. As another example, some networks are not amenable to some congestion control protocols that could be used with ALC. In particular, for a satellite or wireless network, there may be no mechanism for receivers to effectively reduce their reception rate since there may be a fixed transmission rate allocated to the session. 4. General Architecture An object transmission session comprises all packets sent to ALC groups from a single sender that pertain to the transmission of a particular object that could potentially be received by a receiver to recover the object. For example, packets pertaining to a particular object could be transmitted from a sender to four ALC groups at different rates. A receiver may join and receive packets from subsets of these four groups concurrently until it has enough packets in total to recover the object. ALC allows for the more general possibility that several senders are each concurrently transmitting packets to a session for the same object. In this case, a receiver may concurrently join several of these sessions in order to receive the object. Since the senders for these sessions may be located in varying parts of the network, the receiver must perform congestion control on each session independently, although the receiver can take advantage of the aggregate set of packets that arrive Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 6] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 through all sessions to reconstruct an object. For example, there could be four senders, each using three ALC groups for a session pertaining to the same object. A receiver could join all four sessions and collect enough packets to reconstruct the object, but the receiver must perform congestion control independently for each of the four sessions. This document does not specify this mode of operation, assuming that it can be implemented by multiple concurrent ALC sessions. Note however that additional coordination among senders is recommended in order to achieve good reception overhead (see [FEC00]). The receivers need to obtain an object transmission session description before starting the download of an object. The session description must include the relevant session parameters needed by a receiver to enact a download of an object from the senders participating in the session. The object transmission session description is determined and agreed upon by the senders and communicated to the receivers out of band, or, in some cases, included or partially included in the header of each packet. The session description could include the object name, the object length, the packet format and length, the FEC codec type, the sender IP address, the multicast address(es) of the multicast groups, their port number(s), and transmission rates. The session description could be in a form such as SDP [HAN98]. We assume that there exists an out of band mechanism for receivers to obtain the session description. The session description might be carried in a session announcement protocol such as SAP [HAN96], located on a Web page with scheduling information, or conveyed via E-mail or other out of band methods. Discussion of session description format, and distribution of session descriptions is beyond the scope of this document. An FEC encoder is used to generate encoding symbols that are placed in the payload of ALC packets. A description of FEC codecs can be found in [FEC00], and the current document relies upon and uses the terminology introduced in it. The FEC coding information is information that needs to be passed to a receiver in order to decode objects. FEC coding information includes the FEC codec type, the source block length, the symbol length, the object length, the encoding block number, the encoding symbol ID, and an encoding flag indicating whether the encoding symbol is a source symbol or a redundant symbol for block codes. The FEC protocol ID specifies the FEC codec type and the way it is to be used for the transmission (see delivery service models below). The object length, source block length and the symbol length are part of FEC object transmission information. The encoding block number (if used) and the encoding symbol ID that identify the encoding symbol in the payload of an ALC packet constitute the FEC payload ID. Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 7] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 Congestion control information must be included in the ALC packet header. The content of this information depends on the type of congestion control used, and [MRCC00] or an equivalent must be used. The type of congestion control to use is also encoded in the ALC header. Some specific congestion control algorithm(s) are defined in [MRCC00]. All ALC packets pertaining to a particular object transmission session MUST have the same format. An ALC packet consists of an ALC header and a payload. Together with other information, the ALC header MUST contain congestion control information, an FEC protocol ID, and an FEC payload ID. Receivers use congestion control information to coordinate the rate at which they receive packets and to measure congestion as indicated by packet loss in order to determine this rate. Other OPTIONAL information that an ALC header may contain is an object transmission label, FEC session information, FEC object transmission information, and authentication information. The object transmission label can be used by receivers to verify that received packets are associated with a particular object transmission session. Therefore, object transmission labels for sessions pertaining to different objects should be different. As an example, the object transmission label may be the MD5 hash of the object name, object length and FEC object transmission information described below. As another example, the object transmission label may be the MD5 hash of the object itself. The ALC packet format described in this document is intended to be used in conjunction to the UDP transport protocol [POST80]. Future version of this document or companion documents MAY specify a different encapsulation for ALC. 5. Minimizing reception overhead The primary purpose of using FEC codes is to ensure that minimal number of packets need be received in order for a receiver to reconstruct an object. Reception overhead is used to measure this. Reception overhead is the aggregate length of packets needed to recover the object beyond the object length, measured as a percentage of the object length. For example, if it takes 15 MB of packets in order to recover a 10 MB object, then the reception overhead is (15-10)/10 times 100, or 50%. The minimal reception overhead possible is 0%. Under ideal conditions, reception overhead is 0% using even the simplest of FEC codes. For example, a simple carousel achieves 0% reception overhead when transmission is over a network with no packet loss using a Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 8] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 single ALC group with receivers that join and stay attached to the group until they have enough encoding symbols to recover the object. However, under more realistic conditions when transmission uses multiple ALC groups, when there is packet loss, and when receivers join and leave groups during the download process, more sophisticated FEC codes are clearly useful to minimize reception overhead. There are three primary contributors to reception overhead, and these guide the design of how to use FEC codes for ALC. These contributors are: (1) redundant encoding symbol reception due to division of the object into blocks; (2) duplicate encoding symbol reception due t