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 to fixed length FEC codes; (3) inherent reception overhead of the FEC code. ALC based on small block codes is prone to (1) and (2), ALC based on large block codes is most prone to (2) and (3), and ALC based on large expandable codes is most prone to (3). 5.1. Division into blocks One concern is the order of encoding symbol transmission from different blocks when the object is partitioned into blocks. Suppose the object is partitioned into m blocks of k source symbols each, and any k encoding symbols from a block is sufficient to recover the k source symbols from that block. Ideally, reception of any km encoding symbols is sufficient to recover the entire object. Actually, reception of k encoding symbols for each of the m blocks is necessary to recover the entire object. Thus, it is important to schedule the transmission of symbols so that in the face of most patterns of packet loss receivers can recover the object from reception of as close to km encoding symbols as possible. A RECOMMENDED ordering is to interleave encoding symbols from different blocks. This interleaving can be described in terms of rounds, where in a round m encoding symbols are transmitted, one from each block. A particular sending order in each round is not specified by ALC. However, it is RECOMMENDED that some randomization be performed to eliminate correlation with periodic losses. For example, sending could be performed as follows: In round i, randomly choose a permutation p(i) of the m blocks, and then send the i-th encoding symbol from each of the m blocks in the order determined by p(i). In the following example, the object is split into 3 blocks of 4 source symbols each: Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 9] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ + s00 + s01 + s02 + s03 + s10 + s11 + s12 + s13 + s20 + s21 + s22 + s23 + +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ Source block 0 | Source block 1 | Source block 2 Then the first 4 permutations chosen are p(0) = (1,0,2), p(1) = (0,2,1), p(2) = (2,0,1), p(3) = (0,1,2), and the send order for the first 4 rounds is: +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ + e10 + e00 + e20 + e01 + e21 + e11 + e22 + e02 + e12 + e03 + e13 + e23 + +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ Encoding symbol send order Object division into blocks, and thus application of this scheme, is applicable to all the codes, as the value of k is ultimately limited for all the codes. For example, small block codes use small values of k because of computational limits, and large block codes and large expandable codes use much larger yet still limited values of k because of memory and packet length limitations. This interleaving scheme minimizes the induced reception overhead due to division into blocks for any predefined loss pattern for a given value of k. However, it is likely that the induced reception overhead will be larger and more variable when k is small and when losses are moderate or more. For example, when k = 20 and m = 50, the induced reception overhead with respect to a 10% random packet loss is on average 18%, and will reach over 40% for some receiver among 1,000 receivers. See [BYE98] for a more detailed analysis of this. Thus, the reception overhead will tend to be smaller and less variable when using either large block codes or large expandable codes than when using small block codes. For small block codes and large block codes the limit on the number of encoding symbols n for the codes will limit the number of distinct rounds to n. For large expandable codes, since there is no limit to the number of encoding symbols there can be an unlimited number of rounds. A simple way to choose the permutation in each round is the following, and this is RECOMMENDED when protecting against arbitrary packet loss patterns. At each round, the permutation p(i) is determined by selecting a first block randomly, and the rest of the ordering is the consecutive blocks following this first block, modulo the number of Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 10] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 blocks. For example, if there are m blocks, and block j is selected as the first, the permutation p(i) consists of block j through block m-1, followed by block 0 through block j-1. For more detailed discussion, see [VIC98B,GEM99]. 5.2. Block FEC codes For some FEC codes for a given object consisting of s source symbols there is a limited supply t of encoding symbols that are produced. If the number of encoding symbols to be sent exceeds t then some encoding symbols need to be sent more than once. Thus, it is important to schedule the order of sending encoding symbols in such a way as to avoid as much as possible reception of the same encoding symbol more than once by the same receiver. This applies to ALC based on block codes as these codes produce a limited number of encoding symbols. However, this does not apply to ALC based on large expandable codes, as these codes can produce an essentially unlimited supply of encoding symbols. 5.2.1. A single group In some simple scenarios, receivers will join a single ongoing ALC group, collect enough encoding symbols to decode the object, and then leave the object transmission session. In this situation, in order to avoid as much as possible duplicate reception of packets by such receivers, it is important to send the encoding symbols the second and subsequent times in the same order that they were sent the first time. Thus, for example, a receiver that joins the session towards the end of the transmission of the encoding symbols for the first time can continue receiving packets from the transmission of the encoding symbols for the second time and be sure to receive distinct encoding symbols. However, it is inevitable that the reception overhead due to reception of duplicate encoding symbols can be large for receivers that join and leave the transmission over intervals of time that span the transmission of more than the total supply of encoding symbols. For example, a receiver may join the session at the beginning of the first transmission of encoding symbols and receive e0, e1, ... , e98, e99, leave the session and then rejoin the session again at the beginning of the second transmission of encoding symbols and receive again e0, e1, ... , e98, e99, thus receiving 100 duplicate encoding symbols that provide no benefit to recovering the object. Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 11] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ + e0 + e1 + ... + e98 + e99 + ... + e0 + e1 + ... + e98 + e99 + +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ first transmission | second transmission 5.2.2. Multiple groups In more general scenarios, in order to recover an object, receivers will join multiple ongoing ALC groups dynamically. These groups may emanate from more than one server and may be running at different rates. Furthermore, receivers may join a given group and rejoin the same group an arbitrary amount of time later (for example, the next day) to complete the recovery. Finally, for congestion control purposes, receivers dynamically change the set of ALC groups they are receiving from based on dynamically changing loss conditions. How to schedule the encoding symbols from a block code among the various ALC groups in order to minimize reception overhead under all of these different conditions is a challenge. Let r = t/s be the ratio of the number of encoding symbols to the number of source symbols. The larger the value of r the easier it is to avoid receiver reception of duplicate encoding symbols, and in particular as r goes to infinity then reception overhead due to this problem can go to zero. There are ordering schemes that keep reception overhead minimal for small value of r under certain restrictions. For example, in the previous subsection a scheme is described that minimizes reception overhead under the restriction that there is only one group and the receiver is able to complete recovery within a time period that encompasses the transmission of t encoding symbols. However, under general conditions the best and simplest scheme for minimizing reception overhead for objects that aren't blocked is the following. For each group, organize the sending of encoding symbols into rounds. In each round, choose independently a random permutation of all t encoding symbols and send the encoding symbols in this order. Using this ordering, it is not hard to show that no matter in which order and at what time a receiver may join and leave groups the induced reception overhead due to reception of duplicate encoding symbols of a receiver is at most on average r*ln(r/r-1)-1. Furthermore, there are examples of receiver behavior that achieves these maximum averages. As examples, when r is two then the induced reception overhead is at most 38.6%, when r is five then the reception overhead is at most 11.5%, and when r is ten then the reception overhead is at most 5.4%. Thus, to achieve a Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 12] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 reasonable overhead the total length of the encoding must be substantially longer than the length of the object. 5.3. Inherent overhead A (n, k) linear block code has no inherent reception overhead, as any k encoding symbols are sufficient to recover all k source symbols. On the other hand, both the large block codes and large expandable codes described in [FEC00] do have a small amount of inherent reception overhead. 6. Delivery service models ALC can support several different delivery service models. Some examples are briefly enumerated here. On demand delivery model. Receivers may join the ongoing object transmission session at their discretion, obtain the necessary encoding symbols to reproduce the object, and then leave the session. For an on demand service model senders typically transmit for some given time period selected to be long enough to allow all the intended receivers to join the session and recover the object. The time period would typically be much larger than the download time for the object to make it convenient for receivers to enact the download at their discretion. For example a popular software update might be sent using ALC for several days, even though a receiver may be able to complete the download in one hour total of connection time, perhaps spread over several intervals of time. Push service model. This is a variant of the on demand delivery model, with the difference that the transmission is intended for a set of loosely synchronized receivers. Receivers join the session at approximatively the same time the sender start the transmission (one way to to this is to have the sender send the required out of band information about the session to the designated list of receivers, and this triggers the receivers to join the session to start the download). Then receivers provide feedback about the status of reception in order to allow the sender to keep the session alive until the last receiver has finished. This specification describes an OPTIONAL lightweight scalable mechanism for receivers to provide in-band feedback in ALC. Other out of band mechanisms can be used, including those that rely on explicit knowledge of the session participants and demand that all of them send explicit notification of the successful reception. Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 13] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 Streaming service model. Typically, receivers join and remain joined to a particular set of ALC groups to receive multiple related objects in consecutive object transmission sessions. For a streaming service model senders typically transmit a fixed number of encoding symbols for each object. This number may depend on network conditions that are obtained using out of band methods. For example, if network conditions are such that at most 33% of the packets are lost over any 15 MB of transmitted packets, then 15 MB of encoding symbols may be transmitted for a 10 MB object to ensure that receivers are able to reassemble the object under the worst loss conditions. A typical application is a streaming real- time MPEG video, where each object consists of a segment of the stream. For each object, the receiver obtains enough ALC packets to recover the object and then discards all subsequent packets associated with the object until packets start arriving for the next object. There are many other delivery service models that ALC can be used for that are not covered above. The description of the many potential applications and the appropriate delivery service model is beyond the scope of this document. With many of these delivery service models substantial additional mechanisms beyond what is described in this document will be needed to support the delivery service model, i.e. the out of band mechanism for delivering object transmission session information to the receivers. This document only attempts to describe the minimal common scalable elements to these diverse applications using ALC as the delivery mechanism. 7. Congestion Control A congestion control algorithm for ALC is specified in a companion document [MRCC00]. 8. Packet Content ALC defines two types of packets: a Data Packet and Request Packet. In this specification of ALC both these packets are transmitted as UDP payload [POST80]. Future versions of this specification or companion documents may remove this limitation. Data packets are sent by the sender(s) to a multicast IP destination address. Request packets are sent by receivers to the unicast IP destination address of the sender (one of them, if there is more than one) or to the unicast address of a session-control node. ALC does not strictly require the presence of Request packets, the only purpose of these is to implement the OPTIONAL "transmission extension" mechanism. Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 14] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 When present, the ALC payload immediately follows the ALC header. In the ALC header, all integer fields are carried in "big-endian" or "network order", that is, most significant byte (octet) first. Bits designated as "padding" or "reserved" MUST by set to 0 by senders and ignored by receivers. Unless otherwise noted, numeric constants are in decimal (base 10). 8.1. Data-Packet content The ALC data-packet header contains the following types of information provided by the sender(s): o Congestion Control Information (mandatory) Used by receivers (or intermediate nodes) to implement congestion control algorithms. o FEC Information This is the instantiation of the abstract fields defined in [FEC00]. This class is further decomposable as follows: o FEC Encoding Identifier (mandatory) Identifies the type of FEC coding scheme being used. o FEC Object Transmission Information (optional) Identifies the parameters associated with the encoding of an object through the FEC coding scheme in use. o FEC Payload Identifier (mandatory) Identifies the content of the data packet for the purpose of decoding. o FEC Encoding Flag (mandatory) Identifies packets containing only source symbols o Object Transmission Label (optional) Used by receivers to de-multiplex different objects being transmitted in a single session and possibly to associate them to Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 15] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 their description provided out of band. o Source Authentication Information (optional) Used by receivers to authenticate the content of the packet. o Object Transmission Status (optional) Used by receivers to implement the OPTIONAL "transmission extension" mechanism. The actual packet format is depicted in Figure 1 below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Congestion Control Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V | HDR_LEN |FEC Encoding ID| CCID|E| resvd |F|TLL|TIL|R|A|X| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | FEC Payload ID (1-:-2 32-bit words) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Object Transmission Label (0,1,2 or 4 32-bit words) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Object Transmission Information (0-:-3 32-bit words) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|r| Residual Object Transmission Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Authentication Information (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 - ALC Data-packet header layout The ALC data-packet header is made of a fixed part, 64 bits long, followed by a variable part. The fixed part contains congestion control information, general protocol settings and information describing the variable part of the header. The variable part is composed by one or more variable-length fields. The presence of each of those field is determined by the description provided in the fixed part of the header. The length of each field is either constant or determined in the fixed part of the header or defined in the field itself. Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 16] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 Optionally an ALC data-packet header can contain additional header-extension fields intended both for protocol extensions and as a mechanism to extend the length of some of the fields already present in the header. Header extensions fields are described in a separate section. The explanation each field in the packet header is the following. Congestion Control Information (CCI): 32 bits Used for Congestion Control purposes. This field is opaque for the purpose of this specification. [MRCC00] defines its format and usage according to the value of the CCID field. ALC version number (V): 3 bits The ALC version number for this specification is 0. Non-fixed ALC header Length (HDR_LEN): 5 bits Length of the non-fixed portion of the ALC header in units of 32-bit words, starting form the 3rd 32-bits word in the ALC header up to the ALC payload (including header extensions, see below). I.e. this is the total header length excluding the first two 32-bit words. This field can be used for direct access to the beginning of the ALC payload. FEC encoding ID (FEC_ENC_ID): 8 bits Specifies the type of FEC encoding being used and, implicitly, the specification of the decoder [FEC00]. FEC_ENC_ID also determines the internal format of the FTI and FPI fields described below. This field is the instantiation of the "FEC encoding ID" abstract field defined in [FEC00]. Congestion Control ID (CCID): 3 bits Specifies the congestion control algorithm being used and, implicitly, the meaning of the CCI field. This field is the instantiation of the "Congestion Control ID" field defined in [MRCC00]. FEC Encoding flag (E): 1 bit Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 17] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 E = 1 indicates that the packet payload contains only source symbols. E = 0 indicates redundant symbols in the payload. The meaning of this field is not defined for some values of FEC_ENC_ID, when this happens E MUST be set to 0 by the sender. This field is the instantiation of the "encoding flag" abstract field defined in [FEC00]. reserved: 4 bits FEC payload-ID length (F): 1 bit Length of FEC payload ID field (FPI). F = 0 indicates the FPI field is 32-bits long. F = 1 indicates the FPI field is 64-bits in length. Object Transmission Label length (TLL): 2 bits Length of object transmission label field (OTL). An TLL value of 0 means "OTL field not present"; TLL values of 1, 2 and 3 mean 32, 64, 128 bits OTL-field length respectively. FEC-object Transmission-Information length (TIL): 2 bit Length of FEC object transmission information field (FTI) in units of 32-bit words. TIL = y indicates the FTI field is y words in length. TIL = 0 means that the FTI field is not present. Residual Object Transmission Time flag (R): 1 bit R = 1 indicates that the field Residual Object Transmission Time (ROT) is present. R = 0 indicates "no ROT field". Source Authentication flag (A): 1 bit A = 1 indicates that the Source Authentication header field (SAI) is present. A = 0 indicates "no SAI field". Header-extension fields flag (X): 1 bit X = 1 indicates that additional fields, beside the ones specified in this section, are present in the ALC header. X = 0 indicates no additional header fields is present. See the "Header Extension" section for the definition of additional header field. Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 18] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 FEC Payload ID (FPI): 1 -:- 2 x 32 bits The FEC Payload ID field identifies the content of the ALC payload for the purpose of decoding. For example this may be the the ID of the FEC symbol carried in the packet and its encoding block number, if the object is partitioned into blocks. The exact format and interpretation of the FPI field is dependent on the value of FEC_ENC_ID as specified in [FEC00]. The FPI field is the instantiation of the "FEC Payload ID" abstract field defined in [FEC00]. The length of the FEC payload ID field is determined by the F field. Object Transmission Label (OTL): 0,1,2 or 4 x 32 bits Its content is opaque to receivers and is used by them to de- multiplex different objects being transmitted within a single session and possibly to associate the objects to their description provided out of band. In the scope of a session, each label MUST be uniquely associated to a single object, the opposite in NOT REQUIRED. The length of the Object transmission label field is determined by the TLL field. FEC object transmission information (FTI): 0 -:- 3 x 32 bits This field defines the parameters of the FEC coding scheme and of its application to the object being encoded. For example this could include the length of the object and the source block length, in the case of block-codes. The format of this field is dependent on the value of FEC_ENC_ID, as specified in [FEC00]. The FTI field is the instantiation of the "FEC Transmission Information" abstract field specified in [FEC00]. The length of the FTI field is determined by the TIL field. When the FTI field is not present in the ALC header, this information MUST be communicated out of band. Continuation Request flag (C): 1 bit reserved: 1 bit Residual Object Transmission Time (ROT): 30 bits These three fields encode the "Object Transmission Status" information, used to implement the OPTIONAL in-band 'transmission- extension' mechanism. Their presence is controlled by the field R: R = 1 means that they are present. The field ROT Represents the time left until the end of the transmission of the Object, expressed in ms (milliseconds). The field C indicates whether Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 19] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 receivers are allowed to send continuation request using the Request Packet: C = 1 means that they are allowed. Source authentication information (SAI): variable length. This field is used to authenticate the content of the packet, it is a self-descriptive, variable-length field. Its format is defined below. The SAI field is only present if A = 1. Although the ALC packet headers may have different formats, All ALC packets pertaining to the same session MUST have the same header format, i.e. all optional field MUST be either present or not-present in all packets and all variable-length header MUST keep a constant length. Also the FEC encoding type MUST NOT vary within the session, which implies that FEC_ENC_ID MUST NOT vary either. The encoding parameters carried in the FTI field MUST be the same within the same object, but MAY vary across different sessions for different objects, even if the sessions occur sequentially in time using the same set of ALC groups for each session. 8.1.1. Source Authentication Information Field The format of the SAI field is depicted below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SAL | SAT | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . Actual Source Authentication Information (variable length) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The explanation of each sub-field is the following. Source Authentication Information length (SAL): 8 bits The length of the whole SAI filed included the SAL sub-field, expressed in multiples of 32-bit words. Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 20] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 Source Authentication Information type (SAT): 8 bits The type of the authentication algorithm being used. This field also determines the structure of the ASA sub-field. Actual Source Authentication Information (ASA): variable length Used by receivers to authenticate the content of the packet. Its internal structure is implicitly defined by the value of the SAT sub-field. Values of the SAT sub-field, their association to an authentication scheme and the format of the ASA sub-field are specified in a separate document. 8.2. Request-Packet content 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V | HDR_LEN | reserved |TLL|resvd|A|X| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Object Transmission Label (0,1,2 or 4 32-bit words) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |res| Requested Object Transmission Extension | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Authentication Information (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ALC Request header layout ALC version number (V): 3 bits The ALC version number for this specification is 0. Non-fixed ALC header Length (HDR_LEN): 5 bits Length of the non-fixed portion of the ALC header in units of 32-bit words, starting form the 3rd 32-bits word in the ALC header up to the end of the request packet. I.e. this is the total length length of the request packet excluding the first two 32-bit Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 21] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 words (request packets do not contain payload). reserved: 17 bits Object Transmission Label length (TLL): 2 bits Length of object transmission label field (OTL). An TLL value of 0 means "OTL field not present"; TLL values of 1, 2 and 3 mean 32, 64, 128 bits OTL-field length respectively. reserved: 3 bits Receiver Authentication flag (A): 1 bit A = 1 indicates that the Receiver Authentication header field (RAI) is present. A = 0 indicates "no RAI field". Additional header-fields flag (X): 1 bit X = 1 indicates that additional fields, beside the ones specified in this section, are present in the ALC header. X = 0 indicates no additional header fields is present. See the "Header Extension" section for the definition of additional header field. Object Transmission Label (OTL): 0,1,2 or 4 x 32 bits This is the Object Transmission Label of the object for which the extension is requested. This field is the copy of the analogous field present in data packets. The OTL field is omitted from Request packets when the analogous field is not present in Data packets. reserved: 2 bit Requested Object Transmission Extension (ROE): 30 bits Represents the requested time until the end of the transmission of the Object, expressed in ms (milliseconds). This value is computed as the Residual Object transmission Time (ROE) plus the extension needed by the receiver. Receiver authentication information (RAI): variable length. This is an optional field used to authenticate the receiver that sends the request. Its structure is identical to the SAI field Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 22] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 structure. Actual authentication mechanisms may be defined in a companion document, similarly to what specified for the SAI field. The RAI field is only present if A = 1. The Request-packet header can be extended using the same mechanism used for data packet headers (see section "Header-Extension Fields"). 8.3. Header-Extension Fields To allow for unanticipated or rarely used additional header fields and to extend the size of some of the predefined fields, the ALC header contains an additional header fields flag "X". If "X" is set to 0 then no additional header fields are included within the ALC header beyond the predefined fields. When additional headers beyond the predefined fields are used, the value of "X" within the ALC header MUST be set to 1. Header-extension fields have the standard format depicted below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| HEL | HET | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . Header Extension Content . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 - format of additional headers The explanation of each sub-field is the following. Last Header Extension (L): 1 bit MUST be set to 1 in the last Header Extension field present in a packet header, MUST be set to 0 in all the others. Header Extension length (HEL): 7 bits Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 23] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 The length of the whole Header Extension field expressed in multiples of 32-bit words. Header Extension type (HET): 8 bits The type of the header extension. This document defines a number of possible types. Additional types may be defined in future version of this specification. Header Extension Content (HEC): variable length The content of the Header Extension. The format of this sub-field depends on the header extension type. The originator of a packet with header extensions SHOULD not leave additional space between the end of the last Header Extension and the beginning of the ALC payload. The recipient of a packet MUST ignore any data present between the end of the last header extension field and the beginning of the ALC payload. The following header extension types are defined: 0 Reserved EXT_CCI = 1 Congestion Control Information extension. This extension field extends the CCI field present in the fixed part of the header. It is used when the congestion control information does not fit in the 32 bits CCI field. EXT_FPI = 2 FEC Payload ID extension. This extension field extends the FPI field of the fixed header. It is used when the FEC payload ID information does not fit in 64 bits (maximum length of FPI). EXT_OTL = 3 Object Transmission Label extension. This extension field extends the OTL field of the fixed header. It is used when the object transmission label does not fit in 128 bits (maximum length of OTL). EXT_FTI = 4 FEC object transmission information extension. This extension field extends the FTI field of the fixed header. It is used when the FEC object transmission information does not fit in 96 bits (maximum length of FTI). Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 24] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 9. Procedures 9.1. Sender Operation Within a ALC session, An ALC sender transmits a sequence of packets containing encoding symbols (either source symbols and/or redundant symbols) addressed to one or more multicast groups which together constitute a session. Transmission rates may be different in different groups. This document does not specify the policy used to place symbols into packets, nor the order in which packets are transmitted, nor the scheduling of packets in multiple groups. Although these issues affect the efficiency of the protocol, they do not affect is the correctness nor the inter-operability between senders and receivers. To address these issues, ALC implementors SHOULD follows the guidelines provided in the introductory sections of this document. If multiple senders are transmitting data about the same object in different sessions, congestion control must be performed independently on each session, although a receiver may benefit by increasing its rate and reliability of reception by participating in more than one session for the same object concurrently. Multiple ALC sessions may transport multiple objects using the same set of multicast groups, either transmitted at different times or intermixed. Typically, the sender(s) continue to send encoding symbols in a session until the transmission is complete. The transmission may be considered complete when some time has expired, a certain number of encoding symbols have been sent, or some out of band signal (from a higher level protocol, perhaps) has indicated completion by a sufficient number of receivers. Feedback through ALC Request packets MAY also be used to determine the end of the session. All encoding symbols in an ALC session MUST be the same size. The sender(s) may determine the symbol size arbitrarily, but must coordinate or use a default symbol size to ensure that all encoding symbols are of equal length. Larger encoding symbols sizes are generally desirable for FEC decoding efficiency reason. ALC does not require that each data packet contains a single symbol, however we believe that this is by far the most common case, hence in the following we will assume it. An additional reason to use large symbol sizes, and hence large packet sizes is to reduce the overhead apported by the combination of IP + UDP + ALC headers. On the other hand, if the packet size is larger than the network's maximum transmission unit (MTU), packets would be fragmented, introducing inefficiency in case of network packet loss. It should also Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 25] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 be considered that the decoding of large object may require the use of secondary storage, for which symbol sizes of 512 bytes or multiples of it are appropriate. For all the above reasons we RECOMMEND to use an ALC payload size of either 512 or 1024 bytes. An ALC sender MUST take part to the implementation of a congestion control strategy in accordance to RFC2357 [MRBP98]. [MRCC00] specifies the details of this. Together with the encoding symbols, an ALC sender MUST provide additional information regarding the symbols being transmitted, the objects provided and the session. The sender MAY also provide additional optional information. Part of this information must be provided within ALC, using the above specified packet headers, part must be provided out of band and part may be provided either out of band or in the ALC headers. An ALC sender MUST provide: Congestion Control Information, consisting on: Identification of the congestion control algorithm being used. This must be provided before or with the start of the session. The sender MUST use the ALC header field CCID for this purpose. It may additionally use out of band mechanisms. Parameter of the Congestion control algorithm (e.g. rates of different layers). This MUST be provided either in the ALC header (part of the CCI field) or out of band, as defined in [MRCC00] for the particular congestion control algorithm being used. Per-packet congestion control information (e.g. sequence numbers to detect packet loss). The CCI field of the data-packet header MUST be used for this purpose. [MRCC00] defines the content and encoding of this information. FEC information FEC encoding Identifier Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 26] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 This must be provided in the FEC_ENC_ID data-header field. FEC Object Transmission Information It MAY be provided in the FTI data-header fields ([FEC00] defines its format). If the FTI field is not present in the data-packet header, the FEC Object Transmission Information MUST be provided out of band for each object prior the start of the object transmission. The content of this is defined by [FEC00] for the FEC_ENC_ID being used. FEC Payload Identifier This MUST be provided for each symbol transmitted, using the FPI data-header field. The format of FPI is defined in [FEC00] for the particular FEC_ENC_ID being used. FEC Encoding flag This is the F flag in the data-packet header. It MUST be set to 1 if the packet contains only source symbols. A sender MUST NOT change the FEC encoder or the congestion control algorithm within a session. An ALC sender MAY also provide: Object Transmission Label Object Transmission Label may be provided either out of band or using the OTL data-header field. If a session is used to transmit multiple objects, than the relative transmission labels MUST be provided in the data-header to enable receivers to demultiplex packets belonging to different objects. Source Authentication Information This has the purpose of authenticating the packet content and is contained in the SAI data-header field. Object Transmission Status This is contained in the ROT data-header field. If the sender(s) provide this information, it can also be required to handle Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 27] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 Request Packets, depending on the value of the C flag. The action that the sender(s) must perform in this case are specified in the "Session Extension" section below. 9.2. Receiver Operation Receivers can operate differently depending on the delivery service model. For example, for an on demand service model receivers may join a session, obtain the necessary encoding symbols to reproduce the object, and then leave the session. As another example, for a push service model a receiver may be tuned in to a continuous session announcement multicast group or channel to determine when objects of interest are scheduled for transmission. Then, at the appropriate time the receiver automatically joins the session to download objects of interest. As another example, for a streaming service model a receiver may be continuously joined to a set of multicast groups to download all objects in sequential session all using the same set of ALC groups. To be able to participate to a session, receivers MUST first obtain the multicast group(s) and UDP port number(s) used for the session. This information is available through some out of band protocol. In certain cases (e.g. when multicast routing protocols inspired to [HOL99] are used) receivers MUST also obtain the IP address of the sender(s). At the moment of joining the session, receivers MUST either o have already identified the congestion control algorithm being used through out of band means; OR o acquire this information through the CCID field of the header first data packet received. In either case receiver MUST implement the congestion control algorithm specified. If a receiver is not able to implement the congestion control algorithm used in the session, it MUST NOT join the session or MUST drop it immediately, if the CCID is learned after having joined the session. When the session is transmitted on multiple multicast groups receivers MUST join it by subscribing to the first group only, unless they have already learned the type of congestion control algorithm through out of band means. Once they know the type of congestion control in use, they are allowed to join other groups in accordance to the congestion control Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 28] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 algorithm itself. This rule has the purpose of preventing receivers from starting at high data rates, if the congestion control algorithm is based on layered transmission on multiple groups. For this to work, the list of groups provided to the receivers MUST be sorted and the first group in the list must be "base layer", if a layered congestion control algorithm is used. To be able to participate to a session, receivers MUST be able to implement the decoder for the FEC encoding in use. If source authentication information is present in data packets, receivers MAY use it to authenticate the packet content. If object transmission status information is present in data packets and the C flag is set, then receivers MAY originate Request packets to extend the transmission of an object. See "Session Extension" section for more details. 9.3. Session Extension ALC defines an OPTIONAL mechanism for the sender(s) to advertise the remaining transmission time of an object in a session. This information MAY be used by receivers to request an extension of the transmission time of the object. A sender MAY use the ROT field in data-packet headers to advertise the remaining transmission time for an object. This time is expressed in milliseconds. A sender MAY additionally set the C flag to 1, indicating that receivers MAY originate requests for transmission extension through the ALC Request packet defined above. If a sender sets the C flag to 1, it MUST be prepared to accept requests for transmission extension and process them. The sender MUST *either* honor the request or immediately indicate that it is not willing to accept further requests for that object, by setting C to 0 in any subsequent data packet transmitted for that object. When a sender decides to honor a request, it MUST immediately reflect this decision back to the receivers by increasing the value of ROT to a value equal or larger than the one present in the request packet. The new value of ROT must be advertised in subsequent data packets transmitted for the object. Failure to do so may result in implosion of receiver-originated requests. Receivers MAY learn the residual transmission time for an object through Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 29] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 the ROT field optionally present in data packets. If the C flag in these data packet is set to 1, then receivers MAY originate request for transmission extension for an object using Request ALC packets. The object(s) for which receivers can generate transmission-extension requests are those whose symbols are transmitted in data packets with C flag set to 1. The association from a data packet to an object is given by the Object Transmission Label (OTL) field in the packet. If this field is not present receivers MAY assume that the session is used to transmit a single object and still originate extension request for that object (provided that the value of the C flag allows it). Receivers MUST NOT originate transmission extension request if the C flag is set to 0 or if this flag is not present in the data-packet header. Similarly to Data packets, ALC Requests are encapsulated in UDP packets and sent to the unicast IP address of the node designated to receive extension request. The UDP destination port to use is the destination port used for multicast data packets, unless otherwise specified through out of band means. By default the destination IP address is the source address used in the Data packets. Out of band mechanism MAY override this default behavior by explicitly designating the node to which extension requests must be sent. Note that when multiple senders are sending to a session and a specific node that accepts requests is not designated, then receivers MAY pick any of the senders as destination of their Request packets. In this case all the senders MUST coordinate in their reaction to requests (e.g. when they increase the residual transmission time or when they decide to set C to 0). A receiver that originates a Request packet for an object whose Transmission Label was advertised in Data packets MUST copy the Object Transmission Label in the OTL field of the Request packet. The Requested Object transmission Extension (ROE) field must be computed as the Residual Object transmission Time (ROE) plus the extension requested by the receiver. Receivers MUST implement feedback-implosion avoidance procedures as follows: o Receivers use the Residual Object transmission Time advertised by the sender(s) to predict whether or not they will be able to recover the object from the packets they have already received and from the packets they can expect to receive in the future. This prediction SHOULD also consider data-rate fluctuations caused by congestion control adaptations. Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 30] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 o When a receiver predicts that the residual object transmission time is not sufficient to successfully recover the object, it MAY schedule the transmission of an extension request at a random time in the future, before the scheduled end of the transmission. o When a receiver has a pending extension request scheduled for transmission, it must keep monitoring the progress of the reception and cancel the pending request if either of the following happens: - The residual object transmission time becomes larger the predicted time needed to complete the reception. - A Data packet for the object of interest is received with the C flag set to 0 or without the C header field. o A receiver MUST cancel pending extension-request when the transmission time of an object is over. The rules stated above are not sufficient to obtain a good implosion prevention in all the cases. For improved performance the following guidelines SHOULD be followed: o Extension requests should be *scheduled* only when the reception of the object is in an advanced status of completion (e.g. more than 50%). This improves the accuracy of the receivers' prediction reducing the chance that an extension is requested uselessly. o The time needed for a Request to suppress pending Request from other receivers is approximatively a packet round trip time (unicast request to the sender and multicast data packets to the receivers). Using random-time scheduling for requests is an effective suppression mechanism only if the the interval from which to select the actual transmission time is much larger than a round trip time. For this reason extension requests should be *scheduled* at least a few seconds before the end of transmission. 10. ALC and Generic Router Assist Router filtering of ALC packets to assist in congestion control is described in [LUB99]. The addresses of the multicast groups or channels can be communicated to the routers and they can do filtering of groups or channels based on congestion. This is one of the reasons why it is good to have the sequence number information in a fixed place in the ALC Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 31] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 packet header, so that the routers can probe this field if necessary (although it may not be necessary). There are some interesting strategies for combining router assisted congestion control with receiver congestion control in such a way that ALC will perform well when only receivers are doing congestion control, and will perform even better with router assist. Describing these strategies is outside the scope of this document. 11. IANA Considerations The identifiers of FEC encoding (FEC Encoding Identifier), congestion control algorithm (Congestion Control Identifier) and source authentication scheme (Source Authentication Information Type) are subject to IANA registering. This issues is better discussed in the building-block specifications (e.g. [FEC00] and [MRCC00]). Building blocks may introduce additional IANA considerations. 12. Intellectual Property Issues Digital Fountain has patents pending for Tornado codes and for LT codes. Digital Fountain has patents pending for congestion control protocols that may be needed to use some of the congestion control protocols described in this document in a commercial product or service. Digital Fountain is willing to provide a royalty free license to the rights it holds that are needed to use the congestion control protocols described in this document if and when these congestion control protocols become part of the IETF standards. 13. Acknowledgments Thanks to Hayder Radha and Vincent Roca for detailed comments on this paper. 14. References [MRCC00] "Congestion Control for multi-rate building block", draft to be written for submission to the IETF. [AFZ95] Acharya, S., Franklin, M., and Zdonik, S., Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 32] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 "Dissemination-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. [R2119] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels (IETF RFC 2119) http://www.rfc-editor.org/rfc/rfc2119.txt [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. [BYE00] Byers, J.W., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M., Roetter, A., "Improved Congestion Control for IP Multicast Using Dynamic Layers", Digital Fountain research paper, June 2000. [CAI99] Cain, B., Speakman, T., and Towsley, D., "Generic Router Assist (GRA) Building Block, Motivation and Architecture", Internet Draft draft-ietf-rmt-gra-arch-00.txt, a work in progress. [DEE88] Deering, S., "Host Extensions for IP Multicasting", RFC 1058, Stanford University, Stanford, CA, 1988. [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 [GEM99] Gemmell, J., Schooler, E., and Gray, J., "FCast 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. [HOL99] Holbrook, H., Cheriton, D., "IP Multicast Channels: Experss Support for Large-scale Single-source Applications", ACM SIGCOMM'99 [HOR00] Horn, G., Luby, M., Mitzenmacher, M., "Fair Layered Increase/Decrease Congestion Control", Digital Fountain research paper, June 2000. Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 33] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 [FEC00] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Crowcroft, J., Luekenhoff, B., "Reliable Multicast Transport Building Blocks: Forward Error Correction", Internet Draft draft-ietf-rmt-bb-fec-00.txt, a work in progress. [LUB99] Luby, M., Vicisano, L., Speakman, T. "Heterogeneous multicast congestion control based on router packet filtering", presented at RMT meeting in Pisa, March 1999. [LUB00] Luby, M., "An Overview of LT codes", Digital Fountain technical paper, July 2000. [MRBP98] Mankin, A., Romanow, A., Brander, S., Paxson, V., "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols," RFC2357, June 1998. [MRCC00] Luby, M., Vicisano, L., Haken, A., "Reliable Multicast Transport Building Block: Multirate Congestion Control", yet to be specified. [POST80] J. Postel, "User Datagram Protocol", RFC768, August 1980. [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. [RIZ97c] Rizzo, L., "On the Feasibility of Software FEC", DEIT Tech Report, http://www.iet.unipi.it/ luigi/softfec.ps, Jan 1997. [RUB99] Rubenstein, D., Kurose, J. and Towsley, D., "The Impact of Multicast Layering on Network Fairness", Proceedings of ACM SIGCOMM '99. [VIC98A] Vicisano, L., Rizzo, L., Crowcroft, J., "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 groups with Different Rates", University College London Computer Science Research Note Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 34] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 RN/98/25, Work in Progress (May 1998). A File Transfer using ALC - 'Fcast' While ALC can be used to transfer arbitrary objects, file transfer is expected to be a primary application. This appendix describes a standard for file transfer, called "Fcast". When the object being transmitted is a file, the receiver usually requires "metadata" in addition to the file itself, such as the file name, its creation date, etc. Metadata can be sent a number of ways. For example, it could be part of the object session description or sent as a separate ALC object with a well-known object transmission label. The method described here combines the file with its metadata in a single ALC object. The metadata is logically appended to the end of the file as a trailer and sent as part of the transmission. The file with appended trailer is referred to as the extended file. In order to find the beginning of the trailer, the last 4 bytes in the object indicate the length of the trailer. Including metadata is OPTIONAL, so the length may be zero. Figure 8 shows the layout of the Fcast file transmission. The metadata is appended rather than prepended to the file so that the file length may be corrected by simply truncating the extended file (rather than requiring re-writing). The nature of ALC does not ensure that the start of the file is received before the end, so there is no drawback to using a trailer in terms of latency to get the information. +----------------------------------------------+ | Object | 4-byte checksum | Null padding| +----------------------------------------------+ / \\ | ........... | \\ | .......... / \\ +--------------------------------------+ | File data | Trailer | Trailer Length | +--------------------------------------+ Figure 8 - Fcast file transmission: The ALC object is the file data, followed by the meta-data trailer, followed by the trailer length (in bytes - 4 byte value) Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 35] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 The metadata in the file trailer is stored as ASCII text. It carries the same information as HTTP object metainformation header fields, as defined in RFC 2068 [R2068]. As in the RFC, field names should be followed by a colon, followed by the field value, followed by a CR-LF. The header fields that are RECOMMENDED/OPTIONAL to be supported by all receiving clients are listed below and should be interpreted as per RFC 2068. RECOMMENDED fields: Content-Location (indicates the URI for the file - could be just the file name) Last-modified OPTIONAL fields: Content-Length (indicates the length of the file) Content-Encoding Content-Type Content-Base Content-Language Content-Style-Type Date Expires Any other header field defined in RFC 2068 or subsequent HTTP standards. Example: Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 36] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 Content-Length : 1024 Content-Location : http://www.foo.com/myfile.zip 15. Authors' Addresses Michael Luby luby@digitalfountain.com Digital Fountain 600 Alabama Street San Francisco, CA, USA, 94110 Jim Gemmell jgemmell@microsoft.com Microsoft Research 301 Howard St., #830 San Francisco, CA, USA, 94105 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 Jon Crowcroft J.Crowcroft@cs.ucl.ac.uk Department of Computer Science University College London Gower Street, London WC1E 6BT, UK Bruce Lueckenhoff brucelu@cadence.com Cadence Design Systems, Inc. 120 Cremona Drive, Suite C Santa Barbara, CA 93117 Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 37] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 16. 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." Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 38] Draft RMT PI, Asynchronous Layered Coding 13 July 2000 Table of Contents 1 Introduction .................................................... 3 2 Related Documents ............................................... 5 3 Applicability ................................................... 6 4 General Architecture ............................................ 6 5 Minimizing reception overhead ................................... 8 5.1 Division into blocks .......................................... 9 5.2 Block FEC codes ............................................... 11 5.2.1 A single group .............................................. 11 5.2.2 Multiple groups ............................................. 12 5.3 Inherent overhead ............................................. 13 6 Delivery service models ......................................... 13 7 Congestion Control .............................................. 14 8 Packet Content .................................................. 14 8.1 Data-Packet content ........................................... 15 8.1.1 Source Authentication Information Field ..................... 20 8.2 Request-Packet content ........................................ 21 8.3 Header-Extension Fields ....................................... 23 9 Procedures ...................................................... 25 9.1 Sender Operation .............................................. 25 9.2 Receiver Operation ............................................ 28 9.3 Session Extension ............................................. 29 10 ALC and Generic Router Assist .................................. 31 11 IANA Considerations ............................................ 32 12 Intellectual Property Issues ................................... 32 13 Acknowledgments ................................................ 32 14 References ..................................................... 32 A File Transfer using ALC - 'Fcast' .............................. 35 15 Authors' Addresses ............................................. 37 16 Full Copyright Statement ....................................... 38 Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 39] --==_Exmh_924555160 Content-Type: text/plain ; name="draft-ietf-rmt-bb-fec-01.txt"; charset=us-ascii Content-Description: draft-ietf-rmt-bb-fec-01.txt Content-Disposition: attachment; filename="draft-ietf-rmt-bb-fec-01.txt" RMT Working Group M.Luby/Digital Fountain Internet Engineering Task Force L.Vicisano/Cisco INTERNET-DRAFT L.Rizzo/U. of Pisa draft-ietf-rmt-bb-fec-01.txt J.Gemmell/Microsoft 13 July 2000 J.Crowcroft/UCL B. Lueckenhoff/Cadence Expires 13 January 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 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 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. Draft RMT BB, Forward Error Correction Codes 13 July 2000 1. Rationale and Overview There are many ways to provide reliability for transmission protocols. 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 success of TCP/IP. ARQ has also been an effective reliability tool for one-to-many reliability protocols, and in particular for some reliable IP multicast protocols. However, for one-to-very many reliability 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 different 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 channel 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 pieces of data, which we hereafter call 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 limitations. 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 reliability protocols such as reliable IP multicast. We first briefly review some of the basic properties and types of FEC codes before reviewing their uses in the context of reliable IP multicast. Later, we provide a more detailed description of some of FEC codes. In the general literature, FEC refers to the ability to overcome both erasures (losses) and bit-level corruption. However, in the case of IP Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 2] Draft RMT BB, Forward Error Correction Codes 13 July 2000 multicast, lower network layers will detect corrupted packets and discard them. Therefore, an IP multicast protocol need not be concerned with corruption; the focus is solely on erasure codes. The 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 input to an FEC encoder is some number k of equal length source symbols. The FEC encoder generates some number of encoding symbols that are of the same length as the source symbols. The chosen length of the symbols can vary upon each application of the FEC encoder, or it can be fixed. These encoding symbols are placed into packets for transmission. The number of encoding symbols placed into each packet can vary on a per packet basis, or a fixed number of symbols (often one) can be placed into each packet. Also, in each packet is placed enough information to identify the particular encoding symbols carried in that packet. Upon receipt of packets containing encoding symbols, the receiver feeds these encoding symbols into the corresponding FEC decoder to recreate an exact copy of the k source symbols. Ideally, the FEC decoder can recreate an exact copy from any k of the encoding symbols. In a later section, we describe a technique for using FEC codes as described above to handle blocks with variable length source symbols. Block FEC codes work as follows. The input to a block FEC encoder is k source symbols and a number n. The encoder generates n-k redundant symbols yielding an encoding block of n encoding symbols in total composed of the k source symbols and the n-k redundant symbols. A block FEC decoder has the property that any k of the n encoding symbols in the encoding block is sufficient to reconstruct the original k source symbols. Expandable FEC codes work as follows. An expandable FEC encoder takes as input k source symbols and generates as many unique encoding symbols as requested on demand, where the amount of time for generating each encoding symbol is the same independent of how many encoding symbols are generated. Unlike block FEC codes, the source symbols are not considered part of the encoding symbols for an expandable FEC code. An expandable FEC decoder has the property that any k of the unique encoding symbols is sufficient to reconstruct the original k source symbols. Along a different dimension, we classify FEC codes loosely as being either small or large. A small FEC code is efficient in terms of processing time requirements for encoding and decoding for small values Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 3] Draft RMT BB, Forward Error Correction Codes 13 July 2000 of k, and a large FEC code is efficient for encoding and decoding for much large values of k. There are implementations of standard block FEC codes that have encoding times proportional to n times the length of the k source symbols, and decoding times proportional l times the length of the k source symbols, where l is the number of missing source symbols among the k received encoding symbols. Because of the growth rate of the encoding and decoding times as a function of k and n, these are typically considered to be small block FEC codes. There are close approximations to block FEC codes which for all practical purposes can generate n encoding symbols and can decode the k source symbols in time proportional to the length of the n encoding symbols. These codes are considered to be large block FEC codes. There are close approximations to expandable FEC codes which for all practical purposes can generate each encoding symbol in time proportional to its length, and can decode all k source symbols in time proportional to their length. These are considered to be large expandable FEC codes. Ideally, FEC codes in the context of IP multicast can be used to generate encoding symbols that are transmitted in 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 specific retransmission of the lost packets or waiting till the packets are resent using Data Carousel, the receiver can use any other subsequent equal amount of data contained in packets that arrive to reassemble the object. These packets can either be proactively transmitted or they can be explicitly requested by receivers. This implies that the data contained in 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 problems mentioned above associated with ARQ and Data Carousel and thereby dramatically increase the scalability of the protocol to orders of magnitude more receivers. 1.1. Application of FEC codecs For some reliable IP multicast protocols, FEC codes are used in conjunction with ARQ to provide reliability. For example, a large object could be partitioned into a number of source blocks consisting of a small number of source symbols each, and in a first round of transmission all of the source symbols for all the source blocks could be transmitted. Then, receivers could report back to the sender the number of source symbols they are missing from each source block. The Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 4] Draft RMT BB, Forward Error Correction Codes 13 July 2000 sender could then compute the maximum number of missing source symbols from each source block among all receivers. Based on this, a small block FEC encoder could be used to generate for each source block a number of redundant symbols equal to the computed maximum number of missing source symbols from the block among all receivers. In a second round of transmission, the server would then send all of these redundant symbols for all blocks. In this example, if there are no losses in the second round of transmission then all receivers will be able to recreate an exact copy of each original block. In this case, even if different receivers are missing different symbols in different blocks, transmitted redundant symbols for a given block are useful to all receivers missing symbols from that block in the second round. For other reliable IP multicast protocols, FEC codes are used in a Data Carousel fashion to provide reliability, which we call an FEC Data Carousel. For example, an FEC Data Carousel using a large block FEC code could work as follows. The large block FEC encoder produces n encoding symbols considering all the k source symbols of an object as one block. The sender cycles through and transmits the n encoding symbols in packets in the same order in each round. An FEC Data Carousel can have much better protection against packet loss than a Data Carousel. For example, 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 the next n encoding symbols, the receiver can completely recover the object. This is true even if the receiver starts receiving packets in the middle of a pass through the encoding symbols. This method can also be used when the object is partitioned into blocks and a short block FEC code is applied to each block separately. In this case, as we explain in more detail below, it is useful to interleave the symbols from the different blocks when they are transmitted. Since any number of encoding symbols can be generated using an expandable FEC encoder, reliable IP multicast protocols that use expandable FEC codes generally rely solely on these codes for reliability. For example, when an expandable FEC code is used in a FEC Data Carousel application, the encoding packets never repeat, and thus any k of the encoding symbols in the potentially unbounded number of encoding symbols are sufficient to recover the original k source symbols. For yet other reliable IP multicast protocols the method to obtain reliability is to generate enough encoding symbols so that each encoding symbol is transmitted at most once. For example, the sender can decide a priori how many encoding symbols it will transmit, use an FEC code to Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 5] Draft RMT BB, Forward Error Correction Codes 13 July 2000 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, the source symbols for each object are encoded into encoding symbols using an FEC code, and then the sets of encoding symbols for each object are transmitted one after the other using IP multicast. 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 symbol. Thus, the packet header also contains an encoding flag that indicates whether the 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 redundant 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. Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 6] Draft RMT BB, Forward Error Correction Codes 13 July 2000 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 some number k of consecutive symbols each, where k may be different for different blocks. If a block consists of k source symbols then a redundant symbol is added to form an encoding block consisting of k+1 encoding symbols. Then, a source block consisting of k source symbols can be recovered from any k of the k+1 encoding 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 a block consisting of k source symbols in an 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 symbols 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 symbols 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 FEC codes Reliable IP multicast protocols may use a block (n, k) FEC code [BLA84]. A popular example of these types of codes is a class of Reed-Solomon codes. For such codes, 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 example, 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. Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 7] Draft RMT BB, Forward Error Correction Codes 13 July 2000 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 (below 256) for such FEC codes as large values make encoding and decoding prohibitively expensive. As many objects are longer than k symbols for reasonable values of k and the symbol length (e.g. larger than 16 kilobyte for k = 16 using 1 kilobyte symbols), they can be divided into a number of source blocks. Each source block consists of some number k of source symbols, where k may vary between different source blocks. The FEC encoder is used to encode a k source symbol source block into a n encoding symbol encoding block, where the length n of the encoding block may vary for each source block. For a receiver to completely recover the object, for each source block consisting of k source symbols, k distinct encoding symbols (i.e., with different symbol IDs) must be received from the corresponding encoding block. For some encoding blocks, more encoding symbols may be received than there are source symbols in the corresponding source block, in which case any additional encoding symbols are discarded. An example encoding structure is shown in Figure 1. Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 8] Draft RMT BB, Forward Error Correction Codes 13 July 2000 | 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 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | FEC encoder | 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 two source blocks consisting of 8 source symbols each, and the FEC encoder is used to generate 2 additional redundant symbols (10 encoding symbols in total) for each of the two source blocks. In many cases, an object is partitioned into equal length source blocks each consisting of k contiguous source symbols of the object, i.e., block c consists of the range of source symbols [ck, (c+1)k-1]. This ensure that the FEC encoder can be optimized to handle a particular number k of source symbols. This also ensures that memory references 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 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 Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 9] Draft RMT BB, Forward Error Correction Codes 13 July 2000 symbol IDs can be numbered consecutively starting from zero for each block independently for the source symbols 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 identifiers 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), (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 FEC codes Tornado codes [LUB97] are block FEC codes that provide an alternative to small block FEC 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 tens of megabytes per second range 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 out of band information to be communicated to all senders and receivers for each different object Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 10] Draft RMT BB, Forward Error Correction Codes 13 July 2000 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 packets. 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. Expandable FEC codes All of the FEC codes described up to this point are block codes. There is a different type of FEC codes that we call expandable FEC codes. Like block codes, an expandable FEC encoder operates on an object of known size that is partitioned into equal length source symbols. Unlike block codes, ideally there is no predetermined number of encoding symbols that can be generated for expandable FEC codes. Instead, an expandable FEC encoder can generate as few or as many unique encoding symbols as required on demand. Also unlike block codes, optimal expandable FEC 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 [LUB00] are an example of large expandable FEC codes. An LT encoder uses randomization to generate each encoding symbol randomly and independently of all other encoding symbols. Like Tornado codes, the number of source symbols k may be very large for LT codes, i.e., on the order of tens to hundreds of thousands, and the encoder and decoder run efficiently in software. For example the encoding and decoding speeds for LT codes are in the range 3-20 megabytes per second for Pentium class machines of various vintages when k is in the high tens of thousands. An LT encoder closely approximates the properties of an ideal expandable FEC encoder, as it can generate as few or as many encoding symbols as required on demand. When a new encoding symbol is to be generated by an LT encoder, it is based on a randomly chosen 32-bit encoding symbol ID that uniquely describes how the encoding symbol is to be generated from the input symbols. In general, each encoding symbol ID value corresponds to a unique encoding symbol, and thus the space of possible encoding symbols is approximately four billion. Thus, the chance that a particular encoding symbol is the same as any other particular encoding symbol is tiny. An LT decoder has the property that with very high probability the receipt of any set of slightly more than k randomly and independently generated encoding Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 11] Draft RMT BB, Forward Error Correction Codes 13 July 2000 symbols is sufficient to reassemble the k source symbols. For example, when k is on the order of tens to hundreds of thousands the reception overhead is less than 5% with no failures in tens of millions of trials under a variety of loss conditions. Because encoding symbols are randomly and independently generated by choosing random encoding symbol IDs, LT codes have the property that encoding symbols for the same k source symbols can be generated and transmitted from multiple senders ad than if all the encoding symbols were generated by a single sender. The only requirement is that the senders choose their encoding symbol IDs randomly and independently of one another. There is a weak tradeoff between the number of source symbols and the reception overhead for LT codes, 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. There are a couple of factors for choosing the appropriate symbol length/ number of input symbols tradeoff. The primary consideration is that there is a fixed overhead per symbol component in the overall processing requirements of the encoding and decoding, independent of the number of input symbols. Thus, using shorter symbols means that this fixed overhead processing per symbol will be a larger component of the overall processing requirements, leading to larger overall processing requirements. Because of this, it is advisable to use a reasonably sized fixed symbol length independent of the length of the object, and thus shorter objects will be partitioned into fewer symbols than larger objects. A second much less important consideration is that there is a component of the processing per symbol that depends logarithmically on the number of input symbols, and thus for this reason there is a slight preference towards less input symbols. 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 megabytes 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 Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 12] Draft RMT BB, Forward Error Correction Codes 13 July 2000 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 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 identify 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 symbol. 2.5. Source blocks with variable length source symbols For all the FEC codes described above, all the source symbols in the same source block are all of the same length. In this section, we describe a general technique to handle the case when it is desirable to use source symbols of varying lengths in a single source block. This technique is applicable to block FEC codes. Let l_1, l_2, ... , l_k be the lengths of k varying length source symbols to be considered part of the same source block. Let lmax be the maximum over i = 1, ... , k of l_i. To prepare the source block for the FEC encoder, pad each source symbol i out to length lmax with a suffix of lmax-i zeroes, and then prepend to the beginning of this the value l_i. Thus, each padded source symbol is of length x+lmax, assuming that the length of an original symbol takes x bytes to store. These padded source symbols, each of length x+lmax, are the input to the encoder, together with the value n. The encoder then generates n-k redundant symbols, each of length x+lmax. The encoding symbols that are placed into packets consist of the original k varying length source symbols and n-k redundant symbols, each of length x+lmax. >From any k of the received encoding symbols, the FEC decoder recreates the k original source symbols as follows. If all k original source symbols are received, then no decoding is necessary. Otherwise, at least one redundant symbol is received, from which the receiver can easily whether the block was composed of variable-length source symbols: if the redundant symbol(s) has a size different (larger) from the source symbols then the source symbols are variable-length. Note that in a variable-length block the redundant symbols are always larger than the largest source symbol, due to the presence of the encoded symbol-length. The receiver can determine the value of lmax by Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 13] Draft RMT BB, Forward Error Correction Codes 13 July 2000 subtracting x from the length of a received redundant symbol. Note that x MUST be a protocol constant. For each of the received original source symbols, the receiver can generate the corresponding padded source symbol as described above. Then, the input to the FEC decoder is the set of received redundant symbols, together with the set of padded source symbols constructed from the received original symbols. The FEC decoder then produces the set of k padded source symbols. Once the k padded source symbols have been recovered, the length l_i of original source symbol i can be recovered from the first x bytes of the ith padded source symbol, and then original source symbol i is obtained by taking the next l_i bytes following the x bytes of the length field. 3. FEC Abstract Packet Fields and Out-of-Band Information This section specify the information that protocol packets must carry to implement the various forms of FEC-based reliability. A session is defined to be all the information associated with a transmission of data about a particular object by a single sender. There are three classes of packets that may contain FEC information within a session: data packets, session-control packets and feedback packets. They generally contain different kinds of FEC information. Note that some protocols do not use feedback packets. Data packets MAY sometime serve as session-control packets as well; both data and session-control packets generally travel downstream (from the sender towards receivers) and are addressed to a multicast IP address (sometime the might be addressed to the unicast address of a specific receiver). In the following, for simplicity we will refer to both data and session control packets as downstream-traveling packets, or simply downstream packets. As a general rule, feedback packets travel upstream (from receivers to the sender) and are addressed to the unicast address of the sender. Sometimes, however, they might be addressed to a multicast IP address or to the unicast address of a receiver or also the the unicast address of some different node (intermediate node that provides recovery services or neighboring router). The FEC-related information that can be present in downstream packets can be classified as follows: 1) FEC Encoding Identifier Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 14] Draft RMT BB, Forward Error Correction Codes 13 July 2000 Identifies the FEC encoding being used and has the purpose of allowing receivers to select the appropriate FEC decoder. As a general rule, the "FEC Encoding Identifier" MUST be the same for a given session, i.e., for all transmission of data related to a particular object, but MAY vary across different transmissions of data about different objects in different sessions, even if transmitted using the same set of multicast groups. 2) FEC payload ID Identifies the symbol(s) in the payload of the packet. The content of this piece of information depends on the encoder being used (e.g. in Block FEC codes this may be the combination of block index and symbol index; in expandable FEC codes this may be just a flat symbol identifier). 3) FEC Object Transmission Information This is information regarding the encoding of a specific object needed by the FEC decoder (e.g. for Block FEC codes this may be the combination of block length and object length). This might also include general parameters of the FEC encoder. All the classes of information above, except 2), can either be transmitted within the transport session (using protocol packet-header fields) or out of band. The information described in 2) MUST be transmitted in data-packet header fields, as it provides a description of the data contained in the packet. In the following we specify the content of 1), 2) and 3) independent of whether these pieces of information are transmitted in protocol packets or out of band. This document does not specify out of band methods to transport the information. Within the context of FEC repair schemes, feedback packets are (optionally) used to request FEC retransmission. The FEC-related information present in feedback packets can be classified as follow: 1) FEC Block Identifier This is the identifier of the FEC block for which retransmission is requested. This information does not apply to some type of decoders. Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 15] Draft RMT BB, Forward Error Correction Codes 13 July 2000 2) Number of Repair Symbols This is the number of repair symbols requested, needed to recover the object. 3.1. FEC Encoding Identifier This is a numeric index that identifies a specific FEC encoding scheme OR a class of encoding schemes that share the same format of "FEC Payload ID" and "FEC Object Transmission Information". The FEC Encoding Identifier identifies a specific FEC encoding scheme when the encoding scheme is formally and fully specified, in a way that independent implementors can implement both encoder and decoder from the specification. Companion documents of this specification may specify such FEC encoding schemes and associate them with "FEC Encoding Identifier" values. These documents MUST also specify a correspondent format for the "FEC Payload ID" and "FEC Object Transmission Information". Currently FEC Encoding Identifiers in the range 0-127 are reserved for this class of encoding schemes. It is possible that a FEC encoding scheme cannot be completely specified or that such a specification is simply not available or also that a party exists that owns the encoding scheme and it is not willing to disclose its algorithm. We refer to these encoding schemes as "Under- Specified" schemes. Under-specified schemes can still be identified as follows: o A format of the fields "FEC Payload ID" and "FEC Object Transmission Information" MUST be defined for the encoding scheme. o A value of "FEC Encoding Identifier" MUST be reserved and associated to the format definitions above. An already reserved "FEC Encoding Identifier" MUST be reused if it is associated to the same format of "FEC Payload ID" and "FEC Object Transmission Information" as the ones needed for the new under-specified FEC encoding scheme. o A value of "FEC Encoding Name" must be reserved (see below). An Under-specified FEC scheme is completely identified by the tuple (FEC Encoding Identifier, FEC Encoding Name). The party that owns this tuple MUST be able to provide an FEC encoder and decoder that implement the Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 16] Draft RMT BB, Forward Error Correction Codes 13 July 2000 under-specified FEC encoding scheme identified by the tuple. "FEC Encoding Names" are numeric identifiers scoped by a FEC Encoding Identifier. The FEC Encoding Name MUST be part of the "FEC Object Transmission Information" and must be communicated to receivers together with the FEC Encoding Identifier. An FEC Encoding Identifier MAY also define a format for the (abstract) feedback packet fields "FEC Block Identifier" and "Number of Repair Symbols". 3.2. FEC Payload ID and FEC Object Transmission Information A document that specifies an encoding scheme and reserves a value of FEC Encoding Identifier MUST define a packet-field format for FEC Payload ID and FEC Object Transmission Information according to the need of the encoding scheme. This also applies to documents that reserves values of FEC Encoding Identifiers for under-specified encoding schemes. In this case the FEC Object Transmission Information must also include a field to contain the "FEC Encoding Name". A packet field definition of FEC Object Transmission Information MUST be provided despite the fact that protocol instantiation may decide to communicate this information out of band. The packet field format of "FEC Block Identifier" and "Number of Repair Symbols" SHOULD be specified for each FEC encoding scheme, even the scheme is mainly intended for feedback-less protocols. FEC Block Identifier may not apply to some encoding schemes. All packet field definition (FEC Payload ID, FEC Object Transmission Information, FEC Block Identifier and Number of Repair Symbols) MUST be fully specified at level of bit-fields and they must have a length that is a multiple of a 4-byte word (this is to facilitate the alignment of packet fields in protocol instantiations). 4. IANA Considerations Values of FEC Encoding Identifiers and FEC Encoding Names are subject to IANA registration. FEC Encoding Identifiers and FEC Encoding Names are hierarchical: FEC Encoding Identifiers (at the top level) scope ranges Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 17] Draft RMT BB, Forward Error Correction Codes 13 July 2000 of FEC Encoding Names. Not all FEC Encoding Identifiers have a corresponding FEC Encoding Name scope (see below). A FEC Encoding Identifier is a numeric non-negative index. Value from 0 to 127 are reserved for FEC encoders that are fully specified, as described in section 3.1. The assignment of a FEC Encoding Identifier in this range can only be granted if the requestor can provide such a specification published as an IETF RFC. Value grater than 127 can be assigned to under-specified encoding schemes. In any case values of FEC Encoding Identifiers can only be assigned if the required FEC packet fields corresponding to it (see section 3.1) are specified in a RFC. Each FEC Encoding Identifier assigned to an under-specified encoding scheme scopes a range of FEC Encoding Names. An FEC Encoding Name is a numeric non-negative index. The document that reserves a FEC Encoding Identifier MAY also specify a range for the subordinate FEC Encoding Names. Under the scope of a FEC Encoding Identifier, FEC Encoding Names are assigned on a First Come First Served base to requestors that are able to provide point of contact information and a pointer to publicly accessible documentation describing the FEC encoder and a ways to obtain it. The requestor is responsible for keeping this information up to date. 5. Security Considerations The use of FEC, in and of itself, imposes no additional security considerations versus sending the same information without FEC. However, 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 down-load 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 Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 18] Draft RMT BB, Forward Error Correction Codes 13 July 2000 protocols 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. 6. Intellectual Property Disclosure Tornado codes [LUB97] have both patents issued and patents pending. LT codes [LUB00] have patents pending. 7. Acknowledgments Thanks to Vincent Roca and Hayder Radha for their detailed comments on this draft. 8. References [AFZ95] Acharya, S., Franklin, M., and Zdonik, S., ``Dissemination- 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. Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 19] Draft RMT BB, Forward Error Correction Codes 13 July 2000 [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. [LUB00] Luby, M., "An overview of LT codes", Digital Fountain white paper, July 2000. [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 IEEE 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. [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). Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 20] Draft RMT BB, Forward Error Correction Codes 13 July 2000 A. Predefined FEC encoders This appendix specifies the FEC Encoding Identifier and the relative packets field for a number of known schemes that follow under the class of under-specified FEC encoding schemes. Others may be specified in companion documents. A.1. Small Block, Large Block and Expandable FEC Codes This section reserves a FEC Encoding Identifier for the family of codes described in Section 2.2, 2.3 and 2.4 and specifies the relative packet fields. Under-specified FEC encoding schemes that belong to this class MUST use this identifier and packet field definitions. The FEC Encoding Identifier assigned to Small Block, Large Block, and Expandable FEC Codes is 128. The FEC Payload ID is composed of an encoding symbol index and an encoding block number structured as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | encoding block number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | encoding symbol ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In addition, a one bit FEC Encoding Flag SHOULD be included, and this flag indicates whether the encoding symbol(s) in the payload of the packet are source symbol(s) or redundant symbol(s). The FEC Object Transmission Information has the following structure: Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 21] Draft RMT BB, Forward Error Correction Codes 13 July 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Encoding Name | Object Length (MSB) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Object Length (LSB) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that this structure limits the range of possible FEC Encoding Names to 0-:-65536, despite the FEC Object Transmission Information can also be transmitted out of band. The Object Length, composed of a Most Significant Bytes portion (MSB) and a Least Significant Bytes portion (LSB), is expressed in bytes. Feedback packet MUST contain both FEC Block Identifier and Number of Repair Symbols. Their structure is the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Block Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Repair Symbols | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9. Authors' Addresses Michael Luby luby@digitalfountain.com Digital Fountain 600 Alabama Street San Francisco, CA, USA, 94110 Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 22] Draft RMT BB, Forward Error Correction Codes 13 July 2000 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 Bruce Lueckenhoff brucelu@cadence.com Cadence Design Systems, Inc. 120 Cremona Drive, Suite C Santa Barbara, CA 93117 Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 23] Draft RMT BB, Forward Error Correction Codes 13 July 2000 10. 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." Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 24] Draft RMT BB, Forward Error Correction Codes 13 July 2000 Table of Contents 1 Rationale and Overview .......................................... 2 1.1 Application of FEC codecs ..................................... 4 2 FEC Codes ....................................................... 6 2.1 Simple codes .................................................. 6 2.2 Small block FEC codes ......................................... 7 2.3 Large block FEC codes ......................................... 10 2.4 Expandable FEC codes .......................................... 11 2.5 Source blocks with variable length source symbols ............. 13 3 FEC Abstract Packet Fields and Out-of-Band Information .......... 14 3.1 FEC Encoding Identifier ....................................... 16 3.2 FEC Payload ID and FEC Object Transmission Information ........ 17 4 IANA Considerations ............................................. 17 5 Security Considerations ......................................... 18 6 Intellectual Property Disclosure ................................ 19 7 Acknowledgments ................................................. 19 8 References ...................................................... 19 A. Predefined FEC encoders ....................................... 21 A.1. Small Block, Large Block and Expandable FEC Codes ........... 21 9 Authors' Addresses .............................................. 22 10 Full Copyright Statement ....................................... 24 Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 25] --==_Exmh_924555160-- >From owner-rmt@listserv.lbl.gov Fri Jul 14 23:34:11 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id XAA09546; Fri, 14 Jul 2000 23:30:57 -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 XAA09542 for ; Fri, 14 Jul 2000 23:30:55 -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 XAA27631 for ; Fri, 14 Jul 2000 23:30:54 -0700 (PDT) Received: from hotmail.com (f49.law8.hotmail.com [216.33.241.49]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id XAA27624 for ; Fri, 14 Jul 2000 23:30:53 -0700 (PDT) Received: (qmail 46957 invoked by uid 0); 15 Jul 2000 06:29:20 -0000 Message-ID: <20000715062920.46956.qmail@hotmail.com> Received: from 202.141.150.16 by www.hotmail.com with HTTP; Fri, 14 Jul 2000 23:29:20 PDT X-Originating-IP: [202.141.150.16] From: "Danesh Tarapore" To: mankin@EAST.ISI.EDU, ark008@email.mot.com, lorenzo@cisco.com, rmt@lbl.gov Subject: More Info on Multicasting Date: Sat, 15 Jul 2000 11:59:20 IST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-rmt@lbl.gov Precedence: bulk Respected Sir, I am a Computer Sc Enginnering student in the final year,studying ina Goverment Enginnering College in India. I want to do a project on Multicasting as I have read some of the whitepapers from ipmulticasting.com and found the topic very intresting. However as I am new to this field I would need your expert guidance to steer me through this project.Kindly send me the related URL's and the emails of some of the people who may be able to help me if you are buzy. Yours most obediently, Danesh Tarapore. ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com >From owner-rmt@listserv.lbl.gov Mon Jul 17 03:44:52 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA14263; Mon, 17 Jul 2000 03:42:45 -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 DAA14259 for ; Mon, 17 Jul 2000 03:42:42 -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 DAA10294 for ; Mon, 17 Jul 2000 03:42: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 DAA10291 for ; Mon, 17 Jul 2000 03:42: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 GAA26085; Mon, 17 Jul 2000 06:42:34 -0400 (EDT) Message-Id: <200007171042.GAA26085@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-tree-config-00.txt Date: Mon, 17 Jul 2000 06:42:34 -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 Block: Tree Auto-Configuration Author(s) : B. Cain, D. Chiu, M. Kadansky, S. Koh, B. Levine, G. Taskale, B. Whetten Filename : draft-ietf-rmt-bb-tree-config-00.txt Pages : 16 Date : 14-Jul-00 The Reliable Multicast Transport Working Group has been chartered to standardize multicast transport services. This working group expects to initially standardize three protocol instantiations. This draft is concerned with the requirements of the tree-based ACK protocol. In particular, it is concerned with defining the building block for auto-configuration of the logical ACK-tree. According to the charter, a building block is 'a coarse-grained modular component that is common to multiple protocols along with abstract APIs that define a building block's access methods and their arguments.' For more information, see the Reliable Multicast Transport Building Blocks and Reliable Multicast Design Space documents [WLKHFL00][HWKFV00]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-tree-config-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-tree-config-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-tree-config-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: <20000714143913.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-tree-config-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-tree-config-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000714143913.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Mon Jul 17 07:12:57 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id HAA15353; Mon, 17 Jul 2000 07:12: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 HAA15349 for ; Mon, 17 Jul 2000 07:12: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 HAA25211 for ; Mon, 17 Jul 2000 07:12:32 -0700 (PDT) Received: from poseidon.bwc.state.oh.us ([198.234.212.100]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA25208 for ; Mon, 17 Jul 2000 07:12:31 -0700 (PDT) Received: by poseidon.bwc.state.oh.us; id KAA19466; Mon, 17 Jul 2000 10:10:18 -0400 (EDT) Received: from venus.bwc.state.oh.us(165.223.131.35) by neptune.bwc.state.oh.us via smap (V5.0) id xma019434; Mon, 17 Jul 00 10:09:23 -0400 Received: from mswg6.bwc.state.oh.us ([165.223.130.24]) by venus.bwc.state.oh.us (8.9.3/8.9.1) with ESMTP id KAA11819; Mon, 17 Jul 2000 10:17:01 -0400 (EDT) Received: by MSWG6 with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jul 2000 10:09:21 -0400 Message-ID: <6FDE0867413DD21182BF00A0C972519204C98ACD@MSWG4> From: "Morrisey Matthew J." To: rmt@lbl.gov Cc: "'azinin@cisco.com'" , "'myeung@procket.com'" Subject: RE: I-D ACTION:draft-ietf-rmt-author-guidelines-00.txt Date: Mon, 17 Jul 2000 10:09:15 -0400 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-rmt@lbl.gov Precedence: bulk 1. I was confused by section 6 "Deployment Considerations", I couldn't decide where area zero was. But maybe i'm the only one who couldn't. 2. I was wondering how these implementation behaviours were enabled and disabled in the respective routers. Other than that i was delighted to read this draft. Matt Morrisey >From owner-rmt@listserv.lbl.gov Mon Jul 17 10:47:45 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id KAA23208; Mon, 17 Jul 2000 10:47: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 KAA23204 for ; Mon, 17 Jul 2000 10:47:10 -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 KAA01332 for ; Mon, 17 Jul 2000 10:47:10 -0700 (PDT) Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.202.251]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA01325 for ; Mon, 17 Jul 2000 10:47:09 -0700 (PDT) Received: from dhcp-c2-2-107.cisco.com (dhcp-c2-2-107.cisco.com [171.68.171.107]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA06944; Mon, 17 Jul 2000 10:46:35 -0700 (PDT) Date: Mon, 17 Jul 2000 10:41:38 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <10445.000717@cisco.com> To: "Morrisey Matthew J." CC: rmt@lbl.gov, "'myeung@procket.com'" Subject: Re: I-D ACTION:draft-ietf-rmt-author-guidelines-00.txt In-reply-To: <6FDE0867413DD21182BF00A0C972519204C98ACD@MSWG4> References: <6FDE0867413DD21182BF00A0C972519204C98ACD@MSWG4> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk The subject is a bit misleading, btw :) It should've been draft-ietf-ospf-abr-alt-02.txt AFAIU. Answers: 1) We call area 0 a "backbone area" 2) It is rather an implementation detail. Anyway, I implemented a configuration command in Zebra. Cisco always uses 'cisco' behavior :) -- Alex Zinin Monday, July 17, 2000, 7:09 AM, Morrisey Matthew J. wrote: > 1. I was confused by section 6 "Deployment Considerations", I couldn't > decide where area zero was. But maybe i'm the only one who couldn't. > 2. I was wondering how these implementation behaviours were enabled and > disabled in the respective routers. > Other than that i was delighted to read this draft. > Matt Morrisey >From owner-rmt@listserv.lbl.gov Tue Jul 18 03:36:48 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA02463; Tue, 18 Jul 2000 03:36: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 DAA02459 for ; Tue, 18 Jul 2000 03:36:07 -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 DAA02256 for ; Tue, 18 Jul 2000 03:36:07 -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 DAA02253 for ; Tue, 18 Jul 2000 03:36:06 -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 GAA14000; Tue, 18 Jul 2000 06:36:05 -0400 (EDT) Message-Id: <200007181036.GAA14000@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-01.txt Date: Tue, 18 Jul 2000 06:36:05 -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 Block: Forward Error Correction Codes Author(s) : M. Luby, L. Rizzo, J. Gemmell, J. Crowcroft, B. Lueckenhoff Filename : draft-ietf-rmt-bb-fec-01.txt Pages : 25 Date : 17-Jul-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-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-bb-fec-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-bb-fec-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: <20000717150054.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-fec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-fec-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000717150054.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Tue Jul 18 03:36:48 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA02457; Tue, 18 Jul 2000 03:36:05 -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 DAA02453 for ; Tue, 18 Jul 2000 03:36:02 -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 DAA02249 for ; Tue, 18 Jul 2000 03:36: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 DAA02245 for ; Tue, 18 Jul 2000 03:36:01 -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 GAA13950; Tue, 18 Jul 2000 06:36:00 -0400 (EDT) Message-Id: <200007181036.GAA13950@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-01.txt Date: Tue, 18 Jul 2000 06:36:00 -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 : Asynchronous Layered Coding A scalable reliable multicast protocol Author(s) : M. Luby, J. Gemmell Filename : draft-ietf-rmt-pi-alc-01.txt Pages : 39 Date : 17-Jul-00 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 leave an existing session in an asynchronous manner independent of other receivers A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-alc-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-pi-alc-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-pi-alc-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: <20000717150045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-pi-alc-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-pi-alc-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000717150045.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Tue Jul 18 11:57:57 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id LAA05988; Tue, 18 Jul 2000 11:56:40 -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 LAA05984 for ; Tue, 18 Jul 2000 11:56:38 -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 LAA27900 for ; Tue, 18 Jul 2000 11:56:38 -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 LAA27881 for ; Tue, 18 Jul 2000 11:56:37 -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 OAA16675; Tue, 18 Jul 2000 14:56:35 -0400 (EDT) Message-Id: <200007181856.OAA16675@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-01.txt Date: Tue, 18 Jul 2000 14:56:34 -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 Block: Forward Error Correction Codes Author(s) : M. Luby, L. Vicisano, L. Rizzo, J. Gemmell, J. Crowcroft, B. Lueckenhoff Filename : draft-ietf-rmt-bb-fec-01.txt Pages : 25 Date : 17-Jul-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-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-bb-fec-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-bb-fec-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: <20000717150054.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-fec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-fec-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000717150054.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Tue Jul 18 11:57:57 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id LAA05980; Tue, 18 Jul 2000 11:56: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 LAA05976 for ; Tue, 18 Jul 2000 11:56: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 LAA27841 for ; Tue, 18 Jul 2000 11:56:32 -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 LAA27834 for ; Tue, 18 Jul 2000 11:56:31 -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 OAA16607; Tue, 18 Jul 2000 14:56:29 -0400 (EDT) Message-Id: <200007181856.OAA16607@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-01.txt Date: Tue, 18 Jul 2000 14:56:29 -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 : Asynchronous Layered Coding A scalable reliable multicast protocol Author(s) : M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, J.Crowcroft, B. Lueckenhoff Filename : draft-ietf-rmt-pi-alc-01.txt Pages : 39 Date : 17-Jul-00 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 leave an existing session in an asynchronous manner independent of other receivers A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-alc-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-pi-alc-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-pi-alc-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: <20000717150045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-pi-alc-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-pi-alc-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000717150045.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Wed Jul 19 03:37:24 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA09307; Wed, 19 Jul 2000 03:35:40 -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 DAA09303 for ; Wed, 19 Jul 2000 03:35:37 -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 DAA03117 for ; Wed, 19 Jul 2000 03:35:36 -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 DAA03114 for ; Wed, 19 Jul 2000 03:35:36 -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 GAA21526; Wed, 19 Jul 2000 06:35:35 -0400 (EDT) Message-Id: <200007191035.GAA21526@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-mrcc-00.txt Date: Wed, 19 Jul 2000 06:35:35 -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 Block: Multirate Congestion Control Author(s) : M. Luby, J. Gemmell, A. Haken Filename : draft-ietf-rmt-bb-mrcc-00.txt Pages : 20 Date : 18-Jul-00 This document describes MRCC, a scalable multirate congestion control building block for multicast. MRCC is an approach that allows multiple receivers to concurrently receive packets from a single sender at vary- ing rates depending on individual bandwidth connections and network con- ditions. Two basic goals of the approach are to allow each receiver to obtain the full benefit of the available bandwidth to the sender and to be fair to other flows in the network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-mrcc-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-mrcc-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-mrcc-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: <20000718140656.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-mrcc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-mrcc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000718140656.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Thu Jul 20 03:53:23 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA12747; Thu, 20 Jul 2000 03:47: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 DAA12743 for ; Thu, 20 Jul 2000 03:47:54 -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 DAA23460 for ; Thu, 20 Jul 2000 03:47:53 -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 DAA23457 for ; Thu, 20 Jul 2000 03:47:53 -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 GAA12658; Thu, 20 Jul 2000 06:47:51 -0400 (EDT) Message-Id: <200007201047.GAA12658@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-mrcc-00.txt Date: Thu, 20 Jul 2000 06:47:51 -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 Block: Multirate Congestion Control Author(s) : M. Luby, L. Vicisano, A. Haken Filename : draft-ietf-rmt-bb-mrcc-00.txt Pages : 20 Date : 18-Jul-00 This document describes MRCC, a scalable multirate congestion control building block for multicast. MRCC is an approach that allows multiple receivers to concurrently receive packets from a single sender at vary- ing rates depending on individual bandwidth connections and network con- ditions. Two basic goals of the approach are to allow each receiver to obtain the full benefit of the available bandwidth to the sender and to be fair to other flows in the network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-mrcc-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-mrcc-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-mrcc-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: <20000719151429.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-mrcc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-mrcc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000719151429.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Thu Jul 20 08:27:01 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id IAA14126; Thu, 20 Jul 2000 08:26:37 -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 IAA14122 for ; Thu, 20 Jul 2000 08:26:35 -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 IAA24100 for ; Thu, 20 Jul 2000 08:26:34 -0700 (PDT) Received: from mail.monisys.ca (mail.monisys.ca [204.225.249.10]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA24083; Thu, 20 Jul 2000 08:26:30 -0700 (PDT) Received: from mailcity.com (ts1-044.wnpg.ca.ziplink.net [165.154.32.44]) by mail.monisys.ca (8.9.3/8.9.3) with SMTP id LAA09925; Thu, 20 Jul 2000 11:35:39 -0400 Date: Thu, 20 Jul 2000 11:35:39 -0400 Message-Id: <200007201535.LAA09925@mail.monisys.ca> X-Mailer: Sent with E-Mail Magnet Version 4.3 From: secrets47@lycos.com Subject: God bless YOU as WE are in the NEXT Millennium! MIME-Version: 1.0 Content-Type: text/html; charset=us-ascii Sender: owner-rmt@lbl.gov Precedence: bulk Online Fantasy Media for a healthy future
Dear Web site Owner

I am writing to you to inquire if you would
be interested in me helping you get a taste
for New Innovations. Your web site is very
informative and very interesting. I know
customers who would be extremely interested
in your products and services. This powerful
idea was designed for Large Companies, but
now others are using it.

This is a Wonderful Idea that was featured in
The Wall Street Journal, The New York Times
and all the other cutting edge publications!
Our Company values helping web site owners.
We want to help you grow and to also improve
your quality of life in every way we can.

So Please scroll down for more information to get
started today!

I'll be looking forward to hearing from you
soon! Thank You!

Sincerely,
Kaizee Anderson
CEO of Fantasy Media 2000


Fantasy Media 2000
Helping Large companies become Larger
& small businesses into large corporations.

The Next Revolution, The Next Solution! Be part of this phenomenon.
Our Focus is to improve your quality of life in every way we can...

YOUR Journey begins Here!Click Here

Many large companies are spending too much money on
Banner Ads & Search Engines with mostly bellow average
results. We are here to save you money at the same
time give you much better results than search
engines & banner ads. You'll be Amazed!

This might sound unbelievable, but there are large
companies out there that spend over $1,000,000 dollars
a day on banner ads with 1% to 2% click through
response, and that's just half the battle, customers
still need to make the purchase. This could mean
a tremendous lost to their Investment!!!

However if you were to do the same with Opt-in
Emails, you will more than quadruple "Your Investment".

The Best Way is through Opt-in Email. These people
in Opt-in emails will be more than happy to here
from you! This is by far the most Powerful Direct Response
Marketing Idea Ever. This is one concept the
Fortune 500 Companies are realizing as being lucrative

Click Here to see the Types of companies that benefits from it!

Marketers have generated response rates as high as 5%
to 15% and sales as great as $50,000 in a single day.
It doesn't matter if you're a small business or
a large corporation, you will get the same results.
After you sign up you will get a confirmation in
your email to rent lists of over 1.2 million people
who are ready to buy any product or service
that you are selling. WARNING!
The results could be staggering!!!



Fantasy Media 2000 & Gemini3Style, This is TOP SECRET!
So you wouldn't find this FREE Offer anywhere else
You wouldn't find us anywhere else, you wouldn't find
us on any Online Classifieds, Search Engines, Banner Ads,
Newsgroups or anywhere else on the Internet.
So if you're one of those LUCKY people that found us through
your email, consider this your only opportunity of a life time
to bring your business to the next level, you'll be amazed!

Place Your tiny Classified Ads



"MailLoop" learn more about this powerful software!Click Here!




E-mail Us
PO Box 68014 rpo Osborne Village
Winnipeg, Manitoba, Canada, r3l 2v9

Fantasy Media 2000 Copyright 1999-2000 All rights reserved
 >From owner-rmt@listserv.lbl.gov Fri Jul 21 00:06:13 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id AAA17521; Fri, 21 Jul 2000 00:03:51 -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 AAA17517 for ; Fri, 21 Jul 2000 00:03: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 AAA02222 for ; Fri, 21 Jul 2000 00:03:49 -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 AAA02219 for ; Fri, 21 Jul 2000 00:03:49 -0700 (PDT) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.10.0/8.10.0) id e6L73mX13156; Fri, 21 Jul 2000 00:03:48 -0700 (PDT) Message-Id: <200007210703.e6L73mX13156@daffy.ee.lbl.gov> To: rmt@lbl.gov Subject: you may be deleted from rmt@lbl.gov - please read! Date: Fri, 21 Jul 2000 00:03:48 PDT From: Vern Paxson Sender: owner-rmt@lbl.gov Precedence: bulk I have been getting repeated bounces from the following addresses for the RMT mailing list rmt@lbl.gov: Joseph.Wesley@east.sun.com Paul.G.Mallasch@grc.nasa.gov aconta@lucent.com bcain@nortelnetworks.com bkumar@glenvan.glenayre.com bohallor@fore.com chris@novedia.de gvjohn@miel.mot.com jr1734@yahoo.com lillie@rsch.comm.mot.com mmichel@bbt.com murchiso@newbridge.com philip@newbridge.com rrt@research.bellcore.com sanjoy@dnrc.bell-labs.com senaka@rsch.comm.mot.com sergeh@nortelnetworks.com thardjon@nortelnetworks.com yzhu@us.ibm.com zbecka@newbridge.com I plan to delete these addresses in a week or so unless I hear from back that particular addresses should be kept or changed. Your RMT list maintainer, Vern >From owner-rmt@listserv.lbl.gov Sun Jul 23 16:46:25 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id QAA24751; Sun, 23 Jul 2000 16:42:54 -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 QAA24747 for ; Sun, 23 Jul 2000 16:42:52 -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 QAA14663 for ; Sun, 23 Jul 2000 16:42:51 -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 QAA14660 for ; Sun, 23 Jul 2000 16:42:51 -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 QAA13710 for ; Sun, 23 Jul 2000 16:42:36 -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 QAA09022 for ; Sun, 23 Jul 2000 16:42:21 -0700 (PDT) Message-Id: <200007232342.QAA09022@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: Proposed meeting agenda MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9017.964395740.1@cisco.com> Date: Sun, 23 Jul 2000 16:42:20 -0700 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk Dear all, This is the proposed agenda. If we have left anything out, please let us know. This is to be submitted by Monday, 17:00 ET, but we can still change it informally later. Due to the tight schedule some of the slots might be shorter than requested, please try to limit the presentation to the key points and leave time for discussion. thanks, the WG chairs. ## 48th IETF - Pittsburgh, PA, USA Reliable Multicast Transport WG, Meeting Agenda. - agenda bashing 5 mins - guidelines draft 10 mins - Tree-Building BB 25 mins - Track arch, PI and security 35 mins - FEC BB 15 mims - ALC PI 15 mins - MRCC BB 30 mins - discussion 15 mins Possible topics for discussion are: - draft-ietf-rmt-buildingblocks-02.txt status - NORM status (no submissions nor presentations in agenda) - what's done and what's left >From owner-rmt@listserv.lbl.gov Mon Jul 24 03:41:38 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA25706; Mon, 24 Jul 2000 03:38:19 -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 DAA25702 for ; Mon, 24 Jul 2000 03:38:17 -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 DAA21127 for ; Mon, 24 Jul 2000 03:38:17 -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 DAA21124 for ; Mon, 24 Jul 2000 03:38:16 -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 GAA09161; Mon, 24 Jul 2000 06:38:15 -0400 (EDT) Message-Id: <200007241038.GAA09161@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-track-arch-00.txt Date: Mon, 24 Jul 2000 06:38:15 -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 : TRACK ARCHITECTURE A SCALEABLE REAL-TIME RELIABLE MULTICAST PROTOCOL Author(s) : B. Whetten, D. Chiu, S. Paul, M. Kadansky, G. Taskale Filename : draft-ietf-rmt-track-arch-00.txt Pages : Date : 21-Jul-00 One of the protocol instantiations the RMT WG is chartered to create is a TRee-based ACKnowledgement protocol (TRACK). Rather than create a set of monolithic protocol specifications, the RMT WG has chosen to break the reliable multicast protocols in to Building Blocks (BB) and Protocol Instantiations (PI). A Building Block is a specification of the algorithms of a single component, with an abstract interface to other BBs and PIs. A PI combines a set of BBs, adds in the additional required functionality not specified in any BB, and specifies the specific instantiation of the protocol. For more information, see the Reliable Multicast Transport Building Blocks and Reliable Multicast Design Space documents [2][3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-track-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-track-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-track-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: <20000721172539.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-track-arch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-track-arch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000721172539.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Mon Jul 24 03:41:46 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA25700; Mon, 24 Jul 2000 03:38:15 -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 DAA25696 for ; Mon, 24 Jul 2000 03:38: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 DAA21118 for ; Mon, 24 Jul 2000 03:38:12 -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 DAA21115 for ; Mon, 24 Jul 2000 03:38:12 -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 GAA09149; Mon, 24 Jul 2000 06:38:11 -0400 (EDT) Message-Id: <200007241038.GAA09149@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-track-security-00.txt Date: Mon, 24 Jul 2000 06:38:10 -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 : Security Requirements For TRACK Author(s) : T. Hardjono, B. Whetten Filename : draft-ietf-rmt-pi-track-security-00.txt Pages : Date : 21-Jul-00 This document discusses the security issues within the TRee-based ACKnowledgement (TRACK) reliable multicast protocol instantiation, and identifies some constraints and requirements for security provisions for this protocol. 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 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, because of the requirement that the interior control nodes only OPTIONALLY have access to the data packet payload. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-track-security-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-track-security-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-track-security-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: <20000721172527.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-pi-track-security-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-pi-track-security-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000721172527.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Mon Jul 24 06:21:12 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id GAA26676; Mon, 24 Jul 2000 06:17:59 -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 GAA26672 for ; Mon, 24 Jul 2000 06:17:57 -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 GAA02400 for ; Mon, 24 Jul 2000 06:17:56 -0700 (PDT) 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 GAA02396 for ; Mon, 24 Jul 2000 06:17:55 -0700 (PDT) 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 JAA23558; Mon, 24 Jul 2000 09:18:05 -0400 (EDT) Mime-Version: 1.0 X-Sender: adamson@pop.itd.nrl.navy.mil Message-Id: In-Reply-To: <200007232342.QAA09022@lorenzo-u10.cisco.com> References: <200007232342.QAA09022@lorenzo-u10.cisco.com> Date: Mon, 24 Jul 2000 09:17:51 -0400 To: Lorenzo Vicisano From: Brian Adamson Subject: Re: Proposed meeting agenda Cc: rmt@lbl.gov Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-rmt@lbl.gov Precedence: bulk Lorenzo, Roger, I have an updated version of the NORM BB draft but I missed the submission deadline. The updated version contains more algorithmic details on NACK suppression backoffs and other areas which were less complete in the last version. With the WG chairs' permission, I will post it to the mailing list and provide an brief overview of the update at the meeting ... best regards, Brian Adamson At 4:42 PM -0700 7/23/00, Lorenzo Vicisano wrote: >Dear all, > >This is the proposed agenda. > >If we have left anything out, please let us know. This is to >be submitted by Monday, 17:00 ET, but we can still change it >informally later. > >Due to the tight schedule some of the slots might be shorter than >requested, please try to limit the presentation to the key points >and leave time for discussion. > > thanks, > the WG chairs. > >## > >48th IETF - Pittsburgh, PA, USA >Reliable Multicast Transport WG, Meeting Agenda. > > - agenda bashing 5 mins > - guidelines draft 10 mins > - Tree-Building BB 25 mins > - Track arch, PI and security 35 mins > - FEC BB 15 mims > - ALC PI 15 mins > - MRCC BB 30 mins > - discussion 15 mins > >Possible topics for discussion are: > > - draft-ietf-rmt-buildingblocks-02.txt status > - NORM status (no submissions nor presentations in agenda) > - what's done and what's left Brian __________________________________ Brian Adamson >From owner-rmt@listserv.lbl.gov Mon Jul 24 08:25:13 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id IAA27152; Mon, 24 Jul 2000 08:23:04 -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 IAA27148 for ; Mon, 24 Jul 2000 08:23:02 -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 IAA22557 for ; Mon, 24 Jul 2000 08:23:01 -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 IAA22554 for ; Mon, 24 Jul 2000 08:23:01 -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 IAA24467; Mon, 24 Jul 2000 08:22:45 -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 IAA11635; Mon, 24 Jul 2000 08:22:30 -0700 (PDT) Message-Id: <200007241522.IAA11635@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: Brian Adamson cc: rmt@lbl.gov Subject: Re: Proposed meeting agenda In-Reply-To: Your message of "Mon, 24 Jul 2000 09:17:51 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Jul 2000 08:22:30 -0700 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk > I have an updated version of the NORM BB draft but I missed the > submission deadline. The updated version contains more algorithmic > details on NACK suppression backoffs and other areas which were less > complete in the last version. With the WG chairs' permission, I will > post it to the mailing list and provide an brief overview of the > update at the meeting ... Brian, please go ahead, we will reserve a short presentation slot for you. Lorenzo >From owner-rmt@listserv.lbl.gov Wed Jul 26 11:05:03 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id LAA07206; Wed, 26 Jul 2000 11:02: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 LAA07202 for ; Wed, 26 Jul 2000 11:02: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 LAA26119 for ; Wed, 26 Jul 2000 11:02:32 -0700 (PDT) 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 LAA26110 for ; Wed, 26 Jul 2000 11:02:30 -0700 (PDT) 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 OAA08191 for ; Wed, 26 Jul 2000 14:02:30 -0400 (EDT) Mime-Version: 1.0 X-Sender: adamson@pop.itd.nrl.navy.mil Message-Id: In-Reply-To: <200007241522.IAA11635@lorenzo-u10.cisco.com> References: <200007241522.IAA11635@lorenzo-u10.cisco.com> Date: Wed, 26 Jul 2000 14:02:27 -0400 To: rmt@lbl.gov From: Brian Adamson Subject: NORM Building Block draft Content-Type: multipart/mixed; boundary="============_-1247487947==_============" Sender: owner-rmt@lbl.gov Precedence: bulk --============_-1247487947==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Attached (text file) is the latest cut of the NORM Building Block draft (finally!). I apologize for not meeting the submission cutoff. I will provide an overview of the changes that have been made since last time. I look forward to the working groups comments and inputs. Let me know if anyone has any problems with the file. . best regards, Brian Adamson At 8:22 AM -0700 7/24/00, Lorenzo Vicisano wrote: > > > I have an updated version of the NORM BB draft but I missed the > > submission deadline. The updated version contains more algorithmic > > details on NACK suppression backoffs and other areas which were less > > complete in the last version. With the WG chairs' permission, I will > > post it to the mailing list and provide an brief overview of the > > update at the meeting ... > >Brian, please go ahead, we will reserve a short presentation >slot for you. > > Lorenzo --============_-1247487947==_============ Content-Id: Content-Type: text/plain; name="draft-ietf-rmt-norm-bb-01.txt"; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-rmt-norm-bb-01.txt" ; modification-date="Wed, 26 Jul 2000 13:52:21 -0400" RMT Working Group B. Adamson/Newlink INTERNET-DRAFT C. Bormann/Tellique draft-ietf-rmt-norm-bb-01.txt S. Floyd/ACIRI Expires: January 2001 M. Handley/ACIRI J. Macker/NRL July 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 negative- acknowledgment (NACK) oriented reliable multicast (NORM) protocols. The general goals and assumptions for NORM are defined. The tech- nical challenges related to NACK-oriented (and in some cases gen- eral) reliable multicast protocol design are identified. These challenges are resolved into a set of applicable "building blocks" which are described in further detail. It is anticipated that these building blocks (as they are further refined and defined in future revisions of this document) will be useful in generating Adamson, Bormann, et al. Expires January 2001 [Page 1] Internet Draft NORM Building Blocks July 2000 different instantiations of reliable multicast protocols. 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 complexities of group communication paradigms neces- sitate 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) oriented reliable multicast (NORM) protocols offer scalability advantages for appli- cations and/or network topologies where, for various reasons, it is prohibitive to construct a higher order delivery infrastructure 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 Applicability Each potential protocol instantiation using the building blocks presented here (and other applicable building block documents) will have specific criteria which will influence individual protocol design. To support the development of applicable building blocks, it is useful to identify and summarize driving general protocol design goals and assumptions. These are areas which each protocol instantiation will need to address in detail. Each building block description in this document will include a discussion of the impact of these design criteria. The categories of design criteria considered here include: 1) Data content model 2) Group membership dynamics 3) Sender/receiver relationships 4) Group size Adamson, Bormann, et al. Expires January 2001 [Page 2] Internet Draft NORM Building Blocks July 2000 5) Data delivery performance 6) Network topology 3) Router/intermediate system assistance In some cases, a building block may be designed to address a wide range of assumptions while in other cases there will be trade-offs required to meet different application needs. Where necessary, building block features will designed to be parametric to meet dif- ferent requirements. Of course, an underlying goal will be to min- imize design complexity and to at least recommend default values for any such parameters which meet a general purpose "bulk data transfer" requirement in a typical Internet environment. 2.1 Data content model The implicit goal of a reliable multicast protocol is the reliable delivery of "data" among a group of members communicating through IP multicast datagram service. However, the nature of the data content and the service the application is attempting to provide can impact design decisions. The service model may range from 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 transmitted data (or state referencing it) for retransmission or repair. The needs for ordering and/or causality in the sequence of transmissions and receptions among members in the group may be dif- ferent depending upon data content. The group communication paradigm differs significantly from the point-to-point model in that, depending upon the data content type, some receivers may com- plete reception of a portion of data content and be able to act upon it before other members 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 protocol 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 Adamson, Bormann, et al. Expires January 2001 [Page 3] Internet Draft NORM Building Blocks July 2000 contrasts 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 application goals, senders and receivers participating in a reliable multicast transport "session" may be able to join late, leave, and/or potentially rejoin while the ongoing group communi- cation "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 members 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. However, the potential for router assistance or other non-linear NACK suppression mechanisms may enable these protocols to scale to very large group sizes. In large scale cases, it may be pro- hibitive for members to maintain state on all other members (in particular, other receivers) in the group. The impact of group size needs to be considered in the development of generally appli- cable 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 Adamson, Bormann, et al. Expires January 2001 [Page 4] Internet Draft NORM Building Blocks July 2000 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. The bandwidth available on the links between the members of a single group today may vary between low numbers of kbit/s for wireless links and multiple Gbit/s for high speed LAN connections, with varying degrees of contention from other flows. Recently, a number of asymmetric network services including 56K/ADSL modems, CATV Internet service, satellite and other wire- less communication services have begun to proliferate. Many of these are inherently broadcast media with potentially large "fanouts" to which IP multicast service is highly applicable. 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 The previous section has presented in general what building blocks are intended to be and some of the criteria which may affect build- ing block identification/design. This section describes different Adamson, Bormann, et al. Expires January 2001 [Page 5] Internet Draft NORM Building Blocks July 2000 building block areas applicable to NACK-oriented reliable multi- cast 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 multi- cast. In those cases, the discussion below describes requirements placed on those other general building block areas from the stand- point of NACK-oriented reliable multicast. For the individual building blocks to be incorporated as part of a specific protocol instantiation, it is 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" provided 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: (NACK-Oriented Components) 1) Sender transmission 2) NACK-oriented Repair Process 3) "Late-joining" Receiver Policies and Mechanisms (Generally-applicable Components) 4) Node (member) 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 Figure 1 provides an pictoral overview of these building block areas and their relationships. For example, the content of the data messages that sender initially transmits depends upon the "Node Identification", Data Content Identification", "FEC" , and "Congestion Control components (Note that the rate of message transmission will generally depend upon the "Congestion Control" component). Subsequently, the receivers response to these trans- missions (e.g. NACKing for repair) will depend upon the content of these transmissions and inputs from other building block compo- nents. Then, the sender's processing of these responses will feed back into its transmission strategy. Adamson, Bormann, et al. Expires January 2001 [Page 6] Internet Draft NORM Building Blocks July 2000 Application Data | V .---------------------. .-----------------------. | Node Identification |----------->| Sender Transmission |<------. '---------------------' _.-' '-----------------------' | .---------------------. _.-' .' | | | Data Identification |--' .'' | ("Join" Policy) | '---------------------' .' ' V | .---------------------. .' ' .------------------------. | .->| Congestion Control |-' ' | Receiver NACK-oriented | | | '---------------------' .' | Repair Process | | | .---------------------. .' | .------------------. | | | | FEC |'. | | NACK Initiation | | | | '---------------------'. '._ | '------------------' | | | .---------------------. , '-._ | .------------------. | | '--| RTT Collection |._' '->| | NACK Content | | | '---------------------' .''. | '------------------' | | .---------------------. ' ''-._ | .------------------. | | | Group Size Est. |---'-'---'->| | NACK Suppression | | | '---------------------''. ' ' | '------------------' | | .---------------------. ' ' ' '------------------------' | | Other | ' ' ' | | '---------------------' ' ' ' | (Router Assistance) | '. ' ' V | '.'' .-------------------------. | '>| Sender NACK Processing |_____/ | and Repair Response | '-------------------------' ^ ^ | | .-----------------------------. | (Security) | '-----------------------------' Fig. 1 - NORM Building Block Framework The components on the left side of this figure represent the components which may be generally applicable beyond NORM and those on the right are specific to NORM protocols. Some components (e.g. "Security") will impact to many aspects of the protocol and others such as "Router Assis- tance" may be more transparent to the core protocol processing. The sections below discuss issues with regards to these building block com- ponents and their relationships. Where applicable, specific technical recommendations are made for mechanisms which will properly satisfy the goals of reliable multicast bulk transport for the Internet. Adamson, Bormann, et al. Expires January 2001 [Page 7] Internet Draft NORM Building Blocks July 2000 3.1 Sender transmission Senders will transmit data content to the multicast session. The data content will be application dependent. The sender will transmit data content at a rate and with packet sizes determined by application and/or network architecture requirements. When congestion control mechanisms are used (recommended), the transmission rate will be controlled by the congestion control mechanism. It is recommended that all data transmis- sions from senders be subject to rate limitations determined by the application or congestion control algorithm. The sender's transmissions should make good utlization of the available capacity (which may be lim- ited by the application and/or by congestion control). As a result, it is expected there will be overlap and multiplexing of new data content transmission with repair content. In addition to data content, other sender messages or commands may be employed as part of protocol operation. For NACK-oriented operation, the reliability of any such commands may depend upon redundant transmis- sion. Other factors related to NACK-oriented operation may determine sender transmission formats and methods. Some consideration needs to be given to the sender's behavior during intermittent idle periods when it has no data to transmit. While many aspects may be protocol-specific, there are techniques which may be generally applicable to NACK-oriented reliable multicast. For example, the periodicity of redundant transmis- sion 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 transmission. 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 sender should allow sufficient time between redundant transmissions to receive any NACK-oriented responses from the receiver set to this com- mand. Other protocol components may benefit from a similar approach. Inputs: 1) Data content 2) Segmentation size 3) Transmission rate 4) Application controls Outputs: 1) Rate-controlled stream of packets with headers uniquely identifying data or repair content within the context of the reliable multicast session. 2) Commands indicating sender's status or other transport Adamson, Bormann, et al. Expires January 2001 [Page 8] Internet Draft NORM Building Blocks July 2000 control actions to be taken. 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 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 receivers to aggregate NACK content into a smaller number of NACK messages. 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. Adamson, Bormann, et al. Expires January 2001 [Page 9] Internet Draft NORM Building Blocks July 2000 Outputs: 1) NACK Process Initiation Decision 3.2.2 NACK Content The content of NACK messages generated by reliable multicast receivers will include information detailing the current repair needs of each receiver. The specific information depends on the use and type of FEC in the NORM repair process. The identification of repair needs is dependent upon the data content identification (See Section 3.5 below). At the highest level the NACK content will identify the data transport object (or stream) within the mul- ticast session which needs repair. For the indicated transport entity, the NACK content will then identify the specific coding blocks and/or segments of coding blocks it needs to reconstruct the transmitted data. This content may be one or more of the items described in the sections below. 3.2.2.1 FEC Block Erasure Counts Where FEC-based repair is used, the NACK message content will need to identify the coding block(s) for which repair is needed and the count of erasures (missing packets) in the coding block. Note that this assumes the FEC algorithm is capable of repairing _any_ loss combination within the coding block and that the quantity of unique FEC parity packets the server has available to transmit is essen- tially unlimited (i.e. the server will always be able to provide new parity packets in response to anysubsequent repair requests for the same coding block). In other cases, the NACK content will need to also _explicitly_ identify which packets (information and/or parity) the receiver needs to successfully reconstruct the content of the coding block. 3.2.2.2 Encoding of Explicit NACK Content When FEC is not used as part of the repair process or the protocol instantiation is required to provide reliability even when the sender has transmitted all available parity for a given coding block (or the sender's ability to buffer transmission history is exceeded by the delay*bandwidth*loss characteristics of the network topology), the NACK content will need to contain _explicit_ coding block and/or packet loss information so that the sender can provide appropriate repair packets and/or data retransmissions. Explicit loss information in NACK content may also potentially serve other purposes. For example, it may be useful for decorrelating loss characteristics among a group of receivers to help differentiate candidate congestion control bottlenecks among the receiver set. Adamson, Bormann, et al. Expires January 2001 [Page 10] Internet Draft NORM Building Blocks July 2000 For cases where the amount of loss is very small with respect to the coding block size, it may be efficient to simply provide a list of coding block vector identifiers. However, in many cases, a bit mask marking the locations of missing packets may be significantly more efficient for communicating receiver repair needs. And since the data content is logically divided into coding blocks, a system of hierarchical bit masks can be used to encode missing content at the object/stream, FEC block, and individual packet levels. Hier- archical bit mask encoding can provide compact NACK messages even in high delay*bandwidth*loss conditions. Bit mask based NACK con- tent can also be efficiently processed with logical operations dur- ing protocol operation. 3.2.2.3 Hybrid Approach When FEC is used and NACK content is designed to contain explicit repair requests, there is strategy where the receivers can NACK for specific content which will help facilitate NACK suppression and repair efficiency. The assumptions for this strategy are that sender may potentially exhaust its supply of new, unique parity packets available for a given coding block and be required to explicitly retransmit some data or parity segments to complete reliable transfer. Another assumption is that an FEC algorithm where any parity packet can fill any erasure within the coding block is used. The goal of this strategy is to make maximum use of the available parity and provide the minimal amount of data and repair transmissions during reliable transfer of a coding block to the group. In this approach, the sender transmits the data content of the cod- ing block (and optionally some quantity of parity packets) in its initial transmission. Note that a coding block is considered to be logically made up of the contiguous set of data vectors plus parity vectors for the given FEC algorithm used. The sender transmits parity vectors from the lowest ordinal part of the parity portion of the coding block. When the receivers construct explicit NACK content, they request transmission of only the _upper_ ordinal por- tion, corresponding to the number of _data_ vectors, of the logical coding block required to fill their packet erasures (Note this _may_ include data vectors if there is a smaller number of parity vectors than data vectors for the selected code, but generally will consist solely of parity vectors). The receivers can also provide a count of erasures as a convenience (saves processing time) to the sender. Upon receipt of the NACK message, the sender will schedule transmission of fresh, new parity vectors based on the erasure count _if_ it has a sufficient quantity of vectors which were _not_ previously transmitted and ignore the explicit content requested.. Otherwise, the sender will resort to transmitting the set of repair Adamson, Bormann, et al. Expires January 2001 [Page 11] Internet Draft NORM Building Blocks July 2000 vectors requested. With this approach, the sender needs to main- tain very little state on requests it has received from the group without need for synchronization of repair requests from the group. Since all receivers use this same algorithm to express their explict repair needs, NACK suppression among receivers is simpli- fied over the course of multiple repair cycles. The receivers can simply compare NACKs heard from other receivers against their own calculated repair needs to determine whether they should transmit or suppress their pending NACK messages. 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 the 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 the repair information it will be subsequently trans- mitting). The backoff timeout periods used by receivers should be indepen- dently, randomly picked by receivers with an exponential distribu- tion [Nonnenmacher98]. This results in the bulk of the receiver set holding off transmission of NACK messages under the assumption that the smaller number of "early NACKers" will supersede the repair needs of the remainder of the group. The mean of the dis- tribution should be determined as a function of the current esti- mate of sender<->group greatest round trip time (GRTT) and a group size estimate which determined by other mechanisms within the pro- tocol (See section below) or preset by the multicast application. A simple algorithm can be constructed to generate random backoff timeouts with the appropriate distribution. Additionally, the algorithm may be designed to optimize the backoff distribution given the number of receivers (R) potentially generating feedback. This "optimization" minimizes the number of feedback messages (e.g. NACK) in the worst-case situation where all receivers generate a NACK. The maximum backoff timeout (T) can also be controlled to allow the application or protocol tradeoff NACK latency versus vol- ume of feedback traffic. A larger value of T will result in a lower density of feedback traffic for a given repair cycle. A smaller value of T results in shorter latency which reduces the buffering requirements of senders and receivers for reliable trans- port. Adamson, Bormann, et al. Expires January 2001 [Page 12] Internet Draft NORM Building Blocks July 2000 Given the receiver group size (R), and maximum allowed backoff timeout (T), a truncated exponential backoff timeout (t') can be picked with the following algorithm: 1) Establish an optimal mean (L) for the exponential backoff based on the group size: L = ln(R) + 1 2) Pick a random number (x) from a uniform distribution over a range of: L L L ---------------- to ---------------- + --- T * (exp(L) - 1) T * (exp(L) - 1) T 3) Transform this random variate to generate the desired random backoff time (t) with the following equation: t' = T/L * ln(x * (exp(L) - 1) * (T/L)) This is a C language function which can be used to perform this function: double RandomBackoff(double maxTime, double groupSize) { double lambda = log(groupSize) + 1; double x = UniformRand(lambda/maxTime) + lambda / (maxTime*(exp(lambda)-1)); return ((maxTime/lambda) * log(x*(exp(lambda)-1)*(maxTime/lambda))); } // end RandomBackoff() where UniformRand(double max) returns random numbers with a uniform distribution from the range of 0..max. For example, based on the POSIX "rand()" function, the following code can be used: double UniformRand(double max) { return (max * ((double)rand()/(double)RAND_MAX)); } The number of expected NACKs generated (N) within the first round trip time for a single loss event can be approximately expected to be: N = exp(1.2 * L / (2*T/GRTT)) Adamson, Bormann, et al. Expires January 2001 [Page 13] Internet Draft NORM Building Blocks July 2000 Thus the maximum backoff time (T) can be adjusted to tradeoff worst-case NACK feedback volume versus latency. This is derived from [Nonnenmacher98] and assumes T >= GRTT, and L is the mean of the distribution optimized for the given group size as shown in the algorithm above. Note that other mechanisms within protocol may work to reduce redundant NACK generation further. There are some secondary NACK suppression mechanisms which can also be considered. For example, the sender's transmissions may follow an ordinal sequence of transmission (observed through data/repair content 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 sender 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 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 sequence position. Adamson, Bormann, et al. Expires January 2001 [Page 14] Internet Draft NORM Building Blocks July 2000 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 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 receivers and senders and reduces redundant transmission of data to the group at large. Interface Description Inputs: 1) Receiver NACKs 1) Group timing information Adamson, Bormann, et al. Expires January 2001 [Page 15] Internet Draft NORM Building Blocks July 2000 Outputs: 1) Repair messages (FEC and/or Data content retransmission) 3.3 Group "Join" Policies/ Procedures Consideration should be given to how new receivers join a group (perhaps where reliable transmission is already in progress) and beging NACKing for any repair needs. If this is unconstrained, the dynamics of group membership may impede the application's ability to meet it goals progressing the transmission of data. Policies limiting the opportunities at which receivers begin participating in the NACK process may be used to achieve the desired behavior. For example, it may be beneficial if receivers only attempt reli- able reception from a newly-heard sender when upon non-repair transmissions of data in the first FEC block of an object or logi- cal portion of a stream. The sender may also implement policies limiting which receivers from which it will accept NACK requests, but this may be prohibitive for scalability reasons in some situa- tions. In some types of bulk transfer applications (and for poten- tial interactive applications), it may alternatively desirable to have a looser transport synchronization policy and rely upon ses- sion management mechanisms to control group dynamics which may result in poor behavior. 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 member identification In a NORM protocol (or other multicast protocols) where there is the potential for multiple sources of data, it is necessary to pro- vide some mechanism to uniquely identify the sources (and possibly some or all receivers in some cases) within the group. Identity based on arriving packet source addresses is insufficient for sev- eral 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 Adamson, Bormann, et al. Expires January 2001 [Page 16] Internet Draft NORM Building Blocks July 2000 session members. 3.5 Data content identification The data content transmitted by a NORM sender requires some form of identification in the protocol header fields. This identification is required to facilitate the reliable NACK-oriented repair pro- cess. These identifiers will be used in NACK messages generated. 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 inter- val. Note that it is _not_ expected that this data content identi- fication 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 and during the time that sender is supporting a specific transport instance of that object or stream. Adamson, Bormann, et al. Expires January 2001 [Page 17] Internet Draft NORM Building Blocks July 2000 Since the "bulk" object/stream content will generally require seg- mentation, some form of segment identification must also be provided. This segment identifier will be relative to any object or stream identifier which has been provided. Thus, in some cases, NORM protocol instantiations may be able to receive trans- missions and request repair for multiple streams and one or 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 individ- ual protocol instantiations. In summary, the following data content identifiers may be required for NORM protocol data content messages: 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. NORM 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 been iden- tified which can provide great performance enhancements to the repair process of NACK-oriented and other reliable multicast proto- cols [Metzner84, Macker97]. NORM protocols can reap additional benefits since FEC-based repair does not _generally_ require explicit knowledge of repair content within the bounds of its cod- ing 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 Adamson, Bormann, et al. Expires January 2001 [Page 18] Internet Draft NORM Building Blocks July 2000 nominal level of expected packet loss. While the application of FEC is not unique to NORM, these sorts of requirements may dictate the types of algorithms and protocol approaches which are applica- ble. A specific issue related to the use of FEC with NORM is the mecha- nism used to identify which portion(s) of transmitted data content to which specific FEC packets are applicable. It is expected that FEC algorithms will be based on generating a set of parity repair packets for a corresponding block of transmitted data packets. Since data content packets are uniquely identified by the concate- nation 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 identifier of the first segment of the block of data content packets for which the FEC repair packet is applicable and add an additional FEC iden- tifier field to its position 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 The measurement of packet propagation round-trip time (RTT) among members of the group is required to support NACK suppression algo- rithms, timing of sender commands or certain repair functions, and congestion control operation. The nature of the round-trip infor- mation collected is dependent upon the type of interaction among the members of the group. In the case where only "one-to-many" transmission is required, it may be necessary that only the sender require RTT knowledge of the greatest RTT (GRTT) among the receiver set and/or RTT knowledge of only a portion of the group. Here, the GRTT information might be collected in a reasonably scalable man- ner. For congestion control operation, it is possible that RTT information may be required by each receiver in the group. In this case, an alternative RTT collection scheme may be utilized where receivers collect individual RTT measurements with respect to the sender and advertise them (or an competed subset) to the group or sender. Where it is likely that exchange of reliable multicast data will occur among the group on a "many-to-many" basis, there are alternative measurement techniques which might be employed for increased efficiency [Ozdemir99]. And in some cases, there might be absolute time synchronization among hosts which may simplify RTT measurement. There are trade-offs in multicast congestion control design which need further consideration before a universal recom- mendation on RTT (or GRTT) measurement can be specified. Regard- less of how the RTT information is collected (and more specifically GRTT) with respect to congestion control or other requirements, the Adamson, Bormann, et al. Expires January 2001 [Page 19] Internet Draft NORM Building Blocks July 2000 sender will need to advertise its current GRTT estimate to the group for timing of the 3.7.1 One-to-Many Sender GRTT Measurement The goal of this form of RTT measurement is for the sender to learn the GRTT among the receivers who are actively participating in NORM operation. The set of receivers participating in this process may be the entire group or some subset of the group determined from another mechanism within the protocol instantiation. An approach to collect this GRTT information follows. The sender periodically polls the group with a message (independent or "piggy-backed" with other transmissions) containing a timestamp relative to an internal clock at the sender. Upon recep- tion of this message, the receivers will record this timestamp and the time (referenced to their own clocks) at which it was received . When the receiver provides feedback to the sender (either explicitly or as part of other feedback messages depending upon protocol instantion specification), it will con- struct a "response" using the formula: = + ( - ) where the is the timestamp from the last probe message received from the source and the ( - ) is the amount of time differential since that request was received until the receiver generated the response. The sender processes each receiver response by calculating a cur- rent RTT measurement for the receiver from whom the response was received using the following formula: = - During the each periodic GRTT probing interval, the source keeps the peak round trip estimate from the set of responses it has received. The GRTT estimate should be filtered to be conservative towards maintaining an estimate biased towards the greatest receiver RTT measurements received. A conservative estimate of GRTT maximizes the efficiency redundant NACK suppression and repair aggregation. The update to the source's ongoing estimate of GRTT is done observing the following rules: 1) If a receiver's response round trip calculation is greater than the current GRTT estimate AND current peak, the response value is immediately fed into the GRTT update fil- ter given below. In any case, the source records the "peak" Adamson, Bormann, et al. Expires January 2001 [Page 20] Internet Draft NORM Building Blocks July 2000 receiver RTT measurement for the current probe interval. 2) At the end of the response collection period (i.e. the GRTT probe interval), if the recorded "peak" response is less than the current GRTT estimate AND this is the third consec- utive collection period with a peak less than the current GRTT estimate the recorded peak is fed into the GRTT update. (Implicitly, Rule #1 was applied otherwise so no new update is required). 3) At the end of the response collection period, the peak tracking value is set to either ZERO if the "peak" is greater than or equal to the current GRTT estimate (i.e. Already incorporated into the filter under Rule #1) or kept the same if its value is less than the current GRTT estimate AND was not yet incorporated into the GRTT update filter according to Rule #2. Thus for decreases in the source's estimate of GRTT, the "peak" is tracked across three consec- utive probe intervals. The current MDP implementation uses the following GRTT update filter to incorporate new peak responses into the the GRTT estimate: if (peak > current_estimate) current_estimate = 0.25 * current_estimate + 0.75 * peak; else current_estimate = 0.75 * current_estimate + 0.25 * peak; This update method is biased towards maintaining an estimate of the worst-case round trip delay. The reason the GRTT estimate is reduced only after 3 consecutive collection periods with smaller response peaks is to be conservative where packet loss may have resulted in lost response messages. And then the reduction is additionally conservatively weighted using the averaging filter from above. The GRTT collection period (i.e. period of probe transmission) could be fixed at a value on the order of that expected for group membership and/or network topology dynamics. For robustness, more rapid probing could be used at protocol startup before settling to a less frequent, steady-state interval. Optionally, an algorithm may be developed to adjust the GRTT collection period dynamically in response to the current GRTT estimate (or variations in it) and to an estimation of packet loss. The overhead of probing messages could then be reduced when the GRTT estimate is stable and unchang- ing, but be adjusted to track more dynamically during periods of variation with correspondingly shorter GRTT collection periods. In summary, although NORM repair cycle timeouts are based on GRTT, Adamson, Bormann, et al. Expires January 2001 [Page 21] Internet Draft NORM Building Blocks July 2000 it should be noted that convergent operation of the protocol does not _strictly_ depend on accurate GRTT estimation. The current mechanism has proved sufficient in simulations and in the environ- ments in which NORM-like protocols have been deployed to date. The estimate provided by the algorithm tracks the peak envelope of actual GRTT (including operating system effect as well as network delays) even in relaitvely high loss connectivity. The steady- state probing/update interval may potentially be varied to accommo- date different levels of expected network dynamics in different environments. 3.7.2 One-to-Many Receiver RTT Measurement (TBD - Receivers "ping" sender for RTT measurement, and then receivers competitively (worst case RTT metric) advertise their measurements to the sender and optionally group so the sender can determine GRTT ... Sender should still robustly advertise its cur- rent GRTT knowledge to the group so group can use appropriate tim- ing) 3.7.3 Many-to-Many RTT Measurement (TBD - Describe approach based on Ozdemir99, if appropriate/appli- cable?) 3.7.4 Sender GRTT Advertisement To facilitate determistic NORM protocol operation, the sender should robustly advertise its current estimation of GRTT to the receiver set. Common, robust knowledge of the sender's current operating GRTT estimate among the group will allow the protocol to progress in its most efficient manner. The sender's GRTT estimate can be robustly advertised to the group by simply embedding the estimate into all pertinent messages transmitted by the sender. The overhead of this can be made quite small by quantizing (com- pressing) the GRTT estimate to a single byte of information. The following C-lanquage function algorithm allows this to be done over a wide range of GRTT values while maintaining a greater range of precision for small GRTT values and less precision for large val- ues: unsigned char QuantizeGrtt(double grtt) { if (grtt > 1.0e03) grtt = 1.0e03; else if (grtt < 1.0e-06) grtt = 1.0e-06; if (grtt < 3.3e-05) Adamson, Bormann, et al. Expires January 2001 [Page 22] Internet Draft NORM Building Blocks July 2000 return ((unsigned char)(grtt * 1.0e06) - 1); else return ((unsigned char)(ceil(255.0.- (13.0 * log(1.0e03/grtt))))); } Note that this function is useful for quantizing GRTT times in the range of 1 microsecond to 1000 seconds. Of course, NORM protocol implementations may wish to further constrain advertised GRTT esti- mates (e.g. limit the maximum value) for practical reasons. 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 statistics collection, session management, etc) 4.0 Security Considerations (TBD) 5.0 References [Mankin98] A. Mankin, A. Romanow, S. Bradner, V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Applica- tion 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 Adamson, Bormann, et al. Expires January 2001 [Page 23] Internet Draft NORM Building Blocks July 2000 Known Classes of Reliable Multicast Protocols", Proc. Interna- tional 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 multicast 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, October 1997. [Ozdemir99] V. Ozdemir, S. Muthukrishnan, I. Rhee, "Scalable, Low- Overhead Network Delay Estimation", NCSU/AT&T White Paper, February 1999. 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 Adamson, Bormann, et al. Expires January 2001 [Page 24] Internet Draft NORM Building Blocks July 2000 Carsten Bormann cabo@tellique.de Tellique Kommunikationstechnik GmbH Gustav-Meyer-Allee 25 Geb ude 12 D-13355 Berlin, 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, Bormann, et al. Expires January 2001 [Page 25] --============_-1247487947==_============-- >From owner-rmt@listserv.lbl.gov Mon Jul 31 10:53:23 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id KAA24199; Mon, 31 Jul 2000 10:51:05 -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 KAA24189 for ; Mon, 31 Jul 2000 10:50: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 KAA19608 for ; Mon, 31 Jul 2000 10:50:52 -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 KAA19559 for ; Mon, 31 Jul 2000 10:50:47 -0700 (PDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 31 Jul 2000 18:50:43 +0100 to: rmt@lbl.gov Subject: NACK comment... Date: Mon, 31 Jul 2000 18:50:42 +0100 Message-ID: <13272.965065842@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk In message , Brian Adamson typed: comment on NACK protocols and advance with Time windows (e.g. PGM) its sometimes nice if there's not only a NACK (and a NACK confirm) but also a NACK reject, so that both sender and receiver are synchronised on their view of the data failure at about the same point in the stream (i.e. for appllciations that are based on synchronouse messageing style repliaction - e.g. highly avaialble transaction servers)..... it also has API issues (you need an error return or exception or event/message at both sender AND receiver at the right point - like TCP oob data, only not:-) cheers jon >From owner-rmt@listserv.lbl.gov Mon Jul 31 12:30:43 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id MAA24757; Mon, 31 Jul 2000 12:29:54 -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 MAA24753 for ; Mon, 31 Jul 2000 12:29:52 -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 MAA22346 for ; Mon, 31 Jul 2000 12:29:51 -0700 (PDT) Received: from sammy.tibco.com (sammy.tibco.com [192.216.111.146]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA22341 for ; Mon, 31 Jul 2000 12:29:50 -0700 (PDT) Received: from osgood.tibco.com (osgood.tibco.com [160.101.240.42]) by sammy.tibco.com (8.9.3/8.9.3) with ESMTP id MAA20341 for ; Mon, 31 Jul 2000 12:29:19 -0700 (PDT) Received: from venus.tibco.com (venus.tibco.com [160.101.240.40]) by osgood.tibco.com (8.9.3/8.9.3) with ESMTP id MAA03200 for ; Mon, 31 Jul 2000 12:32:45 -0700 (PDT) Received: from tibco.com ([160.101.95.124]) by venus.tibco.com (Netscape Messaging Server 3.6) with ESMTP id AAA4A60 for ; Mon, 31 Jul 2000 12:29:18 -0700 Message-ID: <3985D38E.2B0A3E95@tibco.com> Date: Mon, 31 Jul 2000 12:29:18 -0700 From: "Dan Leshchiner" X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rmt@lbl.gov Subject: Re: NACK comment... References: <13272.965065842@cs.ucl.ac.uk> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk in PGM this can be done by sending SPM -- trailing edge sequence number would be greater than NAK'ed seqno. Jon Crowcroft wrote: > > In message , Brian Adamson typed: > > comment on NACK protocols and advance with Time windows (e.g. PGM) > > its sometimes nice if there's not only a NACK (and a NACK confirm) but > also a NACK reject, so that both sender and receiver are synchronised > on their view of the data failure at about the same point in the > stream (i.e. for appllciations that are based on synchronouse > messageing style repliaction - e.g. highly avaialble transaction > servers)..... > > it also has API issues (you need an error return or exception or > event/message at both sender AND receiver at the right point - like > TCP oob data, only not:-) > > cheers > jon >From owner-rmt@listserv.lbl.gov Thu Aug 3 05:40:43 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id FAA07057; Thu, 3 Aug 2000 05:36:08 -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 FAA07053 for ; Thu, 3 Aug 2000 05:36: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 FAA12497 for ; Thu, 3 Aug 2000 05:36:05 -0700 (PDT) Received: from violin.dcs.uky.edu (violin.dcs.uky.edu [204.198.75.11]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA12494 for ; Thu, 3 Aug 2000 05:36:04 -0700 (PDT) Received: from gladstone.dcs.uky.edu (gladstone.dcs.uky.edu [204.198.75.142]) by violin.dcs.uky.edu (8.9.1a/8.9.1) with ESMTP id IAA00659; Thu, 3 Aug 2000 08:36:02 -0400 (EDT) Received: from localhost (calvert@localhost) by gladstone.dcs.uky.edu (8.9.1a/8.9.1) with ESMTP id IAA16386; Thu, 3 Aug 2000 08:36:02 -0400 (EDT) X-Authentication-Warning: gladstone.dcs.uky.edu: calvert owned process doing -bs Date: Thu, 3 Aug 2000 08:36:02 -0400 (EDT) From: Ken Calvert To: rmt@lbl.gov cc: griff@dcs.uky.edu Subject: concast Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rmt@lbl.gov Precedence: bulk [I sent a similar message to the rm list earlier in the week, but it appears not to have made it out.] Folks, We'd like to call your attention to draft-calvert-concast-svc-00.txt, which describes the concast many-to-one service. After looking over the current drafts and hearing the presentations earlier this week, it appears that Concast would make a good RM building block. It is useful for aggregation of feedback, both ack/nack and congestion-related. We'd appreciate any comments. The draft describes the service independent of RM, because it is also useful outside the context of multicast. Cheers, KC -- Ken Calvert calvert@dcs.uky.edu Associate Professor ***************NOTE NEW AREA CODE = 859 Computer Science, 773 Anderson Hall +1.859.257.6745 University of Kentucky Fax: +1.859.323.1971 Lexington, KY 40506-0046 http://www.cs.uky.edu/~calvert/ >From owner-rmt@listserv.lbl.gov Thu Aug 3 07:42:55 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id HAA08106; Thu, 3 Aug 2000 07:40:59 -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 HAA08102 for ; Thu, 3 Aug 2000 07:40:57 -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 HAA27850 for ; Thu, 3 Aug 2000 07:40:56 -0700 (PDT) Received: from nilla.aciri.org (wireless-132-79.ietf.marconi.com [147.73.132.79]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA27835 for ; Thu, 3 Aug 2000 07:40:55 -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 IAA01451; Thu, 3 Aug 2000 08:10:40 -0700 (PDT) (envelope-from mjh@nilla.aciri.org) Message-Id: <200008031510.IAA01451@nilla.aciri.org> From: Mark Handley X-Organisation: ACIRI To: Ken Calvert cc: rmt@lbl.gov Subject: Re: concast In-reply-to: Your message of "Thu, 03 Aug 2000 08:36:02 EDT." Date: Thu, 03 Aug 2000 08:10:40 -0700 Sender: owner-rmt@lbl.gov Precedence: bulk >[I sent a similar message to the rm list earlier in the week, but it >appears not to have made it out.] I received it. If anyone is on both lists, and didn't get both copies, please let me know, so I can figure out if there's a problem with the mail server that handles the rm list. Cheers, Mark >From owner-rmt@listserv.lbl.gov Thu Aug 3 09:36:35 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id JAA08936; Thu, 3 Aug 2000 09:34:49 -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 JAA08932 for ; Thu, 3 Aug 2000 09:34:47 -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 JAA28496 for ; Thu, 3 Aug 2000 09:34:46 -0700 (PDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA28491 for ; Thu, 3 Aug 2000 09:34:46 -0700 (PDT) Received: from localhost (lorenzo@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA26174; Thu, 3 Aug 2000 09:33:46 -0700 (PDT) Message-Id: <200008031633.JAA26174@omega.cisco.com> To: Ken Calvert cc: rmt@lbl.gov Subject: Re: concast In-Reply-To: Your message of "Thu, 03 Aug 2000 08:36:02 EDT." Date: Thu, 03 Aug 2000 09:33:46 -0700 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk Ken, Your work seems to be very relevant to the chater of this WG in the context of GRA (see draft-ietf-rmt-gra-arch-01.txt). You might want to contact the authors of this draft and see if you can coordinate your effort with theirs. cheers, Lorenzo > We'd like to call your attention to draft-calvert-concast-svc-00.txt, > which describes the concast many-to-one service. After looking over the > current drafts and hearing the presentations earlier this week, it appears > that Concast would make a good RM building block. It is useful for > aggregation of feedback, both ack/nack and congestion-related. > > We'd appreciate any comments. The draft describes the service independent > of RM, because it is also useful outside the context of multicast. > > Cheers, > > KC > -- > Ken Calvert calvert@dcs.uky.edu > Associate Professor ***************NOTE NEW AREA CODE = 859 > Computer Science, 773 Anderson Hall +1.859.257.6745 > University of Kentucky Fax: +1.859.323.1971 > Lexington, KY 40506-0046 http://www.cs.uky.edu/~calvert/ > > >From owner-rmt@listserv.lbl.gov Fri Aug 11 04:05:50 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id EAA02848; Fri, 11 Aug 2000 04:02:05 -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 EAA02840 for ; Fri, 11 Aug 2000 04:02:02 -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 EAA23092 for ; Fri, 11 Aug 2000 04:02:01 -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 EAA23087 for ; Fri, 11 Aug 2000 04:02: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 HAA08886; Fri, 11 Aug 2000 07:01:59 -0400 (EDT) Message-Id: <200008111101.HAA08886@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-norm-bb-00.txt Date: Fri, 11 Aug 2000 07:01:58 -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 : NACK-Oriented Reliable Multicast (NORM) Protocol Building Blocks Author(s) : B. Adamson, C. Bormann, S. Floyd, M. Handley, J. Macker Filename : draft-ietf-rmt-norm-bb-00.txt Pages : 25 Date : 10-Aug-00 This memo describes issues related to the creation of negative- acknowledgment (NACK) oriented reliable multicast (NORM) protocols. The general goals and assumptions for NORM are defined. The tech- nical challenges related to NACK-oriented (and in some cases gen- eral) reliable multicast protocol design are identified. These challenges are resolved into a set of applicable 'building blocks' which are described in further detail. It is anticipated that these building blocks (as they are further refined and defined in future revisions of this document) will be useful in generating different instantiations of reliable multicast protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-norm-bb-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-norm-bb-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-norm-bb-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: <20000810140221.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-norm-bb-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-norm-bb-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000810140221.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Fri Aug 11 07:07:24 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id HAA29896; Fri, 11 Aug 2000 07:05:28 -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 HAA29842 for ; Fri, 11 Aug 2000 07:05:24 -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 HAA07501 for ; Fri, 11 Aug 2000 07:05:23 -0700 (PDT) Received: from picard.noroff.no ([212.20.204.3]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA07491 for ; Fri, 11 Aug 2000 07:05:22 -0700 (PDT) Received: by picard.noroff.no (Postfix, from userid 815) id 1376122002; Fri, 11 Aug 2000 16:49:40 +0200 (CEST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by picard.noroff.no (Postfix) with ESMTP id BCECAB3802 for ; Fri, 11 Aug 2000 16:49:37 +0200 (CEST) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA11482 for ietf-123-outbound.09@ietf.org; Fri, 11 Aug 2000 09:25:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA10105 for ; Fri, 11 Aug 2000 07:01:59 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08886; Fri, 11 Aug 2000 07:01:59 -0400 (EDT) Message-Id: <200008111101.HAA08886@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-norm-bb-00.txt Date: Fri, 11 Aug 2000 07:01:58 -0400 X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2 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 : NACK-Oriented Reliable Multicast (NORM) Protocol Building Blocks Author(s) : B. Adamson, C. Bormann, S. Floyd, M. Handley, J. Macker Filename : draft-ietf-rmt-norm-bb-00.txt Pages : 25 Date : 10-Aug-00 This memo describes issues related to the creation of negative- acknowledgment (NACK) oriented reliable multicast (NORM) protocols. The general goals and assumptions for NORM are defined. The tech- nical challenges related to NACK-oriented (and in some cases gen- eral) reliable multicast protocol design are identified. These challenges are resolved into a set of applicable 'building blocks' which are described in further detail. It is anticipated that these building blocks (as they are further refined and defined in future revisions of this document) will be useful in generating different instantiations of reliable multicast protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-norm-bb-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-norm-bb-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-norm-bb-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: <20000810140221.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-norm-bb-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-norm-bb-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000810140221.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Tue Aug 15 17:45:53 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id RAA24015; Tue, 15 Aug 2000 17:42: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 RAA24011 for ; Tue, 15 Aug 2000 17:42:28 -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 RAA09591 for ; Tue, 15 Aug 2000 17:42:27 -0700 (PDT) Received: from tech.cisco.com (tech.cisco.com [161.44.224.17]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA09588 for ; Tue, 15 Aug 2000 17:42:27 -0700 (PDT) Received: from ORANLT ([171.71.147.155]) by tech.cisco.com (Netscape Messaging Server 3.61) with SMTP id AAA5CAB for ; Tue, 15 Aug 2000 20:42:42 -0400 From: "Dave Oran" To: Subject: FW: Adding reliable transport layer above sgm/xcsat Date: Tue, 15 Aug 2000 20:41:54 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-rmt@lbl.gov Precedence: bulk -----Original Message----- From: owner-xcast@public.alcatel.com [mailto:owner-xcast@public.alcatel.com]On Behalf Of Tal Anker Sent: Tuesday, August 15, 2000 7:27 AM To: xcast@public.alcatel.com Cc: dolev@cs.huji.ac.il Subject: Adding reliable transport layer above sgm/xcsat Hi, We would like to share some thoughts on the benefit from the xcast model (or sgm) to small group multicast applications. In particular, we have been playing with reliable multicast transport layers in the last few years. A reliable transport for small group multicast may not be important for video conference application, but for other collaborative application such as shared editor or shared drawing board (whiteboard) it may be very usefull. Since the reliable multicast working group concentrate (for now) on one-to-many within the SSM architecture, this issue may fit to this working group. To trigger a discussion, we have comprised a list of issues that come up when implementing reliale transport layer for multicast: 1) Fault detection - in xcast this is pretty simple to handle. In large groups, the need to probe for liveness of every member is a problem for the scalability proporty. In xcast, it becomes much simple to handle. For instance every source can "ping" the liveness of all the receivers in the members list, which leads us to the next item: 2) Dynamic Group Membership - In xcast every source is requested to know the members list apriori. In general, learning the potential group of members is a chalange. Special challange is the aggreement on the "view" of the group - i.e., aggreement on the active members list. In xcast, leader based or token based algorithms can be easily used. 3) Messages ordering - This is a problem that was discussed in various forums and communities. Ordering is an important property for various applications, such as distributed database applications or shared whiteboards, etc. Typicall applications in xcast may not require a full fledge database consistency requirements, but will certainly benefit from various ordering properties. In particular, consider a shared editor or whiteboard that a small group of participants use. Consider scenarios where someone deletes an object fron the drawing board, and another is moving the object around. An ordering property (such as Total ordering) can resolve these conflicts relatiely easily. We think that the xcast model alleviates the deployments of ordering algorithms. For instance, logical "token based" algorithms or leader based algorithms are very feasible for implementation in the xcast model. 4) Buffering messages for retransmissions: When the group is small, there is no real prolem in "saving" messages for later retransmissions. This may not be nessary for video conferencing, but wheh the conference is coupled with shared text editor or shared drawing board, the two latter applications are sure to benefit from this kind of reliability. 5) Flow control for small group multicast: We think that flow control for small groups is a much easier problem to solve. For instance, one can even think on maintaining a sliding window per receiver (from the source point of view). 6) Handling leave/join of members: When a new member joins the group, the fact that the group is of small size makes it easier to build a "digest" of the group state and transferring this digest to the newcomer. The convergence of the group membership changes is much faster. 7) handling network partitions/merges: In case there is a link that has failed, some of the group members may be temporary partitioned. This calls for the reliability layer to adapt to such cases, and do not try and attempt recovering/retransmitting messages that were sent within each partition. This is a sort of a "can of worms" and is heavily discusses within the area of Group Communication Systems. We suggest to put it away at this time. In any case, in small groups there is a high chance that a sort of temporary "relays" can be constructed within the period of partition. These relays are point-to-point communication channels that can bridge accross partiotions (given that logical transitivity exist). Comments? opinions? anything :) ? Danny & Tal ===================================== Institute of Computer Science The Hebrew University of Jerusalem, Givat Ram, Jerusalem 91904 Israel >From owner-rmt@listserv.lbl.gov Tue Aug 15 18:15:34 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id SAA24053; Tue, 15 Aug 2000 18:13: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 SAA24049 for ; Tue, 15 Aug 2000 18:13:45 -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 SAA14098 for ; Tue, 15 Aug 2000 18:13:45 -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 SAA14095 for ; Tue, 15 Aug 2000 18:13:45 -0700 (PDT) Received: from aardvark.aciri.org (localhost [127.0.0.1]) by aardvark.aciri.org (8.9.3/8.9.3) with ESMTP id SAA46797; Tue, 15 Aug 2000 18:13:38 -0700 (PDT) (envelope-from mjh@aardvark.aciri.org) From: Mark Handley X-Organisation: ACIRI To: "Dave Oran" cc: rmt@lbl.gov Subject: Re: FW: Adding reliable transport layer above sgm/xcsat In-reply-to: Your message of "Tue, 15 Aug 2000 20:41:54 EDT." Date: Tue, 15 Aug 2000 18:13:38 -0700 Message-ID: <46795.966388418@aardvark.aciri.org> Sender: owner-rmt@lbl.gov Precedence: bulk The advantages they state seem to apply to any small group, whether based on SGM, Internet Standard multicast or SSM. I don't see how SGM helps. Also not all RM protocols need to know who the receivers are. (e.g. digital fountain approaches don't care who the receivers are) Requiring the sender to know who the receivers are is therefore an impediment, not an advantage. The advantages of SGM (if any) do not seem to be at the transport/application layer to me. The one exception might be the very limited security gain you get by having slightly more control over who receives the traffic. However IMHO such security gain is a poor substitute for decent encryption. Cheers, Mark >-----Original Message----- >From: owner-xcast@public.alcatel.com >[mailto:owner-xcast@public.alcatel.com]On Behalf Of Tal Anker >Sent: Tuesday, August 15, 2000 7:27 AM >To: xcast@public.alcatel.com >Cc: dolev@cs.huji.ac.il >Subject: Adding reliable transport layer above sgm/xcsat > > > >Hi, > >We would like to share some thoughts on the benefit from the xcast >model (or sgm) to small group multicast applications. In particular, >we have been playing with reliable multicast transport layers in the >last few years. A reliable transport for small group multicast may not >be important for video conference application, but for other >collaborative application such as shared editor or shared drawing >board (whiteboard) it may be very usefull. Since the reliable >multicast working group concentrate (for now) on one-to-many within >the SSM architecture, this issue may fit to this >working group. > >To trigger a discussion, we have comprised a list of issues that come up >when implementing reliale transport layer for multicast: > >1) Fault detection - in xcast this is pretty simple to handle. In >large groups, the need to probe for liveness of every member is a >problem for the scalability proporty. In xcast, it becomes much simple >to handle. For instance every source can "ping" the liveness of all >the receivers in the members list, which leads us to the next item: > >2) Dynamic Group Membership - In xcast every source is requested to >know the members list apriori. In general, learning the potential >group of members is a chalange. Special challange is the aggreement on >the "view" of the group - i.e., aggreement on the active members list. >In xcast, leader based or token based algorithms can be easily used. > >3) Messages ordering - This is a problem that was discussed in various >forums and communities. Ordering is an important property for various >applications, such as distributed database applications or shared >whiteboards, etc. Typicall applications in xcast may not require a >full fledge database consistency requirements, but will certainly >benefit from various ordering properties. In particular, consider a >shared editor or whiteboard that a small group of participants >use. Consider scenarios where someone deletes an object fron the >drawing board, and another is moving the object around. An ordering >property (such as Total ordering) can resolve these conflicts >relatiely easily. We think that the xcast model alleviates the >deployments of ordering algorithms. For instance, logical "token based" >algorithms or leader based algorithms are very feasible for >implementation in the xcast model. > >4) Buffering messages for retransmissions: When the group is small, >there is no real prolem in "saving" messages for later >retransmissions. This may not be nessary for video conferencing, but >wheh the conference is coupled with shared text editor or shared >drawing board, the two latter applications are sure to benefit from >this kind of reliability. > >5) Flow control for small group multicast: We think that flow control >for small groups is a much easier problem to solve. For instance, one >can even think on maintaining a sliding window per receiver (from the >source point of view). > >6) Handling leave/join of members: When a new member joins the group, >the fact that the group is of small size makes it easier to build a >"digest" of the group state and transferring this digest to the >newcomer. The convergence of the group membership changes is much >faster. > >7) handling network partitions/merges: In case there is a link that >has failed, some of the group members may be temporary >partitioned. This calls for the reliability layer to adapt to such >cases, and do not try and attempt recovering/retransmitting messages >that were sent within each partition. This is a sort of a "can of >worms" and is heavily discusses within the area of Group Communication >Systems. We suggest to put it away at this time. In any case, in small >groups there is a high chance that a sort of temporary "relays" can be >constructed within the period of partition. These relays are >point-to-point communication channels that can bridge accross >partiotions (given that logical transitivity exist). > >Comments? opinions? anything :) ? > >Danny & Tal > >===================================== >Institute of Computer Science >The Hebrew University of Jerusalem, >Givat Ram, Jerusalem 91904 >Israel > > >From owner-rmt@listserv.lbl.gov Wed Aug 16 01:20:22 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id BAA24726; Wed, 16 Aug 2000 01:18:15 -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 BAA24722 for ; Wed, 16 Aug 2000 01:18:14 -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 BAA16839 for ; Wed, 16 Aug 2000 01:18:13 -0700 (PDT) Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.10]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA16831 for ; Wed, 16 Aug 2000 01:18:07 -0700 (PDT) Received: from haserver.cs.huji.ac.il ([132.65.200.200] ident=exim) by cs.huji.ac.il with esmtp (Exim 3.15 #1) id 13OyOY-0004ME-00; Wed, 16 Aug 2000 11:17:54 +0300 Received: from anker by haserver.cs.huji.ac.il with local (Exim 3.15 #1) id 13OyOX-0001fM-00; Wed, 16 Aug 2000 11:17:53 +0300 Date: Wed, 16 Aug 2000 11:17:53 +0300 (IDT) From: Tal Anker To: Mark Handley cc: Dave Oran , rmt@lbl.gov, xcast@public.alcatel.com, dolev@cs.huji.ac.il Subject: Re: FW: Adding reliable transport layer above sgm/xcsat In-Reply-To: <46795.966388418@aardvark.aciri.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rmt@lbl.gov Precedence: bulk On Tue, 15 Aug 2000, Mark Handley wrote: > > The advantages they state seem to apply to any small group, whether > based on SGM, Internet Standard multicast or SSM.I don't see how SGM > helps. That is almost correct with one thing different (you already said it bellow): there is more control on who are the receivers that receives the traffic. There are many reliable multicast "flavors", and to some of them the membership (of receivers and sources) is important. When the membership is known, it is much easier to give stronger semantics to the user application, e.g., to guarantee that ALL the messages will be delivered to ALL the alive receivers. This is obviously requires failure detector (in the transport layer) in order to declare a receiver "faulty" and thus enable the progression within the group (otherwise, the source might get stuck and wait for acks from a faulty receiver). These kind of protocols make it easier to build shared whiteboard/editor, where the consistency of the object that is shared is important. - Tal. > > Also not all RM protocols need to know who the receivers are. > (e.g. digital fountain approaches don't care who the receivers are) > Requiring the sender to know who the receivers are is therefore an > impediment, not an advantage. > > The advantages of SGM (if any) do not seem to be at the > transport/application layer to me.The one exception might be the > very limited security gain you get by having slightly more control > over who receives the traffic.However IMHO such security gain is a > poor substitute for decent encryption. > > Cheers, > Mark > > > >From owner-rmt@listserv.lbl.gov Thu Aug 17 10:18:29 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id KAA03017; Thu, 17 Aug 2000 10:14:58 -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 KAA03013 for ; Thu, 17 Aug 2000 10:14:56 -0700 (PDT) From: announce@leisurewebcams.com Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA12493 for ; Thu, 17 Aug 2000 10:14:54 -0700 (PDT) Received: from mail.yourdomain.com (m319-mp1-cvx1a.man.ntl.com [62.252.197.63]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id KAA12468 for ; Thu, 17 Aug 2000 10:14:51 -0700 (PDT) Message-Id: <200008171714.KAA12468@SpamWall.lbl.gov> Date: Thu, 17 Aug 2000 14:39:06 To: Subject: LeisureWebcams.com - See the World Sender: owner-rmt@lbl.gov Precedence: bulk LeisureWebcams.com is a recently launched website specialising in providing free LIVE access to over 1,500 webcams and 2,000 Tourist Offices world wide. Check it out:- http://www.leisurewebcams.com/ This offers you the chance to check out live and frequently updated images of your chosen location through the webcams and get detailed local knowledge through the Tourist Offices. Along with booking holidays direct through our travel partner, there is the opportunity to sell your unwanted clothes and equipment through our free Swap Shop. There is a lot to see, so if you have enjoyed your trip through our site, do tell your friends and let us know through 'Your Views'. If you have any suggestions for the site, or queries, please feel free to contact me at cy@LeisureWebcams.com. I look forward to hearing from you. Kind regards, Charlie Yates MARKETING DIRECTOR LeisureWebcams.com >From owner-rmt@listserv.lbl.gov Fri Aug 18 09:41:04 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id JAA18194; Fri, 18 Aug 2000 09:37: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 JAA18190 for ; Fri, 18 Aug 2000 09:37: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 JAA25942 for ; Fri, 18 Aug 2000 09:37:11 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA25937 for ; Fri, 18 Aug 2000 09:37:11 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA25974; Fri, 18 Aug 2000 09:37:07 -0700 (PDT) Message-Id: <200008181637.JAA25974@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2887 on Multicast Design Space for Bulk Data Transfer Cc: rfc-ed@ISI.EDU, rmt@lbl.gov Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 18 Aug 2000 09:37:07 -0700 From: RFC Editor Sender: owner-rmt@lbl.gov Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2887 Title: The Reliable Multicast Design Space for Bulk Data Transfer Author(s): M. Handley, S. Floyd, B. Whetten, R. Kermode, L. Vicisano, M. Luby Status: Informational Date: August 2000 Mailbox: mjh@aciri.org, floyd@aciri.org, whetten@talarian.com, Roger.Kermode@motorola.com, lorenzo@cisco.com, luby@digitalfountain.com Pages: 22 Characters: 51135 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-rmt-design-space-01.txt URL: ftp://ftp.isi.edu/in-notes/rfc2887.txt 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. This document is a product of the Reliable Multicast Transport Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000818093455.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2887 --OtherAccess Content-Type: Message/External-body; name="rfc2887.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000818093455.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Tue Aug 22 04:34:44 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id EAA04811; Tue, 22 Aug 2000 04:31: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 EAA04807 for ; Tue, 22 Aug 2000 04:31: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 EAA29513 for ; Tue, 22 Aug 2000 04:31:14 -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 EAA29510 for ; Tue, 22 Aug 2000 04:31:13 -0700 (PDT) Received: [from pobox3.mot.com ([10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id EAA15759 for ; Tue, 22 Aug 2000 04:31:12 -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 EAA03759 for ; Tue, 22 Aug 2000 04:30:18 -0700 (MST)] Received: from arc.corp.mot.com ([217.2.31.199]) by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id e7MBV8s23311 for ; Tue, 22 Aug 2000 21:31:09 +1000 (EST) Message-ID: <39A26474.7623C9D2@arc.corp.mot.com> Date: Tue, 22 Aug 2000 21:31:00 +1000 From: Roger Kermode Reply-To: Roger.Kermode@motorola.com Organization: Motorola X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: RMT Slides... Content-Type: multipart/mixed; boundary="------------DCD90943EAD0A24B08893E73" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------DCD90943EAD0A24B08893E73 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear RMT Pittsburgh Presenters, if you have not yet submitted your slides for inclusion in the IETF proceedings please do so by sending them to minutes@ietf.org. thanks! Roger --------------DCD90943EAD0A24B08893E73 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 --------------DCD90943EAD0A24B08893E73-- >From owner-rmt@listserv.lbl.gov Sun Aug 27 11:04:59 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id LAA24975; Sun, 27 Aug 2000 11:00:58 -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 LAA24971 for ; Sun, 27 Aug 2000 11:00:56 -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 LAA22971 for ; Sun, 27 Aug 2000 11:00:55 -0700 (PDT) Received: from tech.cisco.com (tech.cisco.com [161.44.224.17]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA22963 for ; Sun, 27 Aug 2000 11:00:54 -0700 (PDT) Received: from ORANLT ([171.69.210.12]) by tech.cisco.com (Netscape Messaging Server 3.61) with SMTP id AAA2C0F; Sun, 27 Aug 2000 14:01:14 -0400 From: "Dave Oran" To: Cc: , Subject: RE: Adding reliable transport layer above sgm/xcsat Date: Sun, 27 Aug 2000 14:00:20 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <85256944.0065FD30.00@d54mta04.raleigh.ibm.com> Sender: owner-rmt@lbl.gov Precedence: bulk My knowledge of reliable multicast is spotty at best, so I wade in here with some trepidation. Since this is a side issue wrt SGM, feel free to drop this thread at any point. I just want to make sure that any claims are supportable with analysis or hard facts. See below. > -----Original Message----- > From: rhboivie@us.ibm.com [mailto:rhboivie@us.ibm.com] > Sent: Wednesday, August 23, 2000 2:34 PM > To: Dave Oran > Cc: xcast@public.alcatel.com > Subject: RE: FW: FW: Adding reliable transport layer above sgm/xcsat > > > > > >> > > >> > The advantages they state seem to apply to any small group, whether > >> > based on SGM, Internet Standard multicast or SSM. I don't > see how SGM > >> > helps. > >> > >> It is not true that the advantages apply to any small group. The > >> distinguishing characteristic of SGM is that it can easily send to a > >> subset of the destinations, which makes things like reliability and > >> congestion control easier. > >> > >I'm not sure this dicussion is getting us anywhere, but I don't follow > >Dirk's contention that having explicitly-addressed subsets of the group > >helps in any substantial way for congestion control or reliability. An > >explanation might help. > > The explicit list of addresses helps with respect to reliability in > a couple of ways. > - you know the address(es) at the other end which is helpful if > you want to implement "end-to-end" reliability In order to have any sort of end-to-end reliability, you either use FEC or feedback to the transmitter. In the case of FEC the transmitter never finds out (or needs to find out) who the receiver(s) is/are. In the case of feedback, the feedback contains the (unicast) source address of the receiver and hence you can target retransmissions via unicast if need be. > - it's easy with SGM to send "appropriate" retransmissions when > retransmissions are needed. ie you can send an SGM packet to > the subset of destinations that have not acked, say, or to the > subset that have nacked, say, and the retransmission is "optimal" > in terms of the network bandwidth consumed. Well, if you use ACKs/NAKs then the main problem is the number of ACKs/NAKs, right? That's why nearly all rmt schemes use some form of ACK/NAK elimination to avoid implosion. There may be some savings if you use explicit multicast addressing for the retransmissions, but that savings depends sensitively on where the losses occur (the closer to the source, the better you do, I suppose). There is also the problem with estimating the RTT, and hence tuning the retransmission scheme, which I don't think explicit multicast doesn't helps with at all. If you don't have the timers tuned you will wind up with multiple retransmissions to different subsets and hence may have even less gain over multi-unicast, or pure multicast. > - the routers don't have to do much to support reliable SGM (ie > they don't have to do anything other than support unreliable SGM) Well, that's true of some of the RMT schemes as well. For schemes that do have router state, the difference is that with RMT the router state is viewed as optimizations and the sources don't have to get involved in figuring out the optimal strategy. > - i.e. they don't have to keep track of multicast group > state and they don't have to do retransmissions > (since reliability would be end-to-end) Some schemes have routers only holding protocol state and not data state and hence the routers don't actually do any retransmissions. Note that reliability is still end-to-end because the router state is used only as an optimization. > - the routers don't have to build special multicast trees > when a source needs to send a retransmission to a subset > of the destinations. (The tree for the retransmission > is built (as is always the case in SGM) "on the fly" as > the packet flows from the source to the destinations.) > I do not believe I know of schemes which build special trees. Some schemes are smart and prune the existing tree to the subtree needed to cover the receivers which need the retransmission, but this is not a tree computation. > Of course the fact that the groups are "small" is also helpful. > Right. The question again is whether there is any gain compared to "rmt classic" *for groups of identical size*. Has anyone actually done any analysis or simulation? Some of these properties are anti-intuitive and need hard justification. > re: congestion control, if you have end-to-end awareness (as you have > in SGM) you can implement end-to-end congestion control. And the > fact that you can easily send to a subset helps too as Dirk mentioned. > I think I disagree with this, but I'm on REALLY shaky ground here so please correct me as needed. The reason congestion control is hard for multicast in general (and RMT in particular) is because you don't know where the bottlenecks are relative to the delivery tree and because each receiver is seeing a potentially different congestion environment. As long as the source is going to try to get one packet to multiple destinations, no matter how it does so, this fact doesn't change. > You said you're "not sure this discussion is getting us anywhere". > Well it has brought out certain points such as the fact that if one > is using "conference bridges", it seems more appropriate to use > SGM than "classical multicast" as Yuji has explained in his note. > I don't know at all how you got there. I didn't respond to Yuji's note because I assumed he was just pointing out that if you did (audio) conference bridges with SGM, that would win over multi-unicast. If you factor out the group-state-in-the-routers, the optimal strategy is each source unicasting to the bridge, and the bridge unicasting back to the active sources (since each sees a unique mix), and multicasting to the non-active sources. Since any even half-way rational conference only has multiple simultaneous talkers for a brief back-off period, I don't see how you can do better than normal multicast from the bridge to the receivers. There are also hybrid techniques which I won't go into that optimize the multicast case further. > On the larger point of making progress, I'm ok with either of the > problem statements that you proposed for the working group in a note > a little while back. (If I had to choose I mightly lean slightly > toward the first one.) > And I haven't heard any feedback to the contrary so perhaps we should > formally kick off an effort to address one or both of those problem > statements. > I'm going to call the question at the end of the coming week. > Is there any reason why we shouldn't? > Yes. I think the jury is still out. I'd really like to hear from a wider audience than we've been hearing from. Dave. > > > >From owner-rmt@listserv.lbl.gov Mon Aug 28 12:34:47 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id MAA28697; Mon, 28 Aug 2000 12:31: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 MAA28693 for ; Mon, 28 Aug 2000 12:30: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 MAA08248 for ; Mon, 28 Aug 2000 12:30:58 -0700 (PDT) Received: from computer (209-128-164-153.dial-up.ipa.net [209.128.164.153]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id MAA08103 for ; Mon, 28 Aug 2000 12:30:39 -0700 (PDT) Message-Id: <200008281930.MAA08103@SpamWall.lbl.gov> From: "Lloyd Gibson" To: Subject: Secrets of New Millonaires Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 28 Aug 2000 14:31:14 Sender: owner-rmt@lbl.gov Precedence: bulk Secrets of New Millonaires > > > > > > ----- Original Message ----- > > From: "Tom Anderson" > > To: > > Sent: Thursday, June 22, 2000 2:19 PM > > Subject: Fwd: Secrets of New Millionaires > > > > > > > > > > > > > > > > >From: "Lloyd Gibson" > > > >To: billa30@hotmail.com > > > >Subject: Fwd: Secrets of New Millionaires > > > >Date: Wed, 14 Jun 2000 13:04:28 CDT > > > > > > > > > > > > > > > > > > > >>From: > > > >>Subject: Secrets of New Millionaires > > > >>Date: Wed, 26 Apr 2000 02:47:02 > > > >>Received: from [4.3.96.183] by hotmail.com (3.2) with ESMTP id > > > >>MHotMailBAD01C76007BD82197D4040360B709610; Wed Apr 26 04:22:35 2000 > > > >>From webfinderz00@Yahoo.com Wed Apr 26 04:26:05 2000 > > > >>Message-Id: <331.824584.698332@server> > > > >> > > > >>Dear Friend, > > > >> > > > >>You can earn $50,000 or more in the next 90 days > > > >>sending e-mail. > > > >> > > > >> Seem impossible? Read on for details. > > > >> > > > >> "AS SEEN ON NATIONAL TV" > > > >> > > > >> Thank you for your time and interest. This is the > > > >>letter you've been reading about in the news lately. > > > >>Due to the popularity of this letter on the Internet, > > > >>a major nightly news program recently devoted an > > > >>entire show to the investigation of the program > > > >>described below to see if it really can make people > > > >>money. > > > >> > > > >> The show also investigated whether or not the > > > >>program was legal. Their findings proved once and for > > > >>all that there are absolutely no laws prohibiting the > > > >>participation in the program. This has helped to show > > > >>people that this is a simple, harmless and fun way to > > > >>make some extra money at home. > > > >> > > > >> The results of this show have been truly > > > >>remarkable. So many people are participating that > > > >>those involved are doing much better than ever before. > > > >>Since everyone makes more as more people try it out, > > > >>it's been very exciting to be a part of lately. You > > > >>will understand once you experience it. > > > >> > > > >> I did and so far it's going great! HERE IT IS BELOW: > > > >> > > > >> *** Print This Now For Future Reference *** > > > >> > > > >> The following income opportunity is one you may be > > > >>interested in taking a look at. It can be started with > > > >>VERY LITTLE investment and the income return is > > > >>TREMENDOUS!!! > > > >> > > > >> $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ > > > >> > > > >> If you would like to make at least $50,000 in less > > > >>than 90 days! Please read the enclosed program...THEN > > > >>READ IT AGAIN!!! > > > >> > > > >> $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ > > > >> > > > >> THIS IS A LEGITIMATE, LEGAL, MONEY MAKING > > > >>OPPORTUNITY. It does not require you to come into > > > >>contact with people, do any hard work, and best of > > > >>all, you never have to leave the house except to get > > > >>the mail. > > > >> > > > >> If you believe that someday you'll get that big > > > >>break that you've been waiting for, THIS IS IT! > > > >> > > > >> Simply follow the instructions, and your dreams > > > >>will come true. > > > >> > > > >> This multi-level e-mail order marketing program > > > >>works perfectly...100% EVERYTIME. > > > >> > > > >> E-mail is the sales tool of the future. Take > > > >>advantage of this non-commercialized method of > > > >>advertising NOW!!! The longer you wait, the more > > > >>people will be doing business using e-mail. Get your > > > >>piece of this action!!! > > > >> > > > >> MULTI-LEVEL MARKETING (MLM) has finally gained > > > >>respectability. It is being taught in the Harvard > > > >>Business School, and both Stanford Research and the > > > >>Wall Street Journal have stated that between 50% and > > > >>65% of all goods and services will be sold through > > > >>multi-level methods by the mid to late 1990's. > > > >> > > > >> This is a Multi-Billion Dollar industry and of the > > > >>500,000 millionaires in the U.S., 20% (100,000) made > > > >>their fortune in the last several years in MLM. > > > >> Moreover, statistics show 45 people become > > > >>millionaire's everyday through Multi-Level Marketing. > > > >> > > > >> You may have heard this story before, but over the > > > >>summer Donald Trump made an appearance on the David > > > >>Letterman show. Dave asked him what he would do if he > > > >>lost everything and had to start over from scratch. > > > >>Without hesitating, Trump said he would find a good > > > >>network marketing company and get to work. The > > > >>audience started to hoot and boo him. He looked out at > > > >>the audience and deadpanned his response: > > > >> > > > >> "That's why I'm sitting up here and you are all > > > >>sitting out there!" > > > >> > > > >> The enclosed information is something I almost let > > > >>slip through my fingers. > > > >> > > > >> Fortunately, sometime later I re-read everything > > > >>and gave some thought and study to it. My name is > > > >>Johnathon Rourke. Two years ago, the corporation I > > > >>worked at for the past twelve years downsized and my > > > >>position was eliminated. After unproductive job interviews, I > > > >>decided to open my own business. Over the past year, I > > > >>incurred many unforeseen financial problems. > > > >> > > > >> I owed my family, friends and creditors over > > > >>$35,000. The economy was taking a toll on my business > > > >>and I just couldn't seem to make ends meet. I had to > > > >>refinance and borrow against my home to support my > > > >>family and struggling business. > > > >> > > > >> AT THAT MOMENT something significant happened in my > > > >>life and I am writing to share the experience in hopes > > > >>that this will change your life FOREVER FINANCIALLY!!! > > > >> > > > >> In mid December, I received this program via > > > >>e-mail. Six month's prior to receiving this program I > > > >>had been sending away for information on various > > > >>business opportunities. All of the programs I > > > >>received, in my opinion, were not cost effective. They were > > > >>either too difficult for me to comprehend or the initial > > > >>investment was too much for me to risk to see if they > > > >>would work or not. One claimed that I would make a > > > >>million dollars in one year...it didn't tell me I'd > > > >>have to write a book to make it! > > > >> > > > >> But like I was saying, in December of 1999 I > > > >>received this program. I didn't send for it, or ask > > > >>for it, they just got my name off a mailing list. > > > >>THANK GOODNESS FOR THAT!!! After reading it several > > > >>times, to make sure I was reading it correctly, I couldn't > > > >>believe my eyes. Here was a MONEY MAKING PHENOMENON. > > > >>I could invest as much as I wanted to start, without > > > >>putting me further into debt. After I got a pencil and > > > >>paper and figured it out, I would at least get my > > > >>money back. But like most of you I was still a little > > > >>skeptical and a little worried about the legal aspects > > > >>of it all. So I checked it out with the U.S. Post > > > >>Office (1-800-725-2161 24-hrs) and they confirmed that > > > >>it is indeed legal! After determining the program was > > > >>LEGAL and NOT A CHAIN LETTER, I decided WHY NOT." > > > >> > > > >> Initially I sent out 10,000 e-mails. It cost me > > > >>about $15 for my time on-line. The great thing about > > > >>e-mail is that I don't need any money for printing to > > > >>send out the program, and because all of my orders are > > > >>fulfilled via e-mail, my only expense is my time. I am > > > >>telling you like it is I hope it don't turn you off, > > > >>but I promised myself that I would not "rip-off" > > > >>anyone, no matter how much money it made me. > > > >> > > > >> In less than one week, I was starting to receive > > > >>orders for REPORT # 1 By January 13; I had received 26 > > > >>orders for REPORT # 1. Your goal is to "RECEIVE at > > > >>least 20 ORDERS FOR REPORT # 1 WITHIN 2 WEEKS. IF YOU > > > >>DON'T, SEND OUT MORE PROGRAMS UNTIL YOU DO!" > > > >> > > > >> My first step in making $50,000 in 90 days was done. By January > > > >>30, I > > > >>had received 196 orders for REPORT # 2. Your goal is to > > > >>"RECEIVE AT LEAST 100+ ORDERS FOR REPORT # 2 WITHIN 2 > > > >>WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. > > > >>ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU > > > >>WILL MAKE YOUR $50,000 GOAL." Well, I had 196 orders > > > >>for REPORT # 296 more than I needed. So I sat back and > > > >>relaxed. By March 1, of my e-mailing of 10,000, I > > > >>received $58,000 with more coming in every day. > > > >> > > > >> I paid off ALL my debts and bought a much needed > > > >>new car. Please take your time to read the attached > > > >>program, IT WILL CHANGE YOUR LIFE FOREVER!!! > > > >> > > > >> Remember, it won't work if you don't try it. This > > > >>program does work, but you must follow it EXACTLY! > > > >>Especially the rules of not trying to place your name > > > >>in a different place. It won't work and you'll lose > > > >>out on a lot of money! > > > >> > > > >> In order for this program to work, you must meet > > > >>your goal of 20 + orders for REPORT # 1, and 100 + orders > > > >>for REPORT # 2 and you will make $50,000 or more in 90 > > > >>days. I AM LIVING PROOF THAT IT WORKS!!! > > > >> > > > >> If you choose not to participate in this program, I > > > >>am sorry. It really is a great opportunity with little > > > >>cost or risk to you. If you choose to participate, > > > >>follow the program and you will be on your way to > > > >>financial security. If you are a fellow business owner > > > >>and are in financial trouble like I was, or you want > > > >>to start your own business, consider this a sign. > > > >> > > > >> I DID! > > > >> > > > >> Sincerely, > > > >> Johnathon Rourke > > > >> > > > >> > > > >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~ > > > >>~~ > > > >> > > > >> A PERSONAL NOTE FROM THE ORIGINATOR OF THIS > > > >>PROGRAM: > > > >> > > > >> By the time you have read the enclosed program and > > > >>reports, you should have concluded that such a > > > >>program, and one that is legal, could not have been > > > >>created by an amateur. > > > >> > > > >> Let me tell you a little about myself. I had a > > > >>profitable business for 10 years. Then in 1979 my > > > >>business began falling off. I was doing the same > > > >>things that were previously successful for me, but it > > > >>wasn't working. Finally, I figured it out. It wasn't me, it > > > >>was the economy. Inflation and recession had replaced > > > >>the stable economy that had been with us since 1945. > > > >> > > > >> I don't have to tell you what happened to the > > > >>unemployment rate... because many of you know from > > > >>first hand experience. There were more failures and > > > >>bankruptcies than ever before. The middle class was > > > >>vanishing. Those who knew what they were doing > > > >>invested wisely and moved up. Those who did not, > > > >>including those who never had anything to save or > > > >>invest, were moving down into the ranks of the poor. > > > >> > > > >> As the saying goes, "THE RICH GET RICHER AND THE POOR > > > >>GET POORER." The traditional methods of making money > > > >>will never allow you to "move up" or "get rich", inflation will > > > >>see to that. > > > >> > > > >> You have just received information that can give > > > >>you financial freedom for the rest of your life, with > > > >>"NO RISK" and "JUST A LITTLE BIT OF EFFORT." You can > > > >>make more money in the next few months than you have > > > >>ever imagined. I should also point out that I will not see > > > >>a penny of this money, nor anyone else who has > > > >>provided a testimonial for this program. I have > > > >>already made over 4 MILLION DOLLARS! I have retired > > > >>from the program after sending thousands and thousands > > > >>of programs. > > > >> > > > >>Follow the program EXACTLY AS INSTRUCTED. > > > >>Do not change it in any way. It works exceedingly well > > > >>as it is now. Remember to e-mail a copy of this > > > >>exciting report to everyone you can think of. One of the people > > > >>you > > > >>send this to may send out 50,000...and your name will be on > > > >>every one of them! > > > >> > > > >> Remember though, the more you send out the more > > > >>potential customers you will reach. > > > >> > > > >> So my friend, I have given you the ideas, > > > >>information, materials and opportunity to become > > > >>financially independent. IT IS UP TO YOU NOW! > > > >> > > > >> "THINK ABOUT IT" > > > >> > > > >> Before you delete this program from your mailbox, > > > >>as I almost did, take a little time to read it and > > > >>REALLY THINK ABOUT IT. Get a pencil and figure out > > > >>what could happen when YOU participate. Figure out the > > > >>worst possible response and no matter how you > > > >>calculate it, you will still make a lot of money! You > > > >>will definitely get back what you invested. Any doubts > > > >>you have will vanish when your first orders come in. > > > >>IT WORKS! > > > >> > > > >> Jody Jacobs > > > >> Richmond, VA > > > >> > > > >> HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU > > > >>THOUSANDS OF DOLLAR$ > > > >> > > > >> INSTRUCTIONS: > > > >> > > > >> This method of raising capital REALLY WORKS 100% > > > >>EVERY TIME. I am sure that you could use up to $50,000 > > > >>or more in the next 90 days. Before you say "BULL... > > > >>", please read this program carefully. > > > >> > > > >> This is not a chain letter, but a perfectly legal > > > >>money making opportunity. Basically, this is what you > > > >>do: As with all multi-level businesses, we build our > > > >>business by recruiting new partners and selling our > > > >>products. Every state in the USA allows you to recruit > > > >>new multi-level business partners, and we offer a > > > >>product for EVERY dollar sent. > > > >> > > > >> YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, > > > >>so you are not involved in personal selling. You do it > > > >>privately in your own home, store or office. This is > > > >>the GREATEST Multi-Level Mail Order Marketing > > > >>anywhere. > > > >> > > > >> This is what you MUST do: > > > >> > > > >> 1. Order all 4 reports shown on the list below (you > > > >>can't sell them if you don't order them). > > > >> > > > >> -- For each report, send $5.00 CASH, the NAME & > > > >>NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL > > > >>ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a > > > >>problem) to the person whose name appears on the list > > > >>next to the report. > > > >> > > > >> MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE > > > >>IN CASE OF ANY MAIL PROBLEMS! > > > >> > > > >> -- When you place your order, make sure you order > > > >>each of the four reports. You will need all four > > > >>reports so that you can save them on your computer and > > > >>resell them. > > > >> > > > >> -- Within a few days you will receive, via e-mail, > > > >>each of the four reports. Save them on your computer > > > >>so they will be accessible for you to send to the > > > >>1,000's of people who will order them from you. > > > >> > > > >> 2. IMPORTANT DO NOT alter the names of the people > > > >>who are listed next to each report, or their sequence > > > >>on the list, in any way other than is instructed below > > > >>in steps "a" through "f" or you will lose out on the > > > >>majority of your profits. Once you understand the > > > >>way this works, you'll also see how it doesn't work if > > > >>you change it. Remember, this method has been tested, > > > >>and if you alter it, it will not work. > > > >> > > > >> a. Look below for the listing of available reports. > > > >> > > > >> b. After you've ordered the four reports, take this > > > >>advertisement and remove the name and address under > > > >>REPORT # 4. This person has made it through the cycle > > > >>and is no doubt counting their $50,000! > > > >> > > > >> c. Move the name and address under REPORT # 3 down > > > >>to REPORT # 4. > > > >> > > > >> d. Move the name and address under REPORT # 2 down > > > >>to REPORT # 3. > > > >> > > > >> e. Move the name and address under REPORT # 1 down > > > >>to REPORT # 2. > > > >> > > > >> f. Insert your name/address in the REPORT # 1 > > > >>position. > > > >> > > > >> Please make sure you COPY ALL INFORMATION, every > > > >>name and address, ACCURATELY! > > > >> > > > >> 3. Take this entire letter, including the modified > > > >>list of names, and save it to your computer. Make NO > > > >>changes to the instruction portion of this letter. > > > >> > > > >> Your cost to participate in this is practically > > > >>nothing (surely you can afford $20). You obviously > > > >>already have an Internet connection and > > > >>e-mail is FREE! > > > >> > > > >> There are two primary methods of building your > > > >>downline: > > > >> > > > >> METHOD # 1: SENDING BULK E-MAIL > > > >> > > > >> Let's say that you decide to start small, just to > > > >>see how it goes, and we'll assume you and all those > > > >>involved send out only 2,000 programs each. Let's > > > >>also assume that the mailing receives a 0.5% response. > > > >>Using a good list the response could be much better. > > > >>Also, many people will send out hundreds of thousands > > > >>of programs instead of 2,000. But continuing with this > > > >>example, you send out only 2,000 programs. With a 0.5% > > > >>response, that is only 10 orders for REPORT # 1. Those > > > >>10 people respond by sending out 2,000 programs each > > > >>for a total of 20,000. Out of those 0.5%, 100 people > > > >>respond and order REPORT # 2. Those 100 mail out 2,000 > > > >>programs each for a total of 200,000. The 0.5% > > > >>response to that are 1,000 orders for REPORT # 3. Those > > > >>1,000 send out 2,000 programs each for a 2,000,000 > > > >>total. > > > >> > > > >>The 0.5% response to that are 10,000 orders for REPORT # 4. > > > >>That's 10,000 $5 bills for you. CASH!!! Your total > > > >>income in this example is $50 + $500 + $5,000 + $50,000 > > > >>for a total of $55,550!!! REMEMBER FRIEND, THIS IS > > > >>ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO > > > >>WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! > > > >>DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF > > > >>EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF > > > >>2,000. Believe me, many people will do just that, and > > > >>more! By the way, your cost to participate in this is > > > >>practically nothing. You obviously already have an > > > >>Internet connection and e-mail is FREE!!! > > > >> > > > >> REPORT # 2 will show you the best methods for bulk > > > >>e-mailing; tell you where to obtain free bulk e-mail > > > >>software and where to obtain e-mail lists. > > > >> > > > >> METHOD # 2 - PLACING FREE ADS ON THE INTERNET > > > >> > > > >> Advertising on the Internet is very, very > > > >>inexpensive, and there are HUNDREDS of FREE places to > > > >>advertise. Let's say you decide to start small just to > > > >>see how well it works. Assume your goal is to get ONLY > > > >>10 people to participate on your first level. (Placing > > > >>a lot of FREE ads on the Internet will EASILY get a > > > >>larger response.) Also assume that everyone else in > > > >>YOUR ORGANIZATION gets ONLY 10 downline members. > > > >>Follow this example to achieve the STAGGERING results > > > >>below: > > > >> > > > >> 1st level--your 10 members with > > > >> $5.......................................$50 > > > >> > > > >> 2nd level--10 members from those 10 > > > >> ($5 x 100)..................$500 > > > >> > > > >> 3rd level--10 members from those 100 > > > >> ($5 x 1,000)...........$5,000 > > > >> > > > >> 4th level--10 members from those 1,000 > > > >> ($5 x 10,000).....$50,000 > > > >> > > > >> THIS TOTALS ----------$55,550 > > > >> > > > >> Remember friends, this assumes that the people who > > > >>participate only recruit 10 people each. Think for a > > > >>moment what would happen if they got 20 people to > > > >>participate! Most people get 100's of participants! > > > >> > > > >> THINK ABOUT IT! For every $5.00 you receive, all > > > >>you must do is e-mail them the report they ordered. > > > >>THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL > > > >>ORDERS! This will guarantee that the e-mail THEY send > > > >>out with YOUR name and address on it will be prompt > > > >>because they can't advertise until they receive the > > > >>report! > > > >> > > > >> AVAILABLE REPORTS > > > >> > > > >> *** Order Each REPORT by NUMBER and NAME *** > > > >> Notes: > > > >> > > > >> -- ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH > > > >>REPORT. CHECKS NOT > > > >>ACCEPTED. > > > >> > > > >> -- ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL. > > > >> > > > >> Make sure the cash is concealed by wrapping it in at least two > > > >>sheets of paper. > > > >>On one of those sheets of paper, include: > > > >> > > > >> (a) the number & name of the report you are ordering, > > > >> > > > >> (b) your e-mail address, and > > > >> > > > >> (c) your name & postal address. > > > >> > > > >> > > > >> ## PLACE YOUR ORDER FOR THESE REPORTS NOW: > > > >> > > > >> REPORT # 1 "The Insider's Guide to Advertising for > > > >>Free on the Internet" > > > >> > > > >> ORDER REPORT FROM: # 1 FROM: > > > >>Jerry G Enterprisess > > > >> 19007 CopperMine RD. Rogers AR. 72756 > > > >> REPORT # 2 "The Insider's Guide to Sending Bulk > > > >>E-mail on the Internet" > > > >> > > > >> ORDER REPORT # 2 FROM: > > > >>Nitro Marketing > > > >> 29250 Hwy. HH > > > >> Sedalia, MO 65301 > > > >>> > > >> > > > >> REPORT # 3 "The Secrets to Multilevel Marketing on > > > >>the Internet" > > > >>Jerry Bradford > > > >> P.O. Box 366 > > > >> Cole Camp, MO 65235 > > > >> > > > >>> > > >> > > > >> REPORT # 4 "How to become a Millionaire utilizing > > > >>the Power of Multilevel Marketing and the Internet" > > > >>> > > >>> ORDER REport # 4 From> > > >> > > > > > > >> > > > >> > > >> Derald Ewing > > > >> 4000 Hyde Park Ave. Apt. # 83 > > > >> Columbia, MO 65201 > > > >> > > > >> > > > >> About 50,000 new people get online every month! > > > >> > > > >> ******* TIPS FOR SUCCESS ******* > > > >> > > > >> -- TREAT THIS AS YOUR BUSINESS! Be prompt, > > > >>professional, and follow the directions accurately. > > > >> > > > >> -- Send for the four reports IMMEDIATELY so you > > > >>will have them when the orders start coming in > > > >>because: When you receive a $5 order, you MUST send > > > >>out the requested product/report. > > > >> > > > >> -- ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS > > > >>YOU RECEIVE. > > > >> > > > >> -- Be patient and persistent with this program. If > > > >>you follow the instructions exactly, your results WILL > > > >>BE SUCCESSFUL! > > > >> > > > >> -- ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU > > > >>WILL SUCCEED! > > > >> > > > >> ******* YOUR SUCCESS GUIDELINES ******* > > > >> > > > >> Follow these guidelines to guarantee your success: > > > >> > > > >> If you don't receive 20 orders for REPORT # 1 within > > > >>two weeks, continue advertising or sending e-mails > > > >>until you do. Then, a couple of weeks later you should > > > >>receive at least 100 orders for REPORT # 2. If you > > > >>don't, continue advertising or sending e-mails until you do. > > > >>Once you have received 100 or more orders for REPORT > > > >># 2, YOU CAN RELAX, because the system is already > > > >>working for you, and the cash will continue to roll in! > > > >> > > > >> THIS IS IMPORTANT TO REMEMBER: > > > >> > > > >> Every time your name is moved down on the list, you > > > >>are placed in front of a DIFFERENT report. You can > > > >>KEEP TRACK of your PROGRESS by watching which report > > > >>people are ordering from you. If you want to generate > > > >>more income, send another batch of e-mails or continue > > > >>placing ads and start the whole process again! There > > > >>is no limit to the income you will generate from this > > > >>business! Before you make your decision as to whether > > > >>or not you participate in this program. Please answer > > > >>one question. DO YOU WANT TO CHANGE YOUR LIFE? If the > > > >>answer is yes, please look at the following facts > > > >>about this program: > > > >> > > > >> 1. You are selling a product which does not Cost > > > >>anything to PRODUCE, SHIP OR ADVERTISE. > > > >> > > > >> 2. All of your customers pay you in CASH! > > > >> > > > >> 3. E-mail is without question the most powerful > > > >>method of distributing information on earth. This > > > >>program combines the distribution power of e-mail > > > >>together with the revenue generating power of > > > >>multi-level marketing. > > > >> > > > >> 4. Your only expense--other than your initial $20 > > > >>investment--is your time! > > > >> > > > >> 5. Virtually all of the income you generate from > > > >>this program is PURE PROFIT! > > > >> > > > >> 6. This program will change your LIFE FOREVER. > > > >> ACT NOW! Take your first step toward achieving > > > >>financial independence. Order the reports and follow > > > >>the program outlined above--SUCCESS will be > > > >>your reward. > > > >> > > > >> Thank you for your time and consideration. > > > >> > > > >> PLEASE NOTE: If you need help with starting a > > > >>business, registering a business name, learning how > > > >>income tax is handled, etc., contact your local > > > >>office of the Small Business Administration (a > > > >>Federal Agency)1-800-827-5722 for free help and > > > >>answers to questions. > > > >> > > > >>Also, the Internal Revenue Service > > > >>offers free help via telephone and free seminars about > > > >>business tax requirements. Your earnings are highly > > > >>dependant on your activities and advertising. The information > > > >>contained on this site and in the report constitutes > > > >>no guarantees neither stated nor implied. In the event that it > > > >>is determined that this site or report constitutes a > > > >>guarantee of any kind, that guarantee is now void. The > > > >>earnings amounts listed on this site and in the > > > >>report are estimates only. If you have any questions > > > >>of the legality of this program, contact the Office of > > > >>Associate Director for Marketing Practices, Federal > > > >>Trade Commission, and Bureau of > > > >>Consumer Protection in Washington, DC. > > > >> > > > >> > > > >>///////////////////////////////////////////////////////////////// > > > >> ONE TIME MAILING, NO NEED TO REMOVE > > > >> > > > >>///////////////////////////////////////////////////////////////// > > > >> > > > >> > > > >>******************************************************** > > > >> This message is sent in compliance of the proposed > > > >>bill:SECTION 301. > > > >> Per Section 301, Paragraph (a)(2)(C) of S. 1618, > > > >> further transmissions to you by the sender of this > > > >>email may be stopped at no cost to you by sending a > > > >>reply to this email address with the word remove in > > > >>the > > > >>subject line. This message is not intended for > > > >>residents in the State of Washington, screening of > > > >>addresses has been done to the best of our technical > > > >>ability. If you are a Washington, Virginia, or > > > >>California resident or otherwise wish to be removed > > > >>from this list, further transmissions to you by the > > > >>sender of this email may be stopped at no cost to you > > > >>by sending a reply to this email address with the word > > > >>remove in the subject line. > > > >> > > > >>********************************************************* > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > > > > > > > > _______________________________________________________________________ _ > > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com > > > > > > Error: Timeout , Sent From: tMTIAppUnlock.OnfTimer , Var: Error: Timeout , Sent From: tMTIAppUnlock.OnfTimer , Var: Error: Timeout , Sent From: tMTIAppUnlock.OnfTimer , Var: >From owner-rmt@listserv.lbl.gov Mon Aug 28 15:19:53 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id PAA29501; Mon, 28 Aug 2000 15:18: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 PAA29496 for ; Mon, 28 Aug 2000 15:17: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 PAA01132 for ; Mon, 28 Aug 2000 15:17:58 -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 PAA01122 for ; Mon, 28 Aug 2000 15:17:56 -0700 (PDT) Received: from tahoe (talarian32-66.talarian.com [207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id PAA28945 for ; Mon, 28 Aug 2000 15:17:30 -0700 (PDT) Message-Id: <4.1.20000828143653.01ba80e0@mailhost.talarian.com> X-Sender: bwhetten@mailhost.talarian.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 28 Aug 2000 15:17:24 -0700 To: rmt@lbl.gov From: Brian Whetten Subject: Choices for TRACK/NACK report encoding Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rmt@lbl.gov Precedence: bulk Hi there, A question just came up for me on how we should best do NACK (and TRACK) encoding for the information that is sent up. I think there are two primary ways that have been used so far: List NACKs (i.e. PGM) and bitmaps (i.e. RMTP-II & TRAM). The other option, which hasn't been used yet but has been discussed, is run length encoded bitmaps. I'd ideally like to see us use the same encoding format (as part of the common data headers BB) for each. I ran a quick comparison of the overhead of encoding a window of N packets, with a uniform loss rate of P. The overhead for each option is: List NACK=32*N*P Bitmap=N RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this is reasonably accurate for low values of P) Note that as P approaches 1 (worst case, which we need to plan for), we get: List=32*N Bitmap=N RLE Bitmap=Actually goes down (because we encode successes rather than losses), with a worst case always less than either of the other two (but approaching the bitmap case). Here are numeric results for these formulas, in bits, assuming N=1000. p List NACK Bitmap RLE Bitmap 0.001 32 1000 10 0.0031 101 1000 28.5 0.01 320 1000 70 0.031 1012 1000 158.1 0.1 3200 1000 400 0.31 10119 1000 632 0.66 21120 1000 660 0.9 28800 1000 400 As you can see, List NACKs are better than a bitmap for P<3%, and worse otherwise. A RLE bitmap is the most complicated to implement, but is also the most efficient for all cases. A related topic to this is the idea of reliable NACKs. Taking PGM as an example, it uses reliable NACKs, which make a lot of sense if none of these encoding mechanisms are used, since there is no built in redundancy across successive NACKs in that case. I think that NORM/PGM's biggest advantage is being able to work without needing reliability mechanisms, which gives these protocols better scalability in the face of failures. The reliable NACKs actually go directly in the face of this, and increase the amount of NACK implosion traffic that would occur when a network partition occurs. I believe that the need for reliable NACKs could be removed in NACK-only protocols (as it is in TRACK oriented protocols) by reporting a full status of all the non-stable packets. With a RLE mechanism, this scales very nicely, and I think the overhead of adding the RLE mechanism would be less than the complexity of reliable NACKs. Conclusion: I think we should standardize on non-reliable NACKs/TRACKs (they are basically the same thing, just generated at different times), which use the same encoding format for their retransmission request reports. I think that RLE encoded bitmaps should be used for this, since the system needs to be stable even in the face of very high loss rates and high data rates. Comments? Brian >From owner-rmt@listserv.lbl.gov Mon Aug 28 16:08:41 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id QAA29611; Mon, 28 Aug 2000 16:06:58 -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 QAA29607 for ; Mon, 28 Aug 2000 16:06:56 -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 QAA15343 for ; Mon, 28 Aug 2000 16:06:55 -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 QAA15338 for ; Mon, 28 Aug 2000 16:06:54 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 28 Aug 2000 17:06:20 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 28 Aug 2000 17:06:16 -0600 From: "Sukanta Ganguly" To: , Subject: Re: Choices for TRACK/NACK report encoding Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_772FE97C.87E68BD3" Sender: owner-rmt@lbl.gov Precedence: bulk This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_772FE97C.87E68BD3 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Brian, Reliable NACK should not be the fact based on which the design should be = done. Scalability is the obvious probelm with it. So most of your = assumptions are correct. I don't quite understand how you came up with the = overheads. I also could not quite understand where did you get the 32 in = the calculation.=20 However, what do you mean by full status of the non-stable packets? = Where is this full status generated? Are we assumming that the RLE data = reaches the target without any loss? SG >>> Brian Whetten 08/28/00 04:17PM >>> Hi there, A question just came up for me on how we should best do NACK (and TRACK) encoding for the information that is sent up. I think there are two primary ways that have been used so far: List NACKs (i.e. PGM) and = bitmaps (i.e. RMTP-II & TRAM). The other option, which hasn't been used yet but has been discussed, is run length encoded bitmaps. =20 I'd ideally like to see us use the same encoding format (as part of the common data headers BB) for each. I ran a quick comparison of the = overhead of encoding a window of N packets, with a uniform loss rate of P. The overhead for each option is: List NACK=3D32*N*P Bitmap=3DN RLE Bitmap=3Dapproximately Ceiling(Log2(1/P))*N*P (I think this is reasonably accurate for low values of P) Note that as P approaches 1 (worst case, which we need to plan for), we = get: List=3D32*N Bitmap=3DN RLE Bitmap=3DActually goes down (because we encode successes rather than losses), with a worst case always less than either of the other two (but approaching the bitmap case). Here are numeric results for these formulas, in bits, assuming N=3D1000. p List NACK Bitmap RLE Bitmap 0.001 32 1000 10 0.0031 101 1000 28.5 0.01 320 1000 70 0.031 1012 1000 158.1 0.1 3200 1000 400 0.31 10119 1000 632 0.66 21120 1000 660 0.9 28800 1000 400 As you can see, List NACKs are better than a bitmap for P<3%, and worse otherwise. A RLE bitmap is the most complicated to implement, but is also the most efficient for all cases. A related topic to this is the idea of reliable NACKs. Taking PGM as an example, it uses reliable NACKs, which make a lot of sense if none of = these encoding mechanisms are used, since there is no built in redundancy across successive NACKs in that case. I think that NORM/PGM's biggest advantage is being able to work without needing reliability mechanisms, which gives these protocols better scalability in the face of failures. The reliable NACKs actually go directly in the face of this, and increase the amount of NACK implosion traffic that would occur when a network partition occurs. = =20 I believe that the need for reliable NACKs could be removed in NACK-only protocols (as it is in TRACK oriented protocols) by reporting a full = status of all the non-stable packets. With a RLE mechanism, this scales very nicely, and I think the overhead of adding the RLE mechanism would be less than the complexity of reliable NACKs. Conclusion: I think we should standardize on non-reliable NACKs/TRACKs (they are basically the same thing, just generated at different times), which use the same encoding format for their retransmission request reports. I think that RLE encoded bitmaps should be used for this, since the system needs to be stable even in the face of very high loss rates and high data rates. =20 Comments? Brian --=_772FE97C.87E68BD3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Brian,
  Reliable NACK should not be the fact based on which the = design=20 should be done. Scalability is the obvious probelm with it. So most = of your=20 assumptions are correct. I don't quite understand how you came up with = the=20 overheads. I also could not quite understand where did you get the 32 in = the=20 calculation.
  However, what do you mean by full status of the non-s= table=20 packets? Where is this full status generated? Are we assumming that the = RLE data=20 reaches the target without any loss?
 
SG

>>> Brian Whetten <whetten@talarian.com> = 08/28/00=20 04:17PM >>>
Hi there,
A question just came up for me on how = we=20 should best do NACK (and TRACK)
encoding for the information that is = sent=20 up.  I think there are two
primary ways that have been used so=20 far:  List NACKs (i.e. PGM) and bitmaps
(i.e. RMTP-II & = TRAM). =20 The other option, which hasn't been used yet but
has been discussed, is = run=20 length encoded bitmaps. 

I'd ideally like to see us use the = same=20 encoding format (as part of the
common data headers BB) for each.  = I ran=20 a quick comparison of the overhead
of encoding a window of N packets, = with a=20 uniform loss rate of P.  The
overhead for each option is:

Li= st=20 NACK=3D32*N*P
Bitmap=3DN
RLE Bitmap=3Dapproximately Ceiling(Log2(1/P)= )*N*P =20 (I think this is
reasonably accurate for low values of P)

Note = that as=20 P approaches 1 (worst case, which we need to plan for), we=20 get:
List=3D32*N
Bitmap=3DN
RLE Bitmap=3DActually goes down = (because we=20 encode successes rather than
losses), with a worst case always less = than=20 either of the other two (but
approaching the bitmap case).

Here = are=20 numeric results for these formulas, in bits, assuming=20 N=3D1000.

p        List=20 NACK    Bitmap        RLE=20 Bitmap
0.001        32   = =20     1000       =20 10
0.0031    101       =20 1000        28.5
0.01   =20=     320       =20 1000        70
0.031   =20     1012       =20 1000        158.1
0.1   =20=     3200       =20 1000        400
0.31   =20     10119       =20 1000        632
0.66   =20     21120       =20 1000        660
0.9   =20     28800       =20 1000        400

As you can see, List = NACKs=20 are better than a bitmap for P<3%, and worse
otherwise.  A RLE = bitmap=20 is the most complicated to implement, but is also
the most efficient = for all=20 cases.

A related topic to this is the idea of reliable NACKs. = =20 Taking PGM as an
example, it uses reliable NACKs, which make a lot of = sense=20 if none of these
encoding mechanisms are used, since there is no built = in=20 redundancy across
successive NACKs in that case.  I think that=20 NORM/PGM's biggest advantage
is being able to work without needing=20 reliability mechanisms, which gives
these protocols better scalability = in the=20 face of failures.  The reliable
NACKs actually go directly in the = face=20 of this, and increase the amount of
NACK implosion traffic that would = occur=20 when a network partition occurs. 

I believe that the need = for=20 reliable NACKs could be removed in NACK-only
protocols (as it is in = TRACK=20 oriented protocols) by reporting a full status
of all the non-stable=20 packets.  With a RLE mechanism, this scales very
nicely, and I = think the=20 overhead of adding the RLE mechanism would be less
than the complexity = of=20 reliable NACKs.

Conclusion:  I think we should standardize = on=20 non-reliable NACKs/TRACKs
(they are basically the same thing, just = generated=20 at different times),
which use the same encoding format for their=20 retransmission request
reports.  I think that RLE encoded bitmaps = should=20 be used for this, since
the system needs to be stable even in the face = of=20 very high loss rates and
high data rates. =20

Comments?
Brian

--=_772FE97C.87E68BD3-- >From owner-rmt@listserv.lbl.gov Tue Aug 29 06:54:32 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id GAA02929; Tue, 29 Aug 2000 06:52: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 GAA02925 for ; Tue, 29 Aug 2000 06:52:07 -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 GAA14299 for ; Tue, 29 Aug 2000 06:52:06 -0700 (PDT) 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 GAA14296 for ; Tue, 29 Aug 2000 06:52:05 -0700 (PDT) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id PAA51220; Tue, 29 Aug 2000 15:52:06 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200008291352.PAA51220@info.iet.unipi.it> Subject: Re: Choices for TRACK/NACK report encoding In-Reply-To: <4.1.20000828143653.01ba80e0@mailhost.talarian.com> from Brian Whetten at "Aug 28, 2000 03:17:24 pm" To: Brian Whetten Date: Tue, 29 Aug 2000 15:52:06 +0200 (CEST) CC: rmt@lbl.gov 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 > RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this is > reasonably accurate for low values of P) mumble... wonder what did you use to compute the RLE bitmap size for p in the range 0.1 to 0.5 below... was that an actual encoding or just the result from the above formula (which might not apply given your comment above) note though that maybe it is not such a good idea to issue selective naks for >100 losses at once (or said it differently, gropus of 1000 pkts with a loss rate of 10% or more), so maybe we could limit our attention to a relatively small set of missing pkts irrespective of window size. cheers luigi > Note that as P approaches 1 (worst case, which we need to plan for), we get: > List=32*N > Bitmap=N > RLE Bitmap=Actually goes down (because we encode successes rather than > losses), with a worst case always less than either of the other two (but > approaching the bitmap case). > > Here are numeric results for these formulas, in bits, assuming N=1000. > > p List NACK Bitmap RLE Bitmap > 0.001 32 1000 10 > 0.0031 101 1000 28.5 > 0.01 320 1000 70 > 0.031 1012 1000 158.1 > 0.1 3200 1000 400 > 0.31 10119 1000 632 > 0.66 21120 1000 660 > 0.9 28800 1000 400 > > As you can see, List NACKs are better than a bitmap for P<3%, and worse > otherwise. A RLE bitmap is the most complicated to implement, but is also > the most efficient for all cases. > > A related topic to this is the idea of reliable NACKs. Taking PGM as an > example, it uses reliable NACKs, which make a lot of sense if none of these > encoding mechanisms are used, since there is no built in redundancy across > successive NACKs in that case. I think that NORM/PGM's biggest advantage > is being able to work without needing reliability mechanisms, which gives > these protocols better scalability in the face of failures. The reliable > NACKs actually go directly in the face of this, and increase the amount of > NACK implosion traffic that would occur when a network partition occurs. > > I believe that the need for reliable NACKs could be removed in NACK-only > protocols (as it is in TRACK oriented protocols) by reporting a full status > of all the non-stable packets. With a RLE mechanism, this scales very > nicely, and I think the overhead of adding the RLE mechanism would be less > than the complexity of reliable NACKs. > > Conclusion: I think we should standardize on non-reliable NACKs/TRACKs > (they are basically the same thing, just generated at different times), > which use the same encoding format for their retransmission request > reports. I think that RLE encoded bitmaps should be used for this, since > the system needs to be stable even in the face of very high loss rates and > high data rates. > > Comments? > Brian > > >From owner-rmt@listserv.lbl.gov Tue Aug 29 10:38:46 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id KAA03744; Tue, 29 Aug 2000 10:36:52 -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 KAA03740 for ; Tue, 29 Aug 2000 10:36:47 -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 KAA17422 for ; Tue, 29 Aug 2000 10:36:46 -0700 (PDT) Received: from mail.webfountain.com (mail.webfountain.com [63.161.54.5]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA17407 for ; Tue, 29 Aug 2000 10:36:45 -0700 (PDT) Received: from leningrad (gate.webfountain.com [63.161.54.3]) by mail.webfountain.com (8.9.3/8.9.3) with SMTP id KAA20092; Tue, 29 Aug 2000 10:23:15 -0700 X-Authentication-Warning: mail.webfountain.com: Host gate.webfountain.com [63.161.54.3] claimed to be leningrad From: "Mike Luby" To: "Luigi Rizzo" , "Brian Whetten" Cc: Subject: RE: Choices for TRACK/NACK report encoding Date: Tue, 29 Aug 2000 10:27:31 -0700 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: <200008291352.PAA51220@info.iet.unipi.it> Sender: owner-rmt@lbl.gov Precedence: bulk Is there an option to NACK based on FEC, i.e., to just give the number of missing packets (and which block they are from) instead of an explicit list of missing packets? Mike -----Original Message----- From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Luigi Rizzo Sent: Tuesday, August 29, 2000 6:52 AM To: Brian Whetten Cc: rmt@lbl.gov Subject: Re: Choices for TRACK/NACK report encoding > RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this is > reasonably accurate for low values of P) mumble... wonder what did you use to compute the RLE bitmap size for p in the range 0.1 to 0.5 below... was that an actual encoding or just the result from the above formula (which might not apply given your comment above) note though that maybe it is not such a good idea to issue selective naks for >100 losses at once (or said it differently, gropus of 1000 pkts with a loss rate of 10% or more), so maybe we could limit our attention to a relatively small set of missing pkts irrespective of window size. cheers luigi > Note that as P approaches 1 (worst case, which we need to plan for), we get: > List=32*N > Bitmap=N > RLE Bitmap=Actually goes down (because we encode successes rather than > losses), with a worst case always less than either of the other two (but > approaching the bitmap case). > > Here are numeric results for these formulas, in bits, assuming N=1000. > > p List NACK Bitmap RLE Bitmap > 0.001 32 1000 10 > 0.0031 101 1000 28.5 > 0.01 320 1000 70 > 0.031 1012 1000 158.1 > 0.1 3200 1000 400 > 0.31 10119 1000 632 > 0.66 21120 1000 660 > 0.9 28800 1000 400 > > As you can see, List NACKs are better than a bitmap for P<3%, and worse > otherwise. A RLE bitmap is the most complicated to implement, but is also > the most efficient for all cases. > > A related topic to this is the idea of reliable NACKs. Taking PGM as an > example, it uses reliable NACKs, which make a lot of sense if none of these > encoding mechanisms are used, since there is no built in redundancy across > successive NACKs in that case. I think that NORM/PGM's biggest advantage > is being able to work without needing reliability mechanisms, which gives > these protocols better scalability in the face of failures. The reliable > NACKs actually go directly in the face of this, and increase the amount of > NACK implosion traffic that would occur when a network partition occurs. > > I believe that the need for reliable NACKs could be removed in NACK-only > protocols (as it is in TRACK oriented protocols) by reporting a full status > of all the non-stable packets. With a RLE mechanism, this scales very > nicely, and I think the overhead of adding the RLE mechanism would be less > than the complexity of reliable NACKs. > > Conclusion: I think we should standardize on non-reliable NACKs/TRACKs > (they are basically the same thing, just generated at different times), > which use the same encoding format for their retransmission request > reports. I think that RLE encoded bitmaps should be used for this, since > the system needs to be stable even in the face of very high loss rates and > high data rates. > > Comments? > Brian > > >From owner-rmt@listserv.lbl.gov Tue Aug 29 10:59:28 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id KAA03796; Tue, 29 Aug 2000 10:57: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 KAA03792 for ; Tue, 29 Aug 2000 10:57:40 -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 KAA24824 for ; Tue, 29 Aug 2000 10:57:39 -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 KAA24788 for ; Tue, 29 Aug 2000 10:57:33 -0700 (PDT) Received: from tahoe (talarian32-66.talarian.com [207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id KAA15504; Tue, 29 Aug 2000 10:57:05 -0700 (PDT) Message-Id: <4.1.20000829105244.01c0bb70@mailhost.talarian.com> Message-Id: <4.1.20000829105244.01c0bb70@mailhost.talarian.com> X-Sender: bwhetten@mailhost.talarian.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 29 Aug 2000 10:58:00 -0700 To: "Sukanta Ganguly" , From: Brian Whetten Subject: Re: Choices for TRACK/NACK report encoding In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_260870902==_.ALT" Sender: owner-rmt@lbl.gov Precedence: bulk --=====================_260870902==_.ALT Content-Type: text/plain; charset="us-ascii" I'm glad you agree. 32 comes from the size of a sequence number. No, I'm not assuming that any sets of packets reach the sender without loss...that is part of the point of this. Most of the TRACK/NACK RMT protocols out there have the notion of a non-stable receiver window, which is the set of packets from the lost packet with lowest sequence packet that is still considered recoverable, up through the loss detected with the highest sequence number (or alternatively, up through the highest sequence number the receiver is aware of). The core idea is that if you only NACK individual packets, then there is no built in redundancy from NACK to NACK, and you have to build in a reliability mechanism for the NACKs. If you send up a compressed bitmap for the packets in the non-stable window, then you don't need to do this. This status is generated at the receivers, and passed up. (See TRAM or RMTP-II for details) Brian At 05:06 PM 8/28/2000 -0600, Sukanta Ganguly wrote: > > Brian, > Reliable NACK should not be the fact based on which the design should be > done. Scalability is the obvious probelm with it. So most of your assumptions > are correct. I don't quite understand how you came up with the overheads. I > also could not quite understand where did you get the 32 in the calculation. > However, what do you mean by full status of the non-stable packets? Where > is this full status generated? Are we assumming that the RLE data reaches the > target without any loss? > > SG > > >>> Brian Whetten 08/28/00 04:17PM >>> > Hi there, > A question just came up for me on how we should best do NACK (and TRACK) > encoding for the information that is sent up. I think there are two > primary ways that have been used so far: List NACKs (i.e. PGM) and bitmaps > (i.e. RMTP-II & TRAM). The other option, which hasn't been used yet but > has been discussed, is run length encoded bitmaps. > > I'd ideally like to see us use the same encoding format (as part of the > common data headers BB) for each. I ran a quick comparison of the overhead > of encoding a window of N packets, with a uniform loss rate of P. The > overhead for each option is: > > List NACK=32*N*P > Bitmap=N > RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this is > reasonably accurate for low values of P) > > Note that as P approaches 1 (worst case, which we need to plan for), we get: > List=32*N > Bitmap=N > RLE Bitmap=Actually goes down (because we encode successes rather than > losses), with a worst case always less than either of the other two (but > approaching the bitmap case). > > Here are numeric results for these formulas, in bits, assuming N=1000. > > p List NACK Bitmap RLE Bitmap > 0.001 32 1000 10 > 0.0031 101 1000 28.5 > 0.01 320 1000 70 > 0.031 1012 1000 158.1 > 0.1 3200 1000 400 > 0.31 10119 1000 632 > 0.66 21120 1000 660 > 0.9 28800 1000 400 > > As you can see, List NACKs are better than a bitmap for P<3%, and worse > otherwise. A RLE bitmap is the most complicated to implement, but is also > the most efficient for all cases. > > A related topic to this is the idea of reliable NACKs. Taking PGM as an > example, it uses reliable NACKs, which make a lot of sense if none of these > encoding mechanisms are used, since there is no built in redundancy across > successive NACKs in that case. I think that NORM/PGM's biggest advantage > is being able to work without needing reliability mechanisms, which gives > these protocols better scalability in the face of failures. The reliable > NACKs actually go directly in the face of this, and increase the amount of > NACK implosion traffic that would occur when a network partition occurs. > > I believe that the need for reliable NACKs could be removed in NACK-only > protocols (as it is in TRACK oriented protocols) by reporting a full status > of all the non-stable packets. With a RLE mechanism, this scales very > nicely, and I think the overhead of adding the RLE mechanism would be less > than the complexity of reliable NACKs. > > Conclusion: I think we should standardize on non-reliable NACKs/TRACKs > (they are basically the same thing, just generated at different times), > which use the same encoding format for their retransmission request > reports. I think that RLE encoded bitmaps should be used for this, since > the system needs to be stable even in the face of very high loss rates and > high data rates. > > Comments? > Brian --=====================_260870902==_.ALT Content-Type: text/html; charset="us-ascii" I'm glad you agree.  32 comes from the size of a sequence number.  No, I'm not assuming that any sets of packets reach the sender without loss...that is part of the point of this.  Most of the TRACK/NACK RMT protocols out there have the notion of a non-stable receiver window, which is the set of packets from the lost packet with lowest sequence packet that is still considered recoverable, up through the loss detected with the highest sequence number (or alternatively, up through the highest sequence number the receiver is aware of). 

The core idea is that if you only NACK individual packets, then there is no built in redundancy from NACK to NACK, and you have to build in a reliability mechanism for the NACKs.  If you send up a compressed bitmap for the packets in the non-stable window, then you don't need to do this.  This status is generated at the receivers, and passed up.  (See TRAM or RMTP-II for details)

Brian

At 05:06 PM 8/28/2000 -0600, Sukanta Ganguly wrote:
Brian,
  Reliable NACK should not be the fact based on which the design should be done. Scalability is the obvious probelm with it. So most of your assumptions are correct. I don't quite understand how you came up with the overheads. I also could not quite understand where did you get the 32 in the calculation.
  However, what do you mean by full status of the non-stable packets? Where is this full status generated? Are we assumming that the RLE data reaches the target without any loss?
 
SG

>>> Brian Whetten <whetten@talarian.com> 08/28/00 04:17PM >>>
Hi there,
A question just came up for me on how we should best do NACK (and TRACK)
encoding for the information that is sent up.  I think there are two
primary ways that have been used so far:  List NACKs (i.e. PGM) and bitmaps
(i.e. RMTP-II & TRAM).  The other option, which hasn't been used yet but
has been discussed, is run length encoded bitmaps. 

I'd ideally like to see us use the same encoding format (as part of the
common data headers BB) for each.  I ran a quick comparison of the overhead
of encoding a window of N packets, with a uniform loss rate of P.  The
overhead for each option is:

List NACK=32*N*P
Bitmap=N
RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P  (I think this is
reasonably accurate for low values of P)

Note that as P approaches 1 (worst case, which we need to plan for), we get:
List=32*N
Bitmap=N
RLE Bitmap=Actually goes down (because we encode successes rather than
losses), with a worst case always less than either of the other two (but
approaching the bitmap case).

Here are numeric results for these formulas, in bits, assuming N=1000.

p        List NACK    Bitmap        RLE Bitmap
0.001        32        1000        10
0.0031    101        1000        28.5
0.01        320        1000        70
0.031        1012        1000        158.1
0.1        3200        1000        400
0.31        10119        1000        632
0.66        21120        1000        660
0.9        28800        1000        400

As you can see, List NACKs are better than a bitmap for P<3%, and worse
otherwise.  A RLE bitmap is the most complicated to implement, but is also
the most efficient for all cases.

A related topic to this is the idea of reliable NACKs.  Taking PGM as an
example, it uses reliable NACKs, which make a lot of sense if none of these
encoding mechanisms are used, since there is no built in redundancy across
successive NACKs in that case.  I think that NORM/PGM's biggest advantage
is being able to work without needing reliability mechanisms, which gives
these protocols better scalability in the face of failures.  The reliable
NACKs actually go directly in the face of this, and increase the amount of
NACK implosion traffic that would occur when a network partition occurs. 

I believe that the need for reliable NACKs could be removed in NACK-only
protocols (as it is in TRACK oriented protocols) by reporting a full status
of all the non-stable packets.  With a RLE mechanism, this scales very
nicely, and I think the overhead of adding the RLE mechanism would be less
than the complexity of reliable NACKs.

Conclusion:  I think we should standardize on non-reliable NACKs/TRACKs
(they are basically the same thing, just generated at different times),
which use the same encoding format for their retransmission request
reports.  I think that RLE encoded bitmaps should be used for this, since
the system needs to be stable even in the face of very high loss rates and
high data rates. 

Comments?
Brian


--=====================_260870902==_.ALT-- >From owner-rmt@listserv.lbl.gov Tue Aug 29 11:15:03 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id LAA03872; Tue, 29 Aug 2000 11:13:05 -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 LAA03868 for ; Tue, 29 Aug 2000 11:13: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 LAA00963 for ; Tue, 29 Aug 2000 11:13:02 -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 LAA00952 for ; Tue, 29 Aug 2000 11:13:01 -0700 (PDT) Received: from tahoe (talarian32-66.talarian.com [207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id LAA15999; Tue, 29 Aug 2000 11:12:03 -0700 (PDT) Message-Id: <4.1.20000829105816.01c12740@mailhost.talarian.com> X-Sender: bwhetten@mailhost.talarian.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 29 Aug 2000 11:10:35 -0700 To: Luigi Rizzo From: Brian Whetten Subject: Re: Choices for TRACK/NACK report encoding Cc: rmt@lbl.gov In-Reply-To: <200008291352.PAA51220@info.iet.unipi.it> References: <4.1.20000828143653.01ba80e0@mailhost.talarian.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rmt@lbl.gov Precedence: bulk I just used the formula, which is only a quick and dirty approximation. I need to go back and freshen up on encoding/compression algorithms (Mike, I'm sure this is trivial for you...do you have a more accurate formula?). I think the issue of the # of packets you NACK is orthogonal to how you respond to the NACKs. It strikes me that we should always (within the bounds of efficiency) be striving to get as much information as possible to the sender, and then it is a different issue as to how those NACKs are dealt with. The rate of retransmissions needs to be explicitly considered by the congestion control BB. Also, in very high bandwidth-delay product networks, I think you may want to be NACKing 100 or more packets at a time in some cases...but again, this should be dealt with by congestion control. Brian At 03:52 PM 8/29/2000 +0200, Luigi Rizzo wrote: >> RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this is >> reasonably accurate for low values of P) > >mumble... wonder what did you use to compute the RLE bitmap size >for p in the range 0.1 to 0.5 below... was that an actual >encoding or just the result from the above formula (which might >not apply given your comment above) > >note though that maybe it is not such a good idea to issue selective >naks for >100 losses at once (or said it differently, gropus of >1000 pkts with a loss rate of 10% or more), so maybe we could >limit our attention to a relatively small set of missing pkts >irrespective of window size. > > cheers > luigi > >> Note that as P approaches 1 (worst case, which we need to plan for), we get: >> List=32*N >> Bitmap=N >> RLE Bitmap=Actually goes down (because we encode successes rather than >> losses), with a worst case always less than either of the other two (but >> approaching the bitmap case). >> >> Here are numeric results for these formulas, in bits, assuming N=1000. >> >> p List NACK Bitmap RLE Bitmap >> 0.001 32 1000 10 >> 0.0031 101 1000 28.5 >> 0.01 320 1000 70 >> 0.031 1012 1000 158.1 >> 0.1 3200 1000 400 >> 0.31 10119 1000 632 >> 0.66 21120 1000 660 >> 0.9 28800 1000 400 >> >> As you can see, List NACKs are better than a bitmap for P<3%, and worse >> otherwise. A RLE bitmap is the most complicated to implement, but is also >> the most efficient for all cases. >> >> A related topic to this is the idea of reliable NACKs. Taking PGM as an >> example, it uses reliable NACKs, which make a lot of sense if none of these >> encoding mechanisms are used, since there is no built in redundancy across >> successive NACKs in that case. I think that NORM/PGM's biggest advantage >> is being able to work without needing reliability mechanisms, which gives >> these protocols better scalability in the face of failures. The reliable >> NACKs actually go directly in the face of this, and increase the amount of >> NACK implosion traffic that would occur when a network partition occurs. >> >> I believe that the need for reliable NACKs could be removed in NACK-only >> protocols (as it is in TRACK oriented protocols) by reporting a full status >> of all the non-stable packets. With a RLE mechanism, this scales very >> nicely, and I think the overhead of adding the RLE mechanism would be less >> than the complexity of reliable NACKs. >> >> Conclusion: I think we should standardize on non-reliable NACKs/TRACKs >> (they are basically the same thing, just generated at different times), >> which use the same encoding format for their retransmission request >> reports. I think that RLE encoded bitmaps should be used for this, since >> the system needs to be stable even in the face of very high loss rates and >> high data rates. >> >> Comments? >> Brian >> >> > >From owner-rmt@listserv.lbl.gov Tue Aug 29 11:15:19 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id LAA03878; Tue, 29 Aug 2000 11:13:37 -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 LAA03874 for ; Tue, 29 Aug 2000 11:13:35 -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 LAA01156 for ; Tue, 29 Aug 2000 11:13:35 -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 LAA01153 for ; Tue, 29 Aug 2000 11:13:34 -0700 (PDT) Received: from tahoe (talarian32-66.talarian.com [207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id LAA16003; Tue, 29 Aug 2000 11:12:04 -0700 (PDT) Message-Id: <4.1.20000829111049.01c18920@mailhost.talarian.com> X-Sender: bwhetten@mailhost.talarian.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 29 Aug 2000 11:14:45 -0700 To: "Mike Luby" , "Luigi Rizzo" From: Brian Whetten Subject: RE: Choices for TRACK/NACK report encoding Cc: In-Reply-To: References: <200008291352.PAA51220@info.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rmt@lbl.gov Precedence: bulk Hi there, We certainly need to be able to send this information up. If the sender knows the FEC window boundaries, then I believe the FEC information can be extracted from the bitmap (another reason to use a compressed bitmap). So unless the FEC coding windows were as a common case quite large, I'm not sure that the added complexity of offering an explicit count per window option would be worth it, at least for NACK/TRACK protocols. Brain At 10:27 AM 8/29/2000 -0700, Mike Luby wrote: >Is there an option to NACK based on FEC, i.e., to just give the number of >missing packets (and which block they are from) instead of an explicit list >of missing packets? >Mike > >-----Original Message----- >From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Luigi >Rizzo >Sent: Tuesday, August 29, 2000 6:52 AM >To: Brian Whetten >Cc: rmt@lbl.gov >Subject: Re: Choices for TRACK/NACK report encoding > > >> RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this is >> reasonably accurate for low values of P) > >mumble... wonder what did you use to compute the RLE bitmap size >for p in the range 0.1 to 0.5 below... was that an actual >encoding or just the result from the above formula (which might >not apply given your comment above) > >note though that maybe it is not such a good idea to issue selective >naks for >100 losses at once (or said it differently, gropus of >1000 pkts with a loss rate of 10% or more), so maybe we could >limit our attention to a relatively small set of missing pkts >irrespective of window size. > > cheers > luigi > >> Note that as P approaches 1 (worst case, which we need to plan for), we >get: >> List=32*N >> Bitmap=N >> RLE Bitmap=Actually goes down (because we encode successes rather than >> losses), with a worst case always less than either of the other two (but >> approaching the bitmap case). >> >> Here are numeric results for these formulas, in bits, assuming N=1000. >> >> p List NACK Bitmap RLE Bitmap >> 0.001 32 1000 10 >> 0.0031 101 1000 28.5 >> 0.01 320 1000 70 >> 0.031 1012 1000 158.1 >> 0.1 3200 1000 400 >> 0.31 10119 1000 632 >> 0.66 21120 1000 660 >> 0.9 28800 1000 400 >> >> As you can see, List NACKs are better than a bitmap for P<3%, and worse >> otherwise. A RLE bitmap is the most complicated to implement, but is also >> the most efficient for all cases. >> >> A related topic to this is the idea of reliable NACKs. Taking PGM as an >> example, it uses reliable NACKs, which make a lot of sense if none of >these >> encoding mechanisms are used, since there is no built in redundancy across >> successive NACKs in that case. I think that NORM/PGM's biggest advantage >> is being able to work without needing reliability mechanisms, which gives >> these protocols better scalability in the face of failures. The reliable >> NACKs actually go directly in the face of this, and increase the amount of >> NACK implosion traffic that would occur when a network partition occurs. >> >> I believe that the need for reliable NACKs could be removed in NACK-only >> protocols (as it is in TRACK oriented protocols) by reporting a full >status >> of all the non-stable packets. With a RLE mechanism, this scales very >> nicely, and I think the overhead of adding the RLE mechanism would be less >> than the complexity of reliable NACKs. >> >> Conclusion: I think we should standardize on non-reliable NACKs/TRACKs >> (they are basically the same thing, just generated at different times), >> which use the same encoding format for their retransmission request >> reports. I think that RLE encoded bitmaps should be used for this, since >> the system needs to be stable even in the face of very high loss rates and >> high data rates. >> >> Comments? >> Brian >> >> > > >From owner-rmt@listserv.lbl.gov Tue Aug 29 11:59:22 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id LAA04066; Tue, 29 Aug 2000 11:57: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 LAA04062 for ; Tue, 29 Aug 2000 11:57: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 LAA15929 for ; Tue, 29 Aug 2000 11:57:22 -0700 (PDT) Received: from nard.net (nard.net [63.66.160.50]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id LAA15915 for ; Tue, 29 Aug 2000 11:57:21 -0700 (PDT) Received: (qmail 2754 invoked by uid 500); 29 Aug 2000 18:59:56 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 Aug 2000 18:59:56 -0000 Date: Tue, 29 Aug 2000 14:59:56 -0400 (EDT) From: "Todd L. Montgomery" X-Sender: tmont@cartman.nard.net To: Mike Luby cc: Luigi Rizzo , Brian Whetten , rmt@lbl.gov Subject: RE: Choices for TRACK/NACK report encoding In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rmt@lbl.gov Precedence: bulk I hope there is. PGMs FEC adds a nice feature that allows a block to report it's loss count and pack that into a 32-bit number no matter how big the block. That is a LOT smaller with List NAKs than a bitmap can be. To do this, the block size (in packets) must be a power of 2, but that is not very restrictive. On Tue, 29 Aug 2000, Mike Luby wrote: > Is there an option to NACK based on FEC, i.e., to just give the number of > missing packets (and which block they are from) instead of an explicit list > of missing packets? > Mike > > -----Original Message----- > From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Luigi > Rizzo > Sent: Tuesday, August 29, 2000 6:52 AM > To: Brian Whetten > Cc: rmt@lbl.gov > Subject: Re: Choices for TRACK/NACK report encoding > > > > RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this is > > reasonably accurate for low values of P) > > mumble... wonder what did you use to compute the RLE bitmap size > for p in the range 0.1 to 0.5 below... was that an actual > encoding or just the result from the above formula (which might > not apply given your comment above) > > note though that maybe it is not such a good idea to issue selective > naks for >100 losses at once (or said it differently, gropus of > 1000 pkts with a loss rate of 10% or more), so maybe we could > limit our attention to a relatively small set of missing pkts > irrespective of window size. > > cheers > luigi > > > Note that as P approaches 1 (worst case, which we need to plan for), we > get: > > List=32*N > > Bitmap=N > > RLE Bitmap=Actually goes down (because we encode successes rather than > > losses), with a worst case always less than either of the other two (but > > approaching the bitmap case). > > > > Here are numeric results for these formulas, in bits, assuming N=1000. > > > > p List NACK Bitmap RLE Bitmap > > 0.001 32 1000 10 > > 0.0031 101 1000 28.5 > > 0.01 320 1000 70 > > 0.031 1012 1000 158.1 > > 0.1 3200 1000 400 > > 0.31 10119 1000 632 > > 0.66 21120 1000 660 > > 0.9 28800 1000 400 > > > > As you can see, List NACKs are better than a bitmap for P<3%, and worse > > otherwise. A RLE bitmap is the most complicated to implement, but is also > > the most efficient for all cases. > > > > A related topic to this is the idea of reliable NACKs. Taking PGM as an > > example, it uses reliable NACKs, which make a lot of sense if none of > these > > encoding mechanisms are used, since there is no built in redundancy across > > successive NACKs in that case. I think that NORM/PGM's biggest advantage > > is being able to work without needing reliability mechanisms, which gives > > these protocols better scalability in the face of failures. The reliable > > NACKs actually go directly in the face of this, and increase the amount of > > NACK implosion traffic that would occur when a network partition occurs. > > > > I believe that the need for reliable NACKs could be removed in NACK-only > > protocols (as it is in TRACK oriented protocols) by reporting a full > status > > of all the non-stable packets. With a RLE mechanism, this scales very > > nicely, and I think the overhead of adding the RLE mechanism would be less > > than the complexity of reliable NACKs. > > > > Conclusion: I think we should standardize on non-reliable NACKs/TRACKs > > (they are basically the same thing, just generated at different times), > > which use the same encoding format for their retransmission request > > reports. I think that RLE encoded bitmaps should be used for this, since > > the system needs to be stable even in the face of very high loss rates and > > high data rates. > > > > Comments? > > Brian > > > > > > -- Todd L. Montgomery Talarian Corporation 304-291-5972 todd@talarian.com >From owner-rmt@listserv.lbl.gov Tue Aug 29 12:48:17 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id MAA04295; Tue, 29 Aug 2000 12:45:29 -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 MAA04291 for ; Tue, 29 Aug 2000 12:45:28 -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 MAA29190 for ; Tue, 29 Aug 2000 12:45:27 -0700 (PDT) Received: from mail.webfountain.com (mail.webfountain.com [63.161.54.5]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA29180 for ; Tue, 29 Aug 2000 12:45:26 -0700 (PDT) Received: from leningrad (gate.webfountain.com [63.161.54.3]) by mail.webfountain.com (8.9.3/8.9.3) with SMTP id MAA26186; Tue, 29 Aug 2000 12:32:13 -0700 X-Authentication-Warning: mail.webfountain.com: Host gate.webfountain.com [63.161.54.3] claimed to be leningrad From: "Mike Luby" To: "Todd L. Montgomery" Cc: "Luigi Rizzo" , "Brian Whetten" , Subject: RE: Choices for TRACK/NACK report encoding Date: Tue, 29 Aug 2000 12:36:29 -0700 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: Sender: owner-rmt@lbl.gov Precedence: bulk As design goals, it would seem to be desirable: (1) That explicit packets can be NACKed per block. (2) That a count of packets can be NACKed per block. (3) That the mechanisms that achieve (1) and (2) are compatible with each other. (4) That the mechanisms would work relatively efficiently independent of the loss per block or the size of the block. (a) Would be desirable to work with small as well as large blocks (in terms of number of packets per block). (b) Would be desirable that the block size in packets doesn't have to fit any special requirements, e.g., be a power of 2. (c) Would be desirable that the scheme would scale with the number of losses per block, in particular when the report is a count then one should report any number between 0 and the size of the block in packets. Do these goals make sense, and how would people prioritize these goals, and are there other goals that are even more important that are missing? Once the goals and their relative priority are clear, then the design may just fall out as a natural consequence. Mike -----Original Message----- From: Todd L. Montgomery [mailto:todd@talarian.com] Sent: Tuesday, August 29, 2000 12:00 PM To: Mike Luby Cc: Luigi Rizzo; Brian Whetten; rmt@lbl.gov Subject: RE: Choices for TRACK/NACK report encoding I hope there is. PGMs FEC adds a nice feature that allows a block to report it's loss count and pack that into a 32-bit number no matter how big the block. That is a LOT smaller with List NAKs than a bitmap can be. To do this, the block size (in packets) must be a power of 2, but that is not very restrictive. On Tue, 29 Aug 2000, Mike Luby wrote: > Is there an option to NACK based on FEC, i.e., to just give the number of > missing packets (and which block they are from) instead of an explicit list > of missing packets? > Mike > > -----Original Message----- > From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Luigi > Rizzo > Sent: Tuesday, August 29, 2000 6:52 AM > To: Brian Whetten > Cc: rmt@lbl.gov > Subject: Re: Choices for TRACK/NACK report encoding > > > > RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this is > > reasonably accurate for low values of P) > > mumble... wonder what did you use to compute the RLE bitmap size > for p in the range 0.1 to 0.5 below... was that an actual > encoding or just the result from the above formula (which might > not apply given your comment above) > > note though that maybe it is not such a good idea to issue selective > naks for >100 losses at once (or said it differently, gropus of > 1000 pkts with a loss rate of 10% or more), so maybe we could > limit our attention to a relatively small set of missing pkts > irrespective of window size. > > cheers > luigi > > > Note that as P approaches 1 (worst case, which we need to plan for), we > get: > > List=32*N > > Bitmap=N > > RLE Bitmap=Actually goes down (because we encode successes rather than > > losses), with a worst case always less than either of the other two (but > > approaching the bitmap case). > > > > Here are numeric results for these formulas, in bits, assuming N=1000. > > > > p List NACK Bitmap RLE Bitmap > > 0.001 32 1000 10 > > 0.0031 101 1000 28.5 > > 0.01 320 1000 70 > > 0.031 1012 1000 158.1 > > 0.1 3200 1000 400 > > 0.31 10119 1000 632 > > 0.66 21120 1000 660 > > 0.9 28800 1000 400 > > > > As you can see, List NACKs are better than a bitmap for P<3%, and worse > > otherwise. A RLE bitmap is the most complicated to implement, but is also > > the most efficient for all cases. > > > > A related topic to this is the idea of reliable NACKs. Taking PGM as an > > example, it uses reliable NACKs, which make a lot of sense if none of > these > > encoding mechanisms are used, since there is no built in redundancy across > > successive NACKs in that case. I think that NORM/PGM's biggest advantage > > is being able to work without needing reliability mechanisms, which gives > > these protocols better scalability in the face of failures. The reliable > > NACKs actually go directly in the face of this, and increase the amount of > > NACK implosion traffic that would occur when a network partition occurs. > > > > I believe that the need for reliable NACKs could be removed in NACK-only > > protocols (as it is in TRACK oriented protocols) by reporting a full > status > > of all the non-stable packets. With a RLE mechanism, this scales very > > nicely, and I think the overhead of adding the RLE mechanism would be less > > than the complexity of reliable NACKs. > > > > Conclusion: I think we should standardize on non-reliable NACKs/TRACKs > > (they are basically the same thing, just generated at different times), > > which use the same encoding format for their retransmission request > > reports. I think that RLE encoded bitmaps should be used for this, since > > the system needs to be stable even in the face of very high loss rates and > > high data rates. > > > > Comments? > > Brian > > > > > > -- Todd L. Montgomery Talarian Corporation 304-291-5972 todd@talarian.com >From owner-rmt@listserv.lbl.gov Tue Aug 29 15:00:42 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id OAA04851; Tue, 29 Aug 2000 14:58:51 -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 OAA04847 for ; Tue, 29 Aug 2000 14:58:49 -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 OAA12656 for ; Tue, 29 Aug 2000 14:58:49 -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 OAA12643 for ; Tue, 29 Aug 2000 14:58:47 -0700 (PDT) Received: from tahoe (talarian32-66.talarian.com [207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id OAA22617; Tue, 29 Aug 2000 14:57:14 -0700 (PDT) Message-Id: <4.1.20000829143701.01ba2b70@mailhost.talarian.com> X-Sender: bwhetten@mailhost.talarian.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 29 Aug 2000 14:46:10 -0700 To: "Mike Luby" , "Todd L. Montgomery" From: Brian Whetten Subject: RE: Choices for TRACK/NACK report encoding Cc: "Luigi Rizzo" , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rmt@lbl.gov Precedence: bulk I would add: (5) Being able to efficiently encode as many losses across as many blocks as possible. i.e. being able to report a history of outstanding lost packets, rather than just the most recent ones. (6) Simplicity (7) Being stable in the face of very high loss rates, either of data packets and/or NACK packets. I would prioritize 1,2,6,7 as having the highest importance. Brian At 12:36 PM 8/29/2000 -0700, Mike Luby wrote: >As design goals, it would seem to be desirable: > >(1) That explicit packets can be NACKed per block. >(2) That a count of packets can be NACKed per block. >(3) That the mechanisms that achieve (1) and (2) are compatible with each >other. >(4) That the mechanisms would work relatively efficiently independent of the >loss per block or the size of the block. > (a) Would be desirable to work with small as well as large blocks (in >terms of number of packets per block). > (b) Would be desirable that the block size in packets doesn't have to >fit any special requirements, e.g., be a power of 2. > (c) Would be desirable that the scheme would scale with the number of >losses per block, in particular when the report is a count then one should >report any number between 0 and the size of the block in packets. > >Do these goals make sense, and how would people prioritize these goals, and >are there other goals that are even more important that are missing? Once >the goals and their relative priority are clear, then the design may just >fall out as a natural consequence. >Mike > >-----Original Message----- >From: Todd L. Montgomery [mailto:todd@talarian.com] >Sent: Tuesday, August 29, 2000 12:00 PM >To: Mike Luby >Cc: Luigi Rizzo; Brian Whetten; rmt@lbl.gov >Subject: RE: Choices for TRACK/NACK report encoding > > > >I hope there is. PGMs FEC adds a nice feature that allows a block >to report it's loss count and pack that into a 32-bit number >no matter how big the block. That is a LOT smaller with List NAKs >than a bitmap can be. > >To do this, the block size (in packets) must be a power of 2, but that is >not very restrictive. > >On Tue, 29 Aug 2000, Mike Luby wrote: > >> Is there an option to NACK based on FEC, i.e., to just give the number of >> missing packets (and which block they are from) instead of an explicit >list >> of missing packets? >> Mike >> >> -----Original Message----- >> From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Luigi >> Rizzo >> Sent: Tuesday, August 29, 2000 6:52 AM >> To: Brian Whetten >> Cc: rmt@lbl.gov >> Subject: Re: Choices for TRACK/NACK report encoding >> >> >> > RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this is >> > reasonably accurate for low values of P) >> >> mumble... wonder what did you use to compute the RLE bitmap size >> for p in the range 0.1 to 0.5 below... was that an actual >> encoding or just the result from the above formula (which might >> not apply given your comment above) >> >> note though that maybe it is not such a good idea to issue selective >> naks for >100 losses at once (or said it differently, gropus of >> 1000 pkts with a loss rate of 10% or more), so maybe we could >> limit our attention to a relatively small set of missing pkts >> irrespective of window size. >> >> cheers >> luigi >> >> > Note that as P approaches 1 (worst case, which we need to plan for), we >> get: >> > List=32*N >> > Bitmap=N >> > RLE Bitmap=Actually goes down (because we encode successes rather than >> > losses), with a worst case always less than either of the other two (but >> > approaching the bitmap case). >> > >> > Here are numeric results for these formulas, in bits, assuming N=1000. >> > >> > p List NACK Bitmap RLE Bitmap >> > 0.001 32 1000 10 >> > 0.0031 101 1000 28.5 >> > 0.01 320 1000 70 >> > 0.031 1012 1000 158.1 >> > 0.1 3200 1000 400 >> > 0.31 10119 1000 632 >> > 0.66 21120 1000 660 >> > 0.9 28800 1000 400 >> > >> > As you can see, List NACKs are better than a bitmap for P<3%, and worse >> > otherwise. A RLE bitmap is the most complicated to implement, but is >also >> > the most efficient for all cases. >> > >> > A related topic to this is the idea of reliable NACKs. Taking PGM as an >> > example, it uses reliable NACKs, which make a lot of sense if none of >> these >> > encoding mechanisms are used, since there is no built in redundancy >across >> > successive NACKs in that case. I think that NORM/PGM's biggest >advantage >> > is being able to work without needing reliability mechanisms, which >gives >> > these protocols better scalability in the face of failures. The >reliable >> > NACKs actually go directly in the face of this, and increase the amount >of >> > NACK implosion traffic that would occur when a network partition occurs. >> > >> > I believe that the need for reliable NACKs could be removed in NACK-only >> > protocols (as it is in TRACK oriented protocols) by reporting a full >> status >> > of all the non-stable packets. With a RLE mechanism, this scales very >> > nicely, and I think the overhead of adding the RLE mechanism would be >less >> > than the complexity of reliable NACKs. >> > >> > Conclusion: I think we should standardize on non-reliable NACKs/TRACKs >> > (they are basically the same thing, just generated at different times), >> > which use the same encoding format for their retransmission request >> > reports. I think that RLE encoded bitmaps should be used for this, >since >> > the system needs to be stable even in the face of very high loss rates >and >> > high data rates. >> > >> > Comments? >> > Brian >> > >> > >> >> > >-- >Todd L. Montgomery >Talarian Corporation >304-291-5972 >todd@talarian.com > > >From owner-rmt@listserv.lbl.gov Tue Aug 29 16:11:08 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id QAA05190; Tue, 29 Aug 2000 16:09:21 -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 QAA05186 for ; Tue, 29 Aug 2000 16:09:19 -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 QAA04329 for ; Tue, 29 Aug 2000 16:09:19 -0700 (PDT) Received: from mail.webfountain.com (mail.webfountain.com [63.161.54.5]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id QAA04325 for ; Tue, 29 Aug 2000 16:09:18 -0700 (PDT) Received: from leningrad (gate.webfountain.com [63.161.54.3]) by mail.webfountain.com (8.9.3/8.9.3) with SMTP id PAA01934; Tue, 29 Aug 2000 15:55:58 -0700 X-Authentication-Warning: mail.webfountain.com: Host gate.webfountain.com [63.161.54.3] claimed to be leningrad From: "Mike Luby" To: "Brian Whetten" , "Todd L. Montgomery" Cc: "Luigi Rizzo" , Subject: RE: Choices for TRACK/NACK report encoding Date: Tue, 29 Aug 2000 16:00:14 -0700 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: <4.1.20000829143701.01ba2b70@mailhost.talarian.com> Sender: owner-rmt@lbl.gov Precedence: bulk The additional design goals make sense. I would prioritize almost the same: (1,2),6,(4,7),5,3. (Parenthesis enclose goals of similar priority). Given this, the question then is: does a NACK scheme that meets these goals in this priority order jump out? (My only goal was to drive the design process starting from the goals, not from the mechanisms. This may be where I stop contributing.) Mike -----Original Message----- From: Brian Whetten [mailto:whetten@talarian.com] Sent: Tuesday, August 29, 2000 2:46 PM To: Mike Luby; Todd L. Montgomery Cc: Luigi Rizzo; rmt@lbl.gov Subject: RE: Choices for TRACK/NACK report encoding I would add: (5) Being able to efficiently encode as many losses across as many blocks as possible. i.e. being able to report a history of outstanding lost packets, rather than just the most recent ones. (6) Simplicity (7) Being stable in the face of very high loss rates, either of data packets and/or NACK packets. I would prioritize 1,2,6,7 as having the highest importance. Brian At 12:36 PM 8/29/2000 -0700, Mike Luby wrote: >As design goals, it would seem to be desirable: > >(1) That explicit packets can be NACKed per block. >(2) That a count of packets can be NACKed per block. >(3) That the mechanisms that achieve (1) and (2) are compatible with each >other. >(4) That the mechanisms would work relatively efficiently independent of the >loss per block or the size of the block. > (a) Would be desirable to work with small as well as large blocks (in >terms of number of packets per block). > (b) Would be desirable that the block size in packets doesn't have to >fit any special requirements, e.g., be a power of 2. > (c) Would be desirable that the scheme would scale with the number of >losses per block, in particular when the report is a count then one should >report any number between 0 and the size of the block in packets. > >Do these goals make sense, and how would people prioritize these goals, and >are there other goals that are even more important that are missing? Once >the goals and their relative priority are clear, then the design may just >fall out as a natural consequence. >Mike > >-----Original Message----- >From: Todd L. Montgomery [mailto:todd@talarian.com] >Sent: Tuesday, August 29, 2000 12:00 PM >To: Mike Luby >Cc: Luigi Rizzo; Brian Whetten; rmt@lbl.gov >Subject: RE: Choices for TRACK/NACK report encoding > > > >I hope there is. PGMs FEC adds a nice feature that allows a block >to report it's loss count and pack that into a 32-bit number >no matter how big the block. That is a LOT smaller with List NAKs >than a bitmap can be. > >To do this, the block size (in packets) must be a power of 2, but that is >not very restrictive. > >On Tue, 29 Aug 2000, Mike Luby wrote: > >> Is there an option to NACK based on FEC, i.e., to just give the number of >> missing packets (and which block they are from) instead of an explicit >list >> of missing packets? >> Mike >> >> -----Original Message----- >> From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Luigi >> Rizzo >> Sent: Tuesday, August 29, 2000 6:52 AM >> To: Brian Whetten >> Cc: rmt@lbl.gov >> Subject: Re: Choices for TRACK/NACK report encoding >> >> >> > RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this is >> > reasonably accurate for low values of P) >> >> mumble... wonder what did you use to compute the RLE bitmap size >> for p in the range 0.1 to 0.5 below... was that an actual >> encoding or just the result from the above formula (which might >> not apply given your comment above) >> >> note though that maybe it is not such a good idea to issue selective >> naks for >100 losses at once (or said it differently, gropus of >> 1000 pkts with a loss rate of 10% or more), so maybe we could >> limit our attention to a relatively small set of missing pkts >> irrespective of window size. >> >> cheers >> luigi >> >> > Note that as P approaches 1 (worst case, which we need to plan for), we >> get: >> > List=32*N >> > Bitmap=N >> > RLE Bitmap=Actually goes down (because we encode successes rather than >> > losses), with a worst case always less than either of the other two (but >> > approaching the bitmap case). >> > >> > Here are numeric results for these formulas, in bits, assuming N=1000. >> > >> > p List NACK Bitmap RLE Bitmap >> > 0.001 32 1000 10 >> > 0.0031 101 1000 28.5 >> > 0.01 320 1000 70 >> > 0.031 1012 1000 158.1 >> > 0.1 3200 1000 400 >> > 0.31 10119 1000 632 >> > 0.66 21120 1000 660 >> > 0.9 28800 1000 400 >> > >> > As you can see, List NACKs are better than a bitmap for P<3%, and worse >> > otherwise. A RLE bitmap is the most complicated to implement, but is >also >> > the most efficient for all cases. >> > >> > A related topic to this is the idea of reliable NACKs. Taking PGM as an >> > example, it uses reliable NACKs, which make a lot of sense if none of >> these >> > encoding mechanisms are used, since there is no built in redundancy >across >> > successive NACKs in that case. I think that NORM/PGM's biggest >advantage >> > is being able to work without needing reliability mechanisms, which >gives >> > these protocols better scalability in the face of failures. The >reliable >> > NACKs actually go directly in the face of this, and increase the amount >of >> > NACK implosion traffic that would occur when a network partition occurs. >> > >> > I believe that the need for reliable NACKs could be removed in NACK-only >> > protocols (as it is in TRACK oriented protocols) by reporting a full >> status >> > of all the non-stable packets. With a RLE mechanism, this scales very >> > nicely, and I think the overhead of adding the RLE mechanism would be >less >> > than the complexity of reliable NACKs. >> > >> > Conclusion: I think we should standardize on non-reliable NACKs/TRACKs >> > (they are basically the same thing, just generated at different times), >> > which use the same encoding format for their retransmission request >> > reports. I think that RLE encoded bitmaps should be used for this, >since >> > the system needs to be stable even in the face of very high loss rates >and >> > high data rates. >> > >> > Comments? >> > Brian >> > >> > >> >> > >-- >Todd L. Montgomery >Talarian Corporation >304-291-5972 >todd@talarian.com > > >From owner-rmt@listserv.lbl.gov Tue Aug 29 17:30:47 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id RAA05454; Tue, 29 Aug 2000 17:28:55 -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 RAA05450 for ; Tue, 29 Aug 2000 17:28: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 RAA23564 for ; Tue, 29 Aug 2000 17:28:53 -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 RAA23560 for ; Tue, 29 Aug 2000 17:28:52 -0700 (PDT) Received: from tahoe (talarian32-66.talarian.com [207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id RAA25891; Tue, 29 Aug 2000 17:27:13 -0700 (PDT) Message-Id: <4.1.20000829163742.01c18540@mailhost.talarian.com> X-Sender: bwhetten@mailhost.talarian.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 29 Aug 2000 17:21:36 -0700 To: "Mike Luby" , "Todd L. Montgomery" From: Brian Whetten Subject: RE: Choices for TRACK/NACK report encoding Cc: "Luigi Rizzo" , In-Reply-To: References: <4.1.20000829143701.01ba2b70@mailhost.talarian.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rmt@lbl.gov Precedence: bulk This was a good contribution. Thanks, Mike. As always, I was assuming everyone already agreed on the design principles and was just throwing out potential solutions. :) Todd had a good point about being able to encode the number of lost packets in a block very efficiently. I've added another column for this, which I'll title block count. I model its overhead as: Block Count=32*n/b*(1-(1-p)^b), where n=number of packets in the encoded window, b is the size of the FEC block, and p is the probability for loss. I ran three cases, for b=8, 32, and 128. I actually think that smaller block sizes will most often be used for NACK/TRACK based protocols, since otherwise you would likely use the ALC scheme instead. Again, for RLE it is probably off by up to a factor of 2 for the middle cases due to my rough model used. For b=8, the block count is only marginally better than a straight list NACK until the loss rate gets above 10%, and is still worse than bitmap at that point. For b=32, the block count method is approximatley equal to the list for low loss rates, and equal to bitmap for high loss rates, which is a desireable combination. For b=128, Block Count is the most efficient. For B=8 or B=32, RLE still appears to be the most efficient. Going by your prioritization list: - I believe that all of these EXCEPT for List NACKs can easily meet #1 and #2, and therefore also #3. List NACKs has to be combined with one of the others to meet these requirements. Again, this assumes that the sender can derive block counts from a complete bitmap list. - In terms of #6 (simplicity), I believe that RLE is the most complex of the four, and that any single one is less complex than having to specify and implement any two of the others. I think that List NACKs bring higher reliance on reliable NACK mechanisms, which (in terms relative to the complexity of these mechanisms) are very complex. - In terms of #4 and #7 (efficiency in all/worst cases), I think that RLE best meets these requirements, because it works efficiently with b=1 (no FEC, which is a common case we need to be concerned with), b=8, and b=128. The only scenario where it is not the best (again, given my rough model for RLE) is when both p and b are large (p>=10% and b>=64). - For #5, Bitmap and RLE satisfy this, the others don't. So, I think that RLE is the best of the mechanisms proposed, given this analysis and set of requirements. The complexity of having to do two encoding schemes and/or reliable NACKs, combined with its efficiency, is what recommends it to me. Comments? Any mistakes I've made? Brian Tables: b p List Bitmap RLE Block Count 8 0.001 32 1000 10 32 8 0.003 101 1000 28 100 8 0.010 320 1000 70 309 8 0.032 1012 1000 158 907 8 0.100 3200 1000 400 2278 8 0.316 10119 1000 632 3809 8 0.500 16000 1000 500 3984 8 0.660 21120 1000 660 3999 8 0.900 28800 1000 400 4000 b p List Bitmap RLE Block Count 32 0.001 32 1000 10 32 32 0.003 101 1000 28 96 32 0.010 320 1000 70 275 32 0.032 1012 1000 158 642 32 0.100 3200 1000 400 966 32 0.316 10119 1000 632 1000 32 0.500 16000 1000 500 1000 32 0.660 21120 1000 660 1000 32 0.900 28800 1000 400 1000 b p List Bitmap RLE Block Count 128 0.001 32 1000 10 30 128 0.003 101 1000 28 83 128 0.010 320 1000 70 181 128 0.032 1012 1000 158 246 128 0.100 3200 1000 400 250 128 0.316 10119 1000 632 250 128 0.500 16000 1000 500 250 128 0.660 21120 1000 660 250 128 0.900 28800 1000 400 250 At 04:00 PM 8/29/2000 -0700, Mike Luby wrote: >The additional design goals make sense. I would prioritize almost the same: > >(1,2),6,(4,7),5,3. > >(Parenthesis enclose goals of similar priority). Given this, the question >then is: does a NACK scheme that meets these goals in this priority order >jump out? (My only goal was to drive the design process starting from the >goals, not from the mechanisms. This may be where I stop contributing.) > >Mike > >-----Original Message----- >From: Brian Whetten [mailto:whetten@talarian.com] >Sent: Tuesday, August 29, 2000 2:46 PM >To: Mike Luby; Todd L. Montgomery >Cc: Luigi Rizzo; rmt@lbl.gov >Subject: RE: Choices for TRACK/NACK report encoding > > >I would add: >(5) Being able to efficiently encode as many losses across as many blocks >as possible. i.e. being able to report a history of outstanding lost >packets, rather than just the most recent ones. >(6) Simplicity >(7) Being stable in the face of very high loss rates, either of data >packets and/or NACK packets. > >I would prioritize 1,2,6,7 as having the highest importance. > >Brian > >At 12:36 PM 8/29/2000 -0700, Mike Luby wrote: >>As design goals, it would seem to be desirable: >> >>(1) That explicit packets can be NACKed per block. >>(2) That a count of packets can be NACKed per block. >>(3) That the mechanisms that achieve (1) and (2) are compatible with each >>other. >>(4) That the mechanisms would work relatively efficiently independent of >the >>loss per block or the size of the block. >> (a) Would be desirable to work with small as well as large blocks (in >>terms of number of packets per block). >> (b) Would be desirable that the block size in packets doesn't have to >>fit any special requirements, e.g., be a power of 2. >> (c) Would be desirable that the scheme would scale with the number of >>losses per block, in particular when the report is a count then one should >>report any number between 0 and the size of the block in packets. >> >>Do these goals make sense, and how would people prioritize these goals, and >>are there other goals that are even more important that are missing? Once >>the goals and their relative priority are clear, then the design may just >>fall out as a natural consequence. >>Mike >> >>-----Original Message----- >>From: Todd L. Montgomery [mailto:todd@talarian.com] >>Sent: Tuesday, August 29, 2000 12:00 PM >>To: Mike Luby >>Cc: Luigi Rizzo; Brian Whetten; rmt@lbl.gov >>Subject: RE: Choices for TRACK/NACK report encoding >> >> >> >>I hope there is. PGMs FEC adds a nice feature that allows a block >>to report it's loss count and pack that into a 32-bit number >>no matter how big the block. That is a LOT smaller with List NAKs >>than a bitmap can be. >> >>To do this, the block size (in packets) must be a power of 2, but that is >>not very restrictive. >> >>On Tue, 29 Aug 2000, Mike Luby wrote: >> >>> Is there an option to NACK based on FEC, i.e., to just give the number of >>> missing packets (and which block they are from) instead of an explicit >>list >>> of missing packets? >>> Mike >>> >>> -----Original Message----- >>> From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Luigi >>> Rizzo >>> Sent: Tuesday, August 29, 2000 6:52 AM >>> To: Brian Whetten >>> Cc: rmt@lbl.gov >>> Subject: Re: Choices for TRACK/NACK report encoding >>> >>> >>> > RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this is >>> > reasonably accurate for low values of P) >>> >>> mumble... wonder what did you use to compute the RLE bitmap size >>> for p in the range 0.1 to 0.5 below... was that an actual >>> encoding or just the result from the above formula (which might >>> not apply given your comment above) >>> >>> note though that maybe it is not such a good idea to issue selective >>> naks for >100 losses at once (or said it differently, gropus of >>> 1000 pkts with a loss rate of 10% or more), so maybe we could >>> limit our attention to a relatively small set of missing pkts >>> irrespective of window size. >>> >>> cheers >>> luigi >>> >>> > Note that as P approaches 1 (worst case, which we need to plan for), we >>> get: >>> > List=32*N >>> > Bitmap=N >>> > RLE Bitmap=Actually goes down (because we encode successes rather than >>> > losses), with a worst case always less than either of the other two >(but >>> > approaching the bitmap case). >>> > >>> > Here are numeric results for these formulas, in bits, assuming N=1000. >>> > >>> > p List NACK Bitmap RLE Bitmap >>> > 0.001 32 1000 10 >>> > 0.0031 101 1000 28.5 >>> > 0.01 320 1000 70 >>> > 0.031 1012 1000 158.1 >>> > 0.1 3200 1000 400 >>> > 0.31 10119 1000 632 >>> > 0.66 21120 1000 660 >>> > 0.9 28800 1000 400 >>> > >>> > As you can see, List NACKs are better than a bitmap for P<3%, and worse >>> > otherwise. A RLE bitmap is the most complicated to implement, but is >>also >>> > the most efficient for all cases. >>> > >>> > A related topic to this is the idea of reliable NACKs. Taking PGM as >an >>> > example, it uses reliable NACKs, which make a lot of sense if none of >>> these >>> > encoding mechanisms are used, since there is no built in redundancy >>across >>> > successive NACKs in that case. I think that NORM/PGM's biggest >>advantage >>> > is being able to work without needing reliability mechanisms, which >>gives >>> > these protocols better scalability in the face of failures. The >>reliable >>> > NACKs actually go directly in the face of this, and increase the amount >>of >>> > NACK implosion traffic that would occur when a network partition >occurs. >>> > >>> > I believe that the need for reliable NACKs could be removed in >NACK-only >>> > protocols (as it is in TRACK oriented protocols) by reporting a full >>> status >>> > of all the non-stable packets. With a RLE mechanism, this scales very >>> > nicely, and I think the overhead of adding the RLE mechanism would be >>less >>> > than the complexity of reliable NACKs. >>> > >>> > Conclusion: I think we should standardize on non-reliable NACKs/TRACKs >>> > (they are basically the same thing, just generated at different times), >>> > which use the same encoding format for their retransmission request >>> > reports. I think that RLE encoded bitmaps should be used for this, >>since >>> > the system needs to be stable even in the face of very high loss rates >>and >>> > high data rates. >>> > >>> > Comments? >>> > Brian >>> > >>> > >>> >>> >> >>-- >>Todd L. Montgomery >>Talarian Corporation >>304-291-5972 >>todd@talarian.com >> >> > > > >From owner-rmt@listserv.lbl.gov Wed Aug 30 01:11:07 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id BAA06118; Wed, 30 Aug 2000 01:07: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 BAA06114 for ; Wed, 30 Aug 2000 01:07:43 -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 BAA01884 for ; Wed, 30 Aug 2000 01:07:42 -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 BAA01881 for ; Wed, 30 Aug 2000 01:07:41 -0700 (PDT) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.10.0/8.10.0) id e7U87fX11665; Wed, 30 Aug 2000 01:07:41 -0700 (PDT) Message-Id: <200008300807.e7U87fX11665@daffy.ee.lbl.gov> To: rmt@lbl.gov Subject: Round 2 - you may be deleted from rmt@lbl.gov - please read! Date: Wed, 30 Aug 2000 01:07:41 PDT From: Vern Paxson Sender: owner-rmt@lbl.gov Precedence: bulk I have been getting repeated bounces from the following addresses for the RMT mailing list rmt@lbl.gov: erwan.humez@detexis.thomson-csf.com ietflist.rmt@icn.siemens.de rmontgom@cabletron.com sangli@cse.iitk.ac.in I plan to delete these addresses in a week or so unless I hear back that particular addresses should be kept or changed. Your RMT list maintainer, Vern >From owner-rmt@listserv.lbl.gov Wed Aug 30 07:13:57 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id HAA07512; Wed, 30 Aug 2000 07:11:42 -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 HAA07508 for ; Wed, 30 Aug 2000 07:11:40 -0700 (PDT) From: rhboivie@us.ibm.com Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA02763 for ; Wed, 30 Aug 2000 07:11:39 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA02758 for ; Wed, 30 Aug 2000 07:11:38 -0700 (PDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA36276; Wed, 30 Aug 2000 10:00:06 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.93) with SMTP id KAA20680; Wed, 30 Aug 2000 10:11:37 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525694B.004DF6F9 ; Wed, 30 Aug 2000 10:11:34 -0400 X-Lotus-FromDomain: IBMUS To: "Dave Oran" cc: xcast@public.alcatel.com, rmt@lbl.gov Message-ID: <8525694B.004D959F.00@d54mta04.raleigh.ibm.com> Date: Wed, 30 Aug 2000 10:07:09 -0400 Subject: RE: Adding reliable transport layer above sgm/xcsat Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-rmt@lbl.gov Precedence: bulk >My knowledge of reliable multicast is spotty at best, so I wade in here with >some trepidation. Since this is a side issue wrt SGM, feel free to drop this >thread at any point. I just want to make sure that any claims are >supportable with analysis or hard facts. See below. Dave, I'm also ok with dropping this thread since this is, as you say, a side issue wrt SGM. I'm just saying that the the ability to selectively specify a subset of the destinations and the ability to efficiently deliver data to a subset of destinations lend themselves to reliable multicast since you can do the re-transmissions efficiently if you want to. But as I said, I agree that we can drop this thread since this is kind of a side issue. Rick re: >I don't know at all how you got there. I didn't respond to Yuji's note >because I assumed he was just pointing out that if you did (audio) >conference bridges with SGM, that would win over multi-unicast. If you >factor out the group-state-in-the-routers, the optimal strategy is each >source unicasting to the bridge, and the bridge unicasting back to the >active sources (since each sees a unique mix), and multicasting to the >non-active sources. Yuji's point was that when you multicast to the non-active sources, you may need a number of different class-D addresses, one for each combination of non-active sources ie. in a 5-party conference consisting of parties 1, 2, 3, 4 and 5, you need one multicast group for 2,3,4,5, and one for 1,3,4,5 and one for 1,2,4,5 ... And you need one class D address for each of the various combinations of 3 members, the combinations of 2 members etc. >From owner-rmt@listserv.lbl.gov Wed Aug 30 07:14:55 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id HAA07518; Wed, 30 Aug 2000 07:13: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 HAA07514 for ; Wed, 30 Aug 2000 07:13: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 HAA03029 for ; Wed, 30 Aug 2000 07:13:11 -0700 (PDT) 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 HAA03020 for ; Wed, 30 Aug 2000 07:13:10 -0700 (PDT) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id QAA55310; Wed, 30 Aug 2000 16:13:00 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200008301413.QAA55310@info.iet.unipi.it> Subject: Re: Choices for TRACK/NACK report encoding In-Reply-To: <4.1.20000829111049.01c18920@mailhost.talarian.com> from Brian Whetten at "Aug 29, 2000 11:14:45 am" To: Brian Whetten Date: Wed, 30 Aug 2000 16:13:00 +0200 (CEST) CC: Mike Luby , rmt@lbl.gov 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 > Hi there, ... > Brain interesting typo... does not look so nice for my name! lugii >From owner-rmt@listserv.lbl.gov Wed Aug 30 14:38:29 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id OAA08855; Wed, 30 Aug 2000 14:34:04 -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 OAA08851 for ; Wed, 30 Aug 2000 14:34:02 -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 OAA16576 for ; Wed, 30 Aug 2000 14:34:01 -0700 (PDT) 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 OAA16573 for ; Wed, 30 Aug 2000 14:34:00 -0700 (PDT) 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 RAA01911; Wed, 30 Aug 2000 17:30:49 -0400 (EDT) Mime-Version: 1.0 X-Sender: adamson@pop.itd.nrl.navy.mil Message-Id: In-Reply-To: <4.1.20000829143701.01ba2b70@mailhost.talarian.com> References: <4.1.20000829143701.01ba2b70@mailhost.talarian.com> Date: Wed, 30 Aug 2000 17:30:16 -0400 To: Brian Whetten From: Brian Adamson Subject: RE: Choices for TRACK/NACK report encoding Cc: "Mike Luby" , "Todd L. Montgomery" , "Luigi Rizzo" , , adamson@itd.nrl.navy.mil, macker@itd.nrl.navy.mil Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-rmt@lbl.gov Precedence: bulk I agree with these goals for NACKs as well ... The NACK Content discussion in the current NORM building block draft (but I probably should have put more on "goals" in the draft than just the "solutions" presented) tries to meet these sorts of goals: 1) Explicit packets per block 2) Count of packets NACKed per block 3) Simplicity 4) Independent of block size (within constraints of messaging size ... if a coding blocks are so large that a bit mask (even compressed) representing it can't be fit into a single NACK message some additional fields to support fragmentation might be needed ... but does not necessarily break the protocol given other aspects of the sender<->receiver NACK/repair process) I think the other important goals (stability in high loss, _working_ at all) are also dependent upon the entire NACK process ... i.e. how the NACK messages are used and of course not just the format of the messages themselves. I think it's worthwhile to consider creating a a general NACK format ... particularly to get to a goal of generic router assist in NACK aggregation. I think a general format can be created which satisfies the stated goals and provides the functionality needed for different protocols using NACKs ... The goals outlined make sense for what I hope NORM turns out to be These are also in line with the goals we had for the MDP protocol (some of the current NORM ideas are of course pulled from my experience here) ... In MDP, a NACK message can contain a concatenation of repair requests for coding blocks missed in entirety (if any, which can happen for various reasons) as well as an explicit indication of missing packets within specific partially received coding blocks _and_ a count of the number of erasures for each of those coding blocks. So an individual Repair Request has the following fields: ObjectId - Identifier of transport object or stream requiring repair RepairRequestType - SEGMENT, BLOCK, OBJECT, or INFO NumErasures - count of missing packets (segments) for SEGMENT repair request Offset - starting point of bit mask which follows (coding block identifier) MaskLen - length of bit mask which follows Mask - Bit mask which marks specific blocks or segments needing repair depending upon the RepairRequestType Multiple of these "Repair Requests" are concatenated as needed to form a NACK message. We limit the growth of the size of an individual NACK message to the current multicast session MTU. At most, a single NACK message is sent per repair cycle by a given receiver with respect to a given sender. There is no need for reliability of NACKs given that subsequent transmissions (or lack thereof) by the sender provide an implicit indication of whether the receiver needs to NACK again or not. As Brian Whetten points out, run-length encoding of the bit masks would improve the efficiency of NACK packing in _some_ cases. We have found the above scheme to work well in a variety of situations, but haven't studied NACK size explicitly. (BTW, this could be easily studied with some ns simulations) The above hierarchical NACK lets us NACK for either an entire object (or stream), or some set missing blocks, and/or missing segments efficiently. The receivers' NACKs aren't allowed to grow beyond one session MTU in size The NACK process is self-limited in that all receivers always NACK for the _oldest_ missing data ... the sender follows the rule that it will repair oldest data first (This allows the packing of NACK content be limited to what will fit in one packet)... Thus, receivers constrain themselves from NACKing again until they see the sender's sequence of transmission exceed the point at which they have missing data (This is how the receiver is implicitly aware that the sender has failed to fulfill his repair needs whether from lost repair transmissions or that the receiver's NACK was lost)... The receiver is also constrained by GRTT timing rules to allow the sender sufficient time to receive NACKs, aggregate them, and begin transmitting repairs, etc The above fields may need some additional generalization ... For example, in MDP the "NumErasures" field is an 8-bit value assuming Reed Solomon FEC with 8-bit words ... The erasure count simplifies sender-side processing ... The explicit content is important so that there doesn't need to be synchronization among clients and the sender with respect to multiple repair cycles ... An erasure count alone isn't sufficient to tell the sender to which repair round (1st, 2nd, 3rd, etc) the NACK is applicable ... We found it simplest to have the receivers provide an indication of explicit repair needs even though FEC is usually used for repair ... And the bit masks are easy for the server to process for repair aggregation and receivers (and hopefully eventually routers) to process for NACK suppression purposes ... At 2:46 PM -0700 8/29/00, Brian Whetten wrote: >I would add: >(5) Being able to efficiently encode as many losses across as many blocks >as possible. i.e. being able to report a history of outstanding lost >packets, rather than just the most recent ones. >(6) Simplicity >(7) Being stable in the face of very high loss rates, either of data >packets and/or NACK packets. > >I would prioritize 1,2,6,7 as having the highest importance. > >Brian > >At 12:36 PM 8/29/2000 -0700, Mike Luby wrote: > >As design goals, it would seem to be desirable: > > > >(1) That explicit packets can be NACKed per block. > >(2) That a count of packets can be NACKed per block. > >(3) That the mechanisms that achieve (1) and (2) are compatible with each > >other. > >(4) That the mechanisms would work relatively efficiently independent of the > >loss per block or the size of the block. > > (a) Would be desirable to work with small as well as large blocks (in > >terms of number of packets per block). > > (b) Would be desirable that the block size in packets doesn't have to > >fit any special requirements, e.g., be a power of 2. > > (c) Would be desirable that the scheme would scale with the number of > >losses per block, in particular when the report is a count then one should > >report any number between 0 and the size of the block in packets. > > > >Do these goals make sense, and how would people prioritize these goals, and > >are there other goals that are even more important that are missing? Once > >the goals and their relative priority are clear, then the design may just > >fall out as a natural consequence. > >Mike > > Brian __________________________________ Brian Adamson >From owner-rmt@listserv.lbl.gov Thu Sep 7 12:04:52 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id MAA14434; Thu, 7 Sep 2000 12:01:23 -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 MAA14430 for ; Thu, 7 Sep 2000 12:01:21 -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 MAA22007 for ; Thu, 7 Sep 2000 12:01:20 -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 MAA21996 for ; Thu, 7 Sep 2000 12:01:19 -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 MAA05488; Thu, 7 Sep 2000 12:01:17 -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 PAA13675; Thu, 7 Sep 2000 15:01:16 -0400 (EDT) Received: from bridge (bridge [129.148.75.125]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id PAA08321; Thu, 7 Sep 2000 15:01:15 -0400 (EDT) Message-Id: <200009071901.PAA08321@bcn.East.Sun.COM> Date: Thu, 7 Sep 2000 15:01:14 -0400 (EDT) From: Dah Ming Chiu - Sun Microsystems Reply-To: Dah Ming Chiu - Sun Microsystems Subject: Re: Choices for TRACK/NACK report encoding To: rmt@lbl.gov Cc: whetten@talarian.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: IqPwktKKWF/+PS9/WA2fiA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-rmt@lbl.gov Precedence: bulk I had a brief discussion with Brian Whetten regarding his concerns on loss packet report encoding. He seems to be concerned with a scenario where there are a large number, K, packets in flight (meaning potentially a receiver may report a loss of any one of them), where K can be as large as many thousands. A receiver lost the first of the K packets; and due to the fat-long pipe to its repair head (or sender), it soon is receiving the Kth packet before the first lost packet is repaired. In this "worse case" example, the receiver also lost the (K-1)th packet. So this receiver needs an efficient way to report the status of K packets (received or not received) to its repair head or the sender. Based on this, he did a quick analysis of three schemes: a) listing out the sequence number of each lost packet b) use a bitmask of size K to indicate which ones are lost c) use Run Length Encoding to indicate which ones are lost and concluded that RLE is the best. In the particular example above, a total of 2 of K packets lost, the rough encoding overhead is respectively: a) 2*W b) W+K c) W+2*logK where W is the size of a sequence number (32). If in additional to the above 2 lost packet, there are an additional (n-2) lost packets - making it a total of n lost packets, then: a) n*W b) W+K c) W+n*logK What is wrong with this analysis, I think some other people have also pointed out, is that it does not take into account the option of sending multiple ACKs (here an ACK is a general term for a common receipt/lost reporting message). Of course, there is some overhead in sending each ACK. But in the case of (b), sending multiple ACKs would be more efficient than sending a huge bitmask of size K. It is complicated to do an exact analysis of the different encodings taking into account of the option of sending multiple ACKs. On the other hand, I don't think the result differ that much for us to be concerned about it. I think we should just adopt something simple. Having a sequence number plus an optional bit mask - where the sequence number indicates receipt up to, and the mask indicates lost packets - is simple and flexible. As to whether it makes sense to run a reliability service with K packets in flight for such large K makes sense or not, that is another debate. Does this make sense? Dah Ming >From owner-rmt@listserv.lbl.gov Fri Sep 8 00:18:22 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id AAA17019; Fri, 8 Sep 2000 00:15:45 -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 AAA17015 for ; Fri, 8 Sep 2000 00:15:43 -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 AAA18894 for ; Fri, 8 Sep 2000 00:15:43 -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 AAA18891 for ; Fri, 8 Sep 2000 00:15:41 -0700 (PDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 8 Sep 2000 08:15:26 +0100 To: Dah Ming Chiu - Sun Microsystems cc: rmt@lbl.gov, whetten@talarian.com Subject: Re: Choices for TRACK/NACK report encoding In-reply-to: Your message of "Thu, 07 Sep 2000 15:01:14 EDT." <200009071901.PAA08321@bcn.East.Sun.COM> Date: Fri, 08 Sep 2000 08:15:24 +0100 Message-ID: <1132.968397324@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk analysis looks ok to me - there was an analysis done for SACK in TCP that is worth re-reading (look on end2end-interest archive) its not clear why multicast is so different (theres probably enough reasons for occasional feedback messages and a hierarchy for very large groups that within each group the loss feedback packet encdoding can be similar to SACK or possibly RTCP... one thing is do we believe in long loss bursts or scattered bursts...? In message <200009071901.PAA08321@bcn.East.Sun.COM>, Dah Ming Chiu - Sun Micros ystems typed: >>I had a brief discussion with Brian Whetten regarding his concerns >>on loss packet report encoding. >> >>He seems to be concerned with a scenario where there are a large number, >>K, packets in flight (meaning potentially a receiver may report a >>loss of any one of them), where K can be as large as many thousands. >>A receiver lost the first of the K packets; and due to the fat-long >>pipe to its repair head (or sender), it soon is receiving the Kth packet >>before the first lost packet is repaired. In this "worse case" example, >>the receiver also lost the (K-1)th packet. So this receiver needs an >>efficient way to report the status of K packets (received or not received) >>to its repair head or the sender. >> >>Based on this, he did a quick analysis of three schemes: >>a) listing out the sequence number of each lost packet >>b) use a bitmask of size K to indicate which ones are lost >>c) use Run Length Encoding to indicate which ones are lost >>and concluded that RLE is the best. >> >>In the particular example above, a total of 2 of K packets lost, the rough >>encoding overhead is respectively: >>a) 2*W >>b) W+K >>c) W+2*logK >>where W is the size of a sequence number (32). >> >>If in additional to the above 2 lost packet, there are an additional (n-2) >>lost packets - making it a total of n lost packets, then: >>a) n*W >>b) W+K >>c) W+n*logK >> >>What is wrong with this analysis, I think some other people have also >>pointed out, is that it does not take into account the option of sending >>multiple ACKs (here an ACK is a general term for a common receipt/lost >>reporting message). Of course, there is some overhead in sending each >>ACK. But in the case of (b), sending multiple ACKs would be more efficient >>than sending a huge bitmask of size K. >> >>It is complicated to do an exact analysis of the different encodings taking >>into account of the option of sending multiple ACKs. On the other hand, >>I don't think the result differ that much for us to be concerned about it. >> >>I think we should just adopt something simple. Having a sequence number >>plus an optional bit mask - where the sequence number indicates receipt >>up to, and the mask indicates lost packets - is simple and flexible. >> >>As to whether it makes sense to run a reliability service with K packets >>in flight for such large K makes sense or not, that is another debate. >> >>Does this make sense? >> >>Dah Ming >> >> cheers jon >From owner-rmt@listserv.lbl.gov Fri Sep 8 01:35:26 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id BAA17110; Fri, 8 Sep 2000 01:33: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 BAA17106 for ; Fri, 8 Sep 2000 01:33: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 BAA24604 for ; Fri, 8 Sep 2000 01:33:02 -0700 (PDT) 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 BAA24597 for ; Fri, 8 Sep 2000 01:33:01 -0700 (PDT) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id KAA32615; Fri, 8 Sep 2000 10:34:37 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200009080834.KAA32615@info.iet.unipi.it> Subject: Re: Choices for TRACK/NACK report encoding In-Reply-To: <1132.968397324@cs.ucl.ac.uk> from Jon Crowcroft at "Sep 8, 2000 08:15:24 am" To: Jon Crowcroft Date: Fri, 8 Sep 2000 10:34:37 +0200 (CEST) CC: Dah Ming Chiu - Sun Microsystems , rmt@lbl.gov, whetten@talarian.com 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 > analysis > looks ok to me - there was an analysis done for SACK in TCP that is > worth re-reading (look on end2end-interest archive) i do not remember the details but the result ("we only need 3 sack blocks") look more driven by available option space than other considerations. I believe one reason multicast is somewhat different is that delayed feedback gives you the chance to report slightly higher amt of losses in a single msg as opposed to what you do in TCP where you {S|N}AK immediately. > one thing is do we believe in long loss bursts or scattered > bursts...? the experience with mbone sessions is often 30s bursts of silence, but that can be fixed hopefully... Seriously speaking, as long as multicast sessions are not as bursty as TCP, i think that more than long loss bursts (which are usually due to routing problems) we can see the typical losses due to rate mismatches, or patterns like this ....x....x....x....x....x.... ...x..x..x..x..x..x..x..x..x. .xxx.xxx.xxx.xxx.xxx.xxx.xxx. cheers luigi >From owner-rmt@listserv.lbl.gov Fri Sep 8 01:39:51 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id BAA17138; Fri, 8 Sep 2000 01:38:05 -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 BAA17134 for ; Fri, 8 Sep 2000 01:38: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 BAA25031 for ; Fri, 8 Sep 2000 01:38:03 -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 BAA25028 for ; Fri, 8 Sep 2000 01:38:02 -0700 (PDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 8 Sep 2000 09:37:56 +0100 To: Luigi Rizzo cc: Dah Ming Chiu - Sun Microsystems , rmt@lbl.gov, whetten@talarian.com Subject: Re: Choices for TRACK/NACK report encoding In-reply-to: Your message of "Fri, 08 Sep 2000 10:34:37 +0200." <200009080834.KAA32615@info.iet.unipi.it> Date: Fri, 08 Sep 2000 09:37:54 +0100 Message-ID: <2045.968402274@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk In message <200009080834.KAA32615@info.iet.unipi.it>, Luigi Rizzo typed: >>> analysis >>> looks ok to me - there was an analysis done for SACK in TCP that is >>> worth re-reading (look on end2end-interest archive) >> >>i do not remember the details but the result ("we only need 3 >>sack blocks") look more driven by available option space than >>other considerations. I believe one reason multicast is somewhat different >>is that delayed feedback gives you the chance to report slightly higher >>amt of losses in a single msg as opposed to what you do in TCP >>where you {S|N}AK immediately. >> >>> one thing is do we believe in long loss bursts or scattered >>> bursts...? >> >>the experience with mbone sessions is often 30s bursts of silence, >>but that can be fixed hopefully... >>Seriously speaking, as long as multicast sessions are not as bursty >>as TCP, i think that more than long loss bursts (which are usually >>due to routing problems) we can see the typical losses due to rate >>mismatches, or patterns like this >> >> ....x....x....x....x....x.... >> ...x..x..x..x..x..x..x..x..x. >> .xxx.xxx.xxx.xxx.xxx.xxx.xxx. luigi and of course wee might want to consider router or repair server assist in aggregating the loss patterns... cheers jon >From owner-rmt@listserv.lbl.gov Fri Sep 8 07:54:41 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id HAA18547; Fri, 8 Sep 2000 07:52:29 -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 HAA18543 for ; Fri, 8 Sep 2000 07:52:27 -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 HAA01041 for ; Fri, 8 Sep 2000 07:52:27 -0700 (PDT) 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 HAA01037 for ; Fri, 8 Sep 2000 07:52:26 -0700 (PDT) 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 KAA06465; Fri, 8 Sep 2000 10:52:05 -0400 (EDT) Mime-Version: 1.0 X-Sender: adamson@pop.itd.nrl.navy.mil Message-Id: In-Reply-To: <200009080834.KAA32615@info.iet.unipi.it> References: <200009080834.KAA32615@info.iet.unipi.it> Date: Fri, 8 Sep 2000 10:52:05 -0400 To: Luigi Rizzo From: Brian Adamson Subject: Re: Choices for TRACK/NACK report encoding Cc: Jon Crowcroft , Dah Ming Chiu - Sun Microsystems , rmt@lbl.gov, whetten@talarian.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-rmt@lbl.gov Precedence: bulk At 10:34 AM +0200 9/8/00, Luigi Rizzo wrote: > > analysis > > looks ok to me - there was an analysis done for SACK in TCP that is > > worth re-reading (look on end2end-interest archive) > >i do not remember the details but the result ("we only need 3 >sack blocks") look more driven by available option space than >other considerations. I believe one reason multicast is somewhat different >is that delayed feedback gives you the chance to report slightly higher >amt of losses in a single msg as opposed to what you do in TCP >where you {S|N}AK immediately. > > > one thing is do we believe in long loss bursts or scattered > > bursts...? > >the experience with mbone sessions is often 30s bursts of silence, >but that can be fixed hopefully... >Seriously speaking, as long as multicast sessions are not as bursty >as TCP, i think that more than long loss bursts (which are usually >due to routing problems) we can see the typical losses due to rate >mismatches, or patterns like this > > ....x....x....x....x....x.... > ...x..x..x..x..x..x..x..x..x. > .xxx.xxx.xxx.xxx.xxx.xxx.xxx. One of the nice applications of reliable multicast is over satellite services ... at reasonable data rates (several megabits per second), outages which are relatively momentary (a few seconds) can span several FEC coding blocks worth of information and do occur occasionally ... Also depending upon different application policies of when/how receivers join & leave groups or discontinuities during handoff in mobile-wireless systems, there will be times when receivers need to NACK for large portions of data ... Those are some of the reasons I would propose a hierarchical scheme for NACK encoding given that use of FEC blocks (if applicable) provide a natural boundary ... I suppose this isn't much different from the end result of a run-length encoding scheme, but alignment of hierarchical NACKs to coding blocks was easy to implement. > cheers > luigi Brian __________________________________ Brian Adamson >From owner-rmt@listserv.lbl.gov Fri Sep 8 08:12:53 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id IAA18582; Fri, 8 Sep 2000 08:11: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 IAA18578 for ; Fri, 8 Sep 2000 08:11: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 IAA05502 for ; Fri, 8 Sep 2000 08:11:08 -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 IAA05499 for ; Fri, 8 Sep 2000 08:11:07 -0700 (PDT) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 8 Sep 2000 16:10:49 +0100 To: Brian Adamson cc: rmt@lbl.gov Subject: Re: Choices for TRACK/NACK report encoding In-reply-to: Your message of "Fri, 08 Sep 2000 10:52:05 EDT." Date: Fri, 08 Sep 2000 16:10:49 +0100 Message-ID: <2163.968425849@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk so we have a large range+accuracy problem in returning data to the sender(s) about missing sequence numbers and so if the ack return path is noisy, then lets subject the problem to the same attack s we did to data in the forward path layered FEC encoded SACK messages... cheers jon >From owner-rmt@listserv.lbl.gov Fri Sep 8 10:42:46 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id KAA19209; Fri, 8 Sep 2000 10:40:49 -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 KAA19205 for ; Fri, 8 Sep 2000 10:40: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 KAA23042 for ; Fri, 8 Sep 2000 10:40:47 -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 KAA23038 for ; Fri, 8 Sep 2000 10:40:46 -0700 (PDT) Received: from tahoe (talarian32-66.talarian.com [207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id KAA01685; Fri, 8 Sep 2000 10:40:10 -0700 (PDT) Message-Id: <4.1.20000908100047.021b5eb0@mailhost.talarian.com> X-Sender: bwhetten@mailhost.talarian.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 08 Sep 2000 10:39:30 -0700 To: Jon Crowcroft , Brian Adamson From: Brian Whetten Subject: Re: Choices for TRACK/NACK report encoding Cc: rmt@lbl.gov In-Reply-To: <2163.968425849@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-rmt@lbl.gov Precedence: bulk Hello, My original concern were that I would like us to come up with ONE form for NACK encoding, that is the same for both TRACK and NACK, and is as simple as possible. Also, I would like the mechanism to have enough redundancy built in that reliable NACKs are not needed. Jon, RM is different than unicast primarily because optimizing the return control traffic is one of our primary challenges (i.e. minimizing ACK/NACK implosion). Dah Ming, good point. Actually, the biggest problem with bitmaps, that I forgot about, is how you do the aggregation of FEC counts as you move up a hierarchy. You can solve this, but only with added complexity. If you are using one big RLE bitmap, you have to unpack it to make it intelligible by the intermediary nodes, which is probably too much overhead. Jon, I think FEC encoded NACK bitmaps is overly complex and unecessary, but I'm not sure I actually understand what your proposal is. Brian, my initial reaction to your proposal was that it was too complex, but now I'm not so sure. One issue though, is that you need to pass up the most recent congestion information you have in each NACK. If you are not NACKing the most recent packets, then this has to definitely be explicitly reported, rather than implicitly derived at the sender. This might cause problems for PGMCC, for example. I think that the need to do FEC count aggregation is a good argument against using a single long RLE bitmap. So I think we are left with three primary design choices: 1) How to encode each block of packets? i.e. Count, Bitmap, None (for list NACKs, each block is of size 1) 2) How to encode the series of blocks? Do we assume that they are all sequential, or do you encode each block with its starting sequence number? (note that this assumes the length of each block is the same) 3) How much history to put in each NACK? Do we just list the most immediate packets, or do we have some partial redundancy, or do we always encode the entire outstanding window? The more information we encode, the simpler the NACK generation algorithms become, but the harder the encoding algorithms in order to be able to deal with large windows. Brian At 04:10 PM 9/8/2000 +0100, Jon Crowcroft wrote: > >so we have a large range+accuracy problem in returning >data to the sender(s) about missing sequence numbers >and so if the ack return path is noisy, then lets subject >the problem to the same attack s we did to data in the forward >path > >layered FEC encoded SACK messages... > > cheers > > jon > >From owner-rmt@listserv.lbl.gov Fri Sep 8 11:24:15 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id LAA19496; Fri, 8 Sep 2000 11:22:31 -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 LAA19492 for ; Fri, 8 Sep 2000 11:22:29 -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 LAA07554 for ; Fri, 8 Sep 2000 11:22:28 -0700 (PDT) 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 LAA07542 for ; Fri, 8 Sep 2000 11:22:27 -0700 (PDT) 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 OAA13297; Fri, 8 Sep 2000 14:19:02 -0400 (EDT) Mime-Version: 1.0 X-Sender: adamson@pop.itd.nrl.navy.mil Message-Id: In-Reply-To: <4.1.20000908100047.021b5eb0@mailhost.talarian.com> References: <4.1.20000908100047.021b5eb0@mailhost.talarian.com> Date: Fri, 8 Sep 2000 14:19:02 -0400 To: Brian Whetten From: Brian Adamson Subject: Re: Choices for TRACK/NACK report encoding Cc: Jon Crowcroft , rmt@lbl.gov Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-rmt@lbl.gov Precedence: bulk At 10:39 AM -0700 9/8/00, Brian Whetten wrote: >Hello, > >My original concern were that I would like us to come up with ONE form for >NACK encoding, that is the same for both TRACK and NACK, and is as simple >as possible. Also, I would like the mechanism to have enough redundancy >built in that reliable NACKs are not needed. > >Jon, RM is different than unicast primarily because optimizing the return >control traffic is one of our primary challenges (i.e. minimizing ACK/NACK >implosion). > >Dah Ming, good point. Actually, the biggest problem with bitmaps, that I >forgot about, is how you do the aggregation of FEC counts as you move up a >hierarchy. You can solve this, but only with added complexity. If you are >using one big RLE bitmap, you have to unpack it to make it intelligible by >the intermediary nodes, which is probably too much overhead. > >Jon, I think FEC encoded NACK bitmaps is overly complex and unecessary, but >I'm not sure I actually understand what your proposal is. I haven't grok'd that yet either. > >Brian, my initial reaction to your proposal was that it was too complex, >but now I'm not so sure. One issue though, is that you need to pass up the >most recent congestion information you have in each NACK. If you are not >NACKing the most recent packets, then this has to definitely be explicitly >reported, rather than implicitly derived at the sender. This might cause >problems for PGMCC, for example. The congestion control feedback could use different sequence information than the data content identification ... For example, if a different sequence number (i.e. different than the data content identification sequencing) is used to mark packets for loss detection that could be used in congestion control feedback ... In our MDP congestion control implementation, we don't insert congestion control probing information (which is marked with its own sequence number) separately from transmitted data ... For something like PGMCC which is doing a TCP-like ACK of the data packets, the "packet loss" sequence marker on the data packets could perhaps be used? ... I think data content identification needs to be separate for selective repair anyway? ... The "hierarchy" of coding block and segments gives you a degree of NACK compression analogous to RLE and then aggregation doesn't require the RLE decompression/re-encoding step you mention above > >I think that the need to do FEC count aggregation is a good argument >against using a single long RLE bitmap. > >So I think we are left with three primary design choices: >1) How to encode each block of packets? i.e. Count, Bitmap, None (for >list NACKs, each block is of size 1) >2) How to encode the series of blocks? Do we assume that they are all >sequential, or do you encode each block with its starting sequence number? >(note that this assumes the length of each block is the same) Yes ... my assumption was that the bitmask marked a sequential series of coding blocks ... in our case, the blocks are uniform in size so the "offset" or data content sequence identifier of the first segment of the block serves as the block identifier ... I think non-uniform blocks could be accommodated, but the block identifier might need to be interpreted differently ... but that might only be the concern of the end systems ... intermediate systems (like generic assist routers) might still be able to perform aggregation/pruning, etc without needing to know that information ... this would be different for more tree-based protocols which might wish to perform repair subcasting, etc. >3) How much history to put in each NACK? Do we just list the most >immediate packets, or do we have some partial redundancy, or do we always >encode the entire outstanding window? The more information we encode, the >simpler the NACK generation algorithms become, but the harder the encoding >algorithms in order to be able to deal with large windows. The policy I have used in the past is to put as much history in the NACK (only back to the point to where repair is needed) which will fit into a single NACK message using the multicast session MTU as the maximum payload size ... For normal circumstances, NACKs tend to be small ... this limit is only hit when conditions are bad ... In our protocol, the sender actually sort of nacks NACKs when those repair requests ask for repairs earlier in history than the server is willing to repair (for whatever reason, buffer limitations, expired data, etc) ... In this NACK to the NACK (which we actually call a SQUELCH command in protocol specification), the sender advertises his current "window" of data he is willing to repair ... This "SQUELCH" is multicast so that all receivers (some of which may be in the same state as the original NACKer) can "re-sync" to the sender and not generate anymore useless NACKs ... again this is the _exceptional_ occurrence when conditions are very bad, and server buffer limits (or other limits) are otherwise exceeded. >Brian Brian __________________________________ Brian Adamson >From owner-rmt@listserv.lbl.gov Fri Sep 8 13:20:01 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id NAA19869; Fri, 8 Sep 2000 13:17: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 NAA19865 for ; Fri, 8 Sep 2000 13:17: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 NAA14174 for ; Fri, 8 Sep 2000 13:17:15 -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 NAA14163 for ; Fri, 8 Sep 2000 13:17:14 -0700 (PDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA10058 for ; Fri, 8 Sep 2000 13:17:12 -0700 (PDT) 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 QAA22672 for ; Fri, 8 Sep 2000 16:17:11 -0400 (EDT) Received: from bridge (bridge [129.148.75.125]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id QAA12322 for ; Fri, 8 Sep 2000 16:17:11 -0400 (EDT) Message-Id: <200009082017.QAA12322@bcn.East.Sun.COM> Date: Fri, 8 Sep 2000 16:17:09 -0400 (EDT) From: Dah Ming Chiu - Sun Microsystems Reply-To: Dah Ming Chiu - Sun Microsystems Subject: Re: Choices for TRACK/NACK report encoding To: rmt@lbl.gov MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ipYhK4dbBjoAN6bKrs/siw== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-rmt@lbl.gov Precedence: bulk Brian Whetthen wrote: >My original concern were that I would like us to come up with ONE form for >NACK encoding, that is the same for both TRACK and NACK, and is as simple >as possible. Also, I would like the mechanism to have enough redundancy >built in that reliable NACKs are not needed. Yes, this is a very good goal. I am having a little trouble following Brian Adamson's "hierarchical coding block" proposal. I think the problem is with terminology. If you can bear with me and explain your needs in simple terms, perhaps we can work out some common format. Let me state what I understand, and you can correct me where I err: In TRACK terminology, regular FEC encoded stream does not require loss feedback - it is "open loop". In "reactive" FEC usage, the sender computes "parity" packets but does not send them until losses are reported. This is the case error reporting is needed. What is needed at the sender to determine what parity packets to send is a count of lost packets (given a window of packets), rather than the specific packets lost. This count determines the number of parity packets needed. To aggregate the count up the tree to the sender, you need a bitmap to know which packets are lost by each receiver so you don't count duplicate packets. This makes the requirement for reporting losses roughly the same wether it is ACK, NACK or reactive FEC. I think the common format can be as simple as plus other flags and identifiers. If we really have a huge bitmask, the question is whether it should sent as ... or i.e. separate packets. Could you explain your proposal in this simple terminology? Thanks Dah Ming >From owner-rmt@listserv.lbl.gov Sun Sep 10 07:03:41 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id GAA25770; Sun, 10 Sep 2000 06:59: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 GAA25766 for ; Sun, 10 Sep 2000 06:59: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 GAA17059 for ; Sun, 10 Sep 2000 06:59:47 -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 GAA17056 for ; Sun, 10 Sep 2000 06:59:46 -0700 (PDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 10 Sep 2000 14:58:24 +0100 To: Brian Whetten cc: Brian Adamson , rmt@lbl.gov Subject: Re: Choices for TRACK/NACK report encoding In-reply-to: Your message of "Fri, 08 Sep 2000 10:39:30 PDT." <4.1.20000908100047.021b5eb0@mailhost.talarian.com> Date: Sun, 10 Sep 2000 14:58:22 +0100 Message-ID: <2030.968594302@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk In message <4.1.20000908100047.021b5eb0@mailhost.talarian.com>, Brian Whetten t yped: >>Jon, I think FEC encoded NACK bitmaps is overly complex and unecessary, but >>I'm not sure I actually understand what your proposal is. the info in the return path does not have to be 100% accurate -we can err in either direction - not giveing enough detail _can_ result in excessive retransmits (not necessariyl a big problem for aggregating/filtering routers or servers), or excessive stall/congestion back off.....giving too much detail clogs the return path.....layered fec coding the receive sequence number lists allows the aggregtion ponts to choose how to err... >> >>Brian, my initial reaction to your proposal was that it was too complex, >>but now I'm not so sure. One issue though, is that you need to pass up the >>most recent congestion information you have in each NACK. If you are not >>NACKing the most recent packets, then this has to definitely be explicitly >>reported, rather than implicitly derived at the sender. This might cause >>problems for PGMCC, for example. >> >>I think that the need to do FEC count aggregation is a good argument >>against using a single long RLE bitmap. >> >>So I think we are left with three primary design choices: >>1) How to encode each block of packets? i.e. Count, Bitmap, None (for >>list NACKs, each block is of size 1) >>2) How to encode the series of blocks? Do we assume that they are all >>sequential, or do you encode each block with its starting sequence number? >>(note that this assumes the length of each block is the same) >>3) How much history to put in each NACK? Do we just list the most >>immediate packets, or do we have some partial redundancy, or do we always >>encode the entire outstanding window? The more information we encode, the >>simpler the NACK generation algorithms become, but the harder the encoding >>algorithms in order to be able to deal with large windows. >> >>Brian >> >>At 04:10 PM 9/8/2000 +0100, Jon Crowcroft wrote: >>> >>>so we have a large range+accuracy problem in returning >>>data to the sender(s) about missing sequence numbers >>>and so if the ack return path is noisy, then lets subject >>>the problem to the same attack s we did to data in the forward >>>path >>> >>>layered FEC encoded SACK messages... >>> >>> cheers >>> >>> jon >>> >> >> cheers jon >From owner-rmt@listserv.lbl.gov Tue Sep 12 03:59:10 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA01518; Tue, 12 Sep 2000 03:55: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 DAA01514 for ; Tue, 12 Sep 2000 03:55:27 -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 DAA23805 for ; Tue, 12 Sep 2000 03:55:27 -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 DAA23801 for ; Tue, 12 Sep 2000 03:55:26 -0700 (PDT) Received: from sonic2.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Sep 2000 11:55:21 +0100 to: rmt@lbl.gov Subject: MSc report on multicast and crowded virtual spaces Date: Tue, 12 Sep 2000 11:55:20 +0100 Message-ID: <969.968756120@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk some relevance to some of this group: ftp://cs.ucl.ac.uk/darpa/crowded.ps.gz on mapping large crowded distributed LSVEs into multicast... part funded by sprintlabs, work by MSc student Roula Abou-Haidar on our graphics course, has a review of network support for LSVEs etc.... (warning 7M gzipped ps uncompresses to 65M due to color images) cheers jon >From owner-rmt@listserv.lbl.gov Fri Sep 22 08:23:57 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id IAA14821; Fri, 22 Sep 2000 08:18: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 (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA14817 for ; Fri, 22 Sep 2000 08:18:21 -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 IAA15576 for ; Fri, 22 Sep 2000 08:18:21 -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 IAA15573 for ; Fri, 22 Sep 2000 08:18:20 -0700 (PDT) Received: from sprintlabs.com (ip199-2-53-110.sprintlabs.com [199.2.53.110]) by mailman.sprintlabs.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id R668PN5Y; Fri, 22 Sep 2000 08:17:50 -0700 Message-ID: <39CB77B9.5AE3FD7D@sprintlabs.com> Date: Fri, 22 Sep 2000 08:16:09 -0700 From: christophe diot Reply-To: cdiot@sprintlabs.com Organization: Sprint ATL X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Cost264@lip6.fr, rm@mash.CS.Berkeley.EDU, end2end-interest@ISI.EDU, tccc@ieee.org, itc@ieee.org, maddogs@ietf.org, ssm-interest@external.cisco.com, rmt@lbl.gov Subject: NGC 2000: call for posters Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk There will be 2 poster sessions during NGC 2000, November 8, 9, 10, in Stanford, CA. http://www.cs.ucsb.edu/ngc2000 Poster sessions are highly interactive sessions that give posters' authors an opportunity to discuss with workshop participants early research result or on-going research. The call for poster available on the NGC 2000 web site gives more details on how to submit a poster. >From owner-rmt@listserv.lbl.gov Mon Sep 25 15:22:09 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id PAA28441; Mon, 25 Sep 2000 15:17: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 (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA28437 for ; Mon, 25 Sep 2000 15:17:34 -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 PAA07523 for ; Mon, 25 Sep 2000 15:17:32 -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 PAA07510 for ; Mon, 25 Sep 2000 15:17:31 -0700 (PDT) Received: from sprintlabs.com (ip199-2-54-230.sprintlabs.com [199.2.54.230]) by mailman.sprintlabs.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id R668PSDF; Mon, 25 Sep 2000 15:17:02 -0700 Message-ID: <39CF829E.A45A14A2@sprintlabs.com> Date: Mon, 25 Sep 2000 09:51:42 -0700 From: Christophe Diot Organization: SPRINT ATL X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Cost264@lip6.fr, rm@mash.CS.Berkeley.EDU, end2end-interest@ISI.EDU, tccc@ieee.org, itc@ieee.org, maddogs@ietf.org, ssm-interest@external.cisco.com, rmt@lbl.gov Subject: NGC 2000: posters submission extension References: <39CB77B9.5AE3FD7D@sprintlabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Given that we have allocated a week extension to almost all poster authors, we decided to extend the poster submission deadline until until next sunday. But there will be no further extension granted :) NGC 2000 - Networked Group Communication http://www.cs.ucsb.edu/ngc2000 >From owner-rmt@listserv.lbl.gov Tue Sep 26 15:14:59 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id PAA02375; Tue, 26 Sep 2000 15:13: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 PAA02370 for ; Tue, 26 Sep 2000 15:13: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 PAA03438 for ; Tue, 26 Sep 2000 15:13:50 -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 PAA03435 for ; Tue, 26 Sep 2000 15:13:49 -0700 (PDT) Received: from sprintlabs.com (ip199-2-53-110.sprintlabs.com [199.2.53.110]) by mailman.sprintlabs.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id R668P42G; Tue, 26 Sep 2000 15:13:19 -0700 Message-ID: <39D11F0B.934908B9@sprintlabs.com> Date: Tue, 26 Sep 2000 15:11:23 -0700 From: christophe diot Reply-To: cdiot@sprintlabs.com Organization: Sprint ATL X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Cost264@lip6.fr, rm@mash.CS.Berkeley.EDU, end2end-interest@ISI.EDU, tccc@ieee.org, itc@ieee.org, maddogs@ietf.org, ssm-interest@external.cisco.com, rmt@lbl.gov Subject: NGC 2000: registration open Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Registration in now open for NGC 2000 www.cs.ucsb.edu/ngc2000 Please notice that workshop participation is limited 100. >From owner-rmt@listserv.lbl.gov Tue Oct 3 10:09:51 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id KAA14024; Tue, 3 Oct 2000 10:07:07 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal2.lbl.gov (postal2.lbl.gov [131.243.129.79]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA14020 for ; Tue, 3 Oct 2000 10:07:05 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal2.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA28921 for ; Tue, 3 Oct 2000 10:07:05 -0700 (PDT) Received: from Pedro (ppp176.197dip.netdial.caribe.net [209.91.197.176]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id KAA28917 for ; Tue, 3 Oct 2000 10:06:46 -0700 (PDT) Message-Id: <200010031706.KAA28917@SpamWall.lbl.gov> From: "juan" To: Subject: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 3 Oct 2000 13:19:24 Sender: owner-rmt@lbl.gov Precedence: bulk From: tunes To: tunes Subject: Fw: PLEASE READ! 5 min. of your time for $50,000 in 90 DAYS! Date: Friday, August 11, 2000 9:38 AM ----- Original Message ----- From: To: Sent: Monday, July 24, 2000 2:39 PM Subject: PLEASE READ! 5 min. of your time for $50,000 in 90 DAYS! > > > Dear Friend, > > This really works! Don't miss this opportunity. Get involved and it will > work for you as it does for us!!!!! > > Thank you for your time and interest. > > This email contains the ENTIRE PLAN of how YOU can make $50,000 or > more in the next 90 days simply sending email! > > Seem impossible? Just read on and see how easy this is.... > > Due to the popularity of this letter on the Internet, a major nightly > news program recently devoted an entire show to the investigation of the > program described below to see if it really can make people money. > > The show also investigated whether or not the program was legal. > Their findings proved that there are absolutely no laws prohibiting the > participation in the program. This has helped to show people that > this is a simple, harmless and fun way to make some extra money at home. > > The results have been truly remarkable. So many people are > participating that those involved are doing much better than ever > before. Since everyone makes more as more people try it > out, its been very exciting. > > You will understand once you try it yourself! > > ********* THE ENTIRE PLAN IS HERE BELOW ********* > > *** Print This Now For Future Reference *** > > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ > > If you would like to make at least $50,000 in less than 90 days! > Please read this program...THEN READ IT AGAIN!! > > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ > > THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY!! > > It does NOT require you to come into contact with people or make or > take any telephone calls. Just follow the instructions, and you > will make money. This simplified e-mail marketing program works > perfectly 100% EVERY TIME! > > E-mail is the sales tool of the future. Take advantage of this > virtually free method of advertising NOW!!! The longer you wait, > the more people will be doing business using email. Get your > piece of this action!!! > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Hello - My name is Johnathon Rourke, I'm from Rhode Island. > > The enclosed information is something I almost let slip through my > fingers. Fortunately, sometime later I re-read everything and gave > some thought and study to it. Two years ago, the corporation I worked > for the past twelve years down-sized and my position was eliminated. > After unproductive job interviews, I decided to open my own business. > Over the past year, I incurred many unforeseen financial problems. > I owed my family, friends and creditors over $35,000. The economy was > taking a toll on my business and I just couldn't seem to make ends > meet. I had to refinance and borrow against my home to support my > family and struggling business. > > AT THAT MOMENT something significant happened in my life. I am > writing to share the experience in hopes that this could change your > life FOREVER. > > FINANCIALLY$$$!!! > > In mid December, I received this program in my e-mail. Six months > prior to receiving this program I had been sending away for information > on various business opportunities. All of the programs I received, in my > opinion, were not cost effective. They were either too difficult for me > to comprehend or the initial investment was too much for me to risk to > see if they would work. But as I was saying, in December of 1997 I received > this program. I didn't send for it, or ask for it, they just got my name off > a mailing list. > > THANK GOODNESS FOR THAT!!! After reading it several times, to make sure > I was reading it correctly. I couldn't believe my eyes! Here was a > MONEY MAKING MACHINE I could start immediately without any debt. > > Like most of you I was still a little skeptical and a little worried > about the legal aspects of it all. So I checked it out with the U.S. > Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed > > legal! > > After determining the program was LEGAL I decided "WHY NOT!?!??" > > Initially I sent out 10,000 e-mails. It cost me about $15 for my time > on-line. The great thing about e-mail is that I don't need any for > printing to send out the program, and because I also send the product > (reports) by e-mail, my only expense is my time. > > In less than one week, I was starting to receive orders for REPORT #1. > By January 13, I had received 26 orders for REPORT #1. Your goal is to > "RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON'T, > SEND OUT MORE PROGRAMS UNTIL YOU DO. > > My first step in making $50,000 in 90 days was done. By January 30, I > had received 196 orders for REPORT #2. Your goal is to "RECEIVE AT LEAST > > 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS > > UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU > WILL MAKE YOUR $50,000 GOAL." > > Well, I had 196 orders for REPORT #2. 96 more than I needed. > So I sat back and relaxed. By March 1, of my e-mailing of 10,000, > received $58,000 with more coming in every day. I paid off ALL my debts > and bought a much needed new car! > > Please take your time to read this plan, IT WILL CHANGE YOUR LIFE > FOREVER$!!! Remember, it won't work if you don't try it. > This program does work, but you must follow it EXACTLY! > > Especially the rules of not trying to place your name in a different > place. It won't work and you'll lose out on a lot of money! In order > for this program to work, you must meet your goal of 20+ orders for > REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000 or > more in 90 days. > > I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in > this program, I am sorry. It really is a great opportunity with little > cost or risk to you. If you choose to participate, follow the program > and you will be on your way to financial security. If you are a fellow > business owner and are in financial trouble like I was, or you want to > start your own business, consider this a sign. I DID! $$ > > Sincerely, > > Johnathon Rourke > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: > > By the time you have read the enclosed program and reports, you should > have concluded that such a program, and one that is legal, could not > have been created by an amateur. Let me tell you a little about myself. > I had a profitable business for 10 years. Then in 1979 my business began > falling off. I was doing the same things that were previously successful > for me, but it wasn't working. Finally, I figured it out. It wasn't > me, it was the economy. Inflation and recession had replaced the stable > economy that had been with us since 1945. > > I don't have to tell you what happened to the unemployment rate... > because many of you know from first hand experience. There were more > failures and bankruptcies than ever before. The middle class was > vanishing. Those who knew what they were doing invested wisely and > moved up. Those who did not, including those who never had anything to save or > invest, were moving down into the ranks of the poor. As the saying goes, > > "THE RICH GET RICHER AND THE POOR GET POORER." The traditional methods > of making money will never allow you to"move up" or "get rich", inflation > will see to that. > > You have just received information that can give you financial > freedom for the rest of your life, with "NO RISK" and "JUST A LITTLE BIT > OF EFFORT." You can make more money in the next few months than you > have ever imagined. I should also point out that I will not see a penny of > this money, nor anyone else who has provided a testimonial for this > program. > > I have retired from the program after sending thousands and thousands > of programs. Follow the program EXACTLY AS INSTRUCTED. Do not change it > in any way. It works exceedingly well as it is now. Remember to e-mail a > > copy of this exciting report to everyone you can think of. One of the > people you send this to may send out 50,000...and your name will be on > everyone of them! Remember though, the more you send out, the more > potential customers you will reach. So my friend, I have given you the > ideas, information, materials and opportunity to become financially > independent. > > IT IS UP TO YOU!! NOW DO IT!! > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Before you delete this program from your in box, as I almost did, > take a little time to read it and REALLY THINK ABOUT IT. Get a pencil > and figure out what could happen when YOU participate. Figure out the > worst possible response and no matter how you calculate it, you will > still make a lot of money! You will definitely get back what you invested. Any > doubts you have will vanish when your first orders come in. > > $$$ IT WORKS!!! $$$ > > Jody Jacobs Richmond, VA > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF > DOLLAR$$$$!!!! > > This method of raising capital REALLY WORKS 100% EVERY TIME. I am > sure that you could use up to $50,000 or more in the next 90 days. > before you say "BULL... ", please read this program carefully. This is > not a chain letter, but a perfectly legal money making business. > > As with all multi-level businesses, we build our business by > recruiting new partners and selling our products. Every state in the USA > allows you to recruit new multi-level business partners, and we sell and > deliver a product for EVERY dollar received. > > YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not > involved in personal selling. You do it privately in your own home, > store or office. This is the EASIEST marketing plan anywhere! It is > simply order filling by email! > > ******************************************************************* > The product is informational and instructional material, keys to the > secrets for everyone on how to open the doors to the magic world of > E-COMMERCE , the information highway, the wave of the future ! > > PLAN SUMMARY: > > (1) You order the 4 reports listed below ($5US each) They come to you > by email. > > (2) Save a copy of this entire letter and put your name after Report > #1 and move the other names down. > > (3) Via the internet, access Yahoo.com or any of the other major > search engines to locate hundreds of bulk email service companies > (search for "bulk email") and have them send 25,000 - 50,000 emails for > you about $49+) > > (4) Orders will come to you by postal mail - simply email them the > Report they ordered. Let me ask you - isn't this about as easy as it > gets? > > ******************************************************************* > > By the way there are over 50 MILLION email addresses with millions > more joining the internet each year so don't worry about "running out" > or "saturation". People are used to seeing and hearing the same > advertisements every day on radio/TV. How many times have you received > the same pizza flyers on your door? Then one day you are hungry for > pizza and you order one. Same thing with this letter. I received this > letter many times - then one day I decided it was time to try it. > > ******************************************************************* > > YOU CAN START TODAY - JUST DO THESE EASY STEPS: > > STEP #1. ORDER THE FOUR REPORTS > > Order the four reports shown on the list below (you can't sell > them if you don't order them). -- For each report, send $5.00US > CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, > YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a > problem) to the person whose name appears on the list next to the > report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL > PROBLEMS! Within a few days you will receive, by e-mail, each of the four > reports. Save them on your computer so you can send them to the 1,000's > of people who will order them from you. > > STEP #2. ADD YOUR MAILING ADDRESS TO THIS LETTER > a. Look below for the listing of the four reports. > b. After you've ordered the four reports, delete the name and address > under REPORT #4. This person has made it through the cycle. > c. Move the name and address under REPORT #3 down to REPORT #4. > d. Move the name and address under REPORT #2 down to REPORT #3. > e. Move the name and address under REPORT #1 down to REPORT #2. > f. Insert your name/address in the REPORT #1 position. > Please make sure you COPY ALL INFORMATION, every name and address, > ACCURATELY! > > STEP #3. Take this entire letter, including the modified list of > names, and save it to your computer. Make NO changes to these > instructions. Now you are ready to use this entire email to send by > email to prospects. > > Report #1 will tell you how to download bulk email software and email > addresses so you can send it out to thousands of people while you > sleep! Remember that 50,000+ new people are joining the internet every > month. > > Your cost to participate in this is practically nothing (surely you > can afford $20US and initial bulk mailing cost). You obviously already > have a computer and an Internet connection and e-mail is FREE! > There are two primary methods of building your downline: > > METHOD #1: SENDING BULK E-MAIL Let's say that you decide to start > small, just to see how it goes, and we'll assume you and all those > involved email out only 2,000 programs each. Let's also assume that the > mailing receives a 0.5% response. The response could be much better. > Also, many people will email outhundreds of thousands of programs instead of > 2,000 (Why stop at 2000?). But continuing with this example, you send > out only 2,000 programs. With a 0.5% response, that is only 10 orders for > REPORT #1. Those 10 people respond by sending out 2,000 programs each > for a total of 20,000. Out of those 0.5%, 100 people respond and order > > REPORT #2. Those 100 mail out 2,000 programs each for a total of > 200,000. The 0.5% response to that is 1,000 orders for > > REPORT #3. Those 1,000 send out 2,000 programs each for a 2,000,000 > total. The 0.5% response to that is 10,000 orders for > > REPORT #4. That's 10,000 $5 bills for you. CASH!!! > Your total income in this example is $50 + $500 + $5,000 + $50,000 > for a total of $55,550!!! > > REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU > MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! > DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF > SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will > do just that, and more! > > METHOD #2 - PLACING FREE ADS ON THE INTERNET > Advertising on the internet is very, very inexpensive, and there are > HUNDREDS of FREE places to advertise. Let's say you decide to start > small just to see how well it works. Assume your goal is to get ONLY 10 > people to participate on your first level. (Placing a lot of FREE ads on > > the Internet will EASILY get a larger response.) Also assume that > everyone > else in YOUR ORGANIZATION gets ONLY 10 downline members. Look how this > small number accumulates to achieve the STAGGERING results below: > > 1st level--your first 10 send you > $5................................$50 > > 2nd level--10 members from those 10 ($5 x 100).............$500 > 3rd level--10 members from those 100 ($5 x 1,000)........$5,000 > 4th level--10 members from those 1,000 ($5 x 10,000)..$50,000 > > $$$$$$ THIS TOTALS ----------$55,550 $$$$$$ > > AMAZING ISN'T IT? Remember friends, this assumes that the people who > participate only recruit 10 people each. Think for a moment what would > happen if they got 20 people to participate! Most people get 100's of > participants and many will continue to work this program, sending out > programs WITH YOUR NAME ON THEM for years! THINK ABOUT IT! > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > People are going to get emails about this plan from you or somebody > else and many will work this plan - the question is - Don't you want > your name to be on the emails they will send out? > > * * * DON'T MISS OUT!!! * * * JUST TRY IT ONCE!!! * * * > > * * SEE WHAT HAPPENS!!! *** YOU'LL BE AMAZED!!!* * > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! > > This will guarantee that the e-mail THEY send out with YOUR name and > address on it will be prompt because they can't advertise until they > receive the report! > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > GET STARTED TODAY: PLACE YOUR ORDER FOR THE FOUR REPORTS NOW. > > Notes: -- ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS > NOT ACCEPTED. Make sure the cash is concealed by wrapping it in two > sheets of paper. On one of those sheets of paper write: > > (a) the number & name of the report you are ordering > > (b) your e-mail address, and > > (c) your name & postal address. > > REPORT #1 "The Insider's Guide to Advertising for Free on the Internet" > > ORDER REPORT #1 FROM: >PETER OJEDA > 1691 JUAN KEPLER URB. TULIPAN SAN JUAN P.R. 00926 > REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the Internet" > > ORDER REPORT #2 FROM: > KATHY BRONIAK > 4200-E LYNN POINT LANE >RALEIGH , NC27613 > REPORT #3 "The Secrets to Multilevel Marketing on the Internet" > > ORDER REPORT #3 FROM: >JAKE PELLETIER > 128 E 20TH AVE. > VANCOUVER B.C. >V5V 1L9 > REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel > > Marketing and the Internet" > > ORDER REPORT #4 FROM: > KEN KNIGHT > P.O. BOX 535. > 2208 MAPLE ROAD.N. > SOOKE B.C. > VOS 1NO > ******* TIPS FOR SUCCESS ******* > > TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the > directions accurately. -- Send for the four reports IMMEDIATELY so you > will have them when the orders start coming in because: > When you receive a $5 order, you MUST send out the requested > product/report. It is required for this to be a legal business and > they need the reports to send out their letters (with your name on > them!) > > -- ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. -- Be > patient and persistent with this program - If you follow the > instructions exactly - results WILL FOLLOW. $$$$ > > ******* YOUR SUCCESS GUIDELINES ******* > > Follow these guidelines to guarantee your success: If you don't > receive 20 orders for REPORT #1 within two weeks, continue advertising > or sending e-mails until you do. Then, a couple of weeks later you > should receive at least 100 orders for REPORT#2. If you don't, continue > advertising or sending e-mails until you do. Once you have received 100 > or more orders for REPORT #2, YOU CAN RELAX, because the system is already > working for you, and the cash will continue to roll in! > > THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on > the list, you are placed in front of a DIFFERENT report. You can KEEP > TRACK of your PROGRESS by watching which report people are ordering from > you. > > To generate more income, simply send another batch of e-mails or > continue placing ads and start the whole process again! There is no > limit to the income you will generate from this business! > > Before you make your decision as to whether or not you participate in > this program. Please answer one question. ARE YOU HAPPY WITH YOUR > PRESENT INCOME OR JOB? If the answer is no, then please look at the > following facts about this super simple MLM program: > > 1. NO face to face selling, NO meetings, NO inventory! > NO Telephone calls, NO big cost to start!, NOthing to learn, > NO skills needed! (Surely you know how to send email?) > > 2. No equipment to buy - you already have a computer and > internet connection - so you have everything you need to fill > orders! > > 3. You are selling a product which does NOT COST ANYTHING TO PRODUCE OR > SHIP! (Emailing copies of the reports is FREE!) > > 4. All of your customers pay you in CA$H! This program will change > your LIFE FOREVER!! Look at the potential for you to be able to quit > your job and live a life of luxury you could only dream about! > Imagine getting out of debt and buying the car and home of your > dreams and being able to work a super-high paying leisurely > easy business from home! > > $$$ FINALLY MAKE SOME DREAMS COME TRUE! $$$ > > ACT NOW! Take your first step toward achieving financial independence. > Order the reports and follow the program outlined above-- SUCCESS will > be your reward. > > Thank you for your time and consideration. > > PLEASE NOTE: If you need help with starting a business, registering a > business name, learning how income tax is handled, etc., contact your > local office of the Small Business Administration (a Federal Agency) > 1-800-827-5722 for free help and answers to questions. > > Also, the Internal Revenue Service offers free help via telephone and > free seminars about business tax reuirements. Your earnings are highly > dependent on your activities and advertising. The information contained > on this site and in the report constitutes no guarantees stated nor > implied. In the event that it is determined that this site or report > constitutes a guarantee of any kind, that guarantee is now void. The > earnings amounts listed on this site and in the report are estimates > only. > If you have any questions of the legality of this program, contact the > Office of Associate Director for Marketing Practices, Federal Trade > Commission, Bureau of Consumer Protection in Washington, DC. > > ================================================ > > Under Bill s.1618 TITLE III passed by the 105th US Congress this > letter cannot be considered spam as long as the sender includes > contact information and a method of removal. > > This is a one time e-mail transmission. No request for removal is > necessary. > > > >From owner-rmt@listserv.lbl.gov Fri Oct 6 01:09:13 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id BAA02307; Fri, 6 Oct 2000 01:05:34 -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 BAA02303 for ; Fri, 6 Oct 2000 01:05: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 BAA23944 for ; Fri, 6 Oct 2000 01:05:32 -0700 (PDT) Received: from ra.inria.fr (IDENT:root@ra.inria.fr [138.96.32.72]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA23941 for ; Fri, 6 Oct 2000 01:05:30 -0700 (PDT) Received: from sophia.inria.fr by ra.inria.fr (8.10.0/8.10.0) with ESMTP id e9685Rt02383 for ; Fri, 6 Oct 2000 10:05:27 +0200 X-Authentication-Warning: ra.inria.fr: Host localhost [127.0.0.1] claimed to be sophia.inria.fr Message-ID: <39DD87C6.10C58153@sophia.inria.fr> Date: Fri, 06 Oct 2000 08:05:26 +0000 From: Fethi Filali Organization: INRIA Sophia-Antipolis X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.2.14 i586) X-Accept-Language: en MIME-Version: 1.0 To: rmt@lbl.gov Subject: Multicast and Unicast Flows Fairness Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk hi all, My question is how the internet community define the fairness between reliable multicast and TCP connections sharing the same communication link. Should a reliable multicast flows be treated as a TCP flow ? Or, should the reliable multicast flows be given more bandwidth than TCP flow because it is intended to serve more receivers? In the second case, how much more bandwidth should be given to the multicast flow and how do the Internet community define this fairness. Thanks, Fethi. >From owner-rmt@listserv.lbl.gov Fri Oct 6 01:23:39 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id BAA02343; Fri, 6 Oct 2000 01:23: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 BAA02339 for ; Fri, 6 Oct 2000 01:23:30 -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 BAA25205 for ; Fri, 6 Oct 2000 01:23:29 -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 BAA25201 for ; Fri, 6 Oct 2000 01:23:28 -0700 (PDT) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 6 Oct 2000 09:23:22 +0100 To: Fethi Filali cc: rmt@lbl.gov Subject: Re: Multicast and Unicast Flows Fairness In-reply-to: Your message of "Fri, 06 Oct 2000 08:05:26 -0000." <39DD87C6.10C58153@sophia.inria.fr> Date: Fri, 06 Oct 2000 09:23:21 +0100 Message-ID: <1809.970820601@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk In message <39DD87C6.10C58153@sophia.inria.fr>, Fethi Filali typed: >>My question is how the internet community define the fairness between >>reliable multicast and TCP connections sharing the same communication >>link. jolly good question.... >>Should a reliable multicast flows be treated as a TCP flow ? Or, should >>the reliable multicast flows be given more bandwidth than TCP flow >>because it is intended to serve more receivers? In the second case, how >>much more bandwidth should be given to the multicast flow and how do the >>Internet community define this fairness. The problem is that there is no Internet community:-) its up to a mix of people with different motivations 1/ content distribution 2/ service providers 3/ RMT Product vendors 4/ router vendors all have potentially different cost/benefit analysis for multicast and for multicast versus unicast 1/ save capacity at servers 2/ have the headaches of having yet another routing protocol to operate and maintain, yet another set of traffic to engineer for 3/ have varying applicability 4/ have various cost/benefit analysis for state and packet copy (e.g. switch router fabric for multicast costs more)... then there's a pure academicx approach.... now the BIG problem in all this is that the internet is not exactly fair anyhow - sure TCP-friendliness (see http://www.psc.edu/networking/tcp_friendly.html and references therein) is proportionally fair - some people say that for multicast we should be max-min fair (and point out that if you have multicast state in routers, then adding the state necessary for max-min fair policing is only a constant overhead)....but then comparing a mix of TCP proportional fair with a set of RMT flows that were max-min would be weird (would depend _completly_ on the multicast tree topology,since proporionality includes the _length_ of the path....whereas max-min is just the cross section of traffic at the bottlenecks)... maybe a new type of fairness could be introduced.....but what is your goal? if its to _promote_ multicast, then you'd want to let it get more cpaacity, but for a price per source, it already does! if its to create incentives to deploy, you might want to give multicast _less_ capacity than the equivalent TCP flow to the slowest or other receiver (c.g. PGMCC and other single rate schemes) it sure is tricky! so you can see its not obvious cheers jon >From owner-rmt@listserv.lbl.gov Fri Oct 6 05:45:58 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id FAA02771; Fri, 6 Oct 2000 05:45:29 -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 FAA02763 for ; Fri, 6 Oct 2000 05:45:27 -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 FAA15611 for ; Fri, 6 Oct 2000 05:45:26 -0700 (PDT) Received: from multicasttech.com (IDENT:root@ns2.multicasttech.com [63.105.122.8]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA15595 for ; Fri, 6 Oct 2000 05:45:21 -0700 (PDT) Received: from [206.15.135.60] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 536293; Fri, 06 Oct 2000 08:42:34 -0400 Message-ID: <39DDCAD2.1B8CE037@21rst-century.com> Date: Fri, 06 Oct 2000 08:51:30 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Fethi Filali CC: rmt@lbl.gov, rem-conf@es.net Subject: Re: Multicast and Unicast Flows Fairness References: <39DD87C6.10C58153@sophia.inria.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-rmt@lbl.gov Precedence: bulk Fethi Filali wrote: > > hi all, > > My question is how the internet community define the fairness between > reliable multicast and TCP connections sharing the same communication > link. > > Should a reliable multicast flows be treated as a TCP flow ? Or, should > the reliable multicast flows be given more bandwidth than TCP flow > because it is intended to serve more receivers? In the second case, how > much more bandwidth should be given to the multicast flow and how do the > Internet community define this fairness. > > Thanks, > > Fethi. Dear Fethi; This has been discussed at length on the AVT list, because of the desire to add something about congestion control to the RTP profile. ' The current wording is (from draft-avt-profile, 2000]) If best-effort service is being used, RTP receivers SHOULD monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve an average throughput that is not less the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the loss rate is unacceptably high. I did not like, and still do not like, this wording. TCP is not like UDP, especially UDP multicast, and I see nothing ^Ófair^Ô about having a multicast stream sharing the same bandwidth as a host of unicast TCP sessions. In case of large scale receiver based RTP/UDP congestion control, it is also very unclear how the receiver is to determine the amount of TCP traffic. I argued that a scheme based on monitoring of packet loss rates only was sufficient, and suggested a simple minded congestion monitoring wording based purely on packet loss rates. There followed a fair amount of discussion about this point, which has resurfaced a number of time. The following points have been made : 1.) UDP flows, without congestion control, can ruin a bandwidth limited pipe - see [Jeffay, 1999] for an example of congestive collapse (38% packet loss) when you try and stuff TCP traffic + a 8 or 9 mbps UDP flow into a 10 mbps channel. 2.) Conversely, most multicast applications are streaming audio or video, and these do not respond well to TCP like changes in bandwidth - especially the slow start / congestion control. It is possible that RMT would help here. To the extent that there is consensus, I would cautiously say that people have focused more on avoiding congestive collapse instead of fairness. I would also cautiously claim a VERY rough consensus that multicast streams should be allowed to take the bandwidth they need as long as there is not signs of serious congestion, but that they should throttle back or terminate entirely if there is, and that this should be determined by monitoring the rate of packet loss. I am cc:ing the AVT list, for obvious reasons. I apologize for those who get this twice. References : [draft-avt-profile, 2000] http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-09.txt [Jeffay, 1999] Towards a Better-Than-Best-Effort Forwarding Service for Multimedia Flows, K. Jeffay, IEEE Multimedia, 6, 84-88, 1999. The ^Ólong^Ô version is available from http://www.cs.unc.edu/~jeffay/papers/IEEE-MM-99-long.pdf Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com http://www.on-the-i.com >From owner-rmt@listserv.lbl.gov Fri Oct 6 08:57:50 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id IAA04046; Fri, 6 Oct 2000 08:57: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 IAA04042 for ; Fri, 6 Oct 2000 08:57: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 IAA18621 for ; Fri, 6 Oct 2000 08:57:19 -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 IAA18597 for ; Fri, 6 Oct 2000 08:57:17 -0700 (PDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24733; Fri, 6 Oct 2000 08:57:08 -0700 (PDT) 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 LAA06563; Fri, 6 Oct 2000 11:57:07 -0400 (EDT) Received: from bridge (bridge [129.148.75.125]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id LAA26212; Fri, 6 Oct 2000 11:57:07 -0400 (EDT) Message-Id: <200010061557.LAA26212@bcn.East.Sun.COM> Date: Fri, 6 Oct 2000 11:57:05 -0400 (EDT) From: Dah Ming Chiu - Sun Microsystems Reply-To: Dah Ming Chiu - Sun Microsystems Subject: Re: Multicast and Unicast Flows Fairness To: Fethi.Filali@sophia.inria.fr Cc: rmt@lbl.gov MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: BQTohO3D4xFJPWemLKkXHQ== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-rmt@lbl.gov Precedence: bulk Hi Fethi, This topic has been discussed by the IRTF Reliable Multicast working group on numerous occasions. If you are interested in that, you might go to their mail archive and search. I wrote an article on this topic which you might find useful, see http://www.sun.com/research/techrep/1999/abstract-80.html It is a more "academic" perspective (in Jon's terminology). A slightly updated version of it was published in the ISCC2000 proceedings. Regards Dah Ming Chiu Sun Labs X-Authentication-Warning: ra.inria.fr: Host localhost [127.0.0.1] claimed to be sophia.inria.fr From: Fethi Filali X-Accept-Language: en MIME-Version: 1.0 To: rmt@lbl.gov Subject: Multicast and Unicast Flows Fairness Content-Transfer-Encoding: 7bit hi all, My question is how the internet community define the fairness between reliable multicast and TCP connections sharing the same communication link. Should a reliable multicast flows be treated as a TCP flow ? Or, should the reliable multicast flows be given more bandwidth than TCP flow because it is intended to serve more receivers? In the second case, how much more bandwidth should be given to the multicast flow and how do the Internet community define this fairness. Thanks, Fethi. >From owner-rmt@listserv.lbl.gov Mon Oct 9 17:41:20 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id RAA15663; Mon, 9 Oct 2000 17:39:40 -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 RAA15659 for ; Mon, 9 Oct 2000 17:39:38 -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 RAA13730 for ; Mon, 9 Oct 2000 17:39:37 -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 RAA13727 for ; Mon, 9 Oct 2000 17:39:36 -0700 (PDT) Received: from sprintlabs.com (ip199-2-53-112.sprintlabs.com [199.2.53.112]) by mailman.sprintlabs.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id 4GNA7TCP; Mon, 9 Oct 2000 17:38:55 -0700 Message-ID: <39E264B2.B6927993@sprintlabs.com> Date: Mon, 09 Oct 2000 17:37:06 -0700 From: Christophe Diot Organization: SPRINT ATL X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Cost264@lip6.fr, rm@mash.CS.Berkeley.EDU, end2end-interest@ISI.EDU, tccc@ieee.org, itc@ieee.org, maddogs@ietf.org, ssm-interest@external.cisco.com, rmt@lbl.gov Subject: NGC 2000: register asap ! References: <39D11F0B.934908B9@sprintlabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Registration deadline for early rates is tomorrow. Also, we are going fast to the 100 participants. so please register shortly. we will accept early rates for another two days as some people experienced problems to reach the web site today. www.cs.ucsb.edu/ngc2000 >From owner-rmt@listserv.lbl.gov Wed Oct 18 03:36:06 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA10888; Wed, 18 Oct 2000 03:32:29 -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 DAA10884 for ; Wed, 18 Oct 2000 03:32:26 -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 DAA20959 for ; Wed, 18 Oct 2000 03:32:26 -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 DAA20954 for ; Wed, 18 Oct 2000 03:32:25 -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 GAA14670; Wed, 18 Oct 2000 06:32:24 -0400 (EDT) Message-Id: <200010181032.GAA14670@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-03.txt Date: Wed, 18 Oct 2000 06:32:24 -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-03.txt Pages : 22 Date : 17-Oct-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-03.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-03.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-03.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: <20001017125924.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-buildingblocks-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-buildingblocks-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001017125924.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Mon Oct 23 14:30:16 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id OAA09629; Mon, 23 Oct 2000 14:27:58 -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 OAA09625 for ; Mon, 23 Oct 2000 14:27:57 -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 OAA23808 for ; Mon, 23 Oct 2000 14:27:56 -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 OAA23788 for ; Mon, 23 Oct 2000 14:27:54 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA26630 for ; Mon, 23 Oct 2000 14:27:53 -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 OAA11047 for ; Mon, 23 Oct 2000 14:25:50 -0700 (MST)] Received: from arc.corp.mot.com ([217.2.31.39]) by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id e9NLRTn15019 for ; Tue, 24 Oct 2000 08:27:29 +1100 (EST) Message-ID: <39F4ACDB.CD598D58@arc.corp.mot.com> Date: Tue, 24 Oct 2000 08:25:47 +1100 From: Roger Kermode Reply-To: Roger.Kermode@motorola.com Organization: Motorola X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: Call for RMT Agenda items Content-Type: multipart/mixed; boundary="------------8C42FB7D460C9D6DD81796BA" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------8C42FB7D460C9D6DD81796BA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear RMT'ers Please send your requests for RMT agenda items for the next IETF to me when you get the chance. If we get them early enough we might even be able to publish an agenda prior to the meeting (hint hint). FYI...we've asked for two slots again, which will most likely be scheduled early in the week. cheers, Roger --------------8C42FB7D460C9D6DD81796BA 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 --------------8C42FB7D460C9D6DD81796BA-- >From owner-rmt@listserv.lbl.gov Fri Oct 27 09:20:33 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id JAA09486; Fri, 27 Oct 2000 09:16:54 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA09482 for ; Fri, 27 Oct 2000 09:16:52 -0700 (PDT) Received: from zbl6c016.corpeast.baynetworks.com (actually zbl6c016) by ertpg14e1.nortelnetworks.com; Fri, 27 Oct 2000 11:54:23 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VT2NRBP8; Fri, 27 Oct 2000 11:54:17 -0400 Received: from hardjono.nortelnetworks.com (dhcp225-117.engeast.baynetworks.com [192.32.225.117]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VDZZ10HG; Fri, 27 Oct 2000 11:54:16 -0400 Message-Id: <4.3.1.2.20001027111423.00d5cdb0@ZBL6C002.corpeast.baynetworks.com> X-Sender: hardjono@ZBL6C002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 27 Oct 2000 12:04:32 -0700 To: smug@cs.umass.edu, smug@baynetworks.com From: "Thomas Hardjono" Subject: MSEC BOF details Cc: rmt@listserv.lbl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rmt@lbl.gov Precedence: bulk Folks, There will be a BOF on Multicast SECurity (MSEC) in the next IETF San Diego. Date: Tuesday Dec 12 Time: 1300-1400 (Afternoon Sessions I) (break) 1545-1645 (Afternoon Sessions III) http://www.ietf.org/meetings/agenda.html The draft-agenda for the BOF is given below, and an msec mailing list is being set-up. Yours, Thomas ------ --------------------------------------------------------------------------- Multicast Security BOF (msec) Tuesday 12 Dec, 13:00pm ============================== CHAIR: Ran Canetti Thomas Hardjono DESCRIPTION: There is significant interest in the networking industry and content delivery network industry to use IP multicast a vehicle for data delivery to a large audience. One major hindrance to the successful deployment of IP multicast and other group-oriented communication protocols has been the lack of security for both the content and the content-delivery infrastructure. In particular, there has been increasing demand for secure solutions for the 1-to-Many type of group communications, as exemplified by the interest of the cable television sector in using the Internet for content distribution and by the recent emergence of the single-source paradigm in IP multicasting. To this end, the Secure Multicast (SMuG) research group was formed in 1998 under the umbrella of the IRTF. That group has characterized the security concerns and problem areas, has come up with a framework for an overall solution, and has developed protocols for solving much of the problem space in a satisfactory manner. Several of these protocols have reached the needed maturity to be considered for standardization at the IETF. The proposed WG will further develop and standadize the protocols developed at the SMuG RG. The focus will be on mature protocols that are deployable in short term in today's internet. The SMuG RG will continue to examine issues that need further research, delivering protocols to McSEC when they are mature. In the immediate future McSEC will focus on the 1-to-Many group communication, and will address at least the following issues: - Developing the transformations to be applied to the multicasted data. These transformations will provide at least the following functionalities: + Encryption of data using a group key available to all members. + Source and Data Authentications even when the data receivers do not trust each other. Both functionalities are required for content-authors and content-distributors. They represent an important element in the larger digital rights management area. - Group Security Association and Key Management. Secure protocols are needed for management of cryptographic keys and Security Associations for groups. These include techniques for initial key dissemination, key updates and refreshments, and Group Security Association (Group SA) management. Depending on the acceptance and stability of the above two issues, the following issues will be addressed by the WG in the immediate future: - Group Security Policies. Different levels of policies exist for a group, covering a range from member behavior to cryptographic policies. - Secure group announcements. Information regarding the existence of a group, its policies, base security mechanisms and methods for joining needs to be announced in a suitable manner. Secure multicast touches upon the work of several other working groups. The proposed WG will take care to coordinate its activities with the relevant directorates (security, routing, transport) and especially with the IPSec and RMT working groups. The WG will not work on: - Security issues at firewalls and NATs relating to multicast traffic. - Protection against illegal re-distribution of multicasted data. AGENDA: 10 mins - Agenda bashing 10 mins - Charter presentation 80 mins - Internet draft presentations: 10 mins - Taxonomy of multicast security concerns (draft-irtf-smug-taxonomy-01.txt) 10 mins - Framework overview (draft-irtf-smug-framework-01.txt) - Data transforms: 10 mins - Overall design (draft-irtf-smug-data-transforms-00.txt) 10 mins - Source authentication (draft-irtf-smug-tesla-00.txt) - Group key and SA management 10 mins - GKM Building Block (draft-irtf-smug-gkmbb-gsadef-00.txt) 10 mins - GSAKMP (draft-harney-sparta-gsakmp-sec-01.txt) 10 mins - Group DOI for ISAKMP (draft-irtf-smug-gdoi-00.txt) 10 mins - Group policy management (draft-mcast-pol-req00.txt) 20 mins - Open Discussion (work descriptions, objectives, goals/milestones) MAILING LIST A mailing list is currently being set-up. The website is www.securemulticast.org, which contains the drafts (below) and other reading material. READING MATERIAL draft-irtf-smug-taxonomy-02.txt draft-irtf-smug-framework-01.txt draft-irtf-smug-data-transforms-01.txt draft-irtf-smug-tesla-00.txt draft-irtf-smug-gkmbb-gsadef-00.txt draft-harney-sparta-gsakmp-sec-01.txt draft-irtf-smug-gdoi-00.txt draft-irtf-smug-pol-req00.txt ---------------------------------------------------------------------------- >From owner-rmt@listserv.lbl.gov Fri Oct 27 10:13:58 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id KAA09737; Fri, 27 Oct 2000 10:13: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 KAA09733 for ; Fri, 27 Oct 2000 10:13:42 -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 KAA05139 for ; Fri, 27 Oct 2000 10:13:42 -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 KAA05135 for ; Fri, 27 Oct 2000 10:13:41 -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 NAA01955; Fri, 27 Oct 2000 13:13:23 -0400 (EDT) Message-Id: <200010271713.NAA01955@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: rmt@lbl.gov From: The IESG Subject: Document Action: Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer to Informational Date: Fri, 27 Oct 2000 13:13:23 -0400 Sender: owner-rmt@lbl.gov Precedence: bulk The IESG has approved the Internet-Draft 'Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer' as a Informational RFC. This document is the product of the Reliable Multicast Transport Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Note to RFC Editor: Please Rename Section 5 to be Security Considerations. >From owner-rmt@listserv.lbl.gov Mon Oct 30 10:57:54 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id KAA20840; Mon, 30 Oct 2000 10:55:12 -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 KAA20836 for ; Mon, 30 Oct 2000 10:55:10 -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 KAA11531 for ; Mon, 30 Oct 2000 10:55:09 -0800 (PST) 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 KAA11522 for ; Mon, 30 Oct 2000 10:55:09 -0800 (PST) Received: from sprintlabs.com (ip199-2-53-131.sprintlabs.com [199.2.53.131]) by mailman.sprintlabs.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id 47VNGG9L; Mon, 30 Oct 2000 10:54:56 -0800 Message-ID: <39FDC3E8.B2CF173@sprintlabs.com> Date: Mon, 30 Oct 2000 10:54:32 -0800 From: Christophe Diot Organization: SPRINT ATL X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Cost264@lip6.fr, rm@mash.CS.Berkeley.EDU, end2end-interest@ISI.EDU, tccc@ieee.org, itc@ieee.org, maddogs@ietf.org, ssm-interest@external.cisco.com, rmt@lbl.gov, fred bauer Subject: NGC 2000: next week in stanford References: <39D11F0B.934908B9@sprintlabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk NGC is coming soon and only 10 more people can register. We remind you that there will be no on-site registration. www.cs.ucsb.edu/ngc2000/ >From owner-rmt@listserv.lbl.gov Wed Nov 1 18:24:27 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id SAA08295; Wed, 1 Nov 2000 18:20:41 -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 SAA08291 for ; Wed, 1 Nov 2000 18:20:39 -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 SAA06064 for ; Wed, 1 Nov 2000 18:20:38 -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 SAA06055 for ; Wed, 1 Nov 2000 18:20:38 -0800 (PST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id TAA10763 for ; Wed, 1 Nov 2000 19:20:37 -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 TAA18637 for ; Wed, 1 Nov 2000 19:20:35 -0700 (MST)] Received: from motorola.com (mccoy.arc.corp.mot.com [217.1.10.204]) by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id eA22K1S16856 for ; Thu, 2 Nov 2000 13:20:01 +1100 (EST) Message-ID: <3A00CEE7.DB675A83@motorola.com> Date: Thu, 02 Nov 2000 13:18:15 +1100 From: Roger Kermode Reply-To: Roger.Kermode@motorola.com Organization: Motorola X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: Announcment: multicast security BOF at San Diego IETF Content-Type: multipart/mixed; boundary="------------608BAF969F4A519981D5B3B0" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------608BAF969F4A519981D5B3B0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear everyone, the chairs of the IRTF Secure Multicast Research Group will be holding a BoF on Secure Multicast at the next IETF. Please take a moment to read the announcement below if you're so interested, cheers, Roger --------------------------------------------------------------------------- Multicast Security BOF (msec) Tuesday, December 12 at 1415-1515 Tuesday, December 12 at 1700-1800 ================================= CHAIR: Ran Canetti Thomas Hardjono DESCRIPTION: There is significant interest in the networking industry and content delivery network industry to use IP multicast a vehicle for data delivery to a large audience. One major hindrance to the successful deployment of IP multicast and other group-oriented communication protocols has been the lack of security for both the content and the content-delivery infrastructure. In particular, there has been increasing demand for secure solutions for the 1-to-Many type of group communications, as exemplified by the interest of the cable television sector in using the Internet for content distribution and by the recent emergence of the single-source paradigm in IP multicasting. To this end, the Secure Multicast (SMuG) research group was formed in 1998 under the umbrella of the IRTF. That group has characterized the security concerns and problem areas, has come up with a framework for an overall solution, and has developed protocols for solving much of the problem space in a satisfactory manner. Several of these protocols have reached the needed maturity to be considered for standardization at the IETF. The proposed WG will further develop and standardize the protocols developed at the SMuG RG. The focus will be on mature protocols that are deployable in short term in today's internet. The SMuG RG will continue to examine issues that need further research, delivering protocols to MSEC when they are mature. In the immediate future MSEC will focus on the 1-to-Many group communication, and will address at least the following issues: - Developing the transformations to be applied to the multicasted data. These transformations will provide at least the following functionalities: + Encryption of data using a group key available to all members. + Source and Data Authentications even when the data receivers do not trust each other. Both functionalities are required for content-authors and content-distributors. They represent an important element in the larger digital rights management area. - Group Security Association and Key Management. Secure protocols are needed for management of cryptographic keys and Security Associations for groups. These include techniques for initial key dissemination, key updates and refreshments, and Group Security Association (Group SA) management. Depending on the acceptance and stability of the above two issues, the following issues will be addressed by the WG in the immediate future: - Group Security Policies. Different levels of policies exist for a group, covering a range from member behavior to cryptographic policies. - Secure group announcements. Information regarding the existence of a group, its policies, base security mechanisms and methods for joining needs to be announced in a suitable manner. Secure multicast touches upon the work of several other working groups. The proposed WG will take care to coordinate its activities with the relevant directorates (security, routing, transport) and especially with the IPSec and RMT working groups. The WG will not work on: - Security issues at firewalls and NATs relating to multicast traffic. - Protection against illegal re-distribution of multicasted data. AGENDA: 10 mins - Agenda bashing 10 mins - Charter presentation 80 mins - Internet draft presentations: 10 mins - Taxonomy of multicast security concerns (draft-irtf-smug-taxonomy-01.txt) 10 mins - Framework overview (draft-irtf-smug-framework-01.txt) - Data transforms: 10 mins - Overall design (draft-irtf-smug-data-transforms-00.txt) 10 mins - Source authentication (draft-irtf-smug-tesla-00.txt) - Group key and SA management 10 mins - GKM Building Block (draft-irtf-smug-gkmbb-gsadef-00.txt) 10 mins - GSAKMP (draft-harney-sparta-gsakmp-sec-02.txt) 10 mins - Group DOI for ISAKMP (draft-irtf-smug-gdoi-00.txt) 10 mins - Group policy management (draft-mcast-pol-req00.txt) 20 mins - Open Discussion (work descriptions, objectives, goals/milestones) MAILING LIST The mailing list is at msec-request@securemulticast.org (or email the chairs). The website is at www.securemulticast.org READING MATERIAL draft-irtf-smug-taxonomy-02.txt draft-irtf-smug-framework-01.txt draft-irtf-smug-data-transforms-01.txt draft-irtf-smug-tesla-00.txt draft-irtf-smug-gkmbb-gsadef-00.txt draft-harney-sparta-gsakmp-sec-02.txt draft-irtf-smug-gdoi-00.txt draft-irtf-smug-pol-req00.txt --------------------------------------------------------------------------- --------------608BAF969F4A519981D5B3B0 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;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 --------------608BAF969F4A519981D5B3B0-- >From owner-rmt@listserv.lbl.gov Fri Nov 3 16:00:21 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id PAA25494; Fri, 3 Nov 2000 15:57: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 PAA25490 for ; Fri, 3 Nov 2000 15:57:42 -0800 (PST) From: hv@of-hachetal.de Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA05337 for ; Fri, 3 Nov 2000 15:57:41 -0800 (PST) Received: from mail.sinet.net.cn ([202.103.190.4]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA05296 for ; Fri, 3 Nov 2000 15:57:34 -0800 (PST) Received: from isd.com.cn ([202.103.148.117]) by mail.sinet.net.cn (8.9.3/8.9.3) with SMTP id HAA12727; Sat, 4 Nov 2000 07:53:34 +0800 (CST) Date: Sat, 4 Nov 2000 07:53:34 +0800 (CST) Message-Id: <200011032353.HAA12727@mail.sinet.net.cn> Received: from h809 ([63.30.197.239]) by isd.com.cn (Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) with SMTP id 4825698C.0082E7B4; Wed, 4 Nov 1970 07:51:14 +0800 To: hv@of-hachetal.de Subject: At last, Herbal V, the all natural alternative to V----A! Sender: owner-rmt@lbl.gov Precedence: bulk Herbal V: An Incredible All-Natural Healthy Alternative Herbal V is the All Natural Approach to Male Virility, Vitality and Pleasure. Available N o w ! Welcome to the New Sexual Revolution. It's the all natural male potency and pleasure pill that men everywhere are buzzing about. Herbal V is safe, natural and specifically formulated to help support male sexual function and pleasure. You just take two easy-to-swallow tablets one hour before sex. And there's more great news - you can get Herbal V for less than $1 a pill. Amazing word of mouth praise on Herbal V has been spreading like wildfire-already over 1,500,000 men have chosen Herbal V. Since it is 100% natural you will never have to worry about safety. Try doctor-recommended Herbal V today and have the greatest night of your life! Herbal V... Bringing Back the Magic! 1,585,000 men can't be wrong. To date over 1 million men have tried the super supplement Herbal V. Here is why: No Doctor Visit Required Available Over the Counter Not a Drug 100% Natural Safe, No Worries Highest Quality Pharmaceutical-Grade Pure Nutriceuticals Guaranteed Potency & Purity Be a Real Man Again! Questions and Answers What is Herbal V? Herbal V is a proprietary blend that was specifically developed as a safe alternative for men who prefer an all-natural approach to address impotence and boost sexual performance. This amazing formula first became popular with Hollywood insiders and the wealthy elite. They were maximizing their sex lives, long before it was available to the general public. How does Herbal V work? Developed by a team whose goal was to create the perfect all-natural aphrodisiac. Herbal V is the result of that remarkable effort. The Herbal V formula contains a precise blend of cutting edge pro-sexual nutrients from around the world that provide nutritional support, making it possible for a man to have a pleasurable sexual experience. What can Herbal V do for me? Herbal V helps support male sexual function and pleasure in a safe and natural manner. Simply put, it can make your sex life incredible. Is Herbal V Safe? One of the great things about Herbal V is that it is not a drug. It is an incredible herbal dietary supplement that provides nutritional support for male sexual function and pleasure. One of the most comforting features of Herbal V is that you never have to worry about safety. Herbal V: Safe - Natural - Exciting Many have speculated that because Herbal V is so popular with men, it must contain prescription drugs or chemical components. Herbal V does not contain any elements or traces of any prescription drug. Herbal V is made using the world's most technologically advanced state-of-the-art cold processing equipment to ensure maximum purity. Herbal V has been independently analyzed by the nation's premier testing facility to ensure purity, quality and to end the rumors that, because it is so popular, it must somehow be chemical. It is not. Herbal V is natural - just as it says on the label. Herbal V is simply fantastic! Herbal V: Ingredients Yohimbe, saw palmetto, avena sativa, androstenedione, guarana, taurine, siberian ginseng, tribulus terrestris. Tribulus Terrestis is certified to enhanced testosterone levels by increasing Luteinzing hormone (LH) levels. Androstenedione which is a precursor to testosterone unlocks bound testosterone and makes it biologically active again quickly. This means a dramatic surge in desire. Avena Sativa Stimulates the neurotransmitter pleasure centers to maximum capacity. This greatly intensifies pleasure. Just listen to what Herbal V has done for the sex lives of people like you! ^ÓOn a scale of 1 to 10, it's a 15. Electrifying. It's like a wonder pill!^Ô ^× Justin Q B., New Haven, Texas ^ÓI haven't had sexual relations in 11 years. Then with Herbal V it was... wow! It works again!^Ô ^× Sid R., Lakeland, Florida ^ÓI had sex four times in one night. It made me feel like a 19-year-old again.^Ô ^× Chip S, Beech Mountain, North Carolina ^ÓHerbal V has turned my husband into a Sexual Superman! I like the fact that it's all natural and has no side effects. It's bringing back the good old days.^Ô ^× Jennifer B, Beverly Hills, California The above testimonials are from product literature, and we have not independently verified them. However, the following testimonial is from a "senior" gentleman who has purchased his second bottle of Herbal V. When we heard his words with our own ears, we asked his permission to print them here. ^ÓMan! I'm wild as I can be! I feel like I'm 25 years old again! I'm not believing this!^Ô ^× Mr. Murphy, age 64, Lampart, IL. Risk Free: Double Your Money Back Guarantee If Herbal V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked ! Order Now: Safe, Fast, Secure, Private Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Herbal V contains 30 tablets, approximately a 1 month supply. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Herbal V $28 ______ 2 Bottles of Herbal V $48 ______ 3 Bottles of Herbal V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$34, 2 bottles=$54, 3 bottles=$65 ] International Orders Please add $16 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$44, 2 bottles=$64, 3 bottles=$75 ] We cannot accept foreign checks. International money orders or credit cards only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 3502 N. Powerline Rd. #525 Pompano Beach, FL 33069 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Herbal V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Herbal V helps provide herbal and nutritional support for male sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. >From owner-rmt@listserv.lbl.gov Wed Nov 8 15:41:43 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id PAA18292; Wed, 8 Nov 2000 15:36: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 PAA18288 for ; Wed, 8 Nov 2000 15:36: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 PAA28441 for ; Wed, 8 Nov 2000 15:36:44 -0800 (PST) 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 PAA28435 for ; Wed, 8 Nov 2000 15:36:43 -0800 (PST) Received: by mailman.sprintlabs.com with Internet Mail Service (5.5.2652.78) id <47VNGVPH>; Wed, 8 Nov 2000 15:36:40 -0800 Message-ID: <90B65CE19D3DD411895400805F0DAA7A0BDFF7@mailman.sprintlabs.com> From: Christophe Diot To: NGC2000-PC , "'Cost264@lip6.fr'" , "'rm@mash.CS.Berkeley.EDU'" , "'maddogs@ietf.org'" , "'ssm-interest@external.cisco.com'" , "'rmt@lbl.gov'" Subject: NGC 2000 retransmission on SSM Date: Wed, 8 Nov 2000 15:36:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain Sender: owner-rmt@lbl.gov Precedence: bulk 8, November, 2000 Thanks to Sprint, Cisco, the University of Oregon, UC-Santa Barbara, and Stanford University, NGC2000, the Second International Workshop on Networked Group Communication is being multicast live from the Stanford University Campus Nov. 8-10. The conference s being transmitted in real-time via Source Specific Multicast. Sessions are only available by SSM. For information on joining, see the University of Oregon Videolab session page at: http://videolab.uoregon.edu/cgi-bin/urd.cgi to join. This is the first event to be retransmitted over SSM. The conference is being held at Stanford University in Palo Alto, California from November 8th to the 10th and the program can be found at: http://www.cs.ucsb.edu/ngc2000/program/ The aim of the Workshop is to allow researchers and practitioners 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). >From owner-rmt@listserv.lbl.gov Sun Nov 12 08:03:33 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id HAA00959; Sun, 12 Nov 2000 07:59:51 -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 HAA00955 for ; Sun, 12 Nov 2000 07:59:49 -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 HAA04060 for ; Sun, 12 Nov 2000 07:59:48 -0800 (PST) Received: from davis.bandwiz.com ([212.150.220.34]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA04057 for ; Sun, 12 Nov 2000 07:59:46 -0800 (PST) Received: by davis.bandwiz.com with Internet Mail Service (5.5.2650.21) id ; Sun, 12 Nov 2000 17:59:10 +0200 Message-ID: From: Meir Feder To: "'rmt@lbl.gov'" , "'luby@digitalfountain.com'" Cc: Doron Rajwan , Nadav Shulman Subject: Separating the MRCC from the ALC/FEC Date: Sun, 12 Nov 2000 17:59:05 +0200 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 Dear RMT-er's, In response to the standardization effort of the RMT working group in the drafts ALC-01 and MRCC-00, we feel that the ALC draft combines together the FEC and the congestion control somewhat unnecessarily. Thus, we like to suggest that the draft will maintain a clear separation of the functionality between the MRCC and the ALC/FEC part. We believe that the MRCC will prove itself as a working protocol for multicast congestion control, that is important for interoperability and for friendly network behavior. The FEC is the data (maybe the most natural data) that is transferred via the MRCC transport. Thus, MRCC should essentially be (and is) for the Transport layer (layer 4), while ALC/FEC should be for the Application layer (layer 7). The separation will give the following benefits: 1. MRCC will be able to deliver not only FEC packets but also, e.g., RTP packets (for continuous real-time viewing). When the payload is ALC/FEC packets, registering to more MRCC layers will provide a faster download. When using RTP packets, it can provide higher quality streams, by using successive refinement payload. 2. Since MRCC and ALC/FEC (implementing different communication layers) will each have its own header, version number, header size field, extension fields, and so on, modifications in one should not affect the other. 3. The long-term goal should be the implementation of MRCC at the kernel level, like TCP today, in order to give true inter-operability, congestion control, fairness, safety, robustness and so on. Applications will create MRCC socket, possibly giving only (S,G), and start receiving packets at varying rates. If MRCC is not implemented at the kernel, there is a danger that we will see more aggressive MRCC implementations over time. 4. ALC/FEC packets should carry only application-related information, not transport. Note that, then, the source of ALC/FEC packets can be payload of MRCC protocol, disk files, caches, broadcast channels (when there is no need for MRCC...) or any other source. The separation is clear and simple. The header part of the ALC associated with congestion control will be in the MRCC, while the ALC/FEC header will have the code information. In general, in order to know if some information should be in the header field of MRCC or ALC/FEC, one should ask the following question: If a packet is cached to the disk, and re-transmitted later, should it have the original value (ALC/FEC) or a new value (MRCC). Thus, for example, the time extension mechanism should migrate to MRCC. Meir Feder and Doron Rajwan Bandwiz >From owner-rmt@listserv.lbl.gov Sun Nov 12 11:03:55 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id LAA01115; Sun, 12 Nov 2000 11: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 LAA01111 for ; Sun, 12 Nov 2000 11:02: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 LAA12365 for ; Sun, 12 Nov 2000 11:02:02 -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 LAA12362 for ; Sun, 12 Nov 2000 11:02:00 -0800 (PST) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id UAA06380; Sun, 12 Nov 2000 20:00:18 +0100 (CET) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200011121900.UAA06380@info.iet.unipi.it> Subject: Re: Separating the MRCC from the ALC/FEC In-Reply-To: from Meir Feder at "Nov 12, 2000 05:59:05 pm" To: Meir Feder Date: Sun, 12 Nov 2000 20:00:18 +0100 (CET) CC: "'rmt@lbl.gov'" , "'luby@digitalfountain.com'" , Doron Rajwan , Nadav Shulman 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 Hi, ... > drafts ALC-01 and MRCC-00, we feel that the ALC draft combines together the > FEC and the congestion control somewhat unnecessarily. Thus, we like to point well taken and in fact we are working on a revised version of ALC draft mostly along the lines you suggest. In ALC-01 the MRCC info is already well separated from the ALC header (the header field is opaque); it is true that ALC-01 still has some FEC-related header fields which do not belong there, and we are revising the draft and move this info to the payload. > 2. Since MRCC and ALC/FEC (implementing different communication layers) will > each have its own header, version number, header size field, extension > fields, and so on, modifications in one should not affect the other. I am not too happy in using two different headers for MRCC (or whatever cong. control protocol is going to be used) and ALC, as you seem to suggest, as some form of cong.control is an integral part of ALC. > 3. The long-term goal should be the implementation of MRCC at the kernel > level, like TCP today, in order to give true inter-operability, congestion ... > varying rates. If MRCC is not implemented at the kernel, there is a danger > that we will see more aggressive MRCC implementations over time. having a protocol implemented in kernel or user space is irrelevant for most aspects, except perhaps overhead at source/receiver (which i do not think is a concern here) and ease of deployment (and this is a double-edged sword). We can have bad (more aggressive, or buggy, or just initial) kernel implementations of MRCC and be stuck with them for a long time because people do not upgrade the OS (there are still IGMPv1 hosta around). Or we can have good user-space implementations of MRCC and stand the risk of people using "accelerators" which are more aggressive than they should (same as it happens with TCP and various companies offering modified stacks). > The separation is clear and simple. The header part of the ALC associated > with congestion control will be in the MRCC, while the ALC/FEC header will > have the code information. In general, in order to know if some information > should be in the header field of MRCC or ALC/FEC, one should ask the > following question: If a packet is cached to the disk, and re-transmitted > later, should it have the original value (ALC/FEC) or a new value (MRCC). > Thus, for example, the time extension mechanism should migrate to MRCC. I partly disagree with the example. CC controls the throughput ("slower", "faster"), whereas the time extension mechanism operates at a higher level ("I am not done yet"). It certainly does not belong to MRCC e.g. for streaming video you do not need it ("sorry, the show is over!"). You might argue that it does not even belong to ALC/FEC, but the thing is you have to info somewhere. cheers luigi rizzo ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone (510) 666 2927 . ----------------------------------+----------------------------------------- >From owner-rmt@listserv.lbl.gov Fri Nov 17 00:41:12 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id AAA23006; Fri, 17 Nov 2000 00:38: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 AAA23002 for ; Fri, 17 Nov 2000 00:38: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 AAA01981 for ; Fri, 17 Nov 2000 00:38:57 -0800 (PST) Received: from acm.cs.umn.edu (acm.cs.umn.edu [128.101.32.12]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA01976 for ; Fri, 17 Nov 2000 00:38:56 -0800 (PST) Received: from monopoly.cs.umn.edu (monopoly.cs.umn.edu [128.101.32.5]) by acm.cs.umn.edu (8.11.1/8.11.0) with ESMTP id eAH8e6q09362 for ; Fri, 17 Nov 2000 02:40:06 -0600 (CST) (envelope-from orasis@acm.cs.umn.edu) Received: (from orasis@localhost) by monopoly.cs.umn.edu (8.8.8/8.8.8) id CAA25368 for rmt@lbl.gov; Fri, 17 Nov 2000 02:36:38 -0800 (PST) Date: Fri, 17 Nov 2000 02:36:38 -0800 (PST) Message-Id: <200011171036.CAA25368@monopoly.cs.umn.edu> From: Justin Chapweske To: rmt@lbl.gov Subject: Java FEC Library & Java ALC Sender: owner-rmt@lbl.gov Precedence: bulk Hello all, we have just released a Java library for FEC encoding, decoding, and IO at http://www.sourceforge.net/projects/swarmcast/. We are committed to having the best Java FEC library out there, so we will be constantly making minor improvements to this core package and would greatly appreciate any feedback. Next we will be doing an ALC/RLC implementation that will be released under the LGPL. We have not yet started on this and love to collaborate with anyone else that has started or interested in such an undertaking. Release Notes for Java FEC v0.5 This software is a library for performing Forward Error Correction (FEC) encoding, decoding, and IO in Java. 1 Features 1. A SPI plugin architecture that allows any FEC code that has no inherent reception innefficiency to be plugged in. Preferences between different implementations can be expressed via a simple configuration file. 2. A pure Java port of Luigi Rizzo's wonderful C FEC package. The code for this port is quite solid and provides an acceptible 33/k MB/s performance on a 500mhz k6-2 for 8 bit codes. This is 4-5 times faster than the port done by Dan Rubenstein's group, which is to be expected as they were more focused on adding interesting encoding/decoding features than speed. 3. A much improved version of Lorenzo Vicisano's JNI wrapper. The JNI calls now have a negligable overhead for a delightful 160/k MB/s on a 900mhz Athlon. If a native library for your platform is not available then it will fall back to the pure Java version. 4. A FEC I/O package that is optimized for decoding speed and low memory consumption. 5. For the license I've simply included Luigi's original copyright, so you can basically do whatever you want with this thing. But if you do use this thing, please let me know what I can do to make it better for you. 2 Future Work/Open Tasks 1. Implement different IO routines based on Jim Gemmel's very nicely written paper on FEC performance tuning. 2. Implement more codes (Please let me know if you know of any codes as I'll implement them myself if they are compelling enough) 3. Tune the 16 bit codes to create the minimum required matrices on demand, this will allow n values of up to 65536 to be feasible. 4. The shuffling proceedure causes some confusing behavior for decoding, this will be fixed asap. 5. Have the native implementation automatically deploy itself so that the user does not have to manually set up their library path. -Justin >From owner-rmt@listserv.lbl.gov Fri Nov 24 15:14:44 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id PAA23243; Fri, 24 Nov 2000 15:12: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 PAA23236 for ; Fri, 24 Nov 2000 15:12: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 PAA15589 for ; Fri, 24 Nov 2000 15:12:43 -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 PAA15583 for ; Fri, 24 Nov 2000 15:12:42 -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 SAA21886; Fri, 24 Nov 2000 18:12:17 -0500 (EST) Message-Id: <200011242312.SAA21886@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-02.txt Date: Fri, 24 Nov 2000 18:12:17 -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 : RMT BB Forward Error Correction Codes Author(s) : M. Luby et al. Filename : draft-ietf-rmt-bb-fec-02.txt Pages : 12 Date : 22-Nov-00 This memo describes the abstract packet formats and IANA registration procedures for use of Forward Error Correction (FEC) codes within the context of reliable IP multicast transport. This memo should be read in conjunction with and uses the terminology of the companion memo [1], which 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-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-bb-fec-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-bb-fec-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: <20001122150120.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-fec-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-fec-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001122150120.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Fri Nov 24 15:14:44 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id PAA23244; Fri, 24 Nov 2000 15:12: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 PAA23234 for ; Fri, 24 Nov 2000 15:12: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 PAA15588 for ; Fri, 24 Nov 2000 15:12:43 -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 PAA15582 for ; Fri, 24 Nov 2000 15:12:42 -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 SAA21861; Fri, 24 Nov 2000 18:12:14 -0500 (EST) Message-Id: <200011242312.SAA21861@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-lct-00.txt Date: Fri, 24 Nov 2000 18:12:13 -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 : Layered Coding Transport: A massively scalable multicast protocol Author(s) : M. Luby et al. Filename : draft-ietf-rmt-bb-lct-00.txt Pages : 28 Date : 22-Nov-00 This document describes Layered Coding Transport, a massively scalable multicast protocol, hereafter referred to as LCT. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-lct-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-lct-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-lct-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: <20001122150111.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-lct-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-lct-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001122150111.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Fri Nov 24 15:28:17 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id PAA23282; Fri, 24 Nov 2000 15:28: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 PAA23278 for ; Fri, 24 Nov 2000 15:28: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 PAA16822 for ; Fri, 24 Nov 2000 15:28:06 -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 PAA16819 for ; Fri, 24 Nov 2000 15:28: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 SAA26342; Fri, 24 Nov 2000 18:28:03 -0500 (EST) Message-Id: <200011242328.SAA26342@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-lcc-00.txt Date: Fri, 24 Nov 2000 18:28:02 -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: Layered Congestion Control Author(s) : M. Luby et al. Filename : draft-ietf-rmt-bb-lcc-00.txt Pages : 20 Date : 22-Nov-00 This document describes LCC, a scalable layered congestion control building block for multicast. LCC is a combination of approaches that allow multiple receivers to concurrently receive packets from a single sender at varying rates depending on individual bandwidth connections and network conditions. Two basic goals of the approach are to allow each receiver to obtain the full benefit of the available bandwidth to the sender and to be fair to other flows in the network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-lcc-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-lcc-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-lcc-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: <20001122150129.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-lcc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-lcc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001122150129.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Fri Nov 24 15:28:19 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id PAA23288; Fri, 24 Nov 2000 15:28:12 -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 PAA23284 for ; Fri, 24 Nov 2000 15:28:10 -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 PAA16829 for ; Fri, 24 Nov 2000 15:28:10 -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 PAA16826 for ; Fri, 24 Nov 2000 15:28:09 -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 SAA26352; Fri, 24 Nov 2000 18:28:06 -0500 (EST) Message-Id: <200011242328.SAA26352@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-info-fec-00.txt Date: Fri, 24 Nov 2000 18:28:06 -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 use of Forward Error Correction in Reliable Multicast Author(s) : M. Luby et al. Filename : draft-ietf-rmt-info-fec-00.txt Pages : 18 Date : 22-Nov-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-info-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-info-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-info-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: <20001122150137.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-info-fec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-info-fec-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001122150137.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Mon Nov 27 20:26:11 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id UAA05463; Mon, 27 Nov 2000 20:23: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 UAA05459 for ; Mon, 27 Nov 2000 20:23: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 UAA29593 for ; Mon, 27 Nov 2000 20:23:53 -0800 (PST) Received: from acm.cs.umn.edu (acm.cs.umn.edu [128.101.32.12]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA29590 for ; Mon, 27 Nov 2000 20:23:52 -0800 (PST) Received: from monopoly.cs.umn.edu (monopoly.cs.umn.edu [128.101.32.5]) by acm.cs.umn.edu (8.11.1/8.11.0) with ESMTP id eAS4OUq59925 for ; Mon, 27 Nov 2000 22:24:30 -0600 (CST) (envelope-from orasis@acm.cs.umn.edu) Received: (from orasis@localhost) by monopoly.cs.umn.edu (8.8.8/8.8.8) id WAA21496 for rmt@lbl.gov; Mon, 27 Nov 2000 22:21:21 -0800 (PST) Date: Mon, 27 Nov 2000 22:21:21 -0800 From: Justin Chapweske To: rmt@lbl.gov Subject: Vandermonde FEC name Message-ID: <20001127222121.G12583@monopoly.cs.umn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-rmt@lbl.gov Precedence: bulk Very nice job on the newest drafts guys, especially on the RMT BB FEC Codes draft. It is very close to what I implemented against the old ALC draft. Now that 128 is specified as the encoding ID for small block codes, does anyone (Luigi) know what the FEC Encoding Name will be for the Vandermonde codes? -- Justin Chapweske, Lead Swarmcast Developer, openCOLA Inc. http://www.sourceforge.net/projects/swarmcast/ >From owner-rmt@listserv.lbl.gov Mon Nov 27 21:00:22 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id VAA05541; Mon, 27 Nov 2000 21:00:08 -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 VAA05537 for ; Mon, 27 Nov 2000 21:00:06 -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 VAA02421 for ; Mon, 27 Nov 2000 21:00:05 -0800 (PST) Received: from acm.cs.umn.edu (acm.cs.umn.edu [128.101.32.12]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA02417 for ; Mon, 27 Nov 2000 21:00:05 -0800 (PST) Received: from monopoly.cs.umn.edu (monopoly.cs.umn.edu [128.101.32.5]) by acm.cs.umn.edu (8.11.1/8.11.0) with ESMTP id eAS50gq60715 for ; Mon, 27 Nov 2000 23:00:42 -0600 (CST) (envelope-from orasis@acm.cs.umn.edu) Received: (from orasis@localhost) by monopoly.cs.umn.edu (8.8.8/8.8.8) id WAA21875 for rmt@lbl.gov; Mon, 27 Nov 2000 22:57:37 -0800 (PST) Date: Mon, 27 Nov 2000 22:57:37 -0800 From: Justin Chapweske To: rmt@lbl.gov Subject: test... Message-ID: <20001127225737.H12583@monopoly.cs.umn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-rmt@lbl.gov Precedence: bulk testing to see if my mail is getting through to the list.. -- Justin Chapweske, Lead Swarmcast Developer, openCOLA Inc. http://www.sourceforge.net/projects/swarmcast/ >From owner-rmt@listserv.lbl.gov Tue Nov 28 03:23:25 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA05844; Tue, 28 Nov 2000 03: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 DAA05840 for ; Tue, 28 Nov 2000 03: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 DAA10336 for ; Tue, 28 Nov 2000 03:22:44 -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 DAA10325 for ; Tue, 28 Nov 2000 03:22:38 -0800 (PST) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id MAA18835; Tue, 28 Nov 2000 12:25:14 +0100 (CET) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200011281125.MAA18835@info.iet.unipi.it> Subject: Re: Vandermonde FEC name In-Reply-To: <20001127222121.G12583@monopoly.cs.umn.edu> from Justin Chapweske at "Nov 27, 2000 10:21:21 pm" To: Justin Chapweske Date: Tue, 28 Nov 2000 12:25:14 +0100 (CET) CC: rmt@lbl.gov 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 > Very nice job on the newest drafts guys, especially on the RMT BB FEC > Codes draft. It is very close to what I implemented against the old ALC > draft. > > Now that 128 is specified as the encoding ID for small block > codes, does anyone (Luigi) know what the FEC Encoding Name will be for the > Vandermonde codes? no idea, sorry. cheers luigi > -- > Justin Chapweske, Lead Swarmcast Developer, openCOLA Inc. > http://www.sourceforge.net/projects/swarmcast/ > >From owner-rmt@listserv.lbl.gov Wed Nov 29 03:32:43 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA12846; Wed, 29 Nov 2000 03:31:26 -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 DAA12842 for ; Wed, 29 Nov 2000 03:31:25 -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 DAA07749 for ; Wed, 29 Nov 2000 03:31:24 -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 DAA07746 for ; Wed, 29 Nov 2000 03:31:23 -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 GAA01933; Wed, 29 Nov 2000 06:31:22 -0500 (EST) Message-Id: <200011291131.GAA01933@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-track-00.txt Date: Wed, 29 Nov 2000 06:31: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 : Reliable Multicast Transport Building Block for TRACK Author(s) : B. Whetten, D. Chiu et al. Filename : draft-ietf-rmt-bb-track-00.txt Pages : 26 Date : 28-Nov-00 This document describes the TRACK Building Block. It contains functions relating to positive acknowledgments and hierarchical tree construction and maintenance. It is primarily meant to be used as part of the TRACK Protocol Instantiation. It is also designed to be useful as part of overlay multicast systems that wish to offer efficient confirmed delivery of multicast messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-track-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-track-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-track-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: <20001128134540.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-track-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-track-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128134540.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Wed Nov 29 03:32:43 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA12853; Wed, 29 Nov 2000 03:31:30 -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 DAA12849 for ; Wed, 29 Nov 2000 03:31: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 DAA07764 for ; Wed, 29 Nov 2000 03:31:28 -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 DAA07761 for ; Wed, 29 Nov 2000 03:31:27 -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 GAA01967; Wed, 29 Nov 2000 06:31:26 -0500 (EST) Message-Id: <200011291131.GAA01967@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-tree-config-01.txt Date: Wed, 29 Nov 2000 06:31:26 -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: Tree Auto-Configuration Author(s) : M. Kadansky, B. Levine, D. Chiu, B. Whetten, G. Taskale, B. Cain, D. Thaler, S. Koh Filename : draft-ietf-rmt-bb-tree-config-01.txt Pages : 21 Date : 28-Nov-00 The Reliable Multicast Transport Working Group has been chartered to standardize multicast transport services. This working group expects to initially standardize three protocol instantiations. This draft is concerned with the requirements of the tree-based ACK protocol. In particular, it is concerned with defining the building block for auto-configuration of the logical ACK-tree. According to the charter, a building block is 'a coarse-grained modular component that is common to multiple protocols along with abstract APIs that define a building block's access methods and their arguments.' For more information, see the Reliable Multicast Transport Building Blocks and Reliable Multicast Design Space documents [WLKHFL00][HWKFV00]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-tree-config-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-bb-tree-config-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-bb-tree-config-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: <20001128134550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-tree-config-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-tree-config-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128134550.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Wed Nov 29 03:32:44 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA12840; Wed, 29 Nov 2000 03:31: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 DAA12836 for ; Wed, 29 Nov 2000 03:31:20 -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 DAA07728 for ; Wed, 29 Nov 2000 03:31:20 -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 DAA07718 for ; Wed, 29 Nov 2000 03:31:19 -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 GAA01887; Wed, 29 Nov 2000 06:31:18 -0500 (EST) Message-Id: <200011291131.GAA01887@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-norm-00.txt Date: Wed, 29 Nov 2000 06:31:17 -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 : NACK-Oriented Reliable Multicast Protocol (NORM) Author(s) : B. Adamson, C. Bormann, S. Floyd, M. Handley, J. Macker Filename : draft-ietf-rmt-pi-norm-00.txt Pages : 11 Date : 28-Nov-00 This document describes the messages and procedures of the Nega- tive-acknowledgement (NACK) oriented reliable multicast (NORM). This revision of the document represents an initial outline of the protocol description. The document requires refinement in a number of areas to be considered complete. At this time, the document describes the high level details of the reliable multicast bulk transfer service model this protocol hopes to fulfill and the gen- eral message types and mechanisms which will be used to accomplish those goals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-norm-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-norm-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-norm-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: <20001128134529.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-pi-norm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-pi-norm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128134529.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Wed Nov 29 18:00:47 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id RAA18573; Wed, 29 Nov 2000 17:59:38 -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 RAA18565 for ; Wed, 29 Nov 2000 17:59:35 -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 RAA17940 for ; Wed, 29 Nov 2000 17:59:35 -0800 (PST) Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA17935 for ; Wed, 29 Nov 2000 17:59:34 -0800 (PST) Received: (from root@localhost) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU1msN25363; Wed, 29 Nov 2000 18:48:54 -0700 Received: from mailproxy.lanl.gov ([128.165.254.25]) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATM4Hf09303; Wed, 29 Nov 2000 15:04:17 -0700 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mailproxy.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATM4Ff25980; Wed, 29 Nov 2000 15:04:15 -0700 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id QAA06320 for ietf-123-outbound.07@ietf.org; Wed, 29 Nov 2000 16:45:01 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA01521 for ; Wed, 29 Nov 2000 06:31:27 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01967; Wed, 29 Nov 2000 06:31:26 -0500 (EST) Message-Id: <200011291131.GAA01967@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-tree-config-01.txt Date: Wed, 29 Nov 2000 06:31:26 -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: Tree Auto-Configuration Author(s) : M. Kadansky, B. Levine, D. Chiu, B. Whetten, G. Taskale, B. Cain, D. Thaler, S. Koh Filename : draft-ietf-rmt-bb-tree-config-01.txt Pages : 21 Date : 28-Nov-00 The Reliable Multicast Transport Working Group has been chartered to standardize multicast transport services. This working group expects to initially standardize three protocol instantiations. This draft is concerned with the requirements of the tree-based ACK protocol. In particular, it is concerned with defining the building block for auto-configuration of the logical ACK-tree. According to the charter, a building block is 'a coarse-grained modular component that is common to multiple protocols along with abstract APIs that define a building block's access methods and their arguments.' For more information, see the Reliable Multicast Transport Building Blocks and Reliable Multicast Design Space documents [WLKHFL00][HWKFV00]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-tree-config-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-bb-tree-config-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-bb-tree-config-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: <20001128134550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-tree-config-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-tree-config-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128134550.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Wed Nov 29 18:00:47 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id RAA18572; Wed, 29 Nov 2000 17:59:38 -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 RAA18563 for ; Wed, 29 Nov 2000 17:59:35 -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 RAA17937 for ; Wed, 29 Nov 2000 17:59:34 -0800 (PST) Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA17933 for ; Wed, 29 Nov 2000 17:59:34 -0800 (PST) Received: (from root@localhost) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU1teo26146; Wed, 29 Nov 2000 18:55:40 -0700 Received: from mailproxy.lanl.gov ([128.165.254.25]) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATM4Hf09303; Wed, 29 Nov 2000 15:04:17 -0700 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mailproxy.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATM4Ff25980; Wed, 29 Nov 2000 15:04:15 -0700 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id QAA06320 for ietf-123-outbound.07@ietf.org; Wed, 29 Nov 2000 16:45:01 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA01521 for ; Wed, 29 Nov 2000 06:31:27 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01967; Wed, 29 Nov 2000 06:31:26 -0500 (EST) Message-Id: <200011291131.GAA01967@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-tree-config-01.txt Date: Wed, 29 Nov 2000 06:31:26 -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: Tree Auto-Configuration Author(s) : M. Kadansky, B. Levine, D. Chiu, B. Whetten, G. Taskale, B. Cain, D. Thaler, S. Koh Filename : draft-ietf-rmt-bb-tree-config-01.txt Pages : 21 Date : 28-Nov-00 The Reliable Multicast Transport Working Group has been chartered to standardize multicast transport services. This working group expects to initially standardize three protocol instantiations. This draft is concerned with the requirements of the tree-based ACK protocol. In particular, it is concerned with defining the building block for auto-configuration of the logical ACK-tree. According to the charter, a building block is 'a coarse-grained modular component that is common to multiple protocols along with abstract APIs that define a building block's access methods and their arguments.' For more information, see the Reliable Multicast Transport Building Blocks and Reliable Multicast Design Space documents [WLKHFL00][HWKFV00]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-tree-config-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-bb-tree-config-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-bb-tree-config-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: <20001128134550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-tree-config-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-tree-config-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128134550.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Wed Nov 29 18:13:43 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id SAA18640; Wed, 29 Nov 2000 18:13: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 SAA18636 for ; Wed, 29 Nov 2000 18:13: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 SAA20665 for ; Wed, 29 Nov 2000 18:13:27 -0800 (PST) Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA20662 for ; Wed, 29 Nov 2000 18:13:26 -0800 (PST) Received: (from root@localhost) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU1u2s26542; Wed, 29 Nov 2000 18:56:02 -0700 Received: from listman.lanl.gov ([128.165.3.62]) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATM5af11545; Wed, 29 Nov 2000 15:05:36 -0700 Received: (from daemon@localhost) by listman.lanl.gov (8.9.3/8.9.3/(cic-5, 2/9/99)) id PAA02438 for ietf-outgoing; Wed, 29 Nov 2000 15:05:32 -0700 Message-Id: <200011291131.GAA01933@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-track-00.txt Date: Wed, 29 Nov 2000 06:31:21 -0500 Sender: owner-rmt@lbl.gov Precedence: bulk --NextPart-- >From owner-rmt@listserv.lbl.gov Wed Nov 29 19:01:30 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id TAA18770; Wed, 29 Nov 2000 19:01:12 -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 TAA18761 for ; Wed, 29 Nov 2000 19:01:10 -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 TAA27710 for ; Wed, 29 Nov 2000 19:01:09 -0800 (PST) Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id TAA27702 for ; Wed, 29 Nov 2000 19:01:08 -0800 (PST) Received: (from root@localhost) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU2TV409186; Wed, 29 Nov 2000 19:29:31 -0700 Received: from mailproxy.lanl.gov ([128.165.254.25]) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATM4Hf09303; Wed, 29 Nov 2000 15:04:17 -0700 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mailproxy.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATM4Ff25980; Wed, 29 Nov 2000 15:04:15 -0700 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id QAA06320 for ietf-123-outbound.07@ietf.org; Wed, 29 Nov 2000 16:45:01 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA01521 for ; Wed, 29 Nov 2000 06:31:27 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01967; Wed, 29 Nov 2000 06:31:26 -0500 (EST) Message-Id: <200011291131.GAA01967@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-tree-config-01.txt Date: Wed, 29 Nov 2000 06:31:26 -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: Tree Auto-Configuration Author(s) : M. Kadansky, B. Levine, D. Chiu, B. Whetten, G. Taskale, B. Cain, D. Thaler, S. Koh Filename : draft-ietf-rmt-bb-tree-config-01.txt Pages : 21 Date : 28-Nov-00 The Reliable Multicast Transport Working Group has been chartered to standardize multicast transport services. This working group expects to initially standardize three protocol instantiations. This draft is concerned with the requirements of the tree-based ACK protocol. In particular, it is concerned with defining the building block for auto-configuration of the logical ACK-tree. According to the charter, a building block is 'a coarse-grained modular component that is common to multiple protocols along with abstract APIs that define a building block's access methods and their arguments.' For more information, see the Reliable Multicast Transport Building Blocks and Reliable Multicast Design Space documents [WLKHFL00][HWKFV00]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-tree-config-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-bb-tree-config-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-bb-tree-config-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: <20001128134550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-tree-config-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-tree-config-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128134550.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Wed Nov 29 19:01:30 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id TAA18776; Wed, 29 Nov 2000 19:01: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 TAA18772 for ; Wed, 29 Nov 2000 19:01: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 TAA27726 for ; Wed, 29 Nov 2000 19:01:12 -0800 (PST) Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id TAA27723 for ; Wed, 29 Nov 2000 19:01:12 -0800 (PST) Received: (from root@localhost) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU2UcX09784; Wed, 29 Nov 2000 19:30:38 -0700 Received: from listman.lanl.gov ([128.165.3.62]) by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATM5af11545; Wed, 29 Nov 2000 15:05:36 -0700 Received: (from daemon@localhost) by listman.lanl.gov (8.9.3/8.9.3/(cic-5, 2/9/99)) id PAA02438 for ietf-outgoing; Wed, 29 Nov 2000 15:05:32 -0700 Message-Id: <200011291131.GAA01933@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-track-00.txt Date: Wed, 29 Nov 2000 06:31:21 -0500 Sender: owner-rmt@lbl.gov Precedence: bulk --NextPart-- >From owner-rmt@listserv.lbl.gov Thu Nov 30 14:13:30 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id OAA21466; Thu, 30 Nov 2000 14:10: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 OAA21458 for ; Thu, 30 Nov 2000 14:10:36 -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 OAA10987 for ; Thu, 30 Nov 2000 14:10:36 -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 OAA10872 for ; Thu, 30 Nov 2000 14:10:20 -0800 (PST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id PAA17469; Thu, 30 Nov 2000 15:09:49 -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 PAA16741; Thu, 30 Nov 2000 15:09:46 -0700 (MST)] Received: from arc.corp.mot.com (marcia.arc.corp.mot.com [217.1.10.74]) by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id eAUM8US05125; Fri, 1 Dec 2000 09:08:30 +1100 (EST) Message-ID: <3A26CF70.552047EF@arc.corp.mot.com> Date: Fri, 01 Dec 2000 09:06:40 +1100 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 CC: Lorenzo Vicisano , Allison Mankin Subject: RMT Tentative Agenda (items only at this stage) Content-Type: multipart/mixed; boundary="------------0336CD28CEB2CCF5E1221257" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------0336CD28CEB2CCF5E1221257 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear RMT'ers, in preparing the agenda for the San Diego meeting We've noticed that we have a lot of drafts, some of which are new and some of which have expired. In keeping with directives from the ADs we are asking that presenters assume that people have read the draft and that their presentations consist of a brief summary of the draft/updates to the draft followed by discussion on outstanding issues. Given this approach we are expecting that there will only be presentations for the drafts that have changed since the last meeting, i.e. drafts with * in front of them. To date we've only received a couple of explicit requests for time slots. If you want to present during the RMT sessions at the IETF please email the chairs ASAP regards, Roger, Lorenzo, and Allison Outstanding RMT Drafts/Potential Presentations at San Diego ========================================= Key: * = updated since last meeting exp = draft has expired Agenda Bashing, Roger 5 mins General Draft Updates * NORM reorganisation * ALC drafts * * TRACK * CONGESTION CONTROL * Mike Luby 15 mins? GRA exp Individual drafts * Ken Calvert 15 mins MIBs Michale Garwood 10 mins msec WG advertisement, Roger, 5 mins --------------0336CD28CEB2CCF5E1221257 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 --------------0336CD28CEB2CCF5E1221257-- >From owner-rmt@listserv.lbl.gov Mon Dec 4 08:39:56 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id IAA09125; Mon, 4 Dec 2000 08:35:07 -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 IAA09121 for ; Mon, 4 Dec 2000 08:35:05 -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 IAA28600 for ; Mon, 4 Dec 2000 08:35:04 -0800 (PST) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA28589 for ; Mon, 4 Dec 2000 08:35:03 -0800 (PST) Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14]) by east.isi.edu (8.9.2/8.9.2) with SMTP id LAA26743; Mon, 4 Dec 2000 11:35:11 -0500 (EST) Posted-Date: Mon, 04 Dec 2000 11:38:48 -0500 Message-Id: <10012041638.AA28386@maia.east.isi.edu> Received: from LOCALHOST.east.isi.edu by maia.east.isi.edu (4.1/4.0.3-6) id ; Mon, 4 Dec 00 11:38:49 EST To: agenda@ietf.org Subject: RMT Draft Agenda Cc: lorenzo@cisco.com, roger.kermode@motorola.com, mankin@ISI.EDU, sob@harvard.edu, rmt@lbl.gov Reply-To: mankin@east.isi.edu Date: Mon, 04 Dec 2000 11:38:48 -0500 From: Allison Mankin Sender: owner-rmt@lbl.gov Precedence: bulk RMT Topics at San Diego - Draft Agenda ====================================== Key: exp = draft has expired * = updated since last meeting, expected to be discussed, times to be refined no star means probably not to be discussed Agenda Bashing, Roger 5 mins General Draft Updates * NORM reorganisation * ALC drafts * * TRACK * CONGESTION CONTROL * Mike Luby 15 mins? GRA/PGM exp Newly issued PGM draft - plan? Individual drafts (not in charter) * Ken Calvert 15 mins MIBs Michale Garwood 10 mins Advertisement of MSEC BOF, Roger, 5 mins Advertisement of discussion of TFRC in TSVWG, Allison 2 mins >From owner-rmt@listserv.lbl.gov Mon Dec 4 09:23:24 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id JAA09408; Mon, 4 Dec 2000 09:20:08 -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 JAA09404 for ; Mon, 4 Dec 2000 09:20: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 JAA18090 for ; Mon, 4 Dec 2000 09:20:06 -0800 (PST) Received: from cisco.com (zipper.cisco.com [171.69.25.142]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA18086 for ; Mon, 4 Dec 2000 09:20:06 -0800 (PST) Received: from localhost (speakman@localhost) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id JAA21548; Mon, 4 Dec 2000 09:18:33 -0800 (PST) Message-Id: <200012041718.JAA21548@cisco.com> To: mankin@east.isi.edu cc: sob@harvard.edu, rmt@lbl.gov Subject: Re: RMT Draft Agenda Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Date: Mon, 04 Dec 2000 09:18:32 -0800 From: Tony Speakman Sender: owner-rmt@lbl.gov Precedence: bulk > GRA/PGM > exp At least one of the authors is no longer active on the draft while others have expressed interest. I plan to revisit the thing with Don Towsley and Christos Papadopoulos shortly, but there's nothing to discuss for the moment. > Newly issued PGM draft - plan? On behalf of all the PGM authors, I can say that we have no plan to discuss the new PGM spec in this forum. Tony S >From owner-rmt@listserv.lbl.gov Mon Dec 4 10:20:40 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id KAA09996; Mon, 4 Dec 2000 10:17:27 -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 KAA09992 for ; Mon, 4 Dec 2000 10:17:25 -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 KAA12605 for ; Mon, 4 Dec 2000 10:17:24 -0800 (PST) Received: from mail.webfountain.com (mail.webfountain.com [63.161.54.5]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA12594 for ; Mon, 4 Dec 2000 10:17:23 -0800 (PST) Received: from leningrad (gate.webfountain.com [63.161.54.3]) by mail.webfountain.com (8.9.3/8.9.3) with SMTP id KAA17928; Mon, 4 Dec 2000 10:16:39 -0800 X-Authentication-Warning: mail.webfountain.com: Host gate.webfountain.com [63.161.54.3] claimed to be leningrad From: "Mike Luby" To: , Cc: , , , Subject: RE: RMT Draft Agenda Date: Mon, 4 Dec 2000 10:16:35 -0800 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <10012041638.AA28386@maia.east.isi.edu> Sender: owner-rmt@lbl.gov Precedence: bulk Allison et. al., Roger sent out a very similar draft agenda recently, and I sent the enclosed email back to him in response. Please take a look at what this email proposes before making up the final schedule. Thanks, Mike ---------------------------------------------------------------------------- -------------- From: Mike Luby [luby@digitalfountain.com] Sent: Thursday, November 30, 2000 7:53 PM To: Roger.Kermode@motorola.com Cc: Michael Luby; Luigi Rizzo; Lorenzo Vicisano; Mark Handley Subject: RE: RMT Tentative Agenda (items only at this stage) Roger, A couple of clarifications and explanations. We submitted four drafts this time from within what used to be called the ALC track (changing the name, and not all of the drafts formally belong in whatever the track is called anyway). The four new drafts are the LCT draft (correctly listed below, which will subsume the ALC draft), the LCC draft (correctly listed below, which will subsume the MRCC draft), and two FEC drafts. There is only one FEC draft listed below. There is a new version draft-ietf-rmt-bb-fec-02.txt of the previous FEC draft, and then there is a new FEC draft called draft-ietf-rmt-info-fec-00.txt. Here is how it all fits together: It was decided by Mark Handley and Luigi Rizzo that ALC should be renamed Layered Coding Transport (LCT), and Lorenzo and I agreed with their proposal. The basic rationale is that the LCT protocol could be used for more than reliable content delivery of one object in the future, and in particular it could be used for things like use with layered codecs for video delivery, or for sequential delivery of many objects, etc. In conjunction with this I decided that the MRCC name was too general (multi-rate congestion control can be achieve by a variety of means that don't involve layering), and thus I thought it would be better to rename this to Layered Congestion Control (LCC) (which is more in the spirit of the name LCT). As we are gaining experience with the building block approach, we decided that it made sense to split the FEC documents into two parts: one informational track draft that would describe the available codes and their uses within the RMT working group (this is the new draft, which largely contains material taken from the previous building block draft), and another standards track draft that would specify the abstract packet formats and IANA registration considerations for some specific codes that can be used in conjunction with LCT (also containing material largely from the previous building block draft, and this draft maintained the name of the previous draft). We didn't do this yet with the LCC building block, but I believe that in the long term, if this approach work for the FEC building block, the same model will be adopted by the LCC building block (and perhaps all the building blocks). So, given all of this, I think it actually makes sense to have an agenda item on the schedule for someone to describe all of these structural and naming changes and the rationales behind them. I nominate Mark Handley for this general presentation. Then, I think that Luigi Rizzo should do the LCT presentation and Lorenzo Vicisano should do the two FEC presentations, and I will do the LCC presentation (assuming that they are all willing to do it, of course). Make sense? Mike -----Original Message----- From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Roger Kermode Sent: Thursday, November 30, 2000 2:07 PM To: rmt-list Cc: Lorenzo Vicisano; Allison Mankin Subject: RMT Tentative Agenda (items only at this stage) Dear RMT'ers, in preparing the agenda for the San Diego meeting We've noticed that we have a lot of drafts, some of which are new and some of which have expired. In keeping with directives from the ADs we are asking that presenters assume that people have read the draft and that their presentations consist of a brief summary of the draft/updates to the draft followed by discussion on outstanding issues. Given this approach we are expecting that there will only be presentations for the drafts that have changed since the last meeting, i.e. drafts with * in front of them. To date we've only received a couple of explicit requests for time slots. If you want to present during the RMT sessions at the IETF please email the chairs ASAP regards, Roger, Lorenzo, and Allison Outstanding RMT Drafts/Potential Presentations at San Diego ========================================= Key: * = updated since last meeting exp = draft has expired Agenda Bashing, Roger 5 mins General Draft Updates * NORM reorganisation * ALC drafts * * TRACK * CONGESTION CONTROL * Mike Luby 15 mins? GRA exp Individual drafts * Ken Calvert 15 mins MIBs Michale Garwood 10 mins msec WG advertisement, Roger, 5 mins ---------------------------------------------------------------------------- ------------- -----Original Message----- From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Allison Mankin Sent: Monday, December 04, 2000 8:39 AM To: agenda@ietf.org Cc: lorenzo@cisco.com; roger.kermode@motorola.com; mankin@ISI.EDU; sob@harvard.edu; rmt@lbl.gov Subject: RMT Draft Agenda RMT Topics at San Diego - Draft Agenda ====================================== Key: exp = draft has expired * = updated since last meeting, expected to be discussed, times to be refined no star means probably not to be discussed Agenda Bashing, Roger 5 mins General Draft Updates * NORM reorganisation * ALC drafts * * TRACK * CONGESTION CONTROL * Mike Luby 15 mins? GRA/PGM exp Newly issued PGM draft - plan? Individual drafts (not in charter) * Ken Calvert 15 mins MIBs Michale Garwood 10 mins Advertisement of MSEC BOF, Roger, 5 mins Advertisement of discussion of TFRC in TSVWG, Allison 2 mins >From owner-rmt@listserv.lbl.gov Mon Dec 4 10:55:47 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id KAA10198; Mon, 4 Dec 2000 10:55: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 KAA10194 for ; Mon, 4 Dec 2000 10:55: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 KAA29088 for ; Mon, 4 Dec 2000 10:55:34 -0800 (PST) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA29078 for ; Mon, 4 Dec 2000 10:55:33 -0800 (PST) Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14]) by east.isi.edu (8.9.2/8.9.2) with SMTP id NAA28319; Mon, 4 Dec 2000 13:55:39 -0500 (EST) Posted-Date: Mon, 04 Dec 2000 13:59:17 -0500 Message-Id: <10012041859.AA28576@maia.east.isi.edu> Received: from LOCALHOST.east.isi.edu by maia.east.isi.edu (4.1/4.0.3-6) id ; Mon, 4 Dec 00 13:59:18 EST To: "Mike Luby" Cc: mankin@east.isi.edu, lorenzo@cisco.com, roger.kermode@motorola.com, sob@harvard.edu, rmt@lbl.gov Reply-To: mankin@east.isi.edu Subject: Re: RMT Draft Agenda In-Reply-To: Your message of Mon, 04 Dec 2000 10:16:35 -0800. Date: Mon, 04 Dec 2000 13:59:17 -0500 From: Allison Mankin Sender: owner-rmt@lbl.gov Precedence: bulk Mike, I have dropped agenda@ietf.org from the cc list. We can revise the draft agenda later after we nail down all the details. I jumped in and sent a slightly cleaned-up of Roger's tentative agenda to the Secretariat, because of my AD instincts, wanting RMT very much not to miss today's deadline. In the likely absence of Mark, it sounds to me like you would be a good person to speak to the reorg/rename. Please let us know too how long the several talks you suggest should be. Other comments/corrections on the draft agenda are welcome. Allison >From owner-rmt@listserv.lbl.gov Mon Dec 4 10:58:00 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id KAA10257; Mon, 4 Dec 2000 10:57: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 KAA10253 for ; Mon, 4 Dec 2000 10:57:55 -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 KAA00060 for ; Mon, 4 Dec 2000 10:57:54 -0800 (PST) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA00030 for ; Mon, 4 Dec 2000 10:57:51 -0800 (PST) Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14]) by east.isi.edu (8.9.2/8.9.2) with SMTP id NAA28388; Mon, 4 Dec 2000 13:57:58 -0500 (EST) Posted-Date: Mon, 04 Dec 2000 14:01:37 -0500 Message-Id: <10012041901.AA28589@maia.east.isi.edu> Received: from LOCALHOST.east.isi.edu by maia.east.isi.edu (4.1/4.0.3-6) id ; Mon, 4 Dec 00 14:01:37 EST To: Tony Speakman Cc: mankin@east.isi.edu, sob@harvard.edu, rmt@lbl.gov Reply-To: mankin@east.isi.edu Subject: Re: RMT Draft Agenda In-Reply-To: Your message of Mon, 04 Dec 2000 09:18:32 -0800. <200012041718.JAA21548@cisco.com> Date: Mon, 04 Dec 2000 14:01:37 -0500 From: Allison Mankin Sender: owner-rmt@lbl.gov Precedence: bulk Tony, Thanks for your response to the agenda trial balloons... we'll remove those discussions from the agenda, but look forward to hearing about GRA's revival soon. If anyone wants to just give a short talk about the plans, the chairs are receptive... >From owner-rmt@listserv.lbl.gov Mon Dec 4 11:39:33 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id LAA10911; Mon, 4 Dec 2000 11:39:08 -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 LAA10907 for ; Mon, 4 Dec 2000 11:39:06 -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 LAA17351 for ; Mon, 4 Dec 2000 11:39:05 -0800 (PST) Received: from mail.webfountain.com (mail.webfountain.com [63.161.54.5]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA17338 for ; Mon, 4 Dec 2000 11:39:04 -0800 (PST) Received: from leningrad (gate.webfountain.com [63.161.54.3]) by mail.webfountain.com (8.9.3/8.9.3) with SMTP id LAA24648; Mon, 4 Dec 2000 11:38:50 -0800 X-Authentication-Warning: mail.webfountain.com: Host gate.webfountain.com [63.161.54.3] claimed to be leningrad From: "Mike Luby" To: Cc: , , , , "Mark Handley" , "Michael Luby" Subject: Some proposals for RMT Draft Agenda Date: Mon, 4 Dec 2000 11:38:46 -0800 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <10012041859.AA28576@maia.east.isi.edu> Sender: owner-rmt@lbl.gov Precedence: bulk Allison, Yes, I should have figured that you were making sure to do this before some deadline, and thanks for that. I would be willing to give the general talk, as long as Luigi, Mark and Lorenzo will work with me a bit before the meeting to structure the talk. I'll work with them directly on this if they are willing. Given this, here is my proposed portion of the agenda. I made estimates of the times for each part (and I have less confidence in my time estimates for the presentations with a time interval. Mark, Luigi, Lorenzo, please chip in with your estimates.) Presentation I: General overview (Luby, 20 minutes) (1) Rationale for transition from ALC to LCT (2) Rationale for FEC partitioned into standard track and information track (and why this may be the right approach for all building blocks eventually). (3) Rationale for transition from MRCC to LCC (4) How all the pieces fit together Presentation II: LCT00 changes from ALC01 (Rizzo, 15-20 minutes) Presentation III: FECBB02 and FECInfo00 changes from FECBB01 (Vicisano, 10-15 minutes) Presentation IV: LCC00 changes from MRCC00 (Luby, 5 minutes) Mike -----Original Message----- From: Allison Mankin [mailto:mankin@isi.edu] Sent: Monday, December 04, 2000 10:59 AM To: Mike Luby Cc: mankin@east.isi.edu; lorenzo@cisco.com; roger.kermode@motorola.com; sob@harvard.edu; rmt@lbl.gov Subject: Re: RMT Draft Agenda Mike, I have dropped agenda@ietf.org from the cc list. We can revise the draft agenda later after we nail down all the details. I jumped in and sent a slightly cleaned-up of Roger's tentative agenda to the Secretariat, because of my AD instincts, wanting RMT very much not to miss today's deadline. In the likely absence of Mark, it sounds to me like you would be a good person to speak to the reorg/rename. Please let us know too how long the several talks you suggest should be. Other comments/corrections on the draft agenda are welcome. Allison >From owner-rmt@listserv.lbl.gov Mon Dec 4 11:55:26 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id LAA11043; Mon, 4 Dec 2000 11:55:21 -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 LAA11039 for ; Mon, 4 Dec 2000 11:55: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 LAA23639 for ; Mon, 4 Dec 2000 11:55:18 -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 LAA23629 for ; Mon, 4 Dec 2000 11:55:17 -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 LAA16421; Mon, 4 Dec 2000 11:54:17 -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 LAA22188; Mon, 4 Dec 2000 11:54:16 -0800 (PST) Message-Id: <200012041954.LAA22188@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: "Mike Luby" cc: mankin@east.isi.edu, roger.kermode@motorola.com, sob@harvard.edu, rmt@lbl.gov, "Mark Handley" Subject: Re: Some proposals for RMT Draft Agenda In-Reply-To: Your message of "Mon, 04 Dec 2000 11:38:46 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Dec 2000 11:54:16 -0800 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk > I would be willing to give the general talk, as long as Luigi, Mark and > Lorenzo will work with me a bit before the meeting to structure the talk. > I'll work with them directly on this if they are willing. Given this, here > is my proposed portion of the agenda. I made estimates of the times for > each part (and I have less confidence in my time estimates for the > presentations with a time interval. Mark, Luigi, Lorenzo, please chip in > with your estimates.) Mike, your time estimates seem reasonable to me. Lorenzo > > Presentation I: General overview (Luby, 20 minutes) > (1) Rationale for transition from ALC to LCT > (2) Rationale for FEC partitioned into standard track and information track > (and why this may be the right approach for all building blocks eventually). > (3) Rationale for transition from MRCC to LCC > (4) How all the pieces fit together > > Presentation II: LCT00 changes from ALC01 (Rizzo, 15-20 minutes) > > Presentation III: FECBB02 and FECInfo00 changes from FECBB01 (Vicisano, > 10-15 minutes) > > Presentation IV: LCC00 changes from MRCC00 (Luby, 5 minutes) > > Mike > > > -----Original Message----- > From: Allison Mankin [mailto:mankin@isi.edu] > Sent: Monday, December 04, 2000 10:59 AM > To: Mike Luby > Cc: mankin@east.isi.edu; lorenzo@cisco.com; roger.kermode@motorola.com; > sob@harvard.edu; rmt@lbl.gov > Subject: Re: RMT Draft Agenda > > > Mike, > > I have dropped agenda@ietf.org from the cc list. We can revise > the draft agenda later after we nail down all the details. > > I jumped in and sent a slightly cleaned-up of Roger's tentative > agenda to the Secretariat, because of my AD instincts, wanting > RMT very much not to miss today's deadline. > > In the likely absence of Mark, it sounds to me like you would be > a good person to speak to the reorg/rename. Please let > us know too how long the several talks you suggest should > be. > > Other comments/corrections on the draft agenda are welcome. > > Allison >From owner-rmt@listserv.lbl.gov Sat Dec 9 10:11:38 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id KAA05026; Sat, 9 Dec 2000 10:08:42 -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 KAA05022 for ; Sat, 9 Dec 2000 10:08:39 -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 KAA11395 for ; Sat, 9 Dec 2000 10:08:38 -0800 (PST) Received: from nt1.rocori.k12.mn.us (nt1.rocori.k12.mn.us [207.229.251.2]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA11392; Sat, 9 Dec 2000 10:08:37 -0800 (PST) Message-Id: <200012091808.KAA11392@SpamWall.lbl.gov> From: Mail Sender To: rms46@geocities.com CC: rms46@oke.com, rmt@lbl.gov, rmt-request@lbl.gov, rmwj@kc.net, rmyers@dgexchange.dg.com Subject: Russian Goods and Service from Moscow Reply-To: mailsender@mailsender.ru Date: 09.12.2000 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-rmt@lbl.gov Precedence: bulk www.rusgoods.com www.rusgoods.ru ================================================================ We present you the production of the 1-st Moscow Watch Factory "Poljot" (Flying). From the simple mechanical watch of the series 2609 till unique, composite and precise mechanical o'clock - Marine timer . It is unique factory in Russia, which makes mechanical hours with the Swiss quality. Factory, which makes watches for the Russian Air Forces , Russian Naval Forces. All mechanical watch which we offer to you, will be delivered to you directly from the factory. If it isn't in the warehouse of the factory, we will place your order directly at the 1-st Moscow Watch Factory without any middlemans. The submarine "Kursk" had on board mechanical marine hronometr 6MX. =============================================================== The "table" of orders. Here you can to order, to find, to know almost everything, than the Russia is rich, everything that does not contradict Russian Federation laws. Here you can receive or order: The information about any enterprise, firm, organization, or person in Russia The production or any goods of Russian manufactories, and other things if it is possible. =============================================================== www.rusgoods.com www.rusgoods.ru >From owner-rmt@listserv.lbl.gov Sun Dec 10 22:12:14 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id WAA08010; Sun, 10 Dec 2000 22:10:08 -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 WAA08006 for ; Sun, 10 Dec 2000 22:10: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 WAA26397 for ; Sun, 10 Dec 2000 22:10:02 -0800 (PST) Received: from raq3.ndmc.net ([63.140.75.133]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA26394; Sun, 10 Dec 2000 22:10:01 -0800 (PST) Received: (from mail@localhost) by raq3.ndmc.net (8.9.3/8.9.3) id RAA07187 for suscribe2_site123-list; Sun, 10 Dec 2000 17:48:47 -0500 X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f Received: from mail.mailstart.com (mail.mailstart.com [207.231.76.67]) by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id RAA07173; Sun, 10 Dec 2000 17:47:14 -0500 Received: from maroon [207.231.76.76] by mail.mailstart.com (SMTPD32-5.05) id A785DAB500EE; Sun, 10 Dec 2000 14:45:25 -0800 To: suscribe@allairporttransport.com CC: suscribe2@allairporttransport.com, advert@allairporttransport.com From: advert@allairporttransport.com Subject: Get listed on Allairporttransport.com Message-Id: <101200345.53126@63.194.85.87> Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Sun, 10 Dec 2000 14:45:27 -0800 Sender: owner-rmt@lbl.gov Precedence: bulk Get listed on Allairporttransport.com http://www.allairporttransport.com ----- Sent using MailStart.com ( http://MailStart.Com/welcome.html ) The FREE way to access your mailbox via any web browser, anywhere! >From owner-rmt@listserv.lbl.gov Mon Dec 11 00:47:37 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id AAA08198; Mon, 11 Dec 2000 00:47:12 -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 AAA08194 for ; Mon, 11 Dec 2000 00:47:10 -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 AAA05427 for ; Mon, 11 Dec 2000 00:47:09 -0800 (PST) Received: from raq3.ndmc.net ([63.140.75.133]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA05421; Mon, 11 Dec 2000 00:47:07 -0800 (PST) Received: (from mail@localhost) by raq3.ndmc.net (8.9.3/8.9.3) id WAA21017 for suscribe2_site123-list; Sun, 10 Dec 2000 22:05:45 -0500 X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f Received: from smartwall.v-one.com (firewall-user@smartwall.v-one.com [206.151.78.11]) by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id WAA21012; Sun, 10 Dec 2000 22:04:35 -0500 Received: by smartwall.v-one.com; id WAA08691; Sun, 10 Dec 2000 22:36:27 -0500 (EST) Received: from mail.v-one.com(198.69.135.122) by smartwall.v-one.com via smap (V4.2) id xma008689; Sun, 10 Dec 00 22:36:26 -0500 Received: from v-one.com (firewall-user@smartwall.v-one.com [198.69.135.11]) by mail.v-one.com (8.9.3/8.8.7) with ESMTP id WAA24572; Sun, 10 Dec 2000 22:01:22 -0500 Message-ID: <3A34448B.B4A8F4D0@v-one.com> Date: Sun, 10 Dec 2000 22:05:48 -0500 From: Keith Young Organization: V-ONE X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 CC: advert@allairporttransport.com, suscribe2@allairporttransport.com Subject: Re: allairporttransport References: <101200345.53126@63.194.85.87> <006901c0630f$414257a0$e2ed68d5@laptop> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk What I want to know is who is the complete moron who had the reply to address of a SPAM letter going to a Majordomo mailing list? Damn, I guess only SPAMmers are *this* dumb. By the way, if anyone wants to complain, info is below. Make sure to contact the ISP (register.com). Also, for the sake of stopping this mailing list, lets end the reply e-mails to the listserver e-mail address now: Organization: American Airport Connection Christopher Fagbolu 19990 Skywest Dr. Ste. 1121 Hayward, CA 94541 US Phone: 510-732-6482 Fax..: 510-732-6947 Email: cofagb@airportconnection.net Registrar Name....: Register.com Registrar Whois...: whois.register.com Registrar Homepage: http://www.register.com > > Get listed on Allairporttransport.com > > > > http://www.allairporttransport.com > > > > ----- > > Sent using MailStart.com ( http://MailStart.Com/welcome.html ) > > The FREE way to access your mailbox via any web browser, anywhere! By the way, this e-mail is by no means V-ONE official business and my personal thoughts are not endorsed by my employer. >From owner-rmt@listserv.lbl.gov Mon Dec 11 01:04:21 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id BAA08226; Mon, 11 Dec 2000 01:04:16 -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 BAA08222 for ; Mon, 11 Dec 2000 01:04:14 -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 BAA06321 for ; Mon, 11 Dec 2000 01:04:13 -0800 (PST) Received: from raq3.ndmc.net ([63.140.75.133]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA06318; Mon, 11 Dec 2000 01:04:12 -0800 (PST) Received: (from mail@localhost) by raq3.ndmc.net (8.9.3/8.9.3) id VAA20025 for suscribe2_site123-list; Sun, 10 Dec 2000 21:48:29 -0500 X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f Received: from teapot27.domain5.bigpond.com (teapot27.domain5.bigpond.com [139.134.5.174]) by raq3.ndmc.net (8.9.3/8.9.3) with SMTP id VAA20017 for ; Sun, 10 Dec 2000 21:47:17 -0500 Received: from localhost (localhost [127.0.0.1]) by teapot27.domain5.bigpond.com (NTMail 3.02.13) with ESMTP id ja418791 for ; Mon, 11 Dec 2000 12:44:50 +1000 Received: from DC-72-188.bpb.bigpond.com ([203.40.72.188]) by mail5.bigpond.com (Claudes-Volcanic-MailRouter V2.9c 9/310865); 11 Dec 2000 12:44:49 Message-ID: <002701c062b8$69974640$bc4828cb@tim> Reply-To: " Tim Kleinig - Thrifty Car Rental" From: " Tim Kleinig - Thrifty Car Rental" To: "Lefkas2000" , Cc: References: <101200345.53126@63.194.85.87> <006901c0630f$414257a0$e2ed68d5@laptop> Subject: Re: UNSUBSCRIBE ME FROM YOUR MAILING LIST Date: Mon, 11 Dec 2000 00:49:33 +1000 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 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-rmt@lbl.gov Precedence: bulk >From owner-rmt@listserv.lbl.gov Mon Dec 11 01:48:52 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id BAA08272; Mon, 11 Dec 2000 01:48:27 -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 BAA08268 for ; Mon, 11 Dec 2000 01:48:25 -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 BAA08926 for ; Mon, 11 Dec 2000 01:48:25 -0800 (PST) Received: from raq3.ndmc.net ([63.140.75.133]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA08923; Mon, 11 Dec 2000 01:48:24 -0800 (PST) Received: (from mail@localhost) by raq3.ndmc.net (8.9.3/8.9.3) id WAA21396 for suscribe2_site123-list; Sun, 10 Dec 2000 22:12:19 -0500 X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f Received: from chico.rediris.es (chico.rediris.es [130.206.1.3]) by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id WAA21392 for ; Sun, 10 Dec 2000 22:11:09 -0500 Message-Id: <200012110311.WAA21392@raq3.ndmc.net> Received: from chico.rediris.es (130.206.1.3) by chico.rediris.es (LSMTP for Solaris v1.1b) with SMTP id <4.000A568F@chico.rediris.es>; Mon, 11 Dec 2000 4:09:21 +0100 Date: Mon, 11 Dec 2000 04:09:21 +0100 From: "L-Soft list server at LISTSERV.REDIRIS.ES (1.8d)" Subject: Message ("Your message dated Sun, 10 Dec 2000 17:48:47...") To: suscribe2@allairporttransport.com Sender: owner-rmt@lbl.gov Precedence: bulk Your message dated Sun, 10 Dec 2000 17:48:47 -0500 with subject "Get listed on Allairporttransport.com" has been submitted to the moderator of the MBONE-ES list: Pedro Ruiz . >From owner-rmt@listserv.lbl.gov Mon Dec 11 03:04:29 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA08364; Mon, 11 Dec 2000 03:04:03 -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 DAA08360 for ; Mon, 11 Dec 2000 03:03: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 DAA14064 for ; Mon, 11 Dec 2000 03:03:57 -0800 (PST) Received: from raq3.ndmc.net ([63.140.75.133]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA14054; Mon, 11 Dec 2000 03:03:48 -0800 (PST) Received: (from mail@localhost) by raq3.ndmc.net (8.9.3/8.9.3) id XAA26919 for suscribe2_site123-list; Sun, 10 Dec 2000 23:45:38 -0500 X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f Received: from webzilla.weblife.net ([63.99.222.120]) by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id XAA26915 for ; Sun, 10 Dec 2000 23:44:53 -0500 Received: from [24.17.130.126] by webzilla.weblife.net (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-48626U1000L100S0) with SMTP id AAA2557 for ; Sun, 10 Dec 2000 22:47:46 -0600 Date: 10 Dec 2000 22:43:08 -0600 Message-ID: <-1235634310mellard@weblifepro.com> From: James Mellard Subject: Re: UNSUBSCRIBE ME FROM YOUR MAILING LIST To: X-Mailer: QuickMail Pro 2.0.4 (Mac) X-Priority: 3 MIME-Version: 1.0 Reply-To: James Mellard Content-Type: text/plain; charset="US-Ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by SpamWall.lbl.gov id DAA08361 Sender: owner-rmt@lbl.gov Precedence: bulk On Sunday, December 10, 2000, Lefkas2000 wrote: > > >www.lefkas2000.com >THE Guide to Lefkas >----- Original Message ----- >From: >To: >Cc: ; >Sent: Sunday, December 10, 2000 10:45 PM >Subject: Get listed on Allairporttransport.com > > >> >> >> Get listed on Allairporttransport.com >> >> http://www.allairporttransport.com >> >> ----- >> Sent using MailStart.com ( http://MailStart.Com/welcome.html ) >> The FREE way to access your mailbox via any web browser, >anywhere! >> >> > >From owner-rmt@listserv.lbl.gov Mon Dec 11 03:38:39 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA08392; Mon, 11 Dec 2000 03:38:18 -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 DAA08388 for ; Mon, 11 Dec 2000 03:38:16 -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 DAA15356 for ; Mon, 11 Dec 2000 03:38:15 -0800 (PST) Received: from raq3.ndmc.net ([63.140.75.133]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA15353; Mon, 11 Dec 2000 03:38:14 -0800 (PST) Received: (from mail@localhost) by raq3.ndmc.net (8.9.3/8.9.3) id AAA28368 for suscribe2_site123-list; Mon, 11 Dec 2000 00:10:01 -0500 X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id AAA28363 for ; Mon, 11 Dec 2000 00:08:50 -0500 From: www-lib-request@w3.org Received: by www19.w3.org (8.9.0/8.9.0) id AAA12045; Mon, 11 Dec 2000 00:06:48 -0500 (EST) Date: Mon, 11 Dec 2000 00:06:48 -0500 (EST) Message-Id: <200012110506.AAA12045@www19.w3.org> To: suscribe2@allairporttransport.com Subject: Re: Message ("Your message dated Sun, 10 Dec 2000 17:48:47...") References: <200012110311.WAA21392@raq3.ndmc.net> In-Reply-To: <200012110311.WAA21392@raq3.ndmc.net> X-Loop: www-lib@w3.org Sender: owner-rmt@lbl.gov Precedence: bulk ******* www-lib@w3.org ******* This is the public mailing list for discussion about the W3C reference library of common code (a.k.a. libwww). This is the proper location for discussing bug reports, patches, enhancements, and public contributions to libwww. ******* About the W3C Mailing Lists ******* There are many mailing lists provided by the W3C for discussion and development on the World Wide Web. A full list of them is available at: http://www.w3.org/Mail/Lists.html NOTE that this list is not the place for any of the following: How do I configure [insert-favorite-software-here]? I'm new to the web -- what is it? I tried to ask [insert-company-here] customer support, but [I didn't get any response / they told me to RTFM] What does RTFM mean? Answers to the above are often found in the WWW FAQ maintained by Thomas Boutell. The FAQ is available from several sites. Use the mirror closest to you: Sunsite, eastern United States (North America): http://sunsite.unc.edu/boutell/faq/ Internex Online, Montreal, eastern Canada (North America): http://www.io.org/faq/www/index.html New Software Technologies Service, Austria (Europe): http://nswt.tuwien.ac.at:8000/htdocs/boutell/ Glocom, Japan (Asia): http://www1.glocom.ac.jp/mirror/www.boutell.com/faq/index.htm The FAQ also lists the names of all the USENET newsgroups that are available regarding the WWW (most under the comp.infosystems.www.* hierarchy). ******* Administrative Requests ******* The -request mail address should be used for all list administrative requests. It accepts the following commands (in the Subject of an e-mail message): subscribe -- Subscribe to the list. If you want to subscribe under a different address, use a Reply-To: address header in the message. unsubscribe -- Unsubscribe from the list. help -- Get information about the mailing list. archive help -- Get information about the list archive(s). In the event of an address change, it would probably be wisest to first send an unsubscribe for the old address (this can be done from the new address), and then a new subscribe from the new address (the order is important). Most (un)subscription requests are processed automatically without human intervention. Do not send multiple (un)subscription or info requests in one mail. Only one will be processed per mail. NOTE: The -request server usually does quite a good job in discriminating between (un)subscribe requests and messages intended for the maintainer. If you'd like to make sure a human reads your message, make it look like a reply (i.e. the first word in the Subject: field should be "Re:", without the quotes of course); the -request server does not react to replies. ******* Archive Server ******* Every submission sent to this list is archived. Archives of public lists are available at URL: http://lists.w3.org/Archives/Public/ If you want to access this archive by e-mail, you have to send mail to the -request address with the word "archive" as the first word of your Subject:. To get you started, try sending a mail to the -request address with the following: Subject: archive help Rev. 18/Jul/97 -JK ================================================================= >From owner-rmt@listserv.lbl.gov Mon Dec 11 04:59:18 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id EAA08446; Mon, 11 Dec 2000 04:58:23 -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 EAA08442 for ; Mon, 11 Dec 2000 04:58:21 -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 EAA20295 for ; Mon, 11 Dec 2000 04:58:21 -0800 (PST) Received: from raq3.ndmc.net ([63.140.75.133]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA20292; Mon, 11 Dec 2000 04:58:19 -0800 (PST) Received: (from mail@localhost) by raq3.ndmc.net (8.9.3/8.9.3) id BAA32270 for suscribe2_site123-list; Mon, 11 Dec 2000 01:15:37 -0500 X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f Received: from chico.rediris.es (chico.rediris.es [130.206.1.3]) by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id BAA32263 for ; Mon, 11 Dec 2000 01:14:42 -0500 Message-Id: <200012110614.BAA32263@raq3.ndmc.net> Received: from chico.rediris.es (130.206.1.3) by chico.rediris.es (LSMTP for Solaris v1.1b) with SMTP id <1.000A56C1@chico.rediris.es>; Mon, 11 Dec 2000 7:12:56 +0100 Date: Mon, 11 Dec 2000 07:12:56 +0100 From: "L-Soft list server at LISTSERV.REDIRIS.ES (1.8d)" Subject: Message ("Your message dated Sun, 10 Dec 2000 22:05:45...") To: suscribe2@allairporttransport.com Sender: owner-rmt@lbl.gov Precedence: bulk Your message dated Sun, 10 Dec 2000 22:05:45 -0500 with subject "Re: allairporttransport" has been submitted to the moderator of the MBONE-ES list: Pedro Ruiz . >From owner-rmt@listserv.lbl.gov Mon Dec 11 09:08:16 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id JAA10012; Mon, 11 Dec 2000 09:07:41 -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 JAA10008 for ; Mon, 11 Dec 2000 09:07:39 -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 JAA03982 for ; Mon, 11 Dec 2000 09:07:38 -0800 (PST) Received: from raq3.ndmc.net ([63.140.75.133]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA03948; Mon, 11 Dec 2000 09:07:30 -0800 (PST) Received: (from mail@localhost) by raq3.ndmc.net (8.9.3/8.9.3) id FAA15770 for suscribe2_site123-list; Mon, 11 Dec 2000 05:47:16 -0500 X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f Received: from fep13-svc.tin.it (mta13-acc.tin.it [212.216.176.44]) by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id FAA15694; Mon, 11 Dec 2000 05:44:54 -0500 Received: from exodus ([212.216.163.234]) by fep13-svc.tin.it (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20001211104238.NTY1148.fep13-svc.tin.it@exodus>; Mon, 11 Dec 2000 11:42:38 +0100 Message-ID: <00c501c0635f$1046eb20$1556fea9@exodus> From: "Roman Homes - Dr. Mauro Abate" To: , Cc: , References: <101200345.53126@63.194.85.87> <00a201c06358$7c3083c0$1556fea9@exodus> Subject: Re: REMOVE ME FROM YOUR MAILING LIST Re: Get listed on Allairporttransport.com Date: Mon, 11 Dec 2000 11:42:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-rmt@lbl.gov Precedence: bulk Please reply with the "reply to" button, or by copying/pasting if you are an AOL user, necessary for us to keep track of the dialogue between us, without being lost to find it among 1000s messages. Thank you. _______________ Dear Sir / Madam Thank you for your consideration and welcome to Roman Homes. Kind regards, Dr. Mauro Abate, Roman Homes® http://www.romanhomes.com http://www.romanholidays.com Your carefree Roman rental When in Rome, stay in homes as the Romans do!® ----- Original Message ----- From: Roman Homes - Dr. Mauro Abate To: ; Cc: ; Sent: Monday, December 11, 2000 6:54 AM Subject: REMOVE ME FROM YOUR MAILING LIST Re: Get listed on Allairporttransport.com Please reply with the "reply to" button, or by copying/pasting if you are an AOL user, necessary for us to keep track of the dialogue between us, without being lost to find it among 1000s messages. Thank you. _______________ Dear Sir / Madam, PLEASE REMOVE ME FROM YOUR MAILING LIST. I AM HAVING STRANGE MESSAGES FROM YOUR OR YOUR CUSTOMERS. MAKE SURE THEY DON'T ARRIVE ANYMORE. Thank you. Regards, Dr. Mauro Abate, Roman Homes® http://www.romanhomes.com http://www.romanholidays.com Your carefree Roman rental When in Rome, stay in homes as the Romans do!® ----- Original Message ----- From: To: Cc: ; Sent: Sunday, December 10, 2000 11:45 PM Subject: Get listed on Allairporttransport.com > > > Get listed on Allairporttransport.com > > http://www.allairporttransport.com > > ----- > Sent using MailStart.com ( http://MailStart.Com/welcome.html ) > The FREE way to access your mailbox via any web browser, anywhere! > > >From owner-rmt@listserv.lbl.gov Mon Dec 11 09:13:09 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id JAA10077; Mon, 11 Dec 2000 09:12:59 -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 JAA10073 for ; Mon, 11 Dec 2000 09:12: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 JAA05816 for ; Mon, 11 Dec 2000 09:12:56 -0800 (PST) Received: from raq3.ndmc.net ([63.140.75.133]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA05806; Mon, 11 Dec 2000 09:12:54 -0800 (PST) Received: (from mail@localhost) by raq3.ndmc.net (8.9.3/8.9.3) id EAA13191 for suscribe2_site123-list; Mon, 11 Dec 2000 04:59:55 -0500 X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f Received: from fep13-svc.tin.it (mta13-acc.tin.it [212.216.176.44]) by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id EAA13107; Mon, 11 Dec 2000 04:57:30 -0500 Received: from exodus ([212.216.163.234]) by fep13-svc.tin.it (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20001211095541.HVM1148.fep13-svc.tin.it@exodus>; Mon, 11 Dec 2000 10:55:41 +0100 Message-ID: <00a501c06358$8176eae0$1556fea9@exodus> From: "Roman Homes - Dr. Mauro Abate" To: , Cc: , References: <101200345.53126@63.194.85.87> Subject: REMOVE ME FROM YOUR MAILING LIST Re: Get listed on Allairporttransport.com Date: Mon, 11 Dec 2000 06:54:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-rmt@lbl.gov Precedence: bulk Please reply with the "reply to" button, or by copying/pasting if you are an AOL user, necessary for us to keep track of the dialogue between us, without being lost to find it among 1000s messages. Thank you. _______________ Dear Sir / Madam, PLEASE REMOVE ME FROM YOUR MAILING LIST. I AM HAVING STRANGE MESSAGES FROM YOUR OR YOUR CUSTOMERS. MAKE SURE THEY DON'T ARRIVE ANYMORE. Thank you. Regards, Dr. Mauro Abate, Roman Homes® http://www.romanhomes.com http://www.romanholidays.com Your carefree Roman rental When in Rome, stay in homes as the Romans do!® ----- Original Message ----- From: To: Cc: ; Sent: Sunday, December 10, 2000 11:45 PM Subject: Get listed on Allairporttransport.com > > > Get listed on Allairporttransport.com > > http://www.allairporttransport.com > > ----- > Sent using MailStart.com ( http://MailStart.Com/welcome.html ) > The FREE way to access your mailbox via any web browser, anywhere! > > >From owner-rmt@listserv.lbl.gov Mon Dec 11 09:38:11 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id JAA10101; Mon, 11 Dec 2000 09:37:51 -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 JAA10097 for ; Mon, 11 Dec 2000 09:37:49 -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 JAA16272 for ; Mon, 11 Dec 2000 09:37:49 -0800 (PST) Received: from raq3.ndmc.net ([63.140.75.133]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA16269; Mon, 11 Dec 2000 09:37:48 -0800 (PST) Received: (from mail@localhost) by raq3.ndmc.net (8.9.3/8.9.3) id EAA13198 for suscribe2_site123-list; Mon, 11 Dec 2000 04:59:57 -0500 X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f Received: from fep13-svc.tin.it (mta13-acc.tin.it [212.216.176.44]) by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id EAA13134; Mon, 11 Dec 2000 04:57:49 -0500 Received: from exodus ([212.216.163.234]) by fep13-svc.tin.it (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20001211095533.HUX1148.fep13-svc.tin.it@exodus>; Mon, 11 Dec 2000 10:55:33 +0100 Message-ID: <00a201c06358$7c3083c0$1556fea9@exodus> From: "Roman Homes - Dr. Mauro Abate" To: , Cc: , References: <101200345.53126@63.194.85.87> Subject: REMOVE ME FROM YOUR MAILING LIST Re: Get listed on Allairporttransport.com Date: Mon, 11 Dec 2000 06:54:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-rmt@lbl.gov Precedence: bulk Please reply with the "reply to" button, or by copying/pasting if you are an AOL user, necessary for us to keep track of the dialogue between us, without being lost to find it among 1000s messages. Thank you. _______________ Dear Sir / Madam, PLEASE REMOVE ME FROM YOUR MAILING LIST. I AM HAVING STRANGE MESSAGES FROM YOUR OR YOUR CUSTOMERS. MAKE SURE THEY DON'T ARRIVE ANYMORE. Thank you. Regards, Dr. Mauro Abate, Roman Homes® http://www.romanhomes.com http://www.romanholidays.com Your carefree Roman rental When in Rome, stay in homes as the Romans do!® ----- Original Message ----- From: To: Cc: ; Sent: Sunday, December 10, 2000 11:45 PM Subject: Get listed on Allairporttransport.com > > > Get listed on Allairporttransport.com > > http://www.allairporttransport.com > > ----- > Sent using MailStart.com ( http://MailStart.Com/welcome.html ) > The FREE way to access your mailbox via any web browser, anywhere! > > >From owner-rmt@listserv.lbl.gov Mon Dec 11 09:59:32 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id JAA10180; Mon, 11 Dec 2000 09:59: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 JAA10176 for ; Mon, 11 Dec 2000 09:59: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 JAA26396 for ; Mon, 11 Dec 2000 09:59:03 -0800 (PST) Received: from raq3.ndmc.net ([63.140.75.133]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA26388; Mon, 11 Dec 2000 09:59:02 -0800 (PST) Received: (from mail@localhost) by raq3.ndmc.net (8.9.3/8.9.3) id GAA18042 for suscribe2_site123-list; Mon, 11 Dec 2000 06:28:25 -0500 X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f Received: from cmailg3.svr.pol.co.uk (cmailg3.svr.pol.co.uk [195.92.195.173]) by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id GAA17985; Mon, 11 Dec 2000 06:26:16 -0500 Received: from modem-76.beryllium.dialup.pol.co.uk ([62.136.3.76] helo=alan) by cmailg3.svr.pol.co.uk with smtp (Exim 3.13 #0) id 145R4H-0002kV-00; Mon, 11 Dec 2000 11:24:30 +0000 Message-ID: <002501c06364$fd5724c0$4c03883e@alan> From: "Russian Gateway (UK) Limited" To: , , Subject: REMOVE FROM LIST Date: Mon, 11 Dec 2000 11:24:53 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C06364.FB8A5400" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C06364.FB8A5400 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Remove from mailing list immediately ------=_NextPart_000_0022_01C06364.FB8A5400 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Remove from mailing list=20 immediately
------=_NextPart_000_0022_01C06364.FB8A5400-- >From owner-rmt@listserv.lbl.gov Mon Dec 11 09:59:35 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id JAA10186; Mon, 11 Dec 2000 09:59:27 -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 JAA10182 for ; Mon, 11 Dec 2000 09:59:25 -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 JAA26486 for ; Mon, 11 Dec 2000 09:59:20 -0800 (PST) Received: from raq3.ndmc.net ([63.140.75.133]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA26482; Mon, 11 Dec 2000 09:59:19 -0800 (PST) Received: (from mail@localhost) by raq3.ndmc.net (8.9.3/8.9.3) id GAA19583 for suscribe2_site123-list; Mon, 11 Dec 2000 06:56:06 -0500 X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f Received: from mail1.band-x.net (mail1.band-x.net [213.166.0.230]) by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id GAA19579 for ; Mon, 11 Dec 2000 06:54:54 -0500 Received: from chesterton.co.uk (fwuser@[213.166.16.2]) by mail1.band-x.net (8.9.3/8.9.3) with SMTP id LAA05295 for ; Mon, 11 Dec 2000 11:53:09 GMT Received: from London-Message_Server by chesterton.co.uk with Novell_GroupWise; Mon, 11 Dec 2000 11:52:42 +0000 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Mon, 11 Dec 2000 11:52:11 +0000 From: "Andrew Hartwright" To: , Subject: Re: Message ("Your message dated Sun, 10 Dec 2000 17:48:47...") 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 JAA10183 Sender: owner-rmt@lbl.gov Precedence: bulk I do not know what this about DO NOT include me in future emails >>> "L-Soft list server at LISTSERV.REDIRIS.ES (1.8d)" 12/11/00 03:12am >>> Your message dated Sun, 10 Dec 2000 17:48:47 -0500 with subject "Get listed on Allairporttransport.com" has been submitted to the moderator of the MBONE-ES list: Pedro Ruiz . _____________________________________________________________________ This message has been checked for all known viruses by the MessageLabs Virus Control Centre. For further information visit http://www.messagelabs.com/stats.asp >From owner-rmt@listserv.lbl.gov Mon Dec 11 12:45:20 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id MAA10901; Mon, 11 Dec 2000 12:44:06 -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 MAA10897 for ; Mon, 11 Dec 2000 12:44:05 -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 MAA01867 for ; Mon, 11 Dec 2000 12:44:04 -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 MAA01864 for ; Mon, 11 Dec 2000 12:44:03 -0800 (PST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id NAA06632 for ; Mon, 11 Dec 2000 13:44:03 -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 NAA25850 for ; Mon, 11 Dec 2000 13:44:01 -0700 (MST)] Received: from motorola.com ([217.2.31.177]) by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id eBBKgRS28241 for ; Tue, 12 Dec 2000 07:42:28 +1100 (EST) Message-ID: <3A353B81.DD1F651C@motorola.com> Date: Tue, 12 Dec 2000 07:39:29 +1100 From: Roger Kermode Organization: Motorola Australia Research Centre X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: 49th IETF San Diego RMT Agenda Content-Type: multipart/mixed; boundary="------------4EC31ADEE849A429FEBE71F0" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------4EC31ADEE849A429FEBE71F0 Content-Type: multipart/alternative; boundary="------------8384C1389277A83E861463E7" --------------8384C1389277A83E861463E7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here it *finally* is.... Roger RMT Agenda 49th IETF, San Diego ==================== Monday 19:30 - 22:00 Agenda Bashing [Roger] 19:30 - 09:40 10 mins Advertisement of MSEC BOF [Roger] 19:40 - 19:42 3 mins Apology regarding discussion of TFRC in TSVWG [Roger] 19:42 - 19:45 2 mins Updates [Kermode] 19:45 - 19:50 5 mins NORM reorganisation [Brain/Joe] 19:50 - 20:20 30 mins Security Considerations for NORM [Thomas] 20:20 - 20:30 10 mins Layered Coding Transport (was ALC) drafts [Lorenzo/Mike/Luigi] 20:30 - 21:20 50 mins Overview of structural reorganization , , TRACK [Whetten/Chiu] 21:20 - 22:00 40 mins , Tuesday 13:00 - 14:00 ===================== Building Blocks Registry Discussion [Roger] 13:00 - 13:10 10 mins TFRC discussion [Sally Floyd/Jitendra Padhye] 13:10 - 13:30 20 mins GRA/PGM Cattle Prod [Roger/Tony] 13:30 - 13:35 5 mins Newly issued PGM draft - plan? Individual drafts (not in charter) [Michael Garwood] 13:50 - 14:00 10 mins [Ken Calvert] 13:35 - 13:50 15 mins --------------8384C1389277A83E861463E7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Here it *finally* is....

Roger
 

RMT Agenda
49th IETF, San Diego
====================

Monday 19:30 - 22:00
  Agenda Bashing [Roger]                    19:30 - 09:40   10 mins
  Advertisement of MSEC BOF [Roger]         19:40 - 19:42    3 mins
  Apology regarding discussion of TFRC in TSVWG
                                 [Roger]    19:42 - 19:45    2 mins

Updates [Kermode]                           19:45 - 19:50    5 mins
  <draft-ietf-rmt-buildingblocks-03.txt>
  <draft-ietf-rmt-author-guidelines-00.txt>

NORM reorganisation [Brain/Joe]
  <draft-ietf-rmt-pi-norm-00.txt>           19:50 - 20:20   30 mins
  Security Considerations for NORM [Thomas] 20:20 - 20:30   10 mins

Layered Coding Transport (was ALC) drafts
  [Lorenzo/Mike/Luigi]                      20:30 - 21:20   50 mins
  Overview of structural reorganization
  <draft-ietf-rmt-bb-lct-00.txt>, <draft-ietf-rmt-info-fec-02.txt>
  <draft-ietf-rmt-bb-fec-02.txt>, <draft-ietf-rmt-bb-lcc-00.txt>

TRACK [Whetten/Chiu]                        21:20 - 22:00   40 mins
  <draft-ietf-rmt-bb-track-00.txt>,
  <draft-ietf-rmt-bb-tree-config-01.txt>
 

Tuesday 13:00 - 14:00
=====================
Building Blocks Registry Discussion [Roger]        13:00 - 13:10  10 mins

TFRC discussion [Sally Floyd/Jitendra Padhye]      13:10 - 13:30  20 mins

GRA/PGM Cattle Prod [Roger/Tony]                   13:30 - 13:35   5 mins
  Newly issued PGM draft - plan?

Individual drafts (not in charter)
  <draft-petrova-pgmmib-00.txt> [Michael Garwood]  13:50 - 14:00  10 mins
  <draft-calvert-concast-svc-00.txt> [Ken Calvert] 13:35 - 13:50  15 mins --------------8384C1389277A83E861463E7-- --------------4EC31ADEE849A429FEBE71F0 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 org:Motorola Labs, Motorola Australian Research Centre;Communications and Networks Laboratory version:2.1 email;internet:Roger.Kermode@motorola.com title:Principal Research Engineer, Manager adr;quoted-printable:;;Locked Bag 5028, Botany NSW, 1455=0D=0A=0D=0ALevel 3, 12 Lord St;Botany;NSW;;Australia fn:Roger Kermode end:vcard --------------4EC31ADEE849A429FEBE71F0-- >From owner-rmt@listserv.lbl.gov Mon Dec 11 18:55:25 2000 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id SAA13821; Mon, 11 Dec 2000 18:54:49 -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 SAA13817 for ; Mon, 11 Dec 2000 18:54:47 -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 SAA01976 for ; Mon, 11 Dec 2000 18:54:47 -0800 (PST) Received: from raq3.ndmc.net ([63.140.75.133]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA01973; Mon, 11 Dec 2000 18:54:36 -0800 (PST) Received: (from mail@localhost) by raq3.ndmc.net (8.9.3/8.9.3) id JAA29924 for suscribe2_site123-list; Mon, 11 Dec 2000 09:52:22 -0500 X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f Received: from sgbd.com (ANeuilly-101-2-1-15.abo.wanadoo.fr [193.251.60.15]) by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id JAA29911 for ; Mon, 11 Dec 2000 09:51:09 -0500 Received: from willy (195.154.186.131) by sgbd.com with SMTP (Eudora Internet Mail Server 3.0.1); Mon, 11 Dec 2000 15:50:28 +0100 From: "willy bouchentouf" To: "James Mellard" , Subject: RE: UNSUBSCRIBE ME FROM YOUR MAILING LIST Date: Mon, 11 Dec 2000 15:48:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 In-Reply-To: <-1235634310mellard@weblifepro.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-rmt@lbl.gov Precedence: bulk ?????? -----Message d'origine----- De : owner-suscribe2@www.allairporttransport.com [mailto:owner-suscribe2@www.allairporttransport.com]De la part de James Mellard Envoye : lundi 11 decembre 2000 05:43 A : suscribe2@www.allairporttransport.com Objet : Re: UNSUBSCRIBE ME FROM YOUR MAILING LIST On Sunday, December 10, 2000, Lefkas2000 wrote: > > >www.lefkas2000.com >THE Guide to Lefkas >----- Original Message ----- >From: >To: >Cc: ; >Sent: Sunday, December 10, 2000 10:45 PM >Subject: Get listed on Allairporttransport.com > > >> >> >> Get listed on Allairporttransport.com >> >> http://www.allairporttransport.com >> >> ----- >> Sent using MailStart.com ( http://MailStart.Com/welcome.html ) >> The FREE way to access your mailbox via any web browser, >anywhere! >> >> > >From owner-rmt@listserv.lbl.gov Mon Jan 29 02:22:42 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id CAA16987; Mon, 29 Jan 2001 02:20:07 -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 CAA16983 for ; Mon, 29 Jan 2001 02:20:06 -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 CAA09405 for ; Mon, 29 Jan 2001 02:20:05 -0800 (PST) Received: from duns-smtp.duns.wireless.comdev.ca ([212.250.47.4]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id CAA09400 for ; Mon, 29 Jan 2001 02:20:02 -0800 (PST) Received: from DOM_DMZ_04-Message_Server by duns-smtp.duns.wireless.comdev.ca with Novell_GroupWise; Mon, 29 Jan 2001 10:25:50 +0000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Mon, 29 Jan 2001 10:19:32 +0000 From: "Craig Fisher" To: Subject: Access to archive Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_5C071E3E.8DEC8116" Sender: owner-rmt@lbl.gov Precedence: bulk This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_5C071E3E.8DEC8116 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi - Does anyone know the correct address (if there is one) for access to = the archives for the rmt list? I've emailed rmt-request@lbl.gov as listed on the webpage (http://www.ietf.= org/html.charters/rmt-charter.html) but I get a 550 User unknown.... Many thanks, -Craig Craig Fisher - Technical Manager M/Ergy - UK & Europe COM DEV Wireless Vox: +44 1582 445061 Fax: +44 1582 445060 Email: Craig.Fisher@wireless.comdev.ca --=_5C071E3E.8DEC8116 Content-Type: text/x-vcard Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Craig Fisher.vcf" QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpYLUdXVFlQRTpVU0VSDQpGTjpDcmFpZyBGaXNoZXIN ClRFTDtXT1JLOis0NCAxNTgyIDQ0NTA2MQ0KT1JHOkNPTSBERVYgV2lyZWxlc3MgR3JvdXA7SVQN ClRFTDtQUkVGO0ZBWDorNDQgMTU4MiA0NDUwNjANCkVNQUlMO1dPUks7UFJFRjpDcmFpZy5GaXNo ZXJAd2lyZWxlc3MuY29tZGV2LmNhDQpOOkZpc2hlcjtDcmFpZw0KVElUTEU6TWFuYWdlcg0KQURS O0lOVEw7V09SSztQQVJDRUw7UE9TVEFMOjs7MTIgSHVtcGhyeXMgUm9hZFxuV29vZHNpZGUgRXN0 YXRlXG47RHVuc3RhYmxlO0JlZGZvcmRzaGlyZTtMVTUgNFpIO1VLDQpMQUJFTDtJTlRMO1dPUks7 UEFSQ0VMO1BPU1RBTDtFTkNPRElORz1RVU9URUQtUFJJTlRBQkxFOkNyYWlnIEZpc2hlcj0wQT0N CjEyIEh1bXBocnlzIFJvYWQ9MEE9DQpXb29kc2lkZSBFc3RhdGU9MEE9DQo9MEE9DQpEdW5zdGFi bGUsIEJlZGZvcmRzaGlyZSAgTFU1IDRaSD0wQT0NClVLDQpMQUJFTDtET007V09SSztQQVJDRUw7 UE9TVEFMO0VOQ09ESU5HPVFVT1RFRC1QUklOVEFCTEU6Q3JhaWcgRmlzaGVyPTBBPQ0KMTIgSHVt cGhyeXMgUm9hZD0wQT0NCldvb2RzaWRlIEVzdGF0ZT0wQT0NCj0wQT0NCkR1bnN0YWJsZSwgQmVk Zm9yZHNoaXJlICBMVTUgNFpIDQpURUw7Q0VMTDorNDQgNzc2OCA1NTI0MTMNClgtR1dVU0VSSUQ6 Q0ZJU0hFUg0KRU5EOlZDQVJEDQoNCg== --=_5C071E3E.8DEC8116-- >From owner-rmt@listserv.lbl.gov Mon Jan 29 02:34:21 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id CAA17071; Mon, 29 Jan 2001 02:34: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 CAA17067 for ; Mon, 29 Jan 2001 02:34:14 -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 CAA11831 for ; Mon, 29 Jan 2001 02:34:13 -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 CAA11828 for ; Mon, 29 Jan 2001 02:34:12 -0800 (PST) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.10.0/8.10.0) id f0TAY7g21799; Mon, 29 Jan 2001 02:34:07 -0800 (PST) Message-Id: <200101291034.f0TAY7g21799@daffy.ee.lbl.gov> To: "Craig Fisher" Cc: Subject: Re: Access to archive In-reply-to: Your message of Mon, 29 Jan 2001 10:19:32 PST. Date: Mon, 29 Jan 2001 02:34:07 PST From: Vern Paxson Sender: owner-rmt@lbl.gov Precedence: bulk > Hi - Does anyone know the correct address (if there is one) for access to = > the archives for the rmt list? Send mail to majordomo@lbl.gov with get rmt archive as the body. > I've emailed rmt-request@lbl.gov as listed on the webpage (http://www.ietf.= > org/html.charters/rmt-charter.html) but > I get a 550 User unknown.... Oops, config-rot, sorry about that. I'll get it updated. Vern >From owner-rmt@listserv.lbl.gov Fri Feb 2 09:18:00 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id JAA01568; Fri, 2 Feb 2001 09:14: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 JAA01564 for ; Fri, 2 Feb 2001 09:14: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 JAA26506 for ; Fri, 2 Feb 2001 09:14:44 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA26496 for ; Fri, 2 Feb 2001 09:14:43 -0800 (PST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA05874; Fri, 2 Feb 2001 09:14:39 -0800 (PST) Message-Id: <200102021714.JAA05874@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3048 on RMT Building Blocks Cc: rfc-ed@ISI.EDU, rmt@lbl.gov Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 02 Feb 2001 09:14:39 -0800 From: RFC Editor Sender: owner-rmt@lbl.gov Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3048 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 Status: Informational Date: January 2001 Mailbox: whetten@talarian.com, lorenzo@cisco.com, Roger.Kermode@motorola.com, mjh@aciri.org, floyd@aciri.org, luby@digitalfountain.com Pages: 20 Characters: 48965 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-rmt-buildingblocks-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3048.txt 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. This document is a product of the Reliable Multicast Transport Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010202091217.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3048 --OtherAccess Content-Type: Message/External-body; name="rfc3048.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010202091217.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Fri Feb 2 14:10:17 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id OAA03355; Fri, 2 Feb 2001 14:08:11 -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 OAA03351 for ; Fri, 2 Feb 2001 14:08:05 -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 OAA17964 for ; Fri, 2 Feb 2001 14:08:05 -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 OAA17960 for ; Fri, 2 Feb 2001 14:08:04 -0800 (PST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id PAA23038 for ; Fri, 2 Feb 2001 15:08:03 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id PAA17006 for ; Fri, 2 Feb 2001 15:08:01 -0700 (MST)] Received: from arc.corp.mot.com ([217.2.31.42]) by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id f12M7kY14123 for ; Sat, 3 Feb 2001 09:07:46 +1100 (EST) Message-ID: <3A7B2FB4.47590A6@arc.corp.mot.com> Date: Sat, 03 Feb 2001 09:07:48 +1100 From: Roger Kermode Organization: Motorola Australia Research Centre X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt@lbl.gov Subject: Re: RFC 3048 on RMT Building Blocks References: <200102021714.JAA05874@boreas.isi.edu> Content-Type: multipart/mixed; boundary="------------ED286C897DF6E11FD3189DDC" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------ED286C897DF6E11FD3189DDC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Everyone, thanks you to all who contributed to this doc. Good work! cheers, Roger RFC Editor wrote: > A new Request for Comments is now available in online RFC libraries. > > RFC 3048 > > 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 > Status: Informational > Date: January 2001 > Mailbox: whetten@talarian.com, lorenzo@cisco.com, > Roger.Kermode@motorola.com, mjh@aciri.org, > floyd@aciri.org, luby@digitalfountain.com > Pages: 20 > Characters: 48965 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-rmt-buildingblocks-03.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3048.txt > > 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. > > This document is a product of the Reliable Multicast Transport Working > Group of the IETF. > > This memo provides information for the Internet community. It does > not specify an Internet standard of any kind. Distribution of this > memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution.echo > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > Below is the data which will enable a MIME compliant Mail Reader > implementation to automatically retrieve the ASCII version > of the RFCs. > > ------------------------------------------------------------------------ > Content-Type: text/plain > Content-ID: <010202091217.RFC@RFC-EDITOR.ORG> --------------ED286C897DF6E11FD3189DDC 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 org:Motorola Labs, Motorola Australian Research Centre;Communications and Networks Laboratory version:2.1 email;internet:Roger.Kermode@motorola.com title:Principal Research Engineer, Manager adr;quoted-printable:;;Locked Bag 5028, Botany NSW, 1455=0D=0A=0D=0ALevel 3, 12 Lord St;Botany;NSW;;Australia fn:Roger Kermode end:vcard --------------ED286C897DF6E11FD3189DDC-- >From owner-rmt@listserv.lbl.gov Sun Feb 4 17:43:50 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id RAA13230; Sun, 4 Feb 2001 17:40:11 -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 RAA13226 for ; Sun, 4 Feb 2001 17:40:09 -0800 (PST) From: b4h443@arabia.com Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA18775 for ; Sun, 4 Feb 2001 17:40:08 -0800 (PST) Received: from email.molcybercafes.com ([202.184.170.42]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA18772 for ; Sun, 4 Feb 2001 17:40:07 -0800 (PST) Received: from mail.mcities.com - 202.184.170.148 by email.molcybercafes.com with Microsoft SMTPSVC(5.5.1774.114.11); Mon, 5 Feb 2001 05:16:13 +0800 Received: from kwantlen.bc.ca [63.46.223.74] by mail.mcities.com (SMTPD32-6.05) id A72D2867014A; Mon, 05 Feb 2001 05:18:37 +0800 Message-ID: <00005d975838$00003d1a$0000095e@mailhost.ggtech.com> To: Subject: Brand New E-Mail pager for FR-EE! Date: Sun, 04 Feb 2001 15:11:07 -0600 X-Priority: 3 X-MSMail-Priority: Normal Reply-To: b4h443@arabia.com Sender: owner-rmt@lbl.gov Precedence: bulk Brand New E-Mail pager for FREE! No long term contract No activation fee No big prepayment of airtime No credit check PAGING AMERICA is going to give you absolutely Free the Brand new Motorola Accessmate E-Mail display pager. This is the top of the line PCS technology pager made today. This side viewable display pager has a retail value of $189.00and comes with its own e-mail address so you can receive your e-mails as well as alpha-numeric and numeric messages instantly where ever you are. Your new e-mail pager has features like 50,000 character memory, message time stamping, automatic garbled message correction, beeps or vibrates, incandescent backlight, saved message folder, a unique never out of range feature that allows your pager to retrieve messages sent earlier when your pager was out of range or turned completely off. You can also receive weather, news and sports .The Motorola e-mail pager is very small and uses only a single double A battery. All we ask before we ship you your Free pager is for you to allow us to provide the airtime for you. There is no long term contract or credit check. Airtime is month to month and can be cancelled at any time. This pager will comes pre-programmed with its own e-mail address as well as a local telephone number to receive numeric pages. This pager comes with a complete 30 day money back guarantee, if after receiving this pager you're not completely happy, send it back and receive a full refund. For immediate delivery call Paging America at toll free at 877-699-8545 Brand New E-Mail pager for FREE! >From owner-rmt@listserv.lbl.gov Mon Feb 5 00:24:40 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id AAA13946; Mon, 5 Feb 2001 00:23: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 AAA13942 for ; Mon, 5 Feb 2001 00:23:58 -0800 (PST) From: b4h443@arabia.com Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA22509 for ; Mon, 5 Feb 2001 00:23:57 -0800 (PST) Received: from puma.uner.edu.ar (gnome@[170.210.25.10]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id AAA22498 for ; Mon, 5 Feb 2001 00:23:49 -0800 (PST) Received: from nova.sylvest.co(really [63.38.115.221]) by puma.uner.edu.ar via sendmail with smtp id for ; Sun, 4 Feb 2001 19:13:44 +0300 (GMT) (Smail-3.2 1996-Jul-4 #2 built 1996-Aug-16) Message-ID: <000011605966$00000f09$00001d6c@nova.sylvest.co> To: Subject: Brand New E-Mail pager for FR-EE! Date: Sun, 04 Feb 2001 15:37:19 -0600 X-Priority: 3 X-MSMail-Priority: Normal Reply-To: b4h443@arabia.com Sender: owner-rmt@lbl.gov Precedence: bulk Brand New E-Mail pager for FREE! No long term contract No activation fee No big prepayment of airtime No credit check PAGING AMERICA is going to give you absolutely Free the Brand new Motorola Accessmate E-Mail display pager. This is the top of the line PCS technology pager made today. This side viewable display pager has a retail value of $189.00and comes with its own e-mail address so you can receive your e-mails as well as alpha-numeric and numeric messages instantly where ever you are. Your new e-mail pager has features like 50,000 character memory, message time stamping, automatic garbled message correction, beeps or vibrates, incandescent backlight, saved message folder, a unique never out of range feature that allows your pager to retrieve messages sent earlier when your pager was out of range or turned completely off. You can also receive weather, news and sports .The Motorola e-mail pager is very small and uses only a single double A battery. All we ask before we ship you your Free pager is for you to allow us to provide the airtime for you. There is no long term contract or credit check. Airtime is month to month and can be cancelled at any time. This pager will comes pre-programmed with its own e-mail address as well as a local telephone number to receive numeric pages. This pager comes with a complete 30 day money back guarantee, if after receiving this pager you're not completely happy, send it back and receive a full refund. For immediate delivery call Paging America at toll free at 877-699-8545 Brand New E-Mail pager for FREE! No long term contract No activation fee No big prepayment of airtime No credit check >From owner-rmt@listserv.lbl.gov Fri Feb 9 06:38:36 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id GAA19592; Fri, 9 Feb 2001 06:35: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 GAA19588 for ; Fri, 9 Feb 2001 06:35: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 GAA23761 for ; Fri, 9 Feb 2001 06:35:36 -0800 (PST) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA23758 for ; Fri, 9 Feb 2001 06:35:35 -0800 (PST) Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10]) by letters.cs.ucsb.edu (8.9.3+Sun/8.9.3) with ESMTP id GAA19189; Fri, 9 Feb 2001 06:35:29 -0800 (PST) Received: by jackson.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4) id GAA28803 for ; Fri, 9 Feb 2001 06:35:27 -0800 (PST) Date: Fri, 9 Feb 2001 06:35:27 -0800 (PST) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <200102091435.GAA28803@jackson.cs.ucsb.edu> To: almeroth@cs.ucsb.edu, katia@cse.ucsc.edu Subject: CFP: Global Internet 2001 (in conjunction with Globecom 2001) Sender: owner-rmt@lbl.gov Precedence: bulk Sixth Global Internet Symposium in conjunction with Globecom 2001 San Antonio, Texas, USA November 25-29, 2001 http://www.cs.ucsb.edu/gi2001/ ------------------------------------------------------------------------ Call For Papers The sixth Global Internet Symposium will be held simultaneously and co-located with Globecom 2001. Therefore, all of the relevant dates, location, travel information are derived from the Globecom 2001 (http://www.globecom2001.com/) conference site. Symposium Topics Global Internet 2000 solicits technical papers on Internet-related topics. The Program Committee encourages papers submitted on experimental systems and emerging technologies. Also encouraged are original submissions describing promising work in progress, original speculations about the future of the Internet, and progressive position papers. Topics of interest include, but are not limited to: * Novel applications and new paradigms (telephony, streaming media, etc.) * Distributed Internet applications (file sharing, games, conferencing, etc.) * Service provisioning, monitoring, and management * Privacy and/or security issues * Charging and billing issues * Handling Internet dynamics/heterogeneity (by applications and/or the network) * Routing (unicast, multicast, anycast, etc.) * Traffic measurement, analysis, modeling, and visualization * Flow management (fairness/sharing, differentiated services, etc.) * The Internet and mobility/mobile devices * Wireless device access and Internet gateways Important Dates Manuscript Submission: March 31, 2001 Acceptance Notification: July 31, 2001 Final Manuscript: September 31, 2000 Submission Instructions Please see the Global Internet Symposium WWW site at: http://www.cs.ucsb.edu/gi2001/ Technical Program Chairs Kevin Almeroth, UC-Santa Barbara (almeroth@cs.ucsb.edu) Katia Obraczka, UC-Santa Cruz (katia@cse.ucsc.edu) Program Committee To be announced. Sponsorship The Global Internet Symposium is sponsored by the IEEE Communications Society InternetTC. >From owner-rmt@listserv.lbl.gov Sat Feb 10 15:45:03 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id PAA24294; Sat, 10 Feb 2001 15:42: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 PAA24290 for ; Sat, 10 Feb 2001 15:42: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 PAA04500 for ; Sat, 10 Feb 2001 15:42:23 -0800 (PST) Received: from arunapc (patty.levels.unisa.edu.au [130.220.36.156]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id PAA04486 for ; Sat, 10 Feb 2001 15:42:11 -0800 (PST) Date: Sat, 10 Feb 2001 15:42:11 -0800 (PST) Message-Id: <200102102342.PAA04486@SpamWall.lbl.gov> From: Hahaha Subject: Snowhite and the Seven Dwarfs - The REAL story! MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--VEM34D6FKPQNOP6BCPYVOTAFO1" Sender: owner-rmt@lbl.gov Precedence: bulk ----VEM34D6FKPQNOP6BCPYVOTAFO1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) Found virus TROJ_HYBRIS.B in file midgets.scr The file e/iscan/virus/virDKD0TlMRT is moved to the configured virus directory. ********************************************************* ----VEM34D6FKPQNOP6BCPYVOTAFO1 Content-Type: text/plain; charset="us-ascii" Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and polite with Snowhite. When they go out work at mornign, they promissed a *huge* surprise. Snowhite was anxious. Suddlently, the door open, and the Seven Dwarfs enter... ----VEM34D6FKPQNOP6BCPYVOTAFO1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) midgets.scr is removed from here because it contains a virus. ********************************************************* ----VEM34D6FKPQNOP6BCPYVOTAFO1-- >From owner-rmt@listserv.lbl.gov Thu Feb 15 14:34:38 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id OAA12518; Thu, 15 Feb 2001 14:31: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 OAA12514 for ; Thu, 15 Feb 2001 14:31: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 OAA02381 for ; Thu, 15 Feb 2001 14:31:42 -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 OAA02368 for ; Thu, 15 Feb 2001 14:31:41 -0800 (PST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id PAA20966 for ; Thu, 15 Feb 2001 15:31:40 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id PAA05570 for ; Thu, 15 Feb 2001 15:31:38 -0700 (MST)] Received: from arc.corp.mot.com (marcia.arc.corp.mot.com [10.238.80.74]) by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id f1FMVZn11389 for ; Fri, 16 Feb 2001 09:31:36 +1100 (EST) Message-ID: <3A8C58C5.A63850BB@arc.corp.mot.com> Date: Fri, 16 Feb 2001 09:31:33 +1100 From: Roger Kermode Organization: Motorola Australia Research Centre X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: Call for RMT Items Content-Type: multipart/mixed; boundary="------------C2D2002D8A28D7B838CF4A98" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------C2D2002D8A28D7B838CF4A98 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Everyone, Lorenzo has organized the following time slots for the Minneapolis meeting. Please send your agenda items to me ASAP so we can pre publish the agenda with a little more notice this time around. I'd like to emphasize that we will be shooting for brief updates to drafts and that the bulk of the time should be spent discussing issues relating to how we can move towards having real working protocols. Please use the email list to pre announce any items for discussion so we can come to the meeting well informed and ready to make decisions. cheers, Roger Lorenzo Allison TENTATIVE SCHEDULE ---------------------------- TUESDAY, March 20, 2001 1300-1400 Afternoon Sessions I APP webi Web Intermediaries WG GEN iporpr IP over Resilient Packet Rings WG INT atommib AToM MIB WG OPS rap Resource Allocation Protocol WG SEC pkix Public-Key Infrastructure WG TSV issll Integrated Services over Specific Link Layers WG TSV rmt Reliable Multicast Transport WG WEDNESDAY, March 21, 2001 0900-1130 Morning Sessions APP ldapbis LDAP (v3) Revision WG INT ipngwg IPNG WG OPS policy Policy Framework WG SEC idwg Intrusion Detection Exchange Format WG TSV ips IP Storage WG TSV rmt Reliable Multicast Transport WG --------------C2D2002D8A28D7B838CF4A98 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 org:Motorola Labs, Motorola Australian Research Centre;Communications and Networks Laboratory version:2.1 email;internet:Roger.Kermode@motorola.com title:Principal Research Engineer, Manager adr;quoted-printable:;;Locked Bag 5028, Botany NSW, 1455=0D=0A=0D=0ALevel 3, 12 Lord St;Botany;NSW;;Australia fn:Roger Kermode end:vcard --------------C2D2002D8A28D7B838CF4A98-- >From owner-rmt@listserv.lbl.gov Fri Feb 23 06:48:38 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id GAA06823; Fri, 23 Feb 2001 06:46:20 -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 GAA06819 for ; Fri, 23 Feb 2001 06:46: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 GAA13209 for ; Fri, 23 Feb 2001 06:46:17 -0800 (PST) Received: from sm.luth.se (ny.sm.luth.se [130.240.3.1]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA13204 for ; Fri, 23 Feb 2001 06:46:15 -0800 (PST) Received: from fix.cdt.luth.se (fix.cdt.luth.se [130.240.64.20]) by sm.luth.se (8.10.0/8.10.0) with ESMTP id f1NEiQk29689; Fri, 23 Feb 2001 15:44:41 +0100 (MET) Date: Fri, 23 Feb 2001 15:44:12 +0100 (MET) From: Jeremiah Scholl X-Sender: jeremiah@fix.cdt.luth.se To: rmt@lbl.gov cc: peppar@cdt.luth.se Subject: reliable multicast congestion control Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rmt@lbl.gov Precedence: bulk I have recently been looking at the internet drafts available on the web site for rmt workgroup and have a question regarding the standards that are currently being developed. Specifically I am interested in information about congestion control. I noticed that there is currently one document on the site that describes a congestion control mechanism. It is titled "Reliable Multicast Transport Building Block: Layered Congestion Control". This congestion control mechanism seems to be taylored specifically for the case where massive scale is the primary concern and seemed to be created to work along with LTC. I am wondering if there will be additional congestion control "Building Blocks" created that focus more on other types of applications (like collabrative workspaces for example). Does the group plan on creating one congestion control document for each protocol? Any information on how congestion control for reliable multicast will fit into the work on standardization of reliable multicast would be very helpfull. Thank you very much, Jeremiah Scholl >From owner-rmt@listserv.lbl.gov Fri Feb 23 07:10:02 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id HAA06857; Fri, 23 Feb 2001 07:09: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 HAA06853 for ; Fri, 23 Feb 2001 07:09: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 HAA16353 for ; Fri, 23 Feb 2001 07:09:54 -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 HAA16350 for ; Fri, 23 Feb 2001 07:09:52 -0800 (PST) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 23 Feb 2001 15:09:27 +0000 To: Jeremiah Scholl cc: rmt@lbl.gov, peppar@cdt.luth.se Subject: Re: reliable multicast congestion control In-reply-to: Your message of "Fri, 23 Feb 2001 15:44:12 +0100." Date: Fri, 23 Feb 2001 15:09:24 +0000 Message-ID: <21265.982940964@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk In message , Jeremiah Scholl typed: >>I am wondering if there will be additional congestion control "Building >>Blocks" created that focus more on other types of applications (like >>collabrative workspaces for example). Does the group plan on creating >>one congestion control document for each protocol? Any information on how >>congestion control for reliable multicast will fit into the work on >>standardization of reliable multicast would be very helpfull. Jeremiah we went round this loop several times - the problem with this is that we could never get people to poin down the applicationrequirements fir cilaborative workspaces that allowed for congestion control - looking back at this again, let me try to restate where we got to (some of this happened in the LSMA working group) 1/ a lot of colalborative applications have lowish message rates and smallish messages (viz, wb, nte, game traffic) - 2/ they are highly bursty (but not high rate - ) i.e. they are 1 packet or 2, then nothing for ages, per source 3/ many to many: there's no obvious correlation in the rate from one source and another 4/ there _IS_ a requirement for latency control - this means that adaption below a minimum rate is not acceptable, and usualy means that you have to provision, or reserve, for them for them to be usable at all over any significant distance 5/ when there is a large transfer (e.g. wb loading slides to a new/late joiner), its 1-many, which is covered by current approaches 6/ in IETF "stakeholder" terms, the recent trend for ISPs technology pull has been SSM - which mitigates against simple transport protocols for multiple sender - typically, for smallish groups, though, yo uhave a coordination server: "clients" runs unicast to it - it runs ssm to clients - them same rules apply...(actually quite nicely for ALC like protocols, since yo ucan accomodate heterogeneity and asymetric trees quite elegantly) for many-to-many large group, large numebr of senders, the claim has been there aren't "compelling" application demand (at least yet).... that may sound negative - i dont mean to be - i think there's also an element of "oh, we think we can solve this case so lets get it done, then we can go onto the harder case again" given the data rates involved, we are fairly conveinced that games for example will appear that are multiplayer but not server based once the game engines for this are in place - then some sort of "collective bargaining" congestion control looks like being vital..... cheers jon >From owner-rmt@listserv.lbl.gov Tue Feb 27 01:07:28 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id BAA16402; Tue, 27 Feb 2001 01:02: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 BAA16398 for ; Tue, 27 Feb 2001 01:02: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 BAA05033 for ; Tue, 27 Feb 2001 01:02:12 -0800 (PST) Received: from sm.luth.se (ny.sm.luth.se [130.240.3.1]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA05030 for ; Tue, 27 Feb 2001 01:02:10 -0800 (PST) Received: from delta1.sm.luth.se (delta1.sm.luth.se [130.240.3.7]) by sm.luth.se (8.10.0/8.10.0) with ESMTP id f1R92Lk27160; Tue, 27 Feb 2001 10:02:21 +0100 (MET) Date: Tue, 27 Feb 2001 10:02:06 +0100 (MET) From: Jeremiah Scholl To: Jon Crowcroft cc: rmt@lbl.gov, peppar@cdt.luth.se Subject: Re: reliable multicast congestion control In-Reply-To: <21265.982940964@cs.ucl.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rmt@lbl.gov Precedence: bulk On Fri, 23 Feb 2001, Jon Crowcroft wrote: > > In message , Jeremiah > Scholl typed: > > >>I am wondering if there will be additional congestion control "Building > >>Blocks" created that focus more on other types of applications (like > >>collabrative workspaces for example). Does the group plan on creating > >>one congestion control document for each protocol? Any information on how > >>congestion control for reliable multicast will fit into the work on > >>standardization of reliable multicast would be very helpfull. > > Jeremiah > > we went round this loop several times - the problem with this is that > we could never get people to poin down the applicationrequirements > fir cilaborative workspaces that allowed for congestion control - > > looking back at this again, let me try to restate where we got to > (some of this happened in the LSMA working group) > > 1/ a lot of colalborative applications have lowish message rates and > smallish messages (viz, wb, nte, game traffic) - > > 2/ they are highly bursty (but not high rate - ) i.e. they are 1 > packet or 2, then nothing for ages, per source > > 3/ many to many: there's no obvious correlation in the rate from one > source and another > > 4/ there _IS_ a requirement for latency control - this means that > adaption below a minimum rate is not acceptable, and usualy means that > you have to provision, or reserve, for them for them to be usable at > all over any significant distance > > 5/ when there is a large transfer (e.g. wb loading slides to a new/late > joiner), its 1-many, which is covered by current approaches > > 6/ in IETF "stakeholder" terms, the recent trend for ISPs technology pull has > been SSM - which mitigates against simple transport protocols for > multiple sender - typically, for smallish groups, though, yo uhave a > coordination server: "clients" runs unicast to it - it runs ssm to > clients - them same rules apply...(actually quite nicely for ALC like > protocols, since yo ucan accomodate heterogeneity and asymetric trees > quite elegantly) > > for many-to-many large group, large numebr of senders, the claim has > been there aren't "compelling" application demand (at least yet).... > > that may sound negative - i dont mean to be - i think there's also an > element of "oh, we think we can solve this case so lets get it done, > then we can go onto the harder case again" > > given the data rates involved, we are fairly conveinced that games for > example will appear that are multiplayer but not server based once the > game engines for this are in place - then some sort of "collective > bargaining" congestion control looks like being vital..... > > cheers > > jon > > Jon, thanks for the comments! I agree with what you wrote. Has any progress at all been made towards forming a consensus on what the building block will need? Have the most basic requirements been agreed upon yet and if so what are they? For example, because of the interactivity of users multiple-rate congestion control does not lend itself well with collabrative workspaces. Also, as you mentioned above there is still not "compelling application demand" for large many -to- many sessions. This would tend to make tuning the send rate worst-case receiver a realistic option for the scheme. So, has there at least been an agreement to create a building block for a single-rate scheme that tunes its sending rate to the worst-case receiver? Any information about this or any other congestion control builing blocks in the works would be very helpfull. Thanks again! Jeremiah >From owner-rmt@listserv.lbl.gov Tue Feb 27 02:16:19 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id CAA16568; Tue, 27 Feb 2001 02:13:54 -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 CAA16564 for ; Tue, 27 Feb 2001 02:13:52 -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 CAA11473 for ; Tue, 27 Feb 2001 02:13:51 -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 CAA11470 for ; Tue, 27 Feb 2001 02:13:50 -0800 (PST) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id LAA20996; Tue, 27 Feb 2001 11:14:41 +0100 (CET) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200102271014.LAA20996@info.iet.unipi.it> Subject: Re: reliable multicast congestion control In-Reply-To: from Jeremiah Scholl at "Feb 27, 2001 10:02:06 am" To: Jeremiah Scholl Date: Tue, 27 Feb 2001 11:14:40 +0100 (CET) CC: Jon Crowcroft , rmt@lbl.gov, peppar@cdt.luth.se 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 > So, has there at least been an agreement to create a building block for a > single-rate scheme that tunes its sending rate to the worst-case > receiver? i just submitted an I-D on pgmcc, which is a single rate cong.control scheme. You can find more at http://www.iet.unipi.it/~luigi/pgm.html or on the sigcomm2000 site cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone (510) 666 2927 . ----------------------------------+----------------------------------------- >From owner-rmt@listserv.lbl.gov Wed Feb 28 04:01:48 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id DAA01247; Wed, 28 Feb 2001 03:59:20 -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 DAA01243 for ; Wed, 28 Feb 2001 03:59: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 DAA20524 for ; Wed, 28 Feb 2001 03:59:17 -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 DAA20521 for ; Wed, 28 Feb 2001 03:59:15 -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 GAA03109; Wed, 28 Feb 2001 06:59:15 -0500 (EST) Message-Id: <200102281159.GAA03109@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-pgmcc-00.txt Date: Wed, 28 Feb 2001 06:59:14 -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 : PGMCC single rate multicast congestion control: Protocol Specification Author(s) : L. Rizzo, L. Vicisano, M. Handley, G. Iannaccone Filename : draft-ietf-rmt-bb-pgmcc-00.txt Pages : 19 Date : 27-Feb-01 This document describes PGMCC, a single rate multicast congestion control scheme which is TCP-friendly and achieves scalability, stability and fast response to variations in network conditions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-pgmcc-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-pgmcc-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-pgmcc-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: <20010227124130.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-pgmcc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-pgmcc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010227124130.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Sat Mar 3 13:36:36 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id NAA28948; Sat, 3 Mar 2001 13:34: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 NAA28944 for ; Sat, 3 Mar 2001 13:34: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 NAA05797 for ; Sat, 3 Mar 2001 13:34:17 -0800 (PST) Received: from phx292636 (cpe-66-1-193-50.co.sprintbbd.net [66.1.193.50]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id NAA05743 for ; Sat, 3 Mar 2001 13:33:45 -0800 (PST) Message-Id: <200103032133.NAA05743@SpamWall.lbl.gov> From: "Ralph" <1231309@ito.com> To: <> Subject: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 3 Mar 2001 13:29:21 Sender: owner-rmt@lbl.gov Precedence: bulk Dear Friends & Future Millionaire: AS SEEN ON NATIONAL TV: Making over half million dollars every 4 to 5 months right from your home !! THANK'S TO THE COMPUTER AGE AND THE INTERNET ! ================================================== BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!! Before you say ''Bull'', please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the Internet, a national weekly news program recently devoted an entire show to the investigation of this program described below, to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are ''absolutely NO Laws prohibiting the participation in the program and if people can -follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost''. DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: ''Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $610,470.00 in 21 weeks, with money still coming in." Pam Hedland, Fort Lee, New Jersey. =================================================== Here is another testimonial: "This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed the simple instructions and walaa ..... 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program, I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything.'' More testimonials later but first, ===== PRINT THIS NOW FOR YOUR FUTURE REFERENCE ====== $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: =====Order all 5 reports shown on the list below ===== For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. === When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5=$25.00. Within a few days you will receive, vie e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in step '' 1 through 6 '' or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work !!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1.... After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune. 2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 5.... Move the name & address in REPORT # 1 down TO REPORT # 2 6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY! ========================================================== **** Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. To assist you with marketing your business on the Internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD # 1: BY SENDING E-MAIL LEGALLY ========================================================== Let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a 0.2% response (the response could be much better but lets just say it is only 0.2%. Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's=100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5 THAT'S 100,000 ORDERS TIMES $5 EACH=$500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3..... $5,000 + 4 .... $50,000 + 5..... $500,000 ........ Grand Total=$555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! ========================================================= REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone or half or even one 4th of those people mailed 100,000e-mails each or more? There are over 150 million people on the Internet worldwide and counting. Believe me, many people will do just that, and more! METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET ======================================================= Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free ads on the Internet will easily get a larger response. We strongly suggest you start with Method # 1 and progress to METHOD # 2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it. Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report. =========== AVAILABLE REPORTS ==================== ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW : ==================================================== REPORT # 1: "The Insider's Guide to Advertising for Free on the Net" Order Report #1 from: J.R. PMB No. 166 20165 N 67th AVE Ste 122A Glendale, AZ 85308-7002 USA ___________________________________________________________ REPORT # 2: "The Insider's Guide to Sending e-mail on the Net" Order Report # 2 from: S. Cranke 1503-1500 Walkley Rd Ottawa, ON K1V 0H8 Canada ____________________________________________________________ REPORT # 3: "Secret to Multilevel Marketing on the Net" Order Report # 3 from : T. Richardson P.O. Box 753 Richland, MO. 65556 USA ____________________________________________________________ REPORT # 4: "How to Become a Millionaire Utilizing MLM & the Net" Order Report # 4 from: C.J. Kalata P.O. Box 130157 Roseville, MN 55113-0002 USA ____________________________________________________________ REPORT #5: "How to Send Out 0ne Million e-mails for Free" Order Report # 5 from: R. B. Box. 21115, Grande Prairie Alberta, T8V-6W7 Canada _____________________________________________________________ $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ Follow these guidelines to guarantee your success: === If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. === After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT # 2. If you did not, continue advertising or sending e-mails until you do. === Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a Different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business !!! ====================================================== FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2 ..........# 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on every one of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW ! ============ MORE TESTIMONIALS ================ "My name is Mitchell. My wife, Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving ''junk mail''. I made fun of the whole thing,spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn't work. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received total $ 147,200.00 ........... all cash! I was shocked. I have joined Jody in her ''hobby''. Mitchell Wolf, Chicago, Illinois ====================================================== ''Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back''. '' I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big." Dan Sondstrom, Alberta, Canada ======================================================= ''I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks." Susan De Suza, New York, N.Y. ======================================================= ''It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $20,560.00 and by the end of third month my total cash count was $362,840.00. Life is beautiful, Thanx to Internet.". Fred Dellaca, Westport, New Zealand ======================================================= ORDER YOUR REPORTS TODAY AND GET STARTED ON 'YOUR' ROAD TO FINANCIAL FREEDOM ! ======================================================= If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. >From owner-rmt@listserv.lbl.gov Wed Mar 7 04:49:07 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f27CkhP17946; Wed, 7 Mar 2001 04:46:43 -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.11.2/8.11.2) with ESMTP id f27Ckee17942 for ; Wed, 7 Mar 2001 04:46:40 -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 EAA27710 for ; Wed, 7 Mar 2001 04:46:40 -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 EAA27705 for ; Wed, 7 Mar 2001 04:46:39 -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 HAA01542; Wed, 7 Mar 2001 07:46:37 -0500 (EST) Message-Id: <200103071246.HAA01542@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-01.txt Date: Wed, 07 Mar 2001 07:46:37 -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 : Author Guidelines for RMT Building Blocks and Protocol Instantiation documents Author(s) : R. Kermode, L. Vicisano Filename : draft-ietf-rmt-author-guidelines-01.txt Pages : 13 Date : 06-Mar-01 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-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-author-guidelines-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-author-guidelines-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: <20010306125914.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-author-guidelines-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-author-guidelines-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010306125914.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Thu Mar 8 03:59:13 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f28BwI524426; Thu, 8 Mar 2001 03:58:18 -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.11.2/8.11.2) with ESMTP id f28BwHe24422 for ; Thu, 8 Mar 2001 03:58: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 DAA12281 for ; Thu, 8 Mar 2001 03:58:16 -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 DAA12276 for ; Thu, 8 Mar 2001 03:58:15 -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 GAA22543; Thu, 8 Mar 2001 06:58:13 -0500 (EST) Message-Id: <200103081158.GAA22543@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-tree-config-02.txt Date: Thu, 08 Mar 2001 06:58:13 -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: Tree Auto-Configuration Author(s) : M. Kadansky, B. Levine, D. Chiu, B. Whetten, G. Taskale, B. Cain, D. Thaler, S. Koh Filename : draft-ietf-rmt-bb-tree-config-02.txt Pages : 25 Date : 07-Mar-01 The Reliable Multicast Transport Working Group has been chartered to standardize multicast transport services. This working group expects to initially standardize three protocol instantiations. This draft is concerned with the requirements of the tree-based ACK protocol. In particular, it is concerned with defining the building block for auto-configuration of the logical ACK-tree. According to the charter, a building block is 'a coarse-grained modular component that is common to multiple protocols along with abstract APIs that define a building block's access methods and their arguments.' For more information, see the Reliable Multicast Transport Building Blocks and Reliable Multicast Design Space documents [WLKHFL00][HWKFV00]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-tree-config-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-bb-tree-config-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-bb-tree-config-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: <20010307142942.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-tree-config-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-tree-config-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010307142942.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Thu Mar 8 03:59:14 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f28BwFN24420; Thu, 8 Mar 2001 03:58: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.11.2/8.11.2) with ESMTP id f28BwDe24416 for ; Thu, 8 Mar 2001 03:58: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 DAA12268 for ; Thu, 8 Mar 2001 03:58:12 -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 DAA12265 for ; Thu, 8 Mar 2001 03:58:11 -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 GAA22526; Thu, 8 Mar 2001 06:58:09 -0500 (EST) Message-Id: <200103081158.GAA22526@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-track-01.txt Date: Thu, 08 Mar 2001 06:58: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 : Reliable Multicast Transport Building Block for TRACK Author(s) : B. Whetten, D. Chiu, M. Kadansky, G. Taskale Filename : draft-ietf-rmt-bb-track-01.txt Pages : 29 Date : 07-Mar-01 This document describes the TRACK Building Block. It contains functions relating to positive acknowledgments and hierarchical tree construction and maintenance. It is primarily meant to be used as part of the TRACK Protocol Instantiation. It is also designed to be useful as part of overlay multicast systems that wish to offer efficient confirmed delivery of multicast messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-track-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-bb-track-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-bb-track-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: <20010307142929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-track-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-track-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010307142929.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Fri Mar 9 04:40:40 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f29CbJp01157; Fri, 9 Mar 2001 04:37: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.11.2/8.11.2) with ESMTP id f29CbHn01153 for ; Fri, 9 Mar 2001 04:37: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 EAA13524 for ; Fri, 9 Mar 2001 04:37:16 -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 EAA13521 for ; Fri, 9 Mar 2001 04:37:15 -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 HAA11811; Fri, 9 Mar 2001 07:37:12 -0500 (EST) Message-Id: <200103091237.HAA11811@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-norm-01.txt Date: Fri, 09 Mar 2001 07:37:12 -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 : NACK-Oriented Reliable Multicast Protocol (NORM) Author(s) : B. Adamson, C. Bormann, S. Floyd, M. Handley, J. Macker Filename : draft-ietf-rmt-pi-norm-01.txt Pages : 27 Date : 08-Mar-01 This document describes the messages and procedures of the Nega- tive-acknowledgement (NACK) oriented reliable multicast (NORM). This revision of the document represents an initial outline of the protocol description. The document requires refinement in a number of areas to be considered complete. At this time, the document describes the high level details of the reliable multicast bulk transfer service model this protocol hopes to fulfill and the gen- eral message types and mechanisms which will be used to accomplish those goals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-norm-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-pi-norm-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-pi-norm-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: <20010308111127.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-pi-norm-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-pi-norm-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010308111127.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Sun Mar 11 07:01:00 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2BEvRV17321; Sun, 11 Mar 2001 06:57: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.11.2/8.11.2) with ESMTP id f2BEvQn17317 for ; Sun, 11 Mar 2001 06:57: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 GAA00841 for ; Sun, 11 Mar 2001 06:57:25 -0800 (PST) Received: from pop136-mc.mail.com (pop136-mc.mail.com [165.251.48.111]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA00838 for ; Sun, 11 Mar 2001 06:57:25 -0800 (PST) Received: from localhost (cc410790-a.srst1.fl.home.com [24.13.212.54]) by pop136-mc.mail.com (Postfix) with ESMTP id 0467698BA for ; Sun, 11 Mar 2001 09:57:20 -0500 (EST) X-Sender: res02mg1@gte.net From: David Dickson To: rmt@lbl.gov Date: Sun, 11 Mar 2001 09:52:44 -0500 Subject: Security Training Course Availability - Unix Countermeasures, Intrusion Detection, Network Security - Wash DC area Reply-To: res02mg1@gte.net Organization: Market*Access MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20010311145720.0467698BA@pop136-mc.mail.com> Sender: owner-rmt@lbl.gov Precedence: bulk To: rmt@lbl.gov PLEASE FORWARD THIS MESSAGE TO YOUR AGENCY PERSONNEL INVOLVED WITH NETWORK and IT SECURITY TRAINING. The following THREE courses are available now. See our web site for course dates, prerequisites and more details on course content. Visit www.marketaccess.org and the courses will be listed at our home page along with dates available. Course One: Network Security for Managers - Two day course Course Outline: Introduction Security History (famous attacks) Security Principles Common Attacks Discussion on the most common attacks today and how they relate to each security principle Find out what can happen to your network as a result Demonstration of these attacks - see first-hand how they are executed Protection Risk Assessment: in-depth coverage on every aspect of a network Vulnerability Prevention: common mistakes made by administrators Discussion on network security tools and their purpose Steps and recommendations to secure your network Web Site and Server Protection Find out what might be compromised and obtain advice on how to prevent such loss Budget Analysis Discussion on the "bottom line" Security Policy Why you need one and who should be involved In-depth coverage of the topics which should be addressed in an effective policy Incident Handling Detailed discussion on the necessary steps to take if something happens Network Security for Managers - Fee: $695.00 Course Two: UNIX Countermeasures - 5 Days (Hands-on) Course Highlights Identification & Authentication (I&A) -- Learn various methods of I&A including their weaknesses, if any, to include simple passwords, skey, and strong bind Discretionary Access Control (DAC) -- Learn what DAC is and how it can be used to make the operating system more resistant to unauthorized access Audit -- Learn how to configure UNIX platforms where audit files are meaningful as well as how to add extra program audit capabilities Network Services Gain extensive knowledge about various network services and how to configure them securely using TCP wrappers or the new super daemon caked XINITD. The following are some of the services that students will configure in class: Samba (NT file sharing) NFS (UNIX file sharing) HTTP Secure Shell Network Time Protocol (NTP) Unix Countermeasures - Government Fee $2,475.00 Course Three: Intro to Network Security and Intrusion Detection - 5 days - Hands on Course Outline Introduction (Hands-On) Quick familiarization of Linux Gain super-user access with a password cracker Security History (Lecture) Security, in general Discussion of significant security events Definition of terms Intrusion Detection (Mostly Hands-On) Discussion of how logs and various tools can be used to detect unauthorized activities Hands-on experience with three different sniffers How to read audit files Hands-on experience with several system commands and various tools to detect unauthorized activity Reconnaissance (Hands-On) Students will learn how to scan and detect scans from several different manual, as well as automated tools including: Basic UNIX commands Nmap ISS NetCat Sendmail Version Scan Low-Level Access (Hands-On) Students will run a series of several ^Óattacks and detect labs^Ô to gain low-level access to various servers. Examples of the exploits include: HTTP Remote Buffer Overflow NFS Attack NIS Attack X Windows Attack DNS Spoofing Privileged Access (Hands-On) Students will use their low-level access knowledge gained in previous labs to gain access as a super user. Some exploits they will perform and detect include: IMAP Buffer Overflow DIP Buffer Overflow EUID Buffer Overflow Covert Access (Hands-On & Discussion) Although covert access is often difficult to detect, students will learn how to recognize when someone is using a covert channel. They will also learn how intruders conceal their real identity and hide in normal network traffic from being detected by Intrusion Detection Systems and Audit Logs. Following are examples of which the students will gain hands-on experience: UNIX Shell Games NetCat ICMP Covert Channel Trojan Horses NetBus Back Orifice Denial of Service (Hands-On & Discussion) These attacks are commonly executed on today's networks and are often difficult to trace back to the actual attacker. However, sometimes the evidence needed can be found in your Audit System. Students will learn how these attacks work and how to detect them. Examples of some attacks students will learn to perform and detect include: Land Attack UDP Bomb Smurf Attack Course Fee - Intro to Network Security and Intrusion Detection - 5 days - Hands on - Government Rate: $2,475.00 For more information on these courses or to register, call Margo McPhee, Verizon Federal Network Systems (formerly BBN) at 1-800-334-1553. >From owner-rmt@listserv.lbl.gov Sun Mar 11 12:18:41 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2BKHeG17721; Sun, 11 Mar 2001 12:17: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.11.2/8.11.2) with ESMTP id f2BKHbn17717 for ; Sun, 11 Mar 2001 12:17: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 MAA16614 for ; Sun, 11 Mar 2001 12:17:36 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA16601 for ; Sun, 11 Mar 2001 12:17:35 -0800 (PST) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id PAA18813; Sun, 11 Mar 2001 15:16:44 -0500 (EST) Date: Sun, 11 Mar 2001 15:16:44 -0500 (EST) From: Scott Bradner Message-Id: <200103112016.PAA18813@newdev.harvard.edu> To: ark008@email.mot.com, lorenzo@cisco.com, mankin@east.isi.edu, rmt@lbl.gov Subject: PGM Reliable Transport Protocol Sender: owner-rmt@lbl.gov Precedence: bulk To the RGT Chairs and Working Group The IESG has been asked to evaluate the publication of "PGM Reliable Transport Protocol" as an Experimental RFC. This is clearly in the realm of the RMT working group but it seems as if the working group has abandoned this genre of RMT technologies. My feeling is based on the expiration of the Generic Router Assist documents and their absence from your agenda in recent meetings. Am I understanding working group's interest accurately? If that is the case then the right process would seem to be that the Transport ADs should evaluate this (and possibly other proposals in the same genre) against the requirements in RFC 2357 and make a recommendation to the IESG about the suitability of publishing the Internet Draft as an RFC. If indeed the working group is interested in doing work in this space this Internet Draft should be refereed to the Working Group for consideration. advice please Scott Area Director for RMT >From owner-rmt@listserv.lbl.gov Mon Mar 12 00:14:53 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2C8Dj619044; Mon, 12 Mar 2001 00:13: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.11.2/8.11.2) with ESMTP id f2C8Dhn19040 for ; Mon, 12 Mar 2001 00:13: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 AAA02201 for ; Mon, 12 Mar 2001 00:13:42 -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 AAA02198 for ; Mon, 12 Mar 2001 00:13:41 -0800 (PST) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 12 Mar 2001 08:13:17 +0000 To: Scott Bradner cc: ark008@email.mot.com, lorenzo@cisco.com, mankin@east.isi.edu, rmt@lbl.gov, J.Crowcroft@cs.ucl.ac.uk Subject: Re: PGM Reliable Transport Protocol In-reply-to: Your message of "Sun, 11 Mar 2001 15:16:44 EST." <200103112016.PAA18813@newdev.harvard.edu> Date: Mon, 12 Mar 2001 08:13:14 +0000 Message-ID: <791.984384794@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk In message <200103112016.PAA18813@newdev.harvard.edu>, Scott Bradner typed: >>To the RGT Chairs and Working Group >>The IESG has been asked to evaluate the publication of "PGM Reliable >>Transport Protocol" as an Experimental >>RFC. This is clearly in the realm of the RMT working group but it seems as >>if the working group has abandoned this genre of RMT technologies. My >>feeling is based on the expiration of the Generic Router Assist documents >>and their absence from your agenda in recent meetings. Am I >>understanding working group's interest accurately? >>If that is the case then the right process would seem to be that the >>Transport ADs should evaluate this (and possibly other proposals in the >>same genre) against the requirements in RFC 2357 and make a recommendation >>to the IESG about the suitability of publishing the Internet Draft as an >>RFC. >>If indeed the working group is interested in doing work in this space this >>Internet Draft should be refereed to the Working Group for consideration. >>advice please Scott i can't speak for anyone except me, but I think you have to divide the GRA generic work from the PGM specific work - GRA lost some of its general momentum only because we have plenty else to do first and specifically because of change of afiliation (i believe) of one the key designers - my group at UCL would be working on GRA if we weren't so busy on nearer term things for now... pgm is live and kicking as an instance of it... so if you like, its kind of a cart before a horse (examplar before general building block) but i don't want that to sound negative - i am positive about pgm (it does congestion control for example) and has a lot of RMT folks involved..... but i gess the WG chairs will have more to say... cheers jon >From owner-rmt@listserv.lbl.gov Mon Mar 12 07:31:25 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2CFShH20622; Mon, 12 Mar 2001 07:28:43 -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.11.2/8.11.2) with ESMTP id f2CFSfn20618 for ; Mon, 12 Mar 2001 07:28:41 -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 HAA18948 for ; Mon, 12 Mar 2001 07:28:40 -0800 (PST) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA18943 for ; Mon, 12 Mar 2001 07:28:39 -0800 (PST) Received: from localhost (speakman@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA09885; Mon, 12 Mar 2001 07:27:00 -0800 (PST) Message-Id: <200103121527.HAA09885@cisco.com> To: Scott Bradner cc: ark008@email.mot.com, lorenzo@cisco.com, mankin@east.isi.edu, rmt@lbl.gov, calvert@dcs.uky.edu Subject: Re: PGM Reliable Transport Protocol Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Date: Mon, 12 Mar 2001 07:27:00 -0800 From: Tony Speakman Sender: owner-rmt@lbl.gov Precedence: bulk > The IESG has been asked to evaluate the publication of "PGM Reliable > Transport Protocol" as an Experimental > RFC. This is clearly in the realm of the RMT working group but it seems as > if the working group has abandoned this genre of RMT technologies. My > feeling is based on the expiration of the Generic Router Assist documents > and their absence from your agenda in recent meetings. Am I > understanding working group's interest accurately? The GRA work has just been side-lined for a while by the authors' other priorities. There were multiple references to it (and inquiries about it) at the last IETF, and the authors will plan to get together at the Minneapolis IETF to pick up where we left off. In preparation for that, I have gone over the relevant RMT documents, the old GRA draft, and Ken Calvert's concast draft to come up with a document plan for the next set of drafts we should be working on. Tony S > If that is the case then the right process would seem to be that the > Transport ADs should evaluate this (and possibly other proposals in the > same genre) against the requirements in RFC 2357 and make a recommendation > to the IESG about the suitability of publishing the Internet Draft as an > RFC. > > If indeed the working group is interested in doing work in this space this > Internet Draft should be refereed to the Working Group for consideration. > > advice please > > Scott > Area Director for RMT >From owner-rmt@listserv.lbl.gov Mon Mar 12 11:11:26 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2CJ8vv22236; Mon, 12 Mar 2001 11:08: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.11.2/8.11.2) with ESMTP id f2CJ8on22232 for ; Mon, 12 Mar 2001 11:08: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 LAA12761 for ; Mon, 12 Mar 2001 11:08:43 -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 LAA12757 for ; Mon, 12 Mar 2001 11:08:43 -0800 (PST) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [10.34.54.43]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA19069; Mon, 12 Mar 2001 11:08:32 -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 LAA11688; Mon, 12 Mar 2001 11:08:12 -0800 (PST) Message-Id: <200103121908.LAA11688@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: Scott Bradner cc: ark008@email.mot.com, mankin@east.isi.edu, rmt@lbl.gov Subject: Re: PGM Reliable Transport Protocol In-Reply-To: Your message of "Sun, 11 Mar 2001 15:16:44 EST." <200103112016.PAA18813@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Mar 2001 11:08:12 -0800 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk Scott, The Working Group has not abandoned GRA, however the work on this is still at a very early stage. Given the challenges that we will be facing, i.e. mechanism abstraction, hardware constraints, deployment concerns, I think that coming up with a good solution will be a hard task that will require more time than we expected. I don't think that we can consider PGM as a replacement for GRA, both because it is focused on a single mechanism (NAK aggregation) and because does not fit the RMT architecture. Hence my opinion is that the ADs evaluate the PGM draft independently from the WG as a non-standard track candidate. Lorenzo > The IESG has been asked to evaluate the publication of "PGM Reliable > Transport Protocol" as an Experimental > RFC. This is clearly in the realm of the RMT working group but it seems as > if the working group has abandoned this genre of RMT technologies. My > feeling is based on the expiration of the Generic Router Assist documents > and their absence from your agenda in recent meetings. Am I > understanding working group's interest accurately? > > If that is the case then the right process would seem to be that the > Transport ADs should evaluate this (and possibly other proposals in the > same genre) against the requirements in RFC 2357 and make a recommendation > to the IESG about the suitability of publishing the Internet Draft as an > RFC. > > If indeed the working group is interested in doing work in this space this > Internet Draft should be refereed to the Working Group for consideration. > > advice please > > Scott > Area Director for RMT >From owner-rmt@listserv.lbl.gov Fri Mar 16 05:18:20 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2GDFWd26637; Fri, 16 Mar 2001 05:15: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.11.2/8.11.2) with ESMTP id f2GDFUn26633 for ; Fri, 16 Mar 2001 05:15:30 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2GDFTs23491 for ; Fri, 16 Mar 2001 05:15:29 -0800 (PST) Received: from pi4.informatik.uni-mannheim.de (root@pi4.informatik.uni-mannheim.de [134.155.48.96]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2GDFRE23485 for ; Fri, 16 Mar 2001 05:15:28 -0800 (PST) Received: from 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 OAA04734 for ; Fri, 16 Mar 2001 14:15:21 +0100 (MET) Message-ID: <3AB211E8.7EC89A4C@informatik.uni-mannheim.de> Date: Fri, 16 Mar 2001 14:15:20 +0100 From: Martin Mauve Organization: University of Mannheim X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rmt@lbl.gov Subject: SIG on Networked Computer Games Content-Type: multipart/mixed; boundary="------------F5E10FCBA5C9F0B85FDDC3FC" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------F5E10FCBA5C9F0B85FDDC3FC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, I'm posting this to rmt since networked computer games have already been a topic here. cheers, Martin --------------F5E10FCBA5C9F0B85FDDC3FC Content-Type: text/plain; charset=us-ascii; name="NetGameNew.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="NetGameNew.txt" Call for Participation Special Interest Group on Networked Computer Games (SIG NetGame) Over the past three to four years networked computer games have been a tremendous commercial success. Games like Ultima Online, Everquest, Doom, Quake, Diablo II and others have attracted an audience of several million players, worldwide. They are one of the few Internet services for which end users are actually willing to pay money. As the Internet becomes ubiquitous through wireless and/or cheaper Internet access the the audience for networked computer games will increase rapidly, creating a mass market with a multi-billion dollar volume. However, most - if not all - of the successful networked computer games have encountered a large number of technical challenges that are inherent to this application area. These range from inadequate support by network and transport protocols to consistency problems and security breaches (or cheating as players prefer to call it). At the same time scientists have begun to discover networked computer games as an extremely challenging and rewarding area of research. What makes this area of research particularly fascinating is that solutions found for networked computer games tend to solve related problems in other areas such as computer supported collaborative work, distance education and telemedicine. It is the aim of this SIG to bring together developers of commercial and non-commercial networked computer games, service providers, scientists, and interested individuals in order to discuss - and possibly solve - technical challenges of networked computer games. Topics of interest include, but are certainly not limited to: - network and transport protocols - application-level protocol design - architectures for service providers - consistency mechanisms - security / cheating prevention - middle-ware (e.g. Direct Play) - billing and charging ... for networked computer games. You can subscribe to the NetGame mailing list through the NetGame webpage: http://www.informatik.uni-mannheim.de/netgame/index.html or by sending a mail to: netgame-l-request@pi4.informatik.uni-mannheim.de with the following line in the BODY of the message: subscribe I'm looking forward to interesting discussions on netgame-l. Sincerely, Martin Mauve Disclaimer: This SIG is currently not affiliated with any other organization. --------------F5E10FCBA5C9F0B85FDDC3FC-- >From owner-rmt@listserv.lbl.gov Fri Mar 16 09:49:36 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2GHn1L28104; Fri, 16 Mar 2001 09:49: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.11.2/8.11.2) with ESMTP id f2GHmxn28100 for ; Fri, 16 Mar 2001 09:48:59 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2GHmwD23244 for ; Fri, 16 Mar 2001 09:48:58 -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.11.2/8.11.2) with ESMTP id f2GHmwE23239 for ; Fri, 16 Mar 2001 09:48:58 -0800 (PST) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [10.34.54.43]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA18682 for ; Fri, 16 Mar 2001 09:48:56 -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 JAA19118 for ; Fri, 16 Mar 2001 09:48:52 -0800 (PST) Message-Id: <200103161748.JAA19118@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: call for agenda items Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Mar 2001 09:48:52 -0800 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk Although we are late for the official agenda, we still have to put one together.. The items I'm aware of are: Updates on draft-ietf-rmt-author-guidelines-01.txt 5 mins Kermode/Vicisano draft-ietf-rmt-bb-pgmcc-00.txt, CC proposal for NORM 15 mins Vicisano draft-koh-rmt-bb-tsm-01.txt 10 mins Seok Joo Koh Please send me request for additions. Also, we would like to have a representative for each PI + one for GRA to give a brief report on the status of the works: - List of BBs identified - PI document - Other documents (e.g. architectural docs.) - status of advancement and responsible editors ... so that we will be able to update the WG milestones. thanks, the RMT chairs >From owner-rmt@listserv.lbl.gov Fri Mar 16 21:24:11 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2H5NKn29047; Fri, 16 Mar 2001 21:23:20 -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.11.2/8.11.2) with ESMTP id f2H5NIn29043 for ; Fri, 16 Mar 2001 21:23:18 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2H5NIE15779 for ; Fri, 16 Mar 2001 21:23:18 -0800 (PST) Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.164.217]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2H5NFE15776 for ; Fri, 16 Mar 2001 21:23:15 -0800 (PST) Received: from sjkoh (sjkoh.etri.re.kr [129.254.164.46]) by pec.etri.re.kr (8.10.0/8.10.0) with SMTP id f2H5NUT09275; Sat, 17 Mar 2001 14:23:30 +0900 (KST) Message-ID: <002101c0aea2$d089ca40$2ea4fe81@etri.re.kr> Reply-To: "Seok Joo Koh" From: "Seok Joo Koh" To: , "Lorenzo Vicisano" References: <200103161748.JAA19118@lorenzo-u10.cisco.com> Subject: draft-koh-rmt-bb-tsm-01.txt Date: Sat, 17 Mar 2001 14:26:26 +0900 Organization: ETRI/PEC MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001E_01C0AEEE.401D85E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C0AEEE.401D85E0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Dear all, Please see the attached TSM draft, which is going to be discussed in this RMT meeting. It can also be obtained from http://pec.etri.re.kr/~sjkoh/draft-koh-rmt-bb-tsm-01.txt Best Regards, Seok Joo Koh ETRI/PEC sjkoh@pec.etri.re.kr ----- Original Message ----- From: "Lorenzo Vicisano" To: Sent: Saturday, March 17, 2001 2:48 AM Subject: call for agenda items > Although we are late for the official agenda, we still have to > put one together.. > > The items I'm aware of are: > > Updates on draft-ietf-rmt-author-guidelines-01.txt 5 mins > Kermode/Vicisano > draft-ietf-rmt-bb-pgmcc-00.txt, CC proposal for NORM 15 mins > Vicisano > draft-koh-rmt-bb-tsm-01.txt 10 mins > Seok Joo Koh > > Please send me request for additions. > > Also, we would like to have a representative for each PI + one for > GRA to give a brief report on the status of the works: > > - List of BBs identified > - PI document > - Other documents (e.g. architectural docs.) > - status of advancement and responsible editors > > ... so that we will be able to update the WG milestones. > > thanks, > the RMT chairs > ------=_NextPart_000_001E_01C0AEEE.401D85E0 Content-Type: text/plain; name="draft-koh-rmt-bb-tsm-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-koh-rmt-bb-tsm-01.txt" =0A= =0A= =0A= =0A= =0A= =0A= Internet Draft Seok Joo Koh, ETRI/KOREA=0A= Document: draft-koh-rmt-bb-tsm-01.txt Shin Gak Kang, ETRI/KOREA=0A= February 2001 Juyoung Park, ETRI/KOREA=0A= Expires August 2001 Eunsook Kim, ETRI/KOREA=0A= =0A= =0A= Reliable Multicast Transport Building Blocks:=0A= Transport Session Management=0A= =0A= =0A= =0A= Status of this Memo=0A= =0A= This document is an Internet-Draft and is in full conformance with=0A= all provisions of Section 10 of RFC2026.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts. Internet-Drafts are draft documents valid for a maximum of=0A= six months and may be updated, replaced, or obsoleted by other=0A= documents at any time. It is inappropriate to use Internet-Drafts as=0A= reference material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= =0A= =0A= Abstract=0A= =0A= Transport Session Management (TSM) is designed to support desirable=0A= management of end-to-end multicast sessions including the membership=0A= tracking for billing/charging and the group key management, according=0A= to the application's requirements that are represented as a set of=0A= TSM parameters including throughput and packet loss rate. TSM=0A= operations include Session Register, Session Monitoring and Session=0A= Maintenance. In Session Register, the sender informs authorized=0A= receivers about the target values of TSM parameters. In Session=0A= Monitoring, each receiver continues to measure the parameter values=0A= that have been experienced and to report the status of each parameter=0A= value to the sender. Based on the status information monitored and=0A= the target values of TSM parameters, the sender takes Session=0A= Maintenance actions necessary to maintain the session status=0A= desirable. Those actions include adjustment of data transmission=0A= =0A= =0A= =0A= Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 1]=0A= =0C=0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT Expires: August 2001 February 2001=0A= =0A= =0A= rate, troublemaker ejection, session pause/resume, and session=0A= termination. TSM mechanisms can be implemented into an API and=0A= easily adopted by any RMT PIs that wish to tightly control multicast=0A= sessions.=0A= =0A= =0A= 1. Introduction=0A= =0A= A multicast transport protocol instantiation may include various=0A= protocol components such as error recovery, flow and congestion=0A= control, membership management, and session management [RMT-DS, RMT-=0A= BB].=0A= =0A= This document provides a framework of Transport Session Management=0A= (TSM) mechanisms, which has been designed to support desirable=0A= management of end-to-end multicast sessions, according to the=0A= application's requirements that are represented as a set of TSM=0A= parameters including throughput and packet loss rate. TSM operations=0A= include Session Register, Session Monitoring and Session Maintenance.=0A= In Session Register, the sender informs authorized receivers about=0A= the target values of TSM parameters. In Session Monitoring, each=0A= receiver continues to measure the parameter values that have been=0A= experienced and to report the status of each parameter value to the=0A= sender. Based on the status information monitored and the target=0A= values of TSM parameters, the sender takes Session Maintenance=0A= actions necessary to maintain the session status desirable. Those=0A= actions include adjustment of data transmission rate, troublemaker=0A= ejection, session pause/resume, and session termination.=0A= =0A= The key feature of TSM is to provide the senders with information on=0A= membership tracking and current session status in terms of TSM=0A= parameters. Membership information is crucial for design of=0A= billing/charging model. Session status needs to be monitored to=0A= maintain the session desirable.=0A= =0A= TSM is a coarsely grained functionality for end-to-end multicast=0A= transport, and thus can be considered as a Building Block of RMT.=0A= TSM mechanisms can be implemented into an API and easily adopted by=0A= any RMT PIs that wish to tightly control multicast sessions.=0A= =0A= 1.1 Terminology=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in RFC 2119 [RFC2119].=0A= =0A= =0A= =0A= =0A= =0A= =0A= Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 2]=0A= =0C=0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT Expires: August 2001 February 2001=0A= =0A= =0A= Transport Session=0A= =0A= Transport Session refers to a session for multicast data delivery.=0A= In a one-to-many multicast session, there are a single sender and=0A= many receivers.=0A= =0A= Transport Session Management (TSM)=0A= =0A= TSM functionality is provided to maintain a multicast session=0A= desirable, according to application's requirements. TSM mechanisms=0A= can be implemented into an API that a multicast transport protocol=0A= adopts easily.=0A= =0A= TSM Parameters=0A= =0A= A TSM parameter is a performance metric that represents session=0A= status and Quality of Services for the multicast data delivery.=0A= Typical examples of TSM parameters include throughput and packet loss=0A= rate. According to application's requirements, the sender may=0A= configure a set of target values of each TSM parameter for desirable=0A= display of application data. For Session Monitoring, each receiver=0A= reports the experienced status for each TSM parameter to the sender.=0A= =0A= 1.2 Motivations for TSM=0A= =0A= Some multicast applications have a crucial need to guarantee a=0A= desired Quality of Service (QoS) in the delivery of multicast data.=0A= In principal, the QoS for data delivery can be supported with help of=0A= network-layer resource reservation mechanisms such as RSVP or=0A= Diffserv. However, in the end-to-end transport level, the sender=0A= needs to monitor and manage how much desirably the QoS for a=0A= multicast session is being supported [ECTS, ECTP].=0A= =0A= TSM functionality is designed to support a tight control of multicast=0A= sessions. TSM mechanisms can be used to maintain the transport=0A= session desirable according to the application's requirements, and=0A= also to protect the session status from being degraded more severely.=0A= =0A= 1.3 Rationale of TSM BB=0A= =0A= Per the guidelines of RMT BB draft [RMT-Author], this section will be=0A= filled.=0A= =0A= 1.4 Applicability Statement=0A= =0A= Per the guidelines of RMT BB draft [RMT-Author], this section will be=0A= filled.=0A= =0A= =0A= =0A= =0A= Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 3]=0A= =0C=0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT Expires: August 2001 February 2001=0A= =0A= =0A= 2. TSM Overview=0A= =0A= Transport Session Management (TSM) is designed to support a tight=0A= control of multicast sessions. TSM functionality is accomplished by=0A= interactions between the sender and receivers. In TSM, the sender is=0A= responsible for overall TSM operations.=0A= =0A= Figure 1 illustrates an overall TSM functionality during a multicast=0A= session.=0A= =0A= =0A= =0A= +--------------------------------------------------------------+=0A= | |=0A= | +-------------+ +--------------+ |=0A= | | Data Rate | +-------------+ | Session | |=0A= | | Adjustment |<--- | Session | ---> | Pause/Resume | |=0A= | +-------------+ | Monitoring | +--------------+ |=0A= | | with | |=0A= | +-------------+ | Membership | +--------------+ |=0A= | |Troublemaker |<--- | Tracking | ---> | Session | |=0A= | | Ejection | +-------------+ | Termination | |=0A= | +-------------+ ^ +--------------+ |=0A= | | |=0A= +------------------------------+-------------------------------+=0A= ^ | ^=0A= | | |=0A= -----------+---------------------+-------------------+--------------=0A= | | | TSM API=0A= v | v=0A= +---------+ | +-----------+=0A= | | | | |=0A= | Sender = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D>| Receivers |=0A= | | Multicast Data | |=0A= +---------+ +-----------+=0A= =0A= Figure 1. TSM Overview=0A= =0A= =0A= TSM functionality is achieved by the following operations:=0A= (a) Session Register=0A= (b) Session Monitoring=0A= (c) Session Maintenance=0A= =0A= In Session Register, the following two events occur:=0A= - Register Request by a receiver=0A= - Register Confirm by the sender=0A= =0A= =0A= =0A= =0A= Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 4]=0A= =0C=0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT Expires: August 2001 February 2001=0A= =0A= =0A= Each receiver who wants to participate in the session sends a=0A= Register Request message to the sender. The sender may make a=0A= decision whether the Register request should be accepted or not,=0A= possibly along with an authentication process. When the Register=0A= request is accepted, the sender will sends a Register Confirm message=0A= that contains information on the target values of TSM parameters such=0A= as throughput and packet loss rate.=0A= =0A= Session Monitoring is used for sender to diagnose current session=0A= status for multicast data delivery. Session Monitoring also performs=0A= 'Membership Tracking', by which the sender keeps track of the list of=0A= active receivers.=0A= =0A= For Session Monitoring, each receiver is required to measure a status=0A= value for each TSM parameter that has been experienced for the=0A= received multicast data streams. If a status value indicates an=0A= abnormal status, the receiver reports the status value to the sender=0A= via a TSM Response message.=0A= =0A= TSM Response messages are also generated in response to the periodic=0A= TSM Request messages of the sender. Through these interactions with=0A= receivers, the sender can perform the membership tracking.=0A= =0A= Session Maintenance is performed based on the reported status values=0A= and the target values for TSM parameters. Sender continues to=0A= aggregate the status values that have been reported from the=0A= receivers. Based on the aggregated information, the sender will take=0A= one or more of the following Session Maintenance actions:=0A= - Adjustment of data transmission rate=0A= - Troublemaker ejection=0A= - Session pause/resume=0A= - Session termination=0A= =0A= TSM Request messages are also used to indicate a current session=0A= status, which is classified into one of the following:=0A= - Session Creation=0A= - Data Transmission=0A= - Session Pause=0A= - Session Termination=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 5]=0A= =0C=0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT Expires: August 2001 February 2001=0A= =0A= =0A= 3. TSM Components=0A= =0A= 3.1 Sender=0A= =0A= Sender transmits multicast data to the receivers in the session. It=0A= is responsible for the overall TSM operations.=0A= =0A= 3.2 Receiver=0A= =0A= A receiver receives multicast data from the sender. TSM is based on=0A= interaction between sender and receivers.=0A= =0A= 3.3 TSM Parameters=0A= =0A= TSM parameters are used to diagnose a current session status. This=0A= document specifies two TSM parameters: throughput and packet loss=0A= rate. In the future, more TSM parameters may be added, if necessary.=0A= =0A= Throughput (THRUPUT) can be represented in units of bytes per second.=0A= THRUPUT can be interpreted as data transmission rate at the sender=0A= side and also data reception rate at receiver side. Packet loss rate=0A= (PLR) is defined as the ratio of lost packets over totally=0A= transmitted packets. PLR may be represented as an integer number=0A= ranged from 0 to 100. The sequence numbers of data packets can be=0A= used to measure the packet loss rate.=0A= =0A= In Session Register, the sender announces the authorized receiver=0A= about the pre-configured target values for each TSM parameter such as=0A= - MIN: a minimum value=0A= - ALLOWED_LOW: an allowed low value=0A= - ALLOWED_HIGH: an allowed high value=0A= - MAX: a maximum value=0A= =0A= These target values MAY be determined by considering application's=0A= requirements. Among those values, the following inequalities are=0A= enforced:=0A= =0A= MIN <=3D ALLOWED_LOW <=3D ALLOWED_HIGH <=3D MAX=0A= =0A= For THRUPUT parameter, the following variables can be defined:=0A= - MIN_THRUPUT=0A= - ALLOWED_LOW_THRUPUT=0A= - ALLOWED_HIGH_THRUPUT=0A= - MAX_THRUPUT=0A= =0A= For PLR parameter, the following variables can be defined:=0A= - MIN_PLR=0A= - ALLOWED_LOW_PLR=0A= =0A= =0A= =0A= Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 6]=0A= =0C=0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT Expires: August 2001 February 2001=0A= =0A= =0A= - ALLOWED_HIGH_PLR=0A= - MAX_PLR=0A= =0A= In Session Monitoring, each receiver is required to measure the=0A= parameter values experienced for the received multicast data. By=0A= comparing the measured values and the target values, the receiver=0A= sets each of THRUPUT_STATUS and PLR_STATUS to an integer of '0=0A= through 4' as follows:=0A= =0A= 0, if ALLOWED_LOW <=3D measured value <=3D ALLOWED_HIGH=0A= 1, if MIN <=3D measured value <=3D ALLOWED_LOW=0A= 2, if ALLOWED_HIGH <=3D measured value <=3D MAX=0A= 3, if measured value <=3D MIN=0A= 4, if MAX <=3D measured value=0A= =0A= The STATUS value of '0' represents a normal status, while the non-=0A= zero values mean that the session possibly goes into abnormal status=0A= (1 or 2), or is currently being in an abnormal status (3 or 4).=0A= =0A= In Session Monitoring, receivers report those STATUS values to the=0A= sender via TSM Response messages.=0A= =0A= 3.4 TSM Messages=0A= =0A= The following control messages are used for TSM:=0A= - Register Request=0A= - Register Confirm=0A= - Ejection=0A= - TSM Request=0A= - TSM Response=0A= =0A= Table 1 summarizes the detailed use of those TSM messages.=0A= =0A= 3.4.1 Register Request=0A= =0A= A receiver that wishes to register the session sends a Register=0A= Request to the sender.=0A= =0A= 3.4.2 Register Confirm=0A= =0A= The sender responds with a Register Confirm message to the Register=0A= Request. The Register Confirm message contains the following=0A= information:=0A= - Whether a Register Request is accepted or not=0A= - Target values for TSM parameters: MIN, ALLOWED_LOW, ALLOWED_MAX,=0A= MAX=0A= - Receiver ID for the corresponding receiver=0A= =0A= =0A= =0A= =0A= Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 7]=0A= =0C=0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT Expires: August 2001 February 2001=0A= =0A= =0A= The receiver ID can be used for membership tracking, and also used in=0A= generation of a TSM Response message (see Section 5).=0A= =0A= Table 1. TSM messages=0A= =0A= +------------------+------+-----+-----------+---------------------+=0A= | Message | From | To | Unicast/ | TSM Operation |=0A= | Types | | | Multicast | Concerned |=0A= +------------------+------+-----+-----------+---------------------+=0A= | Register Request | R | S | Unicast | Session Register |=0A= +------------------+------+-----+-----------+---------------------+=0A= | Register Confirm | S | R | Unicast | Session Register |=0A= +------------------+------+-----+-----------+---------------------+=0A= | Ejection | S | R | Unicast | Session Maintenance |=0A= +------------------+------+-----+-----------+---------------------+=0A= | TSM Request | S | Rs | Multicast | Session Monitoring |=0A= +------------------+------+-----+-----------+---------------------+=0A= | TSM Response | R | S | Unicast | Session Monitoring |=0A= +------------------+------+-----+-----------+---------------------+=0A= S: Sender, R : Receiver=0A= =0A= =0A= =0A= 3.4.3 Ejection=0A= =0A= In Session Maintenance, the sender MAY eject the trouble-making=0A= receiver by sending an Ejection message.=0A= =0A= =0A= =0A= 3.4.4 TSM Request=0A= =0A= The sender transmits periodic TSM Request messages to the receivers.=0A= The length of periodic time interval MAY vary depending on=0A= implementations.=0A= =0A= Each TSM Request message triggers the corresponding TSM Response=0A= messages from some or all of the receivers. The TSM Request message=0A= contains an integer value to indicate the current session status. To=0A= do this, the current session status is classified into one of the=0A= following phases, with an integer value:=0A= - Session Creation (0)=0A= - Data Transmission (1)=0A= - Session Pause (2)=0A= - Session Termination (3)=0A= =0A= When a session starts, the sender indicates 'Session Creation'. If=0A= TSM BB is used in TRACK PI, 'Session Creation' state can be used as=0A= =0A= =0A= =0A= Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 8]=0A= =0C=0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT Expires: August 2001 February 2001=0A= =0A= =0A= an indication signal for an initial tree configuration [TREE]. After=0A= a session is created, the TSM Request messages will indicate 'Data=0A= Transmission'. 'Session Pause' will be indicated if a sender=0A= realizes that the session potentially goes into an abnormal status.=0A= In Session Pause period, the sender is not allowed to send any new=0A= multicast data. When the session status is perceived to go back to a=0A= normal status, the sender will again indicate 'Data Transmission',=0A= and then resumes the multicast data transmission. 'Session=0A= Termination' is indicated after the sender transmits all the=0A= multicast data, or if the session is detected to be in the severe=0A= abnormal status.=0A= =0A= =0A= 3.4.5 TSM Response=0A= =0A= A TSM Response messages contain the following information:=0A= - Receiver ID=0A= - THRUPUT_STATUS (ranged from 0 - 4)=0A= - PLR_STATUS (ranged from 0 - 4)=0A= =0A= Each receiver generates a TSM message if its measured THRUPUT_STATUS=0A= or PLR_STATUS is a non-zero value. TSM messages can also be=0A= generated in response to a periodic TSM Request message.=0A= =0A= =0A= =0A= 4. TSM Procedures=0A= =0A= 4.1 Session Register=0A= =0A= A receiver who wants to register a session sends a Register Request=0A= message to the sender. When the sender receives a Register Request=0A= message, it MAY check whether the receiver is an authorized user or=0A= not.=0A= =0A= In response to a Register Request, the sender transmits a Register=0A= Confirm message to the receiver. The Register Confirm message=0A= contains information on Receiver ID and whether the Register Request=0A= is accepted or not. The Register Confirm message also contains the=0A= pre-configured target values of TSM parameters: MIN, ALLOWED_LOW,=0A= ALLOWED_HIGH, and MAX (see 3.3).=0A= =0A= In the networks that support resource reservation mechanisms such as=0A= RSVP and Diffserv, the receiver SHALL initiate the reservation of the=0A= required network resources. Then the target parameter values MAY be=0A= referred to in the reservation process.=0A= =0A= =0A= =0A= =0A= =0A= Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 9]=0A= =0C=0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT Expires: August 2001 February 2001=0A= =0A= =0A= 4.2 Session Monitoring=0A= =0A= In Session Monitoring, the sender monitors how well the session=0A= operates and also which receivers are participating in the session.=0A= To do this, each receiver is required to measure the THRUPUT and PLR=0A= values experienced for the received multicast data. Those measured=0A= THRUPUT and PLR values are compared with the target values for=0A= THRUPUT and PLR announced in Session Register, and then the receiver=0A= determines THRUPUT_STATUS and PLR_STATUS values as 0, 1, 2, 3 or 4=0A= (see 3.3).=0A= =0A= If the STATUS value is a non-zero value, the receiver generates a TSM=0A= Response message. For the STATUS value of '0', the receiver does not=0A= need to generate a TSM Response message. In other words, the sender=0A= will realize that a receiver is in the normal status, if it does not=0A= send any TSM Response messages indicating an abnormal status, where=0A= an abnormal status indicates that the STATUS value is non-zero.=0A= =0A= TSM Response message is also generated responsively to a periodic TSM=0A= Request message. This feedback mechanism is designed to support=0A= Membership Tracking and an overall identification of the current=0A= session status.=0A= =0A= In response to the periodic TSM Request message, some or all of=0A= receivers send TSM Response messages to the sender. To reduce the=0A= number of simultaneous TSM Response messages from the receivers, a=0A= specific rule MAY be employed. An example is given in Section 5.=0A= =0A= During a session, the sender aggregates the reported THRUPUT_STATUS=0A= and PLR_STATUS values from the receivers. In the aggregation, the=0A= following considerations will be taken:=0A= - Which receivers are in the abnormal status ?=0A= - How many receivers in a given session are in the abnormal status ?=0A= =0A= Based on this aggregated information, the sender takes one or more=0A= Session Maintenance actions.=0A= =0A= 4.3. Session Maintenance=0A= =0A= Session Maintenance is purposed to maintain the session status=0A= desirable, and to prevent the session status from being degraded more=0A= severely.=0A= =0A= Based on the THRUPUT_STATUS and PLR_STATUS values reported from the=0A= receivers, the sender takes one or more of the following Session=0A= Maintenance actions:=0A= - Adjustment of data transmission rate=0A= - Ejection of Troublemaker=0A= =0A= =0A= =0A= Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 10]=0A= =0C=0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT Expires: August 2001 February 2001=0A= =0A= =0A= - Session Pause and Resume=0A= - Session Termination=0A= =0A= Depending on application services, some of the actions described=0A= above MAY NOT be enabled. For example, for a certain multicast=0A= session, the sender MAY NOT perform Troublemaker Ejection.=0A= =0A= 4.3.1 Adjustment of data transmission rate=0A= =0A= If this option is enabled, the sender will adjust data transmission=0A= rate based on the monitored STATUS values of the TSM parameters. The=0A= data transmission rate is bounded as follows:=0A= =0A= MIN_THRUPUT <=3D Data Transmission Rate <=3D MAX_THRUPUT=0A= =0A= Specific rules to increase or decrease the data transmission rate are=0A= for further study, which MAY depend on the Congestion Control=0A= algorithm that will be developed in the RMT WG.=0A= =0A= 4.3.2 Ejection of Troublemaker=0A= =0A= To determine whether a receiver is a troublemaker or not, the sender=0A= MUST configure a rule to trigger a Troublemaker Ejection. The=0A= specific rule is an implementation issue. For an example, a receiver=0A= can be regarded as a troublemaker if the STATUS values for TSM=0A= parameters have been consecutively in abnormal status more than the=0A= pre-configured threshold times.=0A= =0A= Once a troublemaker is detected, the sender sends an Ejection message=0A= to the concerned receiver.=0A= =0A= 4.3.3 Session Pause and Resume=0A= =0A= Session Pause is used to suspend the data transmission of the sender=0A= temporarily and thus to prevent the session from being more severely=0A= degraded.=0A= =0A= The sender announces 'Session Pause' to all the receivers via TSM=0A= Request message, which has the session status value of '2' (see=0A= 3.4.4). In the Session Pause period, the sender SHALL NOT send any=0A= new multicast data.=0A= =0A= The specific rule to trigger Session Pause can be configured based on=0A= the STATUS values reported from the receivers. For an example, if=0A= the number of receivers reporting an abnormal status is greater than=0A= a pre-configured number, then the sender MAY trigger Session Pause.=0A= =0A= After Session Pause is indicated, Session Resume will be activated if=0A= =0A= =0A= =0A= Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 11]=0A= =0C=0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT Expires: August 2001 February 2001=0A= =0A= =0A= the session status is perceived to come back into the normal state.=0A= The specific rule to trigger Session Resume is an implementation=0A= issue. A simple rule to trigger the Session Resume is to use a=0A= timer. In this case, if the timer expires after Session Pause is=0A= indicated, then the sender will automatically resume the session by=0A= sending a TSM Request message with an indication of 'Data=0A= Transmission' (see 3.4.4).=0A= =0A= 4.3.4 Session Termination=0A= =0A= The natural option for Session Termination is to terminate a session=0A= when all the multicast data have been transmitted. Session=0A= Termination is also triggered if the session is detected to be in the=0A= severe abnormal state. When Session Termination is indicated, the=0A= sender terminates the session and sends a TSM Request message with=0A= indication of Session Termination.=0A= =0A= The activation of Session Termination can be performed in various=0A= ways. One simple way is to trigger Session Termination if the=0A= Session Pause/Resume operations have been consecutively repeated more=0A= than a pre-configured times.=0A= =0A= =0A= =0A= 5. Scalability Enhancement for Feedback Implosions of TSM Response=0A= Messages=0A= =0A= Session Monitoring is based on the 'TSM Response' feedback messages=0A= from the receivers. For the session that consists of a large number=0A= of receivers, simultaneous responses of TSM Response messages may=0A= induce an implosion of feedback messages. This is referred to as the=0A= scalability problem.=0A= =0A= If a hierarchical control tree [TREE] is employed along with TSM BB,=0A= it is clear that we reduce the number of simultaneously generated TSM=0A= Response messages. In the tree hierarchy, each Repair Head=0A= aggregates TSM Response messages from its children, and then delivers=0A= the aggregated information toward the sender [TRACK].=0A= =0A= We also propose an alternate scheme to improve the feedback=0A= implosion, which has benefited from TRACK BB [TRACK]. For this=0A= purpose, we define the following two new variables:=0A= - TSM Sequence Number (TSN)=0A= - Response Generation Number (RGN)=0A= =0A= TSN is an integer number sequentially assigned to each periodic TSM=0A= Request massage. RGN is a scaling factor used to limit the number of=0A= the simultaneously responding receivers. These variables will be=0A= =0A= =0A= =0A= Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 12]=0A= =0C=0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT Expires: August 2001 February 2001=0A= =0A= =0A= contained in the periodic TSM Request message, if they are enabled=0A= for scalability enhancement.=0A= =0A= For a TSM Request message, each receiver responds with a TSM Response=0A= message, if the following condition holds true:=0A= =0A= (TSN % RGN) =3D=3D (Receiver ID % RGN),=0A= =0A= where % represents "modulo" operator.=0A= =0A= For an example, suppose there are receivers with Receiver ID =3D=0A= 1,..,20. In response to a TSM Request message with TSN =3D 3 and RGN = =3D=0A= 5, the receivers with Receiver ID =3D 3, 8, 13, 18 will transmit the=0A= corresponding TSM Response message.=0A= =0A= =0A= =0A= 6. Relationship with the other BBs and PIs=0A= =0A= TSM BB does not impose any requirements and modifications on existing=0A= RMT BBs. The TSM functionality and its mechanisms can be easily=0A= adopted by any RMT PIs that wish a tight control of multicast=0A= session.=0A= =0A= We note that TSM mechanisms are primarily based on feedbacks from the=0A= receivers, 'TSM Response' messages. TSM BB is a good-match with=0A= TRACK PI, in the viewpoint of scalability enhancement of feedback=0A= messages from receivers to sender.=0A= =0A= In NORM PI, the NACK messages can also be used to deliver TSM=0A= Response messages from receivers to the sender. In this case, we MAY=0A= configure that a NACK message will be generated at a receiver, if a=0A= measured parameter value indicates an abnormal status. In addition,=0A= if NORM PI wishes to support Membership Tracking, the periodic=0A= exchanges of TSM Request messages with TSM Response messages need to=0A= be specified in the PI. In this case, we will prefer a larger=0A= periodic time interval between consecutive TSM Requeste messages and=0A= a more conservative mechanism for generation of TSM response=0A= messages.=0A= =0A= If the FEC-based LCT PI wants to support TSM BB, we need to define an=0A= out-of-band control channel for TSM Response messages from receivers=0A= to sender. The well-known RTP/RTCP scheme is an example scenario to=0A= use TSM BB in the LCT PI, where RTCP messages will be used to deliver=0A= TSM Response messages. A more specific scheme is for further study.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 13]=0A= =0C=0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT Expires: August 2001 February 2001=0A= =0A= =0A= 7. Security Considerations=0A= =0A= The Register Confirm messages MAY be used to deliver the group key=0A= information to the receivers for security purposes, if necessary. In=0A= this case, an initial group key will be distributed via the Register=0A= Confirm message, and the changed group key information via the=0A= subsequent TSM Request messages.=0A= =0A= =0A= =0A= 8. References=0A= =0A= [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119, Mar. 1997.=0A= =0A= [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",=0A= BCP 9, RFC 2026, Oct. 1996.=0A= =0A= [RMT-DS] M. Handley, et al., "The Reliable Multicast Design Space for=0A= Bulk Data Transfer", RFC 2887, Aug. 2000.=0A= =0A= [RMT-BB] B. Whetton, et al., "Reliable Multicast Transport Building=0A= Blocks for One-to-Many Bulk Data Transfer", RFC 3048, Jan. 2001.=0A= =0A= [RMT-Author] R. Kermode and L. Vicisano, "Author Guidelines for RMT=0A= Building Blocks and Protocol Instantiation documents", draft-ietf-=0A= rmt-author-guidelines-00.txt, Jun. 2000.=0A= =0A= [SAP] M. Handley, et al., "Session Announcement Protocol", RFC 2974,=0A= Oct. 2000.=0A= =0A= [TRACK] B. Whetton, et al., "Reliable Multicast Transport Building=0A= Block for TRACK", Feb. 2001.=0A= =0A= [TREE] M. Kadansky, et al., "Reliable Multicast Transport Building=0A= Block: Tree Auto-Configuration", Nov. 2000.=0A= =0A= [NORM] C. Bormann, et al., "NACK-Oriented Reliable Multicast (NORM)=0A= Protocol Building Blocks", Jan. 2001.=0A= =0A= [LCT] M.Luby, et al., "Layered Coding Transport: A massively scalable=0A= multicast protocol", Nov. 2000.=0A= =0A= [ECTS] ITU-T Recommendation X.605 and ISO/IEC 13252, "Enhanced=0A= Communication Transport Services", 1999.=0A= =0A= [ECTP] ITU-T Draft Recommendation X.ectp and ISO/IEC JTC1/SC6 CD=0A= 14476, "Enhanced Communications Transport Protocol", Work in=0A= =0A= =0A= =0A= Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 14]=0A= =0C=0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT Expires: August 2001 February 2001=0A= =0A= =0A= Progress, Feb. 2001.=0A= =0A= =0A= =0A= 9. Acknowledgments=0A= =0A= This document is the result of the joint development work on Enhanced=0A= Communications Transport Protocol (ECTP) which is being undertaken by=0A= ISO/IEC JTC 1/SC 6 and ITU-T/SG 7. Transmission to the IETF was=0A= endorsed at the joint ITU-T/SG 7 and by ISO/IEC JTC 1/SC 6 meeting on=0A= 31th Jan. 2001.=0A= =0A= We would like to give special thanks to the following individuals.=0A= Miriam Kadansky, Sun Microsystems=0A= Dah Ming Chiu, Sun Microsystems=0A= Jim Long, UK=0A= Jack Houldsworth, UK=0A= Dae Young Kim, KOREA=0A= Hyun Kook Kahng, KOREA=0A= =0A= =0A= =0A= 10. Author's Addresses=0A= =0A= Seok Joo Koh=0A= sjkoh@pec.etri.re.kr=0A= Shin Gak Kang=0A= sgkang@etri.re.kr=0A= Juyoung Park=0A= jypark@ccl.cnu.ac.kr=0A= Eun Sook Kim=0A= eunsook@cs.sookmyung.ac.kr=0A= =0A= Protocol Engineering Center=0A= Electronics Telecommunications Research Institute=0A= Kajong-Dong, Yusung-Gu, Taejon, 305-350, Korea=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 15]=0A= =0C=0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT Expires: August 2001 February 2001=0A= =0A= =0A= Full Copyright Statement=0A= =0A= "Copyright (C) The Internet Society (2000). All Rights Reserved. = This=0A= document and translations of it may be copied and furnished to = others, and=0A= derivative works that comment on or otherwise explain it or assist in = its=0A= implementation may be prepared, copied, published and distributed, in = whole=0A= or in part, without restriction of any kind, provided that the above=0A= copyright notice and this paragraph are included on all such copies = and=0A= derivative works. However, this document itself may not be modified = in any=0A= way, such as by removing the copyright notice or references to the = Internet=0A= Society or other Internet organizations, except as needed for the = purpose of=0A= developing Internet standards in which case the procedures for = copyrights=0A= defined in the Internet Standards process must be followed, or as = required=0A= to translate it into languages other than English.=0A= =0A= The limited permissions granted above are perpetual and will not be=0A= revoked by the Internet Society or its successors or assigns.=0A= =0A= This document and the information contained herein is provided on an = "AS IS"=0A= basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE=0A= DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT = LIMITED TO=0A= ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE = ANY=0A= RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A=0A= PARTICULAR PURPOSE."=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 16]=0A= =0C=0A= =0A= =0A= ------=_NextPart_000_001E_01C0AEEE.401D85E0-- >From owner-rmt@listserv.lbl.gov Sat Mar 17 22:54:21 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2I6qMA03132; Sat, 17 Mar 2001 22:52: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.11.2/8.11.2) with ESMTP id f2I6qKn03128 for ; Sat, 17 Mar 2001 22:52:20 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2I6qJh00975 for ; Sat, 17 Mar 2001 22:52:19 -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.11.2/8.11.2) with ESMTP id f2I6qIE00972 for ; Sat, 17 Mar 2001 22:52:18 -0800 (PST) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [10.34.54.43]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id WAA04853; Sat, 17 Mar 2001 22:52:13 -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 WAA21625; Sat, 17 Mar 2001 22:52:13 -0800 (PST) Message-Id: <200103180652.WAA21625@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: "Seok Joo Koh" cc: rmt@lbl.gov Subject: Re: draft-koh-rmt-bb-tsm-01.txt In-Reply-To: Your message of "Sat, 17 Mar 2001 14:26:26 +0900." <002101c0aea2$d089ca40$2ea4fe81@etri.re.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 17 Mar 2001 22:52:13 -0800 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk When I listed this in the agenda I did not notice that draft-koh-rmt-bb-tsm-01.txt had missed the submission deadline, hence it cannot be discussed at the meeting. However draft-koh-rmt-bb-tsm-00.txt can be discussed as it met the February deadline for initial submission. Please let me know if this is fine. Lorenzo > Dear all, > > Please see the attached TSM draft, which is going to be discussed in this > RMT meeting. > It can also be obtained from > http://pec.etri.re.kr/~sjkoh/draft-koh-rmt-bb-tsm-01.txt > > Best Regards, > > Seok Joo Koh >From owner-rmt@listserv.lbl.gov Sat Mar 17 23:30:47 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2I7Ud103200; Sat, 17 Mar 2001 23:30: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.11.2/8.11.2) with ESMTP id f2I7Ucn03196 for ; Sat, 17 Mar 2001 23:30:38 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2I7UUl03031 for ; Sat, 17 Mar 2001 23:30:31 -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.11.2/8.11.2) with ESMTP id f2I7URE02977 for ; Sat, 17 Mar 2001 23:30:28 -0800 (PST) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [10.34.54.43]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id XAA23896; Sat, 17 Mar 2001 23:29:35 -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 XAA21693; Sat, 17 Mar 2001 23:29:14 -0800 (PST) Message-Id: <200103180729.XAA21693@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 cc: sob@harvard.edu, mankin@east.isi.edu, ark008@email.mot.com, lorenzo@cisco.com Subject: RMT agenda, 50th IETF Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 17 Mar 2001 23:29:14 -0800 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk this is what the agenda looks like so far. Agenda Bashing 5 mins Kermode/Vicisano Updates on draft-ietf-rmt-author-guidelines-01.txt 5 mins Kermode/Vicisano ALC PI, status of the work 5 mins Luby Updates to the TRACK BB and Tree BB 20 mins Kadansky A New TRACK PI draft 30 mins Whetten draft-ietf-rmt-bb-pgmcc-00.txt, CC proposal for NORM 15 mins Vicisano draft-koh-rmt-bb-tsm-00.txt 10 mins Kang The chairs would like to remind all the speakers that they should not give a technical presentation on the full content of the drafts, but they should assume that the attendees have read them. As for draft-koh-rmt-bb-tsm-00.txt, given that this was not posted as WG draft we suggest the speaker to give a very short (5 mins) overview and defer further discussion to the mailing list to give people the chance to read the draft. thanks, Lorenzo >From owner-rmt@listserv.lbl.gov Mon Mar 19 06:40:41 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2JEbcY06796; Mon, 19 Mar 2001 06:37:38 -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.11.2/8.11.2) with ESMTP id f2JEban06792 for ; Mon, 19 Mar 2001 06:37:36 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2JEbZb24239 for ; Mon, 19 Mar 2001 06:37:35 -0800 (PST) Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2JEbYE24236 for ; Mon, 19 Mar 2001 06:37:34 -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 JAA24483; Mon, 19 Mar 2001 09:37:19 -0500 (EST) Mime-Version: 1.0 X-Sender: adamson@pop.itd.nrl.navy.mil Message-Id: In-Reply-To: <200103180729.XAA21693@lorenzo-u10.cisco.com> References: <200103180729.XAA21693@lorenzo-u10.cisco.com> Date: Mon, 19 Mar 2001 09:37:20 -0500 To: Lorenzo Vicisano From: Brian Adamson Subject: Re: RMT agenda, 50th IETF Cc: rmt@lbl.gov, sob@harvard.edu, mankin@east.isi.edu, ark008@email.mot.com, lorenzo@cisco.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-rmt@lbl.gov Precedence: bulk I will be happy provide an overview of the updates to the NORM PI document also, if there is a slot available. At 11:29 PM -0800 3/17/01, Lorenzo Vicisano wrote: >this is what the agenda looks like so far. > > Agenda Bashing 5 mins > Kermode/Vicisano > Updates on draft-ietf-rmt-author-guidelines-01.txt 5 mins > Kermode/Vicisano > ALC PI, status of the work 5 mins > Luby > Updates to the TRACK BB and Tree BB 20 mins > Kadansky > A New TRACK PI draft 30 mins > Whetten > draft-ietf-rmt-bb-pgmcc-00.txt, CC proposal for NORM 15 mins > Vicisano > draft-koh-rmt-bb-tsm-00.txt 10 mins > Kang > >The chairs would like to remind all the speakers that they should not >give a technical presentation on the full content of the drafts, but they >should assume that the attendees have read them. > >As for draft-koh-rmt-bb-tsm-00.txt, given that this was not posted as >WG draft we suggest the speaker to give a very short (5 mins) overview >and defer further discussion to the mailing list to give people the >chance to read the draft. > > thanks, > Lorenzo -- Brian __________________________________ Brian Adamson >From owner-rmt@listserv.lbl.gov Mon Mar 19 08:00:34 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2JFxvS07223; Mon, 19 Mar 2001 07:59:58 -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.11.2/8.11.2) with ESMTP id f2JFxun07219 for ; Mon, 19 Mar 2001 07:59:56 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2JFxsS09866 for ; Mon, 19 Mar 2001 07:59:54 -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.11.2/8.11.2) with ESMTP id f2JFxrE09852 for ; Mon, 19 Mar 2001 07:59:53 -0800 (PST) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [10.34.54.43]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA13794; Mon, 19 Mar 2001 07:58:41 -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 HAA22807; Mon, 19 Mar 2001 07:58:40 -0800 (PST) Message-Id: <200103191558.HAA22807@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: Brian Adamson cc: rmt@lbl.gov, sob@harvard.edu, mankin@east.isi.edu, ark008@email.mot.com Subject: Re: RMT agenda, 50th IETF In-Reply-To: Your message of "Mon, 19 Mar 2001 09:37:20 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Mar 2001 07:58:40 -0800 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk Brian, I'll add a short (5/10 mins or you need more ?) slot to the agenda. thanks, Lorenzo > I will be happy provide an overview of the updates to the NORM PI > document also, if there is a slot available. > > At 11:29 PM -0800 3/17/01, Lorenzo Vicisano wrote: > >this is what the agenda looks like so far. > > > > Agenda Bashing 5 mins > > Kermode/Vicisano > > Updates on draft-ietf-rmt-author-guidelines-01.txt 5 mins > > Kermode/Vicisano > > ALC PI, status of the work 5 mins > > Luby > > Updates to the TRACK BB and Tree BB 20 mins > > Kadansky > > A New TRACK PI draft 30 mins > > Whetten > > draft-ietf-rmt-bb-pgmcc-00.txt, CC proposal for NORM 15 mins > > Vicisano > > draft-koh-rmt-bb-tsm-00.txt 10 mins > > Kang > > > >The chairs would like to remind all the speakers that they should not > >give a technical presentation on the full content of the drafts, but they > >should assume that the attendees have read them. > > > >As for draft-koh-rmt-bb-tsm-00.txt, given that this was not posted as > >WG draft we suggest the speaker to give a very short (5 mins) overview > >and defer further discussion to the mailing list to give people the > >chance to read the draft. > > > > thanks, > > Lorenzo > > -- > Brian > __________________________________ > Brian Adamson > > >From owner-rmt@listserv.lbl.gov Fri Mar 23 07:45:11 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2NFekU02633; Fri, 23 Mar 2001 07:40: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.11.2/8.11.2) with ESMTP id f2NFeic02629 for ; Fri, 23 Mar 2001 07:40:44 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2NFehK29650 for ; Fri, 23 Mar 2001 07:40:43 -0800 (PST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2NFeg429643 for ; Fri, 23 Mar 2001 07:40:43 -0800 (PST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA08757; Fri, 23 Mar 2001 08:35:26 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id IAA28577; Fri, 23 Mar 2001 08:40:39 -0700 (MST)] Received: from arc.corp.mot.com ([10.238.2.81]) by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id f2NFead13739; Sat, 24 Mar 2001 02:40:37 +1100 (EST) Message-ID: <3ABB6E7F.88E6C101@arc.corp.mot.com> Date: Sat, 24 Mar 2001 02:40:47 +1100 From: Roger Kermode Organization: Motorola X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list CC: Lorenzo Vicisano Subject: raw minutes... Content-Type: multipart/mixed; boundary="------------61382CE69D227FE91A78AF8C" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------61382CE69D227FE91A78AF8C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Could the kind person who took the raw minutes for the second session please send them to Lorenzo and me, thanks, Roger --------------61382CE69D227FE91A78AF8C 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 org:Motorola Labs, Motorola Australia Research Centre;Communications and Networks Laboratory adr:;;Locked Bag 5028;Botany;NSW;1455;Australia version:2.1 email;internet:Roger.Kermode@motorola.com title:Prinicpal Research Engineer / Lab Manager fn:Roger Kermode end:vcard --------------61382CE69D227FE91A78AF8C-- >From owner-rmt@listserv.lbl.gov Fri Mar 23 09:31:10 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2NHUqM03586; Fri, 23 Mar 2001 09:30: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.11.2/8.11.2) with ESMTP id f2NHUpc03582 for ; Fri, 23 Mar 2001 09:30:51 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2NHUos03580 for ; Fri, 23 Mar 2001 09:30:50 -0800 (PST) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2NHUo403573 for ; Fri, 23 Mar 2001 09:30:50 -0800 (PST) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.10.0/8.10.0) id f2NHUo815420; Fri, 23 Mar 2001 09:30:50 -0800 (PST) Message-Id: <200103231730.f2NHUo815420@daffy.ee.lbl.gov> To: rmt@lbl.gov Subject: Administrative: cleanup of rmt@lbl.gov mailing list Date: Fri, 23 Mar 2001 09:30:49 PST From: Vern Paxson Sender: owner-rmt@lbl.gov Precedence: bulk FYI, the following usernames have been deleted due to repeated hard bounces: GK@dial.pipex.com dli@leland.Stanford.EDU husson@matra-ms2i.fr luciana.costa@cselt.it mike.frietman@icoe.att.com pjackson@qualcomm.com yanyu@scf-fs.usc.edu zhwang@dnrc.bell-labs.com - Vern >From owner-rmt@listserv.lbl.gov Sat Mar 24 01:39:14 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2O9YJ807260; Sat, 24 Mar 2001 01:34: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.11.2/8.11.2) with ESMTP id f2O9YIc07256 for ; Sat, 24 Mar 2001 01:34:18 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2O9YIk18441 for ; Sat, 24 Mar 2001 01:34:18 -0800 (PST) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2O9YHR18438 for ; Sat, 24 Mar 2001 01:34:17 -0800 (PST) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.10.0/8.10.0) id f2O9YHL17875; Sat, 24 Mar 2001 01:34:17 -0800 (PST) Message-Id: <200103240934.f2O9YHL17875@daffy.ee.lbl.gov> To: rmt@lbl.gov Subject: Administrative #2: more cleanup of rmt@lbl.gov mailing list Date: Sat, 24 Mar 2001 01:34:17 PST From: Vern Paxson Sender: owner-rmt@lbl.gov Precedence: bulk The following usernames have also been deleted due to hard bounces: bhagatdb@cs.purdue.edu koyk@cs.purdue.edu pbilling@nortelnetworks.com shawn.harris@wcom.com srikar@ipo.att.com - Vern >From owner-rmt@listserv.lbl.gov Wed Mar 28 19:10:04 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2T37rW10697; Wed, 28 Mar 2001 19:07: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.11.2/8.11.2) with ESMTP id f2T37qc10693 for ; Wed, 28 Mar 2001 19:07:52 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2T37p825481 for ; Wed, 28 Mar 2001 19:07:51 -0800 (PST) Received: from uni01du.unity.ncsu.edu (uni01du.unity.ncsu.edu [152.1.2.65]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2T37o125478 for ; Wed, 28 Mar 2001 19:07:51 -0800 (PST) Received: (from njshah@localhost) by uni01du.unity.ncsu.edu (8.8.4/EC02Jan97) id WAA20395; Wed, 28 Mar 2001 22:07:49 -0500 (EST) Date: Wed, 28 Mar 2001 22:07:49 -0500 (EST) From: Nipul Jayvant Shah To: Subject: security related concerns Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rmt@lbl.gov Precedence: bulk Hi! I am a graduate student at NC State. I wanted to know if the RMT WG has already conducted some research work related to the security issues of RMT, especially concerning the denial of service attacks. If so, could anyone suggest the related drafts? Regards, Nipul Shah NCSU, Raleigh, NC. >From owner-rmt@listserv.lbl.gov Thu Mar 29 03:14:04 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2TBDSX11333; Thu, 29 Mar 2001 03:13: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.11.2/8.11.2) with ESMTP id f2TBDRc11329 for ; Thu, 29 Mar 2001 03:13:27 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2TBDQD14629 for ; Thu, 29 Mar 2001 03:13:26 -0800 (PST) Received: from sm.luth.se (ny.sm.luth.se [130.240.3.1]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TBDP114626 for ; Thu, 29 Mar 2001 03:13:25 -0800 (PST) Received: from delta1.sm.luth.se (delta1.sm.luth.se [130.240.3.7]) by sm.luth.se (8.10.0/8.10.0) with ESMTP id f2TBDQM03983; Thu, 29 Mar 2001 13:13:26 +0200 (MET DST) Date: Thu, 29 Mar 2001 13:13:17 +0200 (MET DST) From: Jeremiah Scholl To: rmt@lbl.gov cc: Peter Parnes Subject: local recovery and NORM Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rmt@lbl.gov Precedence: bulk Can anyone out there give me information regarding the NORM protocol and local recovery mechanisms. Is there a plan to add local recovery to NORM before it is standardized? If so, which type of local recovery scheme (hop-scoped, group-scoped ect.) will most likley be a part of the protocol. Thanks! Jeremiah Scholl >From owner-rmt@listserv.lbl.gov Thu Mar 29 03:44:46 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2TBiUA11349; Thu, 29 Mar 2001 03:44:30 -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.11.2/8.11.2) with ESMTP id f2TBiSc11345 for ; Thu, 29 Mar 2001 03:44:28 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2TBiRg16357 for ; Thu, 29 Mar 2001 03:44:27 -0800 (PST) Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TBiQ116354 for ; Thu, 29 Mar 2001 03:44:26 -0800 (PST) Received: from cabo3 (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id f2TBiEG17078; Thu, 29 Mar 2001 13:44:14 +0200 (MEST) From: "Dr. Carsten Bormann" To: "Jeremiah Scholl" , Cc: "Peter Parnes" Subject: RE: local recovery and NORM Date: Thu, 29 Mar 2001 13:44:14 +0200 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Importance: Normal Sender: owner-rmt@lbl.gov Precedence: bulk Jeremiah, one of the main points of NORM is to be simple, so NORM-PI should probably not try to implement local recovery. The NORM building block will certainly allow for local receovery, though. Adding local recovery is probably most useful in cooperation with GRA, which still is in the process of solidifying. Gruesse, Carsten > -----Original Message----- > From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Jeremiah > Scholl > Sent: Thursday, March 29, 2001 13:13 > To: rmt@lbl.gov > Cc: Peter Parnes > Subject: local recovery and NORM > > > Can anyone out there give me information regarding the NORM protocol and > local recovery mechanisms. Is there a plan to add local recovery to NORM > before it is standardized? If so, which type of local recovery scheme > (hop-scoped, group-scoped ect.) will most likley be a part of the > protocol. > > Thanks! > > Jeremiah Scholl > >From owner-rmt@listserv.lbl.gov Thu Mar 29 05:47:39 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2TDlDw11516; Thu, 29 Mar 2001 05:47:13 -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.11.2/8.11.2) with ESMTP id f2TDl2c11512 for ; Thu, 29 Mar 2001 05:47:02 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2TDl1m28009 for ; Thu, 29 Mar 2001 05:47:01 -0800 (PST) Received: from moocow.zweknu.org (128-121-47-185.moocow.ncal.verio.net [128.121.47.185]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TDl0127999 for ; Thu, 29 Mar 2001 05:47:00 -0800 (PST) Received: from null.net (cabbie.zweknu.org [192.168.1.102]) by moocow.zweknu.org (Postfix) with ESMTP id AF2F0236F8; Thu, 29 Mar 2001 07:51:32 -0600 (CST) Message-ID: <3AC33CF9.E43FFCC4@null.net> Date: Thu, 29 Mar 2001 07:47:37 -0600 From: "Michael R. Eckhoff" X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-pre7 i686) X-Accept-Language: en MIME-Version: 1.0 To: rmt@lbl.gov Cc: michael_eckhoff@afcc.com Subject: Multicast Recovery with Loaded Links References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Greetings! I am new to this list, so please forgive me if I bring up topics that have already been discussed in great detail. Currently, I have over 150 multicast locations utilizing distance education software (including white board, audio, application sharing, etc.). Most of these locations utilize 256Kbps frame relay. Normally, all packets are delivered successfully, unless an unexpected TCP file transfer takes place. The main issues that I am finding with the "reliable transport protocol" that is being used with this application (lrmp) is that the recovery process tends to cause more problems than it is worth. Here is why: 1) If a station loses multicast packets, chances are, the entire location lost the packets. 2) It does no good to attempt local recovery on the local segment since everyone else probably lost it as well. 3) If a location loses multicast packets, chances are, the router dropped the packets due to bandwidth constraints. 4) Recovery on a loaded line will just cause more packets to be dropped. 5) If packets are not reliably recovered for, applications that expect to read a stream from their buffer will time out waiting for the recovery. I feel that any sort of multicast recovery should be done through TCP and to a single upstream source. How about this scenario: - Assumption is some sort of RTP header is placed in the multicast packet which includes a sequence number, a tag as to if this packet could be lost or MUST be recovered, and a timer value as to how soon this recovery should take place before a failure should be noted. - Utilize IGMP, or a similar protocol, to signal to the router that recovery of a sequence number is necessary. The client would signal on the group ID in which he lost the packet with a SEQUENCE_RECOVERY payload type. In the payload data, he would include the sequence number in which he is requesting. - Any clients in this group that may have also lost packets would set back off timers if they hear someone request their sequence. Much like standard IGMP operation. - The router would build an upstream TCP connection to it's RPF router towards the source. It would query the RPF router to see if it has the sequence number in its cache. If the RPF router does have the packet, it would pass it down the TCP stream - to "guarantee" delivery of the packet in the case that the line is still loaded - as to not cause the recovery cycle to perform multiple recovery requests. *Note: The router would only have one TCP stream to its upstream neighbor no matter how many packets are being recovered. Therefore, if all packets were lost to 5 clients at a remote location, there would still only be a max. of 1x retransmission on the line since the recovered packets would be multicast on the wire and only one station would attempt recovery for the entire group. So if a line was fully saturated, essentially, the multicast application would switch to a TCP tunnel and maintain connectivity. This TCP "tunnel" should stay established for X amount of time to keep from having to go through a setup/teardown procedure for every missed packet. It may also be convenient to create the tunnel if the bandwidth on the line crosses a specified limit. - If the RPF router does not have the sequence, it would perform the same process until ultimately the source could be contacted. This should never happen since the DR for the source should always have a stable cache if it is connected to the source through a reliable connection. - Once the router gets the sequence, it would cache it and multicast it out to its clients. This caching should be optional if the router is attached to a single ethernet interface to reduce memory requirements at the endpoints. - All clients requesting this sequence would clear it from their recovery list upon arrival. If they miss it, they would run through the process again, only retrieve it from their local routers cache. I think that a procedure such as this would allow for both reliable packet delivery, as well as a reliable recovery from missed packets, even under the constraints of a loaded line. -me Michael R. Eckhoff Sr. WAN Comm Analyst citigroup / The Associates >From owner-rmt@listserv.lbl.gov Thu Mar 29 06:03:13 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2TE37i12289; Thu, 29 Mar 2001 06:03:07 -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.11.2/8.11.2) with ESMTP id f2TE36c12285 for ; Thu, 29 Mar 2001 06:03:06 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2TE35i29715 for ; Thu, 29 Mar 2001 06:03:05 -0800 (PST) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TE34129709 for ; Thu, 29 Mar 2001 06:03:05 -0800 (PST) Received: from muddy.cs.ucsb.edu (muddy [128.111.49.130]) by letters.cs.ucsb.edu (8.9.3+Sun/8.9.3) with ESMTP id GAA00684; Thu, 29 Mar 2001 06:02:48 -0800 (PST) Received: by muddy.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4) id GAA07375 for ; Thu, 29 Mar 2001 06:02:49 -0800 (PST) Date: Thu, 29 Mar 2001 06:02:49 -0800 (PST) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <200103291402.GAA07375@muddy.cs.ucsb.edu> To: katia@cse.ucsc.edu Subject: Global Internet 2001 Deadline Extension Sender: owner-rmt@lbl.gov Precedence: bulk Due to the numerous requests, etc. etc. we are extending the deadline for Global Internet 2001 to April 8, 2001 at 11:59pm. Another note. The submissions length is five pages. Papers that are significantly over will NOT be reviewed. --------------- Sixth Global Internet Symposium in conjunction with Globecom 2001 San Antonio, Texas, USA November 25-29, 2001 http://www.cs.ucsb.edu/gi2001/ ------------------------------------------------------------------------ Call For Papers The sixth Global Internet Symposium will be held simultaneously and co-located with Globecom 2001. Therefore, all of the relevant dates, location, travel information are derived from the Globecom 2001 (http://www.globecom2001.com/) conference site. Symposium Topics Global Internet 2000 solicits technical papers on Internet-related topics. The Program Committee encourages papers submitted on experimental systems and emerging technologies. Also encouraged are original submissions describing promising work in progress, original speculations about the future of the Internet, and progressive position papers. Topics of interest include, but are not limited to: * Novel applications and new paradigms (telephony, streaming media, etc.) * Distributed Internet applications (file sharing, games, conferencing, etc.) * Service provisioning, monitoring, and management * Privacy and/or security issues * Charging and billing issues * Handling Internet dynamics/heterogeneity (by applications and/or network) * Routing (unicast, multicast, anycast, etc.) * Traffic measurement, analysis, modeling, and visualization * Flow management (fairness/sharing, differentiated services, etc.) * The Internet and mobility/mobile devices * Wireless device access and Internet gateways Important Dates Manuscript Submission: April 8, 2001 at 11:59pm PDT Acceptance Notification: July 31, 2001 Final Manuscript: September 31, 2000 Submission Instructions Please see the Global Internet Symposium WWW site at: http://www.cs.ucsb.edu/gi2001/ Technical Program Chairs Kevin Almeroth, UC-Santa Barbara (almeroth@cs.ucsb.edu) Katia Obraczka, UC-Santa Cruz (katia@cse.ucsc.edu) Program Committee See the WWW page. Sponsorship The Global Internet Symposium is sponsored by the IEEE Communications Society InternetTC. >From owner-rmt@listserv.lbl.gov Thu Mar 29 08:38:19 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2TGblM12629; Thu, 29 Mar 2001 08:37: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.11.2/8.11.2) with ESMTP id f2TGbjc12625 for ; Thu, 29 Mar 2001 08:37:45 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2TGbjd01340 for ; Thu, 29 Mar 2001 08:37:45 -0800 (PST) Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TGbh101332 for ; Thu, 29 Mar 2001 08:37:44 -0800 (PST) Received: from cabo3 (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id f2TGbbG02859; Thu, 29 Mar 2001 18:37:37 +0200 (MEST) From: "Dr. Carsten Bormann" To: "Michael R. Eckhoff" , Cc: Subject: RE: Multicast Recovery with Loaded Links Date: Thu, 29 Mar 2001 18:37:36 +0200 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3AC33CF9.E43FFCC4@null.net> Importance: Normal Sender: owner-rmt@lbl.gov Precedence: bulk > 4) Recovery on a loaded line will just cause more packets to be > dropped. This is exactly the reason why RFC2357 ("IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols") *requires* congestion control. Gruesse, Carsten >From owner-rmt@listserv.lbl.gov Thu Mar 29 13:59:36 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2TLx0114140; Thu, 29 Mar 2001 13:59: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.11.2/8.11.2) with ESMTP id f2TLwxc14136 for ; Thu, 29 Mar 2001 13:58:59 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2TLwwk08188 for ; Thu, 29 Mar 2001 13:58:58 -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.11.2/8.11.2) with ESMTP id f2TLww108185 for ; Thu, 29 Mar 2001 13:58:58 -0800 (PST) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [10.34.54.43]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA20530; Thu, 29 Mar 2001 13:58:53 -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 NAA00829; Thu, 29 Mar 2001 13:58:52 -0800 (PST) Message-Id: <200103292158.NAA00829@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: Nipul Jayvant Shah cc: rmt@lbl.gov Subject: Re: security related concerns In-Reply-To: Your message of "Wed, 28 Mar 2001 22:07:49 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Mar 2001 13:58:52 -0800 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk Nipul, There has been some discussion on this in the context of protocol instantiations and building blocks, however better places to ask this this question are smug@cs.umass.edu (secure multicast IRTF group) or msec@securemulticast.org (IETF group). Lorenzo In message , Nipul Jayvant Shah writes: > Hi! I am a graduate student at NC State. I wanted to know if the RMT WG > has already conducted some research work related to the security issues of > RMT, especially concerning the denial of service attacks. If so, could > anyone suggest the related drafts? > > Regards, > > Nipul Shah > NCSU, Raleigh, NC. >From owner-rmt@listserv.lbl.gov Thu Mar 29 14:07:45 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2TM7go14191; Thu, 29 Mar 2001 14:07:42 -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.11.2/8.11.2) with ESMTP id f2TM7ec14187 for ; Thu, 29 Mar 2001 14:07:41 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2TM7e011192 for ; Thu, 29 Mar 2001 14:07:40 -0800 (PST) Received: from dargo.talarian.com (talarian33-3.talarian.com [207.5.33.3]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TM7e111189 for ; Thu, 29 Mar 2001 14:07:40 -0800 (PST) Received: from moya.talarian.com (moya.talarian.com [10.4.10.8]) by dargo.talarian.com (Postfix) with ESMTP id 7CAC022B05; Thu, 29 Mar 2001 14:07:29 -0800 (PST) Received: from C1538898-B.talarian.com (unknown [10.7.1.241]) by moya.talarian.com (Postfix) with ESMTP id 3640D11A; Thu, 29 Mar 2001 14:07:23 -0800 (PST) Message-Id: <5.0.2.1.2.20010329115232.06ad2e90@mailhost.talarian.com> X-Sender: bwhetten@mailhost.talarian.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 29 Mar 2001 11:53:52 -0800 To: "Dr. Carsten Bormann" , "Jeremiah Scholl" , From: Brian Whetten Subject: RE: local recovery and NORM Cc: "Peter Parnes" In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_92387416==_.ALT" Sender: owner-rmt@lbl.gov Precedence: bulk --=====================_92387416==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed The other alternative for local recovery is to use TRACK, which will be hierarchical in nature, but will use a minimum of hard state, so that it keep much of the flexibility and fault resilience of NORM. TRACK primarily uses local multicast addresses for repairs. Brian At 01:44 PM 3/29/2001 +0200, Dr. Carsten Bormann wrote: >Jeremiah, > >one of the main points of NORM is to be simple, so NORM-PI should probably >not try to implement local recovery. >The NORM building block will certainly allow for local receovery, though. >Adding local recovery is probably most useful in cooperation with GRA, which >still is in the process of solidifying. > >Gruesse, Carsten > > > -----Original Message----- > > From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Jeremiah > > Scholl > > Sent: Thursday, March 29, 2001 13:13 > > To: rmt@lbl.gov > > Cc: Peter Parnes > > Subject: local recovery and NORM > > > > > > Can anyone out there give me information regarding the NORM protocol and > > local recovery mechanisms. Is there a plan to add local recovery to NORM > > before it is standardized? If so, which type of local recovery scheme > > (hop-scoped, group-scoped ect.) will most likley be a part of the > > protocol. > > > > Thanks! > > > > Jeremiah Scholl > > --=====================_92387416==_.ALT Content-Type: text/html; charset="us-ascii" The other alternative for local recovery is to use TRACK, which will be hierarchical in nature, but will use a minimum of hard state, so that it keep much of the flexibility and fault resilience of NORM.  TRACK primarily uses local multicast addresses for repairs.

Brian

At 01:44 PM 3/29/2001 +0200, Dr. Carsten Bormann wrote:

Jeremiah,

one of the main points of NORM is to be simple, so NORM-PI should probably
not try to implement local recovery.
The NORM building block will certainly allow for local receovery, though.
Adding local recovery is probably most useful in cooperation with GRA, which
still is in the process of solidifying.

Gruesse, Carsten

> -----Original Message-----
> From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Jeremiah
> Scholl
> Sent: Thursday, March 29, 2001 13:13
> To: rmt@lbl.gov
> Cc: Peter Parnes
> Subject: local recovery and NORM
>
>
> Can anyone out there give me information regarding the NORM protocol and
> local recovery mechanisms.  Is there a plan to add local recovery to NORM
> before it is standardized?  If so, which type of local recovery scheme
> (hop-scoped, group-scoped ect.) will most likley be a part of the
> protocol.
>
> Thanks!
>
> Jeremiah Scholl
>

--=====================_92387416==_.ALT-- >From owner-rmt@listserv.lbl.gov Thu Mar 29 14:48:49 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2TMmdK14299; Thu, 29 Mar 2001 14:48: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.11.2/8.11.2) with ESMTP id f2TMmcc14295 for ; Thu, 29 Mar 2001 14:48:38 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2TMmbH25794 for ; Thu, 29 Mar 2001 14:48:37 -0800 (PST) Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TMmb125791 for ; Thu, 29 Mar 2001 14:48:37 -0800 (PST) Received: from SEXTANT.itd.nrl.navy.mil (sextant.itd.nrl.navy.mil [132.250.92.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA11279; Thu, 29 Mar 2001 17:48:29 -0500 (EST) Message-Id: <5.0.1.4.2.20010329174312.01e043b0@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 29 Mar 2001 17:50:25 -0500 To: "Dr. Carsten Bormann" , "Jeremiah Scholl" , From: Joe Macker Subject: RE: local recovery and NORM Cc: "Peter Parnes" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rmt@lbl.gov Precedence: bulk Jeremiah, I agree with Carsten's observations on the PI. The NORM-PI to be well-suited for single-source multicast environments. The building block should not preclude its use. As mentioned, GRA and TRACK are both potential candidates for adding this. -Joe At 01:44 PM 3/29/2001 +0200, Dr. Carsten Bormann wrote: >Jeremiah, > >one of the main points of NORM is to be simple, so NORM-PI should probably >not try to implement local recovery. >The NORM building block will certainly allow for local receovery, though. >Adding local recovery is probably most useful in cooperation with GRA, which >still is in the process of solidifying. > >Gruesse, Carsten > > > -----Original Message----- > > From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Jeremiah > > Scholl > > Sent: Thursday, March 29, 2001 13:13 > > To: rmt@lbl.gov > > Cc: Peter Parnes > > Subject: local recovery and NORM > > > > > > Can anyone out there give me information regarding the NORM protocol and > > local recovery mechanisms. Is there a plan to add local recovery to NORM > > before it is standardized? If so, which type of local recovery scheme > > (hop-scoped, group-scoped ect.) will most likley be a part of the > > protocol. > > > > Thanks! > > > > Jeremiah Scholl > > >From owner-rmt@listserv.lbl.gov Thu Mar 29 15:23:13 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f2TNMpP14372; Thu, 29 Mar 2001 15:22:51 -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.11.2/8.11.2) with ESMTP id f2TNMnc14368 for ; Thu, 29 Mar 2001 15:22:49 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2TNMmN07598 for ; Thu, 29 Mar 2001 15:22:48 -0800 (PST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TNMl107589 for ; Thu, 29 Mar 2001 15:22:48 -0800 (PST) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 29 Mar 2001 17:49:12 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HS2D2ZQY; Thu, 29 Mar 2001 17:49:12 -0500 Received: from hardjono.nortelnetworks.com (dhcp137-148.engeast.baynetworks.com [192.32.137.148]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GPSTFA0T; Thu, 29 Mar 2001 17:49:11 -0500 Message-Id: <4.3.1.2.20010329175512.01a7a210@ZBL6C002.corpeast.baynetworks.com> X-Sender: hardjono@ZBL6C002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 29 Mar 2001 17:58:07 -0500 To: Lorenzo Vicisano , Nipul Jayvant Shah From: "Thomas Hardjono" Subject: Re: security related concerns Cc: rmt@lbl.gov In-Reply-To: <200103292158.NAA00829@lorenzo-u10.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Orig: Sender: owner-rmt@lbl.gov Precedence: bulk Hi, There is the TRACK security draft, which originated from work on RMTP-II security. There should be a NORM Security draft very soon. cheers, thomas ------ At 3/29/01||01:58 PM, Lorenzo Vicisano wrote: >Nipul, > >There has been some discussion on this in the context of protocol >instantiations and building blocks, however better places to ask this >this question are smug@cs.umass.edu (secure multicast IRTF group) or >msec@securemulticast.org (IETF group). > > Lorenzo > >In message , >Nipul Jayvant Shah writes: > > Hi! I am a graduate student at NC State. I wanted to know if the RMT WG > > has already conducted some research work related to the security issues of > > RMT, especially concerning the denial of service attacks. If so, could > > anyone suggest the related drafts? > > > > Regards, > > > > Nipul Shah > > NCSU, Raleigh, NC. >From owner-rmt@listserv.lbl.gov Mon Apr 2 04:34:18 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f32BVHj22429; Mon, 2 Apr 2001 04:31: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.11.2/8.11.2) with ESMTP id f32BVFc22425 for ; Mon, 2 Apr 2001 04:31:15 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f32BVEK17251 for ; Mon, 2 Apr 2001 04:31:15 -0700 (PDT) Received: from sm.luth.se (ny.sm.luth.se [130.240.3.1]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32BVD117248 for ; Mon, 2 Apr 2001 04:31:13 -0700 (PDT) Received: from delta1.sm.luth.se (delta1.sm.luth.se [130.240.3.7]) by sm.luth.se (8.10.0/8.10.0) with ESMTP id f32BVM501096; Mon, 2 Apr 2001 13:31:23 +0200 (MET DST) Date: Mon, 2 Apr 2001 13:31:10 +0200 (MET DST) From: Jeremiah Scholl To: rmt@lbl.gov cc: Peter Parnes Subject: tcp-friendliness Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rmt@lbl.gov Precedence: bulk Can anyone tell me if there is any generaly accepted definition for TCP-friendliness regarding reliable multicast. The reason I am asking is that the PGMCC paper (the version that was presented at SIGCOMM) has the following statement near the end of section 4.4 "in the presence of multiple receivers, there is no clear definition of a TCP-fair rate." Can anyone help clarify this for me? Does the IETF have any plans to standardize the definitions of TCP-fair or TCP-friendly with regards to reliable multicast? Thanks! Jeremiah >From owner-rmt@listserv.lbl.gov Mon Apr 2 06:08:18 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f32D7pV23272; Mon, 2 Apr 2001 06:07:51 -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.11.2/8.11.2) with ESMTP id f32D7oc23268 for ; Mon, 2 Apr 2001 06:07:50 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f32D7n625047 for ; Mon, 2 Apr 2001 06:07:49 -0700 (PDT) Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32D7m125042 for ; Mon, 2 Apr 2001 06:07:48 -0700 (PDT) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id PAA51751; Mon, 2 Apr 2001 15:07:04 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200104021307.PAA51751@info.iet.unipi.it> Subject: Re: tcp-friendliness In-Reply-To: from Jeremiah Scholl at "Apr 2, 2001 01:31:10 pm" To: Jeremiah Scholl Date: Mon, 2 Apr 2001 15:07:04 +0200 (CEST) CC: rmt@lbl.gov, Peter Parnes 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 > Can anyone tell me if there is any generaly accepted definition for > TCP-friendliness regarding reliable multicast. The reason I am asking is > that the PGMCC paper (the version that was presented at SIGCOMM) has the > following statement near the end of section 4.4 > > "in the presence of multiple receivers, there is no clear definition of a > TCP-fair rate." the issue there is that when you have a bunch of receivers behind the same bottleneck and different RTTs with the source, you have different values from the TCP formula for the different receivers. If only one of the receivers in the set -- any of them -- was active, then the rate associated with that receiver would certainly be TCP-friendly (PGMCC with one receiver is just TCP). The presence of other receivers in the group which do not cause additional traffic through the bottleneck should reasonably not change the judgement, but then it means that any rate in the set is equally good. cheers luigi > Can anyone help clarify this for me? Does the IETF have any plans to > standardize the definitions of TCP-fair or TCP-friendly with regards to > reliable multicast? > > Thanks! > > Jeremiah > > > > >From owner-rmt@listserv.lbl.gov Mon Apr 2 06:16:04 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f32DFeR23301; Mon, 2 Apr 2001 06:15:40 -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.11.2/8.11.2) with ESMTP id f32DFdc23297 for ; Mon, 2 Apr 2001 06:15:39 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f32DFcu25685 for ; Mon, 2 Apr 2001 06:15:38 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f32DFb125680 for ; Mon, 2 Apr 2001 06:15:38 -0700 (PDT) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 2 Apr 2001 14:15:30 +0100 To: Luigi Rizzo cc: Jeremiah Scholl , rmt@lbl.gov, Peter Parnes Subject: Re: tcp-friendliness In-reply-to: Your message of "Mon, 02 Apr 2001 15:07:04 +0200." <200104021307.PAA51751@info.iet.unipi.it> Date: Mon, 02 Apr 2001 14:15:27 +0100 Message-ID: <2723.986217327@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk i thought it was that you have 1 equation in two variables, ( rate as a function of loss average and rtt) so you can define an infinite number of different fairness models depending whether you want to be fair to rtt (proportional) or loss (max min)? In message <200104021307.PAA51751@info.iet.unipi.it>, Luigi Rizzo typed: >>> Can anyone tell me if there is any generaly accepted definition for >>> TCP-friendliness regarding reliable multicast. The reason I am asking is >>> that the PGMCC paper (the version that was presented at SIGCOMM) has the >>> following statement near the end of section 4.4 >>> >>> "in the presence of multiple receivers, there is no clear definition of a >>> TCP-fair rate." >> >>the issue there is that when you have a bunch of receivers behind >>the same bottleneck and different RTTs with the source, you >>have different values from the TCP formula for the different >>receivers. If only one of the receivers in the set -- any of them >>-- was active, then the rate associated with that receiver would >>certainly be TCP-friendly (PGMCC with one receiver is just TCP). >>The presence of other receivers in the group which do not cause >>additional traffic through the bottleneck should reasonably not >>change the judgement, but then it means that any rate in the set >>is equally good. >> >> >> cheers >> luigi >> >>> Can anyone help clarify this for me? Does the IETF have any plans to >>> standardize the definitions of TCP-fair or TCP-friendly with regards to >>> reliable multicast? >>> >>> Thanks! >>> >>> Jeremiah >>> >>> >>> >>> >> cheers jon >From owner-rmt@listserv.lbl.gov Mon Apr 2 06:50:42 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f32DoPp23539; Mon, 2 Apr 2001 06:50: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.11.2/8.11.2) with ESMTP id f32DoOc23535 for ; Mon, 2 Apr 2001 06:50:24 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f32DoNj29423 for ; Mon, 2 Apr 2001 06:50:23 -0700 (PDT) Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32DoM129413 for ; Mon, 2 Apr 2001 06:50:22 -0700 (PDT) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id PAA51999; Mon, 2 Apr 2001 15:49:36 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200104021349.PAA51999@info.iet.unipi.it> Subject: Re: tcp-friendliness In-Reply-To: <2723.986217327@cs.ucl.ac.uk> from Jon Crowcroft at "Apr 2, 2001 02:15:27 pm" To: Jon Crowcroft Date: Mon, 2 Apr 2001 15:49:36 +0200 (CEST) CC: Jeremiah Scholl , rmt@lbl.gov, Peter Parnes 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 > i thought it was that you have 1 equation in two variables, ( > rate as a function of loss average and rtt) so you can > define an infinite number of different fairness models depending > whether you want to be fair to rtt (proportional) or loss (max min)? It is an orthogonal problem. Even if you [can] choose the working point, you still do not know which receiver's data to plug in the equation. cheers luigi > In message <200104021307.PAA51751@info.iet.unipi.it>, Luigi Rizzo typed: > > >>> Can anyone tell me if there is any generaly accepted definition for > >>> TCP-friendliness regarding reliable multicast. The reason I am asking is > >>> that the PGMCC paper (the version that was presented at SIGCOMM) has the > >>> following statement near the end of section 4.4 > >>> > >>> "in the presence of multiple receivers, there is no clear definition of a > >>> TCP-fair rate." > >> > >>the issue there is that when you have a bunch of receivers behind > >>the same bottleneck and different RTTs with the source, you > >>have different values from the TCP formula for the different > >>receivers. If only one of the receivers in the set -- any of them > >>-- was active, then the rate associated with that receiver would > >>certainly be TCP-friendly (PGMCC with one receiver is just TCP). > >>The presence of other receivers in the group which do not cause > >>additional traffic through the bottleneck should reasonably not > >>change the judgement, but then it means that any rate in the set > >>is equally good. > >> > >> > >> cheers > >> luigi > >> > >>> Can anyone help clarify this for me? Does the IETF have any plans to > >>> standardize the definitions of TCP-fair or TCP-friendly with regards to > >>> reliable multicast? > >>> > >>> Thanks! > >>> > >>> Jeremiah > >>> > >>> > >>> > >>> > >> > > cheers > > jon > > >From owner-rmt@listserv.lbl.gov Mon Apr 2 08:50:40 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f32FneK23678; Mon, 2 Apr 2001 08:49:40 -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.11.2/8.11.2) with ESMTP id f32Fncc23674 for ; Mon, 2 Apr 2001 08:49:39 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f32FncW26902 for ; Mon, 2 Apr 2001 08:49:38 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f32Fna126876 for ; Mon, 2 Apr 2001 08:49:36 -0700 (PDT) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 2 Apr 2001 16:49:25 +0100 To: Luigi Rizzo cc: Jeremiah Scholl , rmt@lbl.gov, Peter Parnes , J.Crowcroft@cs.ucl.ac.uk Subject: Re: tcp-friendliness In-reply-to: Your message of "Mon, 02 Apr 2001 15:49:36 +0200." <200104021349.PAA51999@info.iet.unipi.it> Date: Mon, 02 Apr 2001 16:49:22 +0100 Message-ID: <3151.986226562@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk In message <200104021349.PAA51999@info.iet.unipi.it>, Luigi Rizzo typed: >>> i thought it was that you have 1 equation in two variables, ( >>> rate as a function of loss average and rtt) so you can >>> define an infinite number of different fairness models depending >>> whether you want to be fair to rtt (proportional) or loss (max min)? >>It is an orthogonal problem. Even if you [can] choose the working >>point, you still do not know which receiver's data to >>plug in the equation. luigi asuming i can solve the insoluble (getting feedback on RTT and loss rate on all the edges of the tree) then for proportional fairness, i can define a rule for combining the edges based on axiomatic tree weighting rules - for max min, i dont have to since its just the bottleneck that matters but in practice, you're right (of course >>> In message <200104021307.PAA51751@info.iet.unipi.it>, Luigi Rizzo typed: >>> >>> >>> Can anyone tell me if there is any generaly accepted definition for >>> >>> TCP-friendliness regarding reliable multicast. The reason I am asking is >>> >>> that the PGMCC paper (the version that was presented at SIGCOMM) has the >>> >>> following statement near the end of section 4.4 >>> >>> >>> >>> "in the presence of multiple receivers, there is no clear definition of a >>> >>> TCP-fair rate." >>> >> >>> >>the issue there is that when you have a bunch of receivers behind >>> >>the same bottleneck and different RTTs with the source, you >>> >>have different values from the TCP formula for the different >>> >>receivers. If only one of the receivers in the set -- any of them >>> >>-- was active, then the rate associated with that receiver would >>> >>certainly be TCP-friendly (PGMCC with one receiver is just TCP). >>> >>The presence of other receivers in the group which do not cause >>> >>additional traffic through the bottleneck should reasonably not >>> >>change the judgement, but then it means that any rate in the set >>> >>is equally good. >>> >> >>> >> >>> >> cheers >>> >> luigi >>> >> >>> >>> Can anyone help clarify this for me? Does the IETF have any plans to >>> >>> standardize the definitions of TCP-fair or TCP-friendly with regards to >>> >>> reliable multicast? >>> >>> >>> >>> Thanks! >>> >>> >>> >>> Jeremiah >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >>> >>> cheers >>> >>> jon >>> >>> >> cheers jon >From owner-rmt@listserv.lbl.gov Mon Apr 2 11:27:23 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f32IQkS00759; Mon, 2 Apr 2001 11:26: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 (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32IQic00755 for ; Mon, 2 Apr 2001 11:26:44 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f32IQhW02475 for ; Mon, 2 Apr 2001 11:26:43 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32IQg102468 for ; Mon, 2 Apr 2001 11:26:42 -0700 (PDT) Received: from scf-fs.usc.edu (root@scf-fs.usc.edu [128.125.253.183]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA01184; Mon, 2 Apr 2001 11:26:31 -0700 (PDT) Received: from protest2 (protest2.usc.edu [128.125.72.115]) by scf-fs.usc.edu (8.9.3.1/8.9.3/usc) with SMTP id LAA01417; Mon, 2 Apr 2001 11:26:32 -0700 (PDT) Message-ID: <008101c0bba2$0caf3940$73487d80@protest2> From: "Karim Seada" To: Cc: "Luigi Rizzo" , , "Peter Parnes" , "Jeremiah Scholl" References: <200104021307.PAA51751@info.iet.unipi.it> Subject: Re: tcp-friendliness Date: Mon, 2 Apr 2001 11:23:43 -0700 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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-rmt@lbl.gov Precedence: bulk But even in the simple case, where all receivers share the same bottleneck link, but have different RTTs. If the rate is not associated with the receiver with the highest RTT, it is not clear that TCP-friendliness would be achieved with other competing TCP flows with high RTT (their rate according to the formula will be less). Karim Seada ----- Original Message ----- From: "Luigi Rizzo" To: "Jeremiah Scholl" Cc: ; "Peter Parnes" Sent: Monday, April 02, 2001 6:07 AM Subject: Re: tcp-friendliness > > Can anyone tell me if there is any generaly accepted definition for > > TCP-friendliness regarding reliable multicast. The reason I am asking is > > that the PGMCC paper (the version that was presented at SIGCOMM) has the > > following statement near the end of section 4.4 > > > > "in the presence of multiple receivers, there is no clear definition of a > > TCP-fair rate." > > the issue there is that when you have a bunch of receivers behind > the same bottleneck and different RTTs with the source, you > have different values from the TCP formula for the different > receivers. If only one of the receivers in the set -- any of them > -- was active, then the rate associated with that receiver would > certainly be TCP-friendly (PGMCC with one receiver is just TCP). > The presence of other receivers in the group which do not cause > additional traffic through the bottleneck should reasonably not > change the judgement, but then it means that any rate in the set > is equally good. > > > cheers > luigi > > > Can anyone help clarify this for me? Does the IETF have any plans to > > standardize the definitions of TCP-fair or TCP-friendly with regards to > > reliable multicast? > > > > Thanks! > > > > Jeremiah > > > > > > > > > >From owner-rmt@listserv.lbl.gov Mon Apr 2 11:31:58 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f32IVsA00909; Mon, 2 Apr 2001 11:31:54 -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.11.2/8.11.2) with ESMTP id f32IVqc00905 for ; Mon, 2 Apr 2001 11:31:53 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f32IVq104663 for ; Mon, 2 Apr 2001 11:31:52 -0700 (PDT) Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32IVp104653 for ; Mon, 2 Apr 2001 11:31:51 -0700 (PDT) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id UAA54232; Mon, 2 Apr 2001 20:31:05 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200104021831.UAA54232@info.iet.unipi.it> Subject: Re: tcp-friendliness In-Reply-To: <008101c0bba2$0caf3940$73487d80@protest2> from Karim Seada at "Apr 2, 2001 11:23:43 am" To: Karim Seada Date: Mon, 2 Apr 2001 20:31:05 +0200 (CEST) CC: rmt@lbl.gov, J.Crowcroft@cs.ucl.ac.uk, Peter Parnes , Jeremiah Scholl 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 [Charset iso-8859-1 unsupported, filtering to ASCII...] > But even in the simple case, where all receivers share the same bottleneck link, > but have different RTTs. If the rate is not associated with the receiver with > the highest RTT, it is not clear that TCP-friendliness would be achieved with > other competing TCP flows with high RTT (their rate according to the formula > will be less). and vice-versa. However you choose the representative, you make a mistake when comparing with unicast TCP sessions with a different RTT. cheers luigi > Karim Seada > > ----- Original Message ----- > From: "Luigi Rizzo" > To: "Jeremiah Scholl" > Cc: ; "Peter Parnes" > Sent: Monday, April 02, 2001 6:07 AM > Subject: Re: tcp-friendliness > > > > > Can anyone tell me if there is any generaly accepted definition for > > > TCP-friendliness regarding reliable multicast. The reason I am asking is > > > that the PGMCC paper (the version that was presented at SIGCOMM) has the > > > following statement near the end of section 4.4 > > > > > > "in the presence of multiple receivers, there is no clear definition of a > > > TCP-fair rate." > > > > the issue there is that when you have a bunch of receivers behind > > the same bottleneck and different RTTs with the source, you > > have different values from the TCP formula for the different > > receivers. If only one of the receivers in the set -- any of them > > -- was active, then the rate associated with that receiver would > > certainly be TCP-friendly (PGMCC with one receiver is just TCP). > > The presence of other receivers in the group which do not cause > > additional traffic through the bottleneck should reasonably not > > change the judgement, but then it means that any rate in the set > > is equally good. > > > > > > cheers > > luigi > > > > > Can anyone help clarify this for me? Does the IETF have any plans to > > > standardize the definitions of TCP-fair or TCP-friendly with regards to > > > reliable multicast? > > > > > > Thanks! > > > > > > Jeremiah > > > > > > > > > > > > > > > > >From owner-rmt@listserv.lbl.gov Mon Apr 2 12:00:14 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f32J02A01039; Mon, 2 Apr 2001 12:00:02 -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.11.2/8.11.2) with ESMTP id f32J00c01035 for ; Mon, 2 Apr 2001 12:00:00 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f32J00R15498 for ; Mon, 2 Apr 2001 12:00:00 -0700 (PDT) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32Ixx115478 for ; Mon, 2 Apr 2001 11:59:59 -0700 (PDT) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.10.0/8.10.0) id f32Ixxn20841; Mon, 2 Apr 2001 11:59:59 -0700 (PDT) Message-Id: <200104021859.f32Ixxn20841@daffy.ee.lbl.gov> To: rmt@lbl.gov Subject: Administrative: cleanup of rmt@lbl.gov mailing list In-reply-to: Your message of Sat, 24 Mar 2001 01:34:17 PST. Date: Mon, 02 Apr 2001 11:59:59 PDT From: Vern Paxson Sender: owner-rmt@lbl.gov Precedence: bulk FYI, the following usernames have been deleted due to hard bounces: Antoine.Clerget@sophia.inria.fr markg@entera.com - Vern >From owner-rmt@listserv.lbl.gov Mon Apr 2 12:29:55 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f32JTV101085; Mon, 2 Apr 2001 12:29:31 -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.11.2/8.11.2) with ESMTP id f32JTTc01081 for ; Mon, 2 Apr 2001 12:29:29 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f32JTSn26103 for ; Mon, 2 Apr 2001 12:29:28 -0700 (PDT) Received: from multicasttech.com (IDENT:root@garcia.multicasttech.com [63.105.122.8]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32JTQ126091 for ; Mon, 2 Apr 2001 12:29:27 -0700 (PDT) Received: from [63.105.122.193] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 840780; Mon, 02 Apr 2001 15:27:24 -0400 Message-ID: <3AC8D314.9281DAB4@21rst-century.com> Date: Mon, 02 Apr 2001 15:29:22 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Jeremiah Scholl CC: rmt@lbl.gov, Peter Parnes Subject: Re: tcp-friendliness References: Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Jeremiah Scholl wrote: > Can anyone tell me if there is any generaly accepted definition for > TCP-friendliness regarding reliable multicast. The reason I am asking is > that the PGMCC paper (the version that was presented at SIGCOMM) has the > following statement near the end of section 4.4 > > "in the presence of multiple receivers, there is no clear definition of a > TCP-fair rate." > > Can anyone help clarify this for me? Does the IETF have any plans to > standardize the definitions of TCP-fair or TCP-friendly with regards to > reliable multicast? > > Thanks! > > Jeremiah My personal, and unpopular, opinion is that this is not a well-posed problem. Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com >From owner-rmt@listserv.lbl.gov Wed Apr 4 11:02:24 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f34HxNu10429; Wed, 4 Apr 2001 10:59:23 -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.11.2/8.11.2) with ESMTP id f34HxMc10425 for ; Wed, 4 Apr 2001 10:59:22 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f34HxHe14915 for ; Wed, 4 Apr 2001 10:59:17 -0700 (PDT) Received: from ra.ecse.rpi.edu (ra.ecse.rpi.edu [128.113.61.205]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f34HxF114899 for ; Wed, 4 Apr 2001 10:59:15 -0700 (PDT) Received: from localhost (shivkuma@localhost) by ra.ecse.rpi.edu (8.9.2/8.9.2) with SMTP id NAA16388; Wed, 4 Apr 2001 13:57:49 -0400 (EDT) Date: Wed, 4 Apr 2001 13:57:48 -0400 (EDT) From: Shivkumar Kalyanaraman To: Marshall Eubanks cc: Jeremiah Scholl , rmt@lbl.gov, Peter Parnes Subject: Re: tcp-friendliness In-Reply-To: <3AC8D314.9281DAB4@21rst-century.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rmt@lbl.gov Precedence: bulk In a recent work, we decouple the measurement and use of loss rate and RTT. This allows simple source-based implementation assuming loss-indications are the only thing fed back... It does not seem to be too bad as it would seem... No drop-to-zero, no beat down of competing TCP flows+reasonably equivalent rate sharing... http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers-rpi.html#mult -Shiv === Shivkumar Kalyanaraman Asst. Professor, Dept of ECSE, Rensselaer Polytechnic Institute (RPI) 110, 8th Street, Room JEC 6003, Troy NY 12180-3590 Ph: 518 276 8979 Fax: 518 276 2433 WWW: http://www.ecse.rpi.edu/Homepages/shivkuma A goal is a dream with a deadline -C. Knight >From owner-rmt@listserv.lbl.gov Wed Apr 4 11:44:39 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f34IiVq10560; Wed, 4 Apr 2001 11:44:31 -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.11.2/8.11.2) with ESMTP id f34IiUc10556 for ; Wed, 4 Apr 2001 11:44:30 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f34IiTe01742 for ; Wed, 4 Apr 2001 11:44:29 -0700 (PDT) Received: from multicasttech.com (IDENT:root@garcia.multicasttech.com [63.105.122.8]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f34IiS101730 for ; Wed, 4 Apr 2001 11:44:28 -0700 (PDT) Received: from [63.105.122.193] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 841609; Wed, 04 Apr 2001 14:42:09 -0400 Message-ID: <3ACB6B8A.FB3390D6@21rst-century.com> Date: Wed, 04 Apr 2001 14:44:19 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Shivkumar Kalyanaraman CC: Jeremiah Scholl , rmt@lbl.gov, Peter Parnes Subject: Re: tcp-friendliness References: Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Shivkumar Kalyanaraman wrote: > In a recent work, we decouple the measurement and use of loss rate and > RTT. This allows simple source-based implementation assuming > loss-indications are the only thing fed back... It does not seem to be too > bad as it would seem... No drop-to-zero, no beat down of competing TCP > flows+reasonably equivalent rate sharing... > > http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers-rpi.html#mult > > -Shiv > === > Shivkumar Kalyanaraman > Asst. Professor, Dept of ECSE, Rensselaer Polytechnic Institute (RPI) > 110, 8th Street, Room JEC 6003, Troy NY 12180-3590 > Ph: 518 276 8979 Fax: 518 276 2433 > WWW: http://www.ecse.rpi.edu/Homepages/shivkuma > > A goal is a dream with a deadline -C. Knight Thanks ! I'll read these papers. Have you tried the same thing for receiver based CC ? BTW, is RPI multicast enabled ? -- Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ >From owner-rmt@listserv.lbl.gov Thu Apr 5 03:43:35 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f35AfkH11852; Thu, 5 Apr 2001 03:41: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 (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f35Afic11848 for ; Thu, 5 Apr 2001 03:41:44 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f35AfiY03253 for ; Thu, 5 Apr 2001 03:41:44 -0700 (PDT) Received: from plmta00.chello.pl (plmta00.chello.pl [213.46.248.62]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f35Afh103250 for ; Thu, 5 Apr 2001 03:41:43 -0700 (PDT) Message-Id: <200104051041.f35Afh103250@SpamWall.lbl.gov> Received: from hetnet.nl ([213.93.48.181]) by plmta00.chello.pl (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id pl for ; Thu, 5 Apr 2001 08:03:12 -0100 From: "Rita de Groot" To: Subject: huidziekte Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 5 Apr 2001 11:00:43 +0200 Content-Transfer-Encoding: 8bit Sender: owner-rmt@lbl.gov Precedence: bulk Vijf jaar voordat deze foto's werden genomen werd bij mij diagnose reumatische artritis gesteld en als zodanig ook behandeld. Niets hielp. Toen de ziekte zich zo manifesteerde zoals u hieronder kunt zien.......... http://www.naardedokter.com/testimonials/sys_lup_eryth.htm >From owner-rmt@listserv.lbl.gov Fri Apr 6 01:42:13 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f368eOo15005; Fri, 6 Apr 2001 01:40: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 (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f368eMc15001 for ; Fri, 6 Apr 2001 01:40:22 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f368eIe20701 for ; Fri, 6 Apr 2001 01:40:18 -0700 (PDT) Received: from sm.luth.se (ny.sm.luth.se [130.240.3.1]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f368eG120692 for ; Fri, 6 Apr 2001 01:40:17 -0700 (PDT) Received: from delta1.sm.luth.se (delta1.sm.luth.se [130.240.3.7]) by sm.luth.se (8.10.0/8.10.0) with ESMTP id f368eHu01599; Fri, 6 Apr 2001 10:40:17 +0200 (MET DST) Date: Fri, 6 Apr 2001 10:40:04 +0200 (MET DST) From: Jeremiah Scholl To: Marshall Eubanks cc: Jeremiah Scholl , rmt@lbl.gov, Peter Parnes Subject: Re: tcp-friendliness In-Reply-To: <3AC8D314.9281DAB4@21rst-century.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rmt@lbl.gov Precedence: bulk All the responses I received have clarified the meaning of the statement in the context of the PGMCC article. However, I am still curious if there is a standard way to define TCP-friendliness in a multicast setting. The way I see it there are two possible ways to define TCP-friendliness for a multicast flow over its liftime. 1)The flow rate if the scheme was adjusted to the TCP-rate of the worst-case receiver at all times. 2)The flow rate if the scheme was adjusted to the worst-case flow over the lifetime of the transfer. Here is a simple example of how these two definitions could give you different acceptable rates. Suppose we multicast to two receivers for a period of 1 minute, receiver X and and receiver Y. For the first 30 seconds receiver X is in a congested state a has a "TCP-friendly" bandwidth of 5 kb/s. Receiver Y on the other hand is not congested and can receive 100 kb/s. Half way through the life of our transfer the situation for the two receivers is switched and for the final 30 seconds reciever X can recieve 100 kb/s and receiver Y can receive 5 kb/s. Using definition 1 for TCP-friendliness our acceptable send rate would be 5 kb/s for the first half of the transfer and 5 kb/s for the second half of the transfer. So, we would be able to transfer: 5 kb/s * 60 s = 300 kb of data and still be TCP friendly. However, if we use definition 2 for TCP-friendiness from above then our acceptable send rate would be the TCP-friendly rate for either flow throughout the entire minute (since in this case there is not a worst-case flow). So, we would be able to transfer: (100 kb/s + 5 kb/s)/2 = 52.5 kb/s for 60 seconds which gives us 3150 kb of data and still be TCP friendly. So, I suppose what I am wondering is if there is in fact a generaly accepted definition for TCP-friendliness for a multicast flow. If so, what is it. Thanks! Jeremiah On Mon, 2 Apr 2001, Marshall Eubanks wrote: > Jeremiah Scholl wrote: > > > Can anyone tell me if there is any generaly accepted definition for > > TCP-friendliness regarding reliable multicast. The reason I am asking is > > that the PGMCC paper (the version that was presented at SIGCOMM) has the > > following statement near the end of section 4.4 > > > > "in the presence of multiple receivers, there is no clear definition of a > > TCP-fair rate." > > > > Can anyone help clarify this for me? Does the IETF have any plans to > > standardize the definitions of TCP-fair or TCP-friendly with regards to > > reliable multicast? > > > > Thanks! > > > > Jeremiah > > My personal, and unpopular, opinion is that this is not a well-posed problem. > > > Regards > Marshall Eubanks > > > T.M. Eubanks > Multicast Technologies, Inc > 10301 Democracy Lane, Suite 410 > Fairfax, Virginia 22030 > Phone : 703-293-9624 > Fax : 703-293-9609 > e-mail : tme@on-the-i.com tme@multicasttech.com > > http://www.on-the-i.com http://www.buzzwaves.com > > > >From owner-rmt@listserv.lbl.gov Fri Apr 6 03:55:25 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f36AskB15146; Fri, 6 Apr 2001 03:54: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 (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f36Asic15142 for ; Fri, 6 Apr 2001 03:54:44 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f36AsiJ13398 for ; Fri, 6 Apr 2001 03:54:44 -0700 (PDT) Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f36Ash113394 for ; Fri, 6 Apr 2001 03:54:43 -0700 (PDT) Received: from coffeepot.cs.rpi.edu (thaps@coffeepot.cs.rpi.edu [128.213.8.30]) by cs.rpi.edu (8.9.3/8.9.3) with SMTP id GAA39066; Fri, 6 Apr 2001 06:53:40 -0400 (EDT) Date: Fri, 6 Apr 2001 06:53:39 -0400 (EDT) From: Puneet Thapliyal Reply-To: Puneet Thapliyal To: Jeremiah Scholl cc: Marshall Eubanks , rmt@lbl.gov, Peter Parnes Subject: Re: tcp-friendliness In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rmt@lbl.gov Precedence: bulk On Fri, 6 Apr 2001, Jeremiah Scholl wrote: > However, if we use definition 2 for TCP-friendiness from above then our > acceptable send rate would be the TCP-friendly rate for either flow > throughout the entire minute (since in this case there is not a > worst-case flow). So, we would be able to transfer: > > (100 kb/s + 5 kb/s)/2 = 52.5 kb/s for 60 seconds which gives us > > 3150 kb of data and still be TCP friendly. If the source rate is maintained at 100kbps with the "worst" receiver in the receiver set having a b/w of 5kbps, it would be doing no good for congestion control. Cheers, Puneet Thapliyal ---------------------- Networks Research Lab, RPI. ---------------------- >From owner-rmt@listserv.lbl.gov Fri Apr 6 04:27:08 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f36BQpd15172; Fri, 6 Apr 2001 04:26:51 -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.11.2/8.11.2) with ESMTP id f36BQmc15168 for ; Fri, 6 Apr 2001 04:26:49 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f36BQmE18578 for ; Fri, 6 Apr 2001 04:26:48 -0700 (PDT) Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f36BQk118572 for ; Fri, 6 Apr 2001 04:26:47 -0700 (PDT) Received: from cabo3 (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id f36BQQG15620; Fri, 6 Apr 2001 13:26:26 +0200 (MEST) From: "Dr. Carsten Bormann" To: "Jeremiah Scholl" , "Marshall Eubanks" Cc: , "Peter Parnes" Subject: RE: tcp-friendliness Date: Fri, 6 Apr 2001 13:26:27 +0200 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.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-rmt@lbl.gov Precedence: bulk Jeremiah, the definition of multicast TCP-friendliness definitely is certainly governed by that famous Douglas Adams quote -- once somebody figures it out, the universe is replaced by something even more bizarre and unexplicable. The main problem with any new specific hard definition is that somebody will immediately come up with 1) a protocol that is clearly TCP-friendly in all aspects but does not fit the definition, 2) another protocol that manages to comply to the definition while not being TCP-friendly at all. On the other hand, the whole thing is really simple: The whole point of the TCP-friendliness discussion is not to do damage. In particular, you should not encourage destructive behavior: If a multicast stream gets better bandwidth than a unicast stream, people will move unicast traffic to multicast, even if there is only one receiver. (If a multicast stream does not get better bandwidth than the corresponding set of unicast streams, you remove a major incentive to move to multicast.) In your example 2, assuming the bottleneck is a low-statmux link, clearly you are damaging traffic on the links that are being severely overloaded. This is not TCP-friendly by any stretch of the imagination. The situation is slightly more murky on high-statmux links. There is an argument that one multicast stream is better than the equivalent multiple unicast streams, so you are entitled to a higher share of the high-statmux link. If that is granted, you might be allowed to push back TCP traffic more than a single TCP stream would, but not more than the equivalent collection of unicast streams would (note that, until we get infinite-bandwidth links, this is quite different from saying "n times the throughout of a single unicast stream"). Unfortunately, this borders on discussions of ISP business models, so there is no *technical* argument that can bring this discussion to a conclusion. Also, of course, the endpoints have a hard time finding out whether the losses they see are from low-statmux bottlenecks or not. The restricted-worst-edge model championed by Brian Whetten is an example that has been influenced by this kind of thinking. Gruesse, Carsten PS.: And we are cheating by treating Multicast Congestion Control as an L3 problem. With today's L2 networks, you may be severely overloading L2 links although all receivers are happy. This is a real-world problem! Also, there are failure modes where a receiver does get the multicast packets but does not manage to return congestion information. In a world full of middleboxes, this is becoming more prevalent every day. >From owner-rmt@listserv.lbl.gov Fri Apr 6 04:58:47 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f36BwBj15190; Fri, 6 Apr 2001 04:58:11 -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.11.2/8.11.2) with ESMTP id f36Bw9c15186 for ; Fri, 6 Apr 2001 04:58:09 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f36Bw9123907 for ; Fri, 6 Apr 2001 04:58:09 -0700 (PDT) Received: from pi4.informatik.uni-mannheim.de (root@pi4.informatik.uni-mannheim.de [134.155.48.96]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f36Bw7123896 for ; Fri, 6 Apr 2001 04:58:07 -0700 (PDT) Received: from informatik.uni-mannheim.de (IDENT:widmer@meton [134.155.48.2]) by pi4.informatik.uni-mannheim.de (8.9.3/8.9.3) with ESMTP id NAA08632; Fri, 6 Apr 2001 13:57:51 +0200 (MET DST) Message-ID: <3ACDAF3F.FF9A9D32@informatik.uni-mannheim.de> Date: Fri, 06 Apr 2001 13:57:51 +0200 From: Joerg Widmer Organization: University of Mannheim X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jeremiah Scholl CC: Marshall Eubanks , rmt@lbl.gov, Peter Parnes Subject: Re: tcp-friendliness References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Jeremiah Scholl wrote: > > All the responses I received have clarified the meaning of the > statement in the context of the PGMCC article. However, I am still > curious if there is a standard way to define TCP-friendliness in a > multicast setting. The way I see it there are two possible ways to define > TCP-friendliness for a multicast flow over its liftime. > > 1)The flow rate if the scheme was adjusted to the TCP-rate of > the worst-case receiver at all times. > > 2)The flow rate if the scheme was adjusted to the worst-case flow over the > lifetime of the transfer. > To me this seems to be directly related to the form of multicast transmission. If it is a single-rate multicast distribution, only 1) will ensure that competing TCP traffic is treated fairly, while multi-rate multicast transmission can get away with an average rate of 2) and still be TCP-friendly. (So 1) is ok in either case.) Joerg -- Joerg Widmer Praktische Informatik IV, University of Mannheim L15,16, 68131 Mannheim, Germany Tel: +49 621 181 2605, Fax: +49 621 181 2601 http://www.informatik.uni-mannheim.de/informatik/pi4/people/widmer.html >From owner-rmt@listserv.lbl.gov Fri Apr 6 06:11:07 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f36DAh116022; Fri, 6 Apr 2001 06:10: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.11.2/8.11.2) with ESMTP id f36DAgc16018 for ; Fri, 6 Apr 2001 06:10:42 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f36DAfU08182 for ; Fri, 6 Apr 2001 06:10:41 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f36DAe108177 for ; Fri, 6 Apr 2001 06:10:40 -0700 (PDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 6 Apr 2001 14:10:22 +0100 To: Jeremiah Scholl cc: Marshall Eubanks , rmt@lbl.gov, Peter Parnes , J.Crowcroft@cs.ucl.ac.uk Subject: Re: tcp-friendliness In-reply-to: Your message of "Fri, 06 Apr 2001 10:40:04 +0200." Date: Fri, 06 Apr 2001 14:10:22 +0100 Message-ID: <8210.986562622@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk In message , Jere miah Scholl typed: >>1)The flow rate if the scheme was adjusted to the TCP-rate of >>the worst-case receiver at all times. >>2)The flow rate if the scheme was adjusted to the worst-case flow over the >>lifetime of the transfer. the problem with "TCP friendliness" is that there are several levels of "friendly" and usually peopel start to talk about fairness and the whole area is bound up with a range of dilemmas ranging from i) the specifics of implementation of a given TCP (and a given RMT) and ii) ideas of utility and iii) ideas of network efficiency (e.g. user v. provider optimality) the definitons abouve are cute, but while 1/ is elegant its not achievable - an instantaenous equivalent to the TCP rate of a "worst-case" receiver (we.g. on a packet or single RTT timescale) is not scalable, and usually ends up being covergent to zero rate anyhow 2/ is subject to weird games peopel can play esp. aroudn the phase shif at the diurnal (9am/5pm) times.... I would prefer we move to some sort of symptomatic (measurable.verifiable) definiton of TCP co-existence behaviour and do it o na case by case basis - e.g. define the timescales over which an RMT adapts to a set of TCPs that share a set of bottlnecks define the goal seeking model it uses and the asymptotic behaviour maybe only a some sort of last resrt.... the reason i would say thuis is that i beleive the jury is STILL OUT on what users and providers actually WANT in terms of utility (and relative utility of an RMT and a TCP) so we dont want to define any single operating regime, but rather, just set some broad rules (e.g. Asimov's 3 laws of Robotic multicast: i) an RMT mustnt drive TCP to zero on any given bottleneck, over any reasonable (RTT raealted?, or TCP lifetimes) timescale ii) an RMT or let itself be driven to zero by any reasonable mix with TCP over any comparable timescale (e.g. to TCP flow lifes) iii) the feedback or other contrl traffic (igmp for multirate) for an RMT will always be bounded to some reasonable fraction of the actual data traffic for example.. cheers jon >From owner-rmt@listserv.lbl.gov Fri Apr 6 06:42:44 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f36DgMx16176; Fri, 6 Apr 2001 06:42: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.11.2/8.11.2) with ESMTP id f36DgKc16172 for ; Fri, 6 Apr 2001 06:42:21 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f36DgKA14622 for ; Fri, 6 Apr 2001 06:42:20 -0700 (PDT) Received: from multicasttech.com (IDENT:root@garcia.multicasttech.com [63.105.122.8]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f36DgJ114618 for ; Fri, 6 Apr 2001 06:42:19 -0700 (PDT) Received: from [63.105.122.193] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3.2) with ESMTP id 842419; Fri, 06 Apr 2001 09:39:45 -0400 Message-ID: <3ACDC7B5.4FE1E56@21rst-century.com> Date: Fri, 06 Apr 2001 09:42:12 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Jon Crowcroft CC: Jeremiah Scholl , rmt@lbl.gov, Peter Parnes Subject: Re: tcp-friendliness References: <8210.986562622@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Jon Crowcroft wrote: > In message , Jere > miah Scholl typed: > > >>1)The flow rate if the scheme was adjusted to the TCP-rate of > >>the worst-case receiver at all times. > > >>2)The flow rate if the scheme was adjusted to the worst-case flow over the > >>lifetime of the transfer. > > the problem with "TCP friendliness" is that there are several levels > of "friendly" and usually peopel start to talk about fairness and > the whole area is bound up with a range of dilemmas ranging from > i) the specifics of implementation of a given TCP (and a given RMT) > and > ii) ideas of utility > and > iii) ideas of network efficiency (e.g. user v. provider optimality) > > the definitons abouve are cute, but while 1/ is elegant its not > achievable - an instantaenous equivalent to the TCP rate of a > "worst-case" receiver (we.g. on a packet or single RTT timescale) is > not scalable, and usually ends up being covergent to zero rate > anyhow > > 2/ is subject to weird games peopel can play esp. aroudn the phase > shif at the diurnal (9am/5pm) times.... > > I would prefer we move to some sort of symptomatic (measurable.verifiable) > definiton of TCP co-existence behaviour and do it o na case by case > basis - e.g. define the timescales over which an RMT adapts to a > set of TCPs that share a set of bottlnecks define the goal seeking > model it uses and the asymptotic behaviour maybe only a some sort of > last resrt.... > > the reason i would say thuis is that i beleive the jury is STILL OUT > on what users and providers actually WANT in terms of utility (and > relative utility of an RMT and a TCP) so we dont want to define any > single operating regime, but rather, just set some broad rules (e.g. > Asimov's 3 laws of Robotic multicast: > > i) an RMT mustnt drive TCP to zero on any given bottleneck, over any > reasonable (RTT raealted?, or TCP lifetimes) timescale > ii) an RMT or let itself be driven to zero by any reasonable mix with TCP > over any comparable timescale (e.g. to TCP flow lifes) Jon; ii) seems to be garbled - did you mean to say an RMT must NOT let itself be driven to zero... ? Or something else ? If that's what you meant, I think that these 3 guidelines are a good starting point. Marshall > > iii) the feedback or other contrl traffic (igmp for multirate) > for an RMT will always be bounded to some reasonable fraction of the > actual data traffic > > for example.. > > cheers > jon T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ >From owner-rmt@listserv.lbl.gov Fri Apr 6 08:39:42 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f36FdCE16503; Fri, 6 Apr 2001 08:39: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.11.2/8.11.2) with ESMTP id f36FdAc16499 for ; Fri, 6 Apr 2001 08:39:11 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f36FdAl19148 for ; Fri, 6 Apr 2001 08:39:10 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f36FdA119145 for ; Fri, 6 Apr 2001 08:39:10 -0700 (PDT) Received: from bcn.East.Sun.COM ([129.148.75.4]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26802; Fri, 6 Apr 2001 08:39:07 -0700 (PDT) Received: from bridge (bridge [129.148.75.125]) by bcn.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA14153; Fri, 6 Apr 2001 11:39:05 -0400 (EDT) Message-Id: <200104061539.LAA14153@bcn.East.Sun.COM> Date: Fri, 6 Apr 2001 11:39:02 -0400 (EDT) From: Dah Ming Chiu - Sun Microsystems Reply-To: Dah Ming Chiu - Sun Microsystems Subject: Re: tcp-friendliness To: jeremiah@cdt.luth.se Cc: rmt@lbl.gov MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5EOvOf2VjYB+gacvTCKJjg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-rmt@lbl.gov Precedence: bulk We had a lot of discussion on this topic (in the RMRG) a couple of years ago. I think there was a lot of support of using your first definition as a guideline. Of course in reality, "at all times" is subject to interpretation. There is also limits as to how fast each flow can react to congestion, and thus how strict fairness can be maintained dynamically. I agree with Jon Crowcroft's last email. Requiring RMT to be TCP friendly is dictating certain way of allocating network resources between unicast and multicast traffic. This is a rather complex issue. In the long run, the correct solution may very well be governed by the economics/pricing models of the Internet, rather than purely by the transport mechanisms. In the mean time, we should concentrate on the effectiveness of controlling/avoiding congestion, and be more liberal with how we mandate fairness. In thinking about these issues, we have written a couple of papers you might find useful: 1) "Some observations on Fairness of Bandwidth Sharing" http://research.sun.com/techrep/1999/abstract-80.html We discuss the meaning of different fairness criteria, and some issues when applying them to multicast 2) "Pruning Algorithms for Multicast Flow Control" http://www.cs.ucsb.edu/ngc2000/program/117.ps This paper deal with the case when you have n receivers who can receive at 100KB/s and one at 5KB/s, how you might want to "prune" the slow receiver. It also discusses the TCP-friendliness issue with doing that. Regards Dah Ming Chiu Sun Labs X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f From: Jeremiah Scholl To: Marshall Eubanks cc: Jeremiah Scholl , rmt@lbl.gov, Peter Parnes Subject: Re: tcp-friendliness MIME-Version: 1.0 All the responses I received have clarified the meaning of the statement in the context of the PGMCC article. However, I am still curious if there is a standard way to define TCP-friendliness in a multicast setting. The way I see it there are two possible ways to define TCP-friendliness for a multicast flow over its liftime. 1)The flow rate if the scheme was adjusted to the TCP-rate of the worst-case receiver at all times. 2)The flow rate if the scheme was adjusted to the worst-case flow over the lifetime of the transfer. Here is a simple example of how these two definitions could give you different acceptable rates. Suppose we multicast to two receivers for a period of 1 minute, receiver X and and receiver Y. For the first 30 seconds receiver X is in a congested state a has a "TCP-friendly" bandwidth of 5 kb/s. Receiver Y on the other hand is not congested and can receive 100 kb/s. Half way through the life of our transfer the situation for the two receivers is switched and for the final 30 seconds reciever X can recieve 100 kb/s and receiver Y can receive 5 kb/s. Using definition 1 for TCP-friendliness our acceptable send rate would be 5 kb/s for the first half of the transfer and 5 kb/s for the second half of the transfer. So, we would be able to transfer: 5 kb/s * 60 s = 300 kb of data and still be TCP friendly. However, if we use definition 2 for TCP-friendiness from above then our acceptable send rate would be the TCP-friendly rate for either flow throughout the entire minute (since in this case there is not a worst-case flow). So, we would be able to transfer: (100 kb/s + 5 kb/s)/2 = 52.5 kb/s for 60 seconds which gives us 3150 kb of data and still be TCP friendly. So, I suppose what I am wondering is if there is in fact a generaly accepted definition for TCP-friendliness for a multicast flow. If so, what is it. Thanks! Jeremiah On Mon, 2 Apr 2001, Marshall Eubanks wrote: > Jeremiah Scholl wrote: > > > Can anyone tell me if there is any generaly accepted definition for > > TCP-friendliness regarding reliable multicast. The reason I am asking is > > that the PGMCC paper (the version that was presented at SIGCOMM) has the > > following statement near the end of section 4.4 > > > > "in the presence of multiple receivers, there is no clear definition of a > > TCP-fair rate." > > > > Can anyone help clarify this for me? Does the IETF have any plans to > > standardize the definitions of TCP-fair or TCP-friendly with regards to > > reliable multicast? > > > > Thanks! > > > > Jeremiah > > My personal, and unpopular, opinion is that this is not a well-posed problem. > > > Regards > Marshall Eubanks > > > T.M. Eubanks > Multicast Technologies, Inc > 10301 Democracy Lane, Suite 410 > Fairfax, Virginia 22030 > Phone : 703-293-9624 > Fax : 703-293-9609 > e-mail : tme@on-the-i.com tme@multicasttech.com > > http://www.on-the-i.com http://www.buzzwaves.com > > > >From owner-rmt@listserv.lbl.gov Mon Apr 9 03:52:52 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.9.3) id f39AoSa22654; Mon, 9 Apr 2001 03:50:28 -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.11.2/8.11.2) with ESMTP id f39AoQc22650 for ; Mon, 9 Apr 2001 03:50:26 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f39AoOp12788 for ; Mon, 9 Apr 2001 03:50:24 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f39AoJ112708 for ; Mon, 9 Apr 2001 03:50:21 -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 GAA02566; Mon, 9 Apr 2001 06:50:18 -0400 (EDT) Message-Id: <200104091050.GAA02566@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-track-security-01.txt Date: Mon, 09 Apr 2001 06:50:18 -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 : Security Requirements For TRACK Author(s) : T. Hardjono, B. Whetten Filename : draft-ietf-rmt-pi-track-security-01.txt Pages : Date : 06-Apr-01 This document discusses the security issues within the TRee-based ACKnowledgement (TRACK) reliable multicast protocol instantiation, and identifies some constraints and requirements for security provisions for this protocol. 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 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, because of the requirement that the interior control nodes only OPTIONALLY have access to the data packet payload. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-track-security-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-pi-track-security-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-pi-track-security-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: <20010406125122.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-pi-track-security-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-pi-track-security-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010406125122.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Sat Apr 14 08:05:33 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f3EEvXu14497; Sat, 14 Apr 2001 07:57:33 -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.11.2/8.11.2) with ESMTP id f3EEvVg14493 for ; Sat, 14 Apr 2001 07:57:32 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f3EEvUU21791 for ; Sat, 14 Apr 2001 07:57:31 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f3EEvTL21786 for ; Sat, 14 Apr 2001 07:57:29 -0700 (PDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 14 Apr 2001 15:57:25 +0100 To: rmt@lbl.gov, rm@mash.cs.berkeley.edu cc: Cost264.official@lip6.fr cc: mbone@ISI.EDU cfp: "rem-conf@es.net" , jon Subject: NGC2001 CfP - call for papers, networked group communications workshop Date: Sat, 14 Apr 2001 15:57:24 +0100 Message-ID: <1851.987260244@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk apols for x-posting, but i think this is relevant and of interest to many on these lists and we dont have a tool to remove duplicates at send time:-( C A L L F O R P A P E R S The 3rd International Workshop on Networked Group Communication (NGC 2001) November 7-9, 2001 UCL London, England Organized by UCL 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, as well as performance analysis and evaluation of such mechanisms. The focus of the Workshop is on multicast and networked group communication, right up to session and application level control mechanisms and services. This Workshop is the third and only international event in this area (first workshop was in Pisa, Italy, in November 1999; the second was at Stanford, USA, in November 2000). The workshop will start with half day tutorials on the 7th. The technical program will include two keynotes and invited talks on the 8th and the 9th of November 2001. There may also be a panel discussion as well as a poster session. Authors are invited to submit papers on any issue related to networked group communication, including: application layer multicast and content distribution multipeer applications (distributed interactive applications, games, DIS) applications and services enabled through multicast use of group communication mechanisms to support control plane tasks scalability: overheads, stability, analysis, experiments economic models novel group communication architectures routing, naming, address allocation group and session management techniques QoS and network engineering reliable and semi-reliable protocols wireless and mobile multicast security adaption and congestion control for group communication heterogeneous group communication deployment related issues 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.ucl.ac.uk/research/ngc2001/ Important Dates --------------- Paper Submission: June 4, 2001 Author Notification: August 10, 2001 Camera Ready: September 10, 2001 ----------------------------------------------- For more information, visit the workshop WWW page at: http://www.cs.ucl.ac.uk/research/ngc2001/ >From owner-rmt@listserv.lbl.gov Sun Apr 15 19:01:27 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f3G1vrG16589; Sun, 15 Apr 2001 18:57: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.11.2/8.11.2) with ESMTP id f3G1vpg16585 for ; Sun, 15 Apr 2001 18:57:51 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f3G1vpY12702 for ; Sun, 15 Apr 2001 18:57:51 -0700 (PDT) Received: from kegparty.com (cm20816625250.coralsprings.ispchannel.com [208.166.25.250]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f3G1vfL12638; Sun, 15 Apr 2001 18:57:42 -0700 (PDT) Subject: Biz To Business Database Disc X-Mailer: ALPHA_XMR75_00001SLBL To: mydeez@kukamail.com Message-Id: <3pr6am61yw6p15.80uw4d7gqk3u@kegparty.com> Reply-To: terrywhite@acmemail.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 15 Apr 2001 22:02:10 -0500 From: billyp@grabmail.com Sender: owner-rmt@lbl.gov Precedence: bulk As a dot.com professional you know that it is essential to your teams' success to advertise your web site, business, product, service, or your organizations' cause to the masses. You also know that your marketing and advertising budget limits your options. If you are a Fortune 500 corporation, you have the advantage of being able to book 30 second TV spots during the SuperBowl. Most of us are not in that position though. Besides, did you know that something on the order of 92% of TV viewers run to the washroom at commercial breaks during the program, thereby missing the expensive commercial spot. Q: Of all the various advertising mediums which do you feel is most effective, in cases when you require your prospect to remember your telephone number or web address? Let's outline and agree on a list of the main advertising and marketing mediums first: - Television Commercial - Television Infomercial - Internet Banner Ads (paid for on a click-through basis) - Internet Banner Ads (paid for on an impression basis) - So-Called opted-in email list rental and broadcast - Radio Commercial - Print Media (Newspapers, Magazines) - Print Media (Hand-Outs) - Trade Shows - News or Media organization story or profile on your project - Affiliate Links - Signage - Telemarketing - Direct Mail - Broadcast Fax (not personalized to its recipients) - Broadcast Fax (personalized and to the Attention of its recipients) - Targeted Broadcast Email (personalized or not) Now consider the effectiveness of each advertising choice, remembering that in many cases your audience must still remember a telephone number in order to contact you. Q: Which is the least costly and most effective? E-mail marketing works! Why? There are many reasons, but primarily because people are focused on their monitors while checking their e-mail. Totally focused. In addition, they have a hard copy of your ad on their hard drive, and it is simple for them to forward the ad to their friends and associates as well. You can tell your story with more words and target your list to particular types of recipients or geographical areas. We offer some of the best delivery and bulk e-mail prices on the Internet. Bulk e-mail can get you the best exposure on the net. What makes this kind of advertising so effective is the fact that you go to the potential customer. Not like search engines or print ads that the potential customer has to do all the searching. Dollar for dollar bulk e-mailing is also the most economical. We do all the mailing for you. You just provide us with the ad! It's that simple! What we offer is simple: *General Lists or other ISPs #100,000 Emails $495.00 #250,000 Emails $995.00 #500,000 Emails $1,495.00 #1,000,000 Emails $2,495.00 #2,500,000 Emails $4,995.00 #5,000,000+ Emails (Call for Quote) WE ALSO HAVE LARGER PACKAGES! *Targeted Lists (Starting @): #100,000 Emails $995.00 #250,000 Emails $1,495.00 #500,000 Emails $2,995.00 #1,000,000 Emails (Call for Quote) METHOD OF PAYMENT, CASHIERS CHECK MONEY ORDER OR BANK WIRE. $$$GET AN ADDITIONAL FREE 25% ON TOP OF EVERY ORDER... IF YOU ORDER WITHIN 5 DAYS OF RECIEVING THIS MESSAGE! Call for bigger packages! ORDER NOW!!! AND GET THE RIGHT EXPOSURE! For more details on Email Services, please call: #954.340.1628 (US & International) IF YOU ARE THE DO IT YOURSLF TYPE OR ARE STILL USING TRADITONAL MARKETING TECHNICS, YOU MUST TAKE A LOOK AT THE 8 1/2 MILLION BUSINESS TO BUSINESS DATABASE!! Our 3.0 Version B2B Database Will Go Online and Sell For 2.5 to 25 Cents Per Record in early July! (Extended Due to Delays From The 1st) You can now access contact data for over 8.5 Million Records. All of them have their own .com .org or .net domain name, making them serious prospects for Internet business. Our data base readily accessible on CD-Rom, list the Names, Contact Information, Physical Address, Phone #, Fax #, SIC Industry Code, URL (Domain Name), and Contact Email Address which you can use to efficiently target companies worldwide. Over 8.5 Million Physical Addresses let you target businesses by Country, State, City, Province, Zip Code, Area Code or by using the SIC Industry Code. The data comes in a Comma-Delimited ASCII format which makes it easy to manipulate and Import/Export records to your Contact-Management, Spreadsheet, analysis and Broadcasting Applications. We^Òd be happy to give you rough counts for your industry target market. We also build databases to order and carry more than a dozen other data bases both Domestic and International ( B2B and B2C). Please send me more info about: [ ] Master Disc 2000 8.5 Million Records, Cost US$799.00 [ ] Online Updates & Download Access Cost US$199.00 (Annually) [ ] Commercial Email Services & Products Note: Not all records contain complete data, call for breakdowns. For more details on Database, please call: #954.340.1628 (US & International) or fax form below to: #954.753.2846 (Make Sure To Mention Reseller Id #1789 When Calling) Company name: ___________________________________________ Web Site Url: ___________________________________________ Contact name: ___________________________________________ Email: __________________________________________________ Phone: __________________________________________________ Fax: ___________________________________________________ Street address: _________________________________________ City, Zip, State: _______________________________________ Country: ________________________________________________ Check the following that apply: _____ Please Notify Me Of Online Web Site & Register Me For Access Using The Information Above. Also Please, Send Additional Information on: _____ Online Adult & Gaming Owner/Operaters _____ Online Adult Subscribers & Online Gamers Databases _____ Online Billing/Credit Card Processing _____ Emailing Services and Databases _____ Search Engine Positioning _____ International Contact Lists _____ Buying / Selling Traffic _____ Web Site Hosting Services _____ Internet Bandwidth Services (T-1's Starting at $999.00) _____ Other:_______________________________ ############################################################################## ############################################# THIS MESSAGE IS BEING SENT IN COMPLIANCE OF THE EMAIL BILL: SECTION 301. PER SECTION, PARAGRAPH (a) (2) (c) of S. 1618. To discontinue receipt of further notice at not cost and to be removed from our database, please reply with the word "Remove" in subject. Or call us at #954.340.1628 leave your email address for removal from the database and future mailings. Any attempts to disrupt the removal email address etc., will not allow us to be able to retrieve and process the remove requests. ############################################################################## ############################################# .0401601 >From owner-rmt@listserv.lbl.gov Tue Apr 24 14:08:56 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f3OL6i512277; Tue, 24 Apr 2001 14:06: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.11.2/8.11.2) with ESMTP id f3OL6gg12273 for ; Tue, 24 Apr 2001 14:06:42 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f3OL6f416216 for ; Tue, 24 Apr 2001 14:06:41 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f3OL6eL16205 for ; Tue, 24 Apr 2001 14:06:40 -0700 (PDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16470; Tue, 24 Apr 2001 14:06:38 -0700 (PDT) Received: from maple.East.Sun.COM (maple.East.Sun.COM [129.148.75.29]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA13194; Tue, 24 Apr 2001 17:06:36 -0400 (EDT) Received: from maple (maple [129.148.75.29]) by maple.East.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA14030; Tue, 24 Apr 2001 17:06:34 -0400 (EDT) Message-Id: <200104242106.RAA14030@maple.East.Sun.COM> Date: Tue, 24 Apr 2001 17:06:34 -0400 (EDT) From: Miriam Kadansky - SUN Microsystems Reply-To: Miriam Kadansky - SUN Microsystems Subject: Java Reliable Multicast website now available To: rm@mash.CS.Berkeley.EDU, rmt@lbl.gov MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LdUSWtU9g7zcrQDnx7931Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-rmt@lbl.gov Precedence: bulk We are very pleased to announce that the Java Reliable Multicast Service is now downloadable from Sun Microsystems Laboratories. Please visit the web site at http://www.experimentalstuff.com/Technologies/JRMS/ And check out this article about JRMS at javaworld.com: http://www.javaworld.com/javaworld/jw-04-2001/jw-0420-javadev.html We will continue to work on standards for Reliable Multicast within the IETF. Also, Sun is hosting a mailing list for JRMS users, and we will participate as our other commitments allow. However, we have no plans to make additional enhancements to JRMS. Thank you for your support and encouragement over the years. We hope the work we've done will be of value to you. Dah Ming Chiu, Miriam Kadansky, and Joe Provino [apologies for multiple copies] >From owner-rmt@listserv.lbl.gov Fri Apr 27 09:46:12 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f3RGfgj13590; Fri, 27 Apr 2001 09:41:42 -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.11.2/8.11.2) with ESMTP id f3RGffg13586 for ; Fri, 27 Apr 2001 09:41:41 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f3RGffP17671 for ; Fri, 27 Apr 2001 09:41:41 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f3RGfaL17651 for ; Fri, 27 Apr 2001 09:41:40 -0700 (PDT) Received: from sporty.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 27 Apr 2001 17:41:20 +0100 to: rm@mash.cs.berkeley.edu, rmt@lbl.gov Subject: couple of infocom papers really need everyones attention Date: Fri, 27 Apr 2001 17:41:18 +0100 Message-ID: <3418.988389678@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk at http://www.ieee-infocom.org/2001/ see tech. program, for Fine-Grained Layered Multicast John Byers (Boston University), Michael Luby (Digital Fountain), Michael Mitzenmacher (Harvard University) and Impact of Network Delay Variation on Multicast Session Performance With TCP-like Congestion Control Augustin Chaintreau (Ecole Normale Superieure), Francois Baccelli (INRIA), Christophe Diot (Sprint) cheers jon >From owner-rmt@listserv.lbl.gov Thu May 10 08:26:19 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f4AFMbk05597; Thu, 10 May 2001 08:22:37 -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.11.2/8.11.2) with ESMTP id f4AFMag05593 for ; Thu, 10 May 2001 08:22:36 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f4AFMaG11633 for ; Thu, 10 May 2001 08:22:36 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f4AFMZF11628 for ; Thu, 10 May 2001 08:22:35 -0700 (PDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 10 May 2001 16:22:31 +0100 To: rmt@lbl.gov, rm@mash.cs.berkeley.edu Subject: RTT estimation paper of relevance Date: Thu, 10 May 2001 16:22:30 +0100 Message-ID: <13493.989508150@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk tristan notied a neat paper at infocom this yaer - could be useful in RMT work (e.g. retransmission and congestion control/rate estimation) ------- Forwarded Message Measuring delays without needing synchronised clocks: Estimating One-way Delays from Cyclic-Path Delay Measurements, Omer Gurew= itz = (Technion), Moshe Sidi (Technion), INFOCOM 2001 http://infocom.ucsd.edu/papers/232.ps Cheers, Tristan ------- End of Forwarded Message >From owner-rmt@listserv.lbl.gov Fri May 25 03:19:56 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f4PADnF17369; Fri, 25 May 2001 03:13:49 -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.11.2/8.11.2) with ESMTP id f4PADlg17356 for ; Fri, 25 May 2001 03:13:47 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f4PADk127009 for ; Fri, 25 May 2001 03:13:46 -0700 (PDT) Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f4PADjF27003 for ; Fri, 25 May 2001 03:13:45 -0700 (PDT) Received: (qmail 16450 invoked by alias); 25 May 2001 10:13:38 -0000 Delivered-To: GMX delivery to claudia%carmendorn@gmx.de Received: (qmail 16441 invoked by uid 0); 25 May 2001 10:13:38 -0000 Date: Fri, 25 May 2001 12:13:38 +0200 (MEST) From: Carmen Dornbach MIME-Version: 1.0 X-Priority: 3 (Normal) X-Authenticated-Sender: #0010896236@gmx.net X-Authenticated-IP: [195.93.64.171] Message-ID: <29063.990785618@www31.gmx.net> X-Mailer: WWW-Mail 1.5 (Global Message Exchange) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: claudia%CarmenDorn@gmx.de Sender: owner-rmt@lbl.gov Precedence: bulk Hallo, wir sind 9 heiße und hemmungslose Girls, nämlich Babette, Moni, Carola, Angelique, Michelle, Jessica, Melissa, Iris und Sandra, die ein geiles tabuloses Telefonat, oder bei gefallen einen heißen Seitensprung suchen. Ganz wie Du willst :o) Erreichen kannst Du uns direkt unter Telefonnummer: 019085/4794* Am Telefon können wir uns gleich ein Date ausmachen. Oder hast Du etwa keine Lust auf einen wilden One Night Stand ? Wir schon :o) ... also beeil Dich .... fg Wenn Du uns vorher sehen möchtest, dann schau einfach mal auf unserer Homepage vorbei ... dort erfährst Du einiges mehr über uns ... www.datingfon.de Unsere intimsten Geheimnisse verraten wir Dir natürlich nur direkt ... wir können sie Dir ja am Telefon ins Ohr flüstern ... Also alles ist möglich weil wir auf alles Lust haben und noch so vieles ausprobieren wollen .... hoffentlich mit Dir. ... 019085/4794* Lass uns nicht so lange warten .... Bussi bis gleich Deine süssen Girls (* E.p. DM 3,63/min.) -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- U2 Konzertreisen inkl. VIP-Package Hier Eventreisen zur U2-Tour bei Getgo.de online buchen! http://www.getgo.de/cgi-bin/TDoc.dll?doc=reisen/rei_kon_sta&affiliate=GMX >From owner-rmt@listserv.lbl.gov Thu May 31 09:23:21 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f4VGINx23845; Thu, 31 May 2001 09:18:23 -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.11.2/8.11.2) with ESMTP id f4VGIMg23841 for ; Thu, 31 May 2001 09:18:22 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f4VGILY01103 for ; Thu, 31 May 2001 09:18:21 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f4VGIKF01089 for ; Thu, 31 May 2001 09:18:20 -0700 (PDT) Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 31 May 2001 17:18:16 +0100 To: rm@mash.CS.Berkeley.EDU, rmt@lbl.gov Subject: 2 week extensions for ETT and NGC2001 Date: Thu, 31 May 2001 17:18:12 +0100 Message-ID: <1012.991325892@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk due to many requests (no, not because we havnt had any submissions) BOTH the CfPs for the European Transactions on Telecommunications special issue on From Monitoring to Provisioning: towards closing the loop on Internet Traffic Engineering see http://www.cs.ucl.ac.uk/staff/jon/cfp.txt and the Network Group Communications Workshop see http://www-mice.cs.ucl.ac.uk/ngc2001/ have 2 week extensions - i.e. til jun 14th or so. sorry if you see this more than once! cheers jon p.s. for those not familiar with ETT, see http://www.aei.it/ett.html for more details >From owner-rmt@listserv.lbl.gov Fri Jun 1 09:26:22 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f51GKT328266; Fri, 1 Jun 2001 09:20:29 -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.11.2/8.11.2) with ESMTP id f51GKSg28262 for ; Fri, 1 Jun 2001 09:20:28 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f51GKRv13958 for ; Fri, 1 Jun 2001 09:20:27 -0700 (PDT) Received: from wgs.steeple.plc.uk ([195.188.28.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f51GKPF13951 for ; Fri, 1 Jun 2001 09:20:25 -0700 (PDT) Received: from home.com ([195.188.28.55]) by wgs.steeple.plc.uk with Microsoft SMTPSVC(5.0.2195.1600); Fri, 1 Jun 2001 17:13:26 +0100 From: "L@@K dont throw away!" To: Subject: Have you been hacked by f*ck PoizonBOx? Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 1 Jun 2001 17:20:43 +0100 X-Priority: 1 (Highest) Content-Transfer-Encoding: 8bit Message-ID: X-OriginalArrivalTime: 01 Jun 2001 16:13:26.0343 (UTC) FILETIME=[C9E2AD70:01C0EAB5] Sender: owner-rmt@lbl.gov Precedence: bulk I've created an online community called "Have you been hacked by f*ck PoizonBOx?". http://www.delphi.com/PoizonBOx/start/ Please join the discussion! With the message board, you can view discussion folders quickly in the left-hand column and read up to 20 messages at a time. You can even attach files (such as pictures and programs) directly to messages -- just like e-mail. It's fast, easy, and efficient. As the Forum "Host," I control the specific features of the Forum. The other options include real-time Chat, voice chat, and polls. I can also choose to make it public or private. I've chosen to make this Forum public so anyone can participate, so feel free to tell your friends. The best way into my Forum is at the following URL: http://www.delphi.com/PoizonBOx/start/ I'm eager to hear comments and suggestions. Let's get the conversation started! Best regards, >From owner-rmt@listserv.lbl.gov Thu Jun 7 18:37:11 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f581XZq00978; Thu, 7 Jun 2001 18:33: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.11.2/8.11.2) with ESMTP id f581XY100974 for ; Thu, 7 Jun 2001 18:33:34 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f581XXv08852 for ; Thu, 7 Jun 2001 18:33:33 -0700 (PDT) Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.2.33]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f581XX608849 for ; Thu, 7 Jun 2001 18:33:33 -0700 (PDT) Received: from ren.eecis.udel.edu by mail.eecis.udel.edu id aa16170; 7 Jun 2001 21:33 EDT Date: Thu, 7 Jun 2001 21:33:08 -0400 (EDT) From: Xinming He To: rmt@lbl.gov MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Subject: a quick questions about NCF in PGM Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rmt@lbl.gov Precedence: bulk When a network element(PGM capable) receives a NCF from its upstream parent, will it forward the NCF to its downstream nodes, or discard the NCF after establishing the neccessary state in itself? In the PGM sepcification, it just says the NCF will be multicasted the group. Should the network element really forward it to its downstream nodes when receiving one from its parent? If yes, there seems to be too much control traffic as a result of packet loss? >From owner-rmt@listserv.lbl.gov Thu Jun 7 18:55:48 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f581sMg01009; Thu, 7 Jun 2001 18:54: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.11.2/8.11.2) with ESMTP id f581sL101005 for ; Thu, 7 Jun 2001 18:54:21 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f581sKA11152 for ; Thu, 7 Jun 2001 18:54:20 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f581sK611147 for ; Thu, 7 Jun 2001 18:54:20 -0700 (PDT) Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.18]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f581s2906522; Thu, 7 Jun 2001 18:54:02 -0700 (PDT) Date: Thu, 7 Jun 2001 18:53:58 -0700 (PDT) From: Nidhi Bhaskar Reply-To: Nidhi Bhaskar To: Xinming He cc: Subject: Re: a quick questions about NCF in PGM In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rmt@lbl.gov Precedence: bulk On Thu, 7 Jun 2001, Xinming He wrote: > When a network element(PGM capable) receives a NCF from its upstream > parent, will it forward the NCF to its downstream nodes, or discard the > NCF after establishing the neccessary state in itself? In the PGM NCFs travel only 1 PGM hop. > sepcification, it just says the NCF will be multicasted the group. Should > the network element really forward it to its downstream nodes when > receiving one from its parent? If yes, there seems to be too much control > traffic as a result of packet loss? They are multicast to the group address so that they can traverse any non-PGM capable routers in the tree to reach downstream PGM nodes. They carry the router alert option which causes each router to examine them hop-by-hop and a PGM capable router to stop them from being forwarded further than a single PGM hop. Thanks, Nidhi. > > > > > >From owner-rmt@listserv.lbl.gov Fri Jun 8 07:31:58 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f58ESOe02650; Fri, 8 Jun 2001 07:28: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 (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f58ESM102646 for ; Fri, 8 Jun 2001 07:28:23 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f58ESM421893 for ; Fri, 8 Jun 2001 07:28:22 -0700 (PDT) Received: from issaspam-ny01.ssmb.com (mail1.ssmb.COM [199.67.139.25]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f58ESK621871 for ; Fri, 8 Jun 2001 07:28:21 -0700 (PDT) Received: from imbcorp-ny02.ny.ssmb.com (imbcorp-ny02-qfe0 [162.124.152.39]) by issaspam-ny01.ssmb.com (8.11.0/8.11.0/SSMB_EXT/1.2) with ESMTP id f58ERtV05603 for ; Fri, 8 Jun 2001 10:27:55 -0400 (EDT) Received: from imbicmr-ny01.sbi.com (imbicmr-ny01.ny.ssmb.com [162.124.154.48]) by imbcorp-ny02.ny.ssmb.com (8.11.0/8.11.0/SSMB_QQQ_IN/1.1) with ESMTP id f58EQMH04704 for ; Fri, 8 Jun 2001 10:26:22 -0400 (EDT) Received: (from uucp@localhost) by imbicmr-ny01.sbi.com (8.11.0/8.11.0/SSMB_ICMR/1.1) id f58EQMo13575 for ; Fri, 8 Jun 2001 10:26:22 -0400 (EDT) X-Authentication-Warning: imbicmr-ny01.sbi.com: uucp set sender to using -f Received: from nodnsquery(10.96.1.10) by imbicmr-ny01.sbi.com via smap (V4.0) id xma013510; Fri, 8 Jun 01 10:26:10 -0400 Received: by Z1111141.core.afcc.com with Internet Mail Service (5.5.2651.58) id ; Fri, 8 Jun 2001 09:26:10 -0500 Message-ID: <6EF6F5B5843ED211A4800060083FFC750A2D6DBF@Z1111221.core.afcc.com> From: "Eckhoff, Michael" To: "'rmt@lbl.gov'" Subject: Multicast and Cisco 6500 switches Date: Fri, 8 Jun 2001 09:26:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-rmt@lbl.gov Precedence: bulk If this question is way out of line for this group, please advise. We are noticing significant problems with multicast on Cisco 6500 series layer 3 switches (with dual MSFCs). I am going to do additional testing at one of Cisco's labs this weekend, but if anyone has any input beforehand, I'd greatly appreciate it. Also, if you have this working well, if you can forward any configs/IOS versions/etc. I'd appreciate it. What I am expecting to find is duplicate packets or dropped packets under high utilization. I have found that this is more than what just LRMP can handle. The end application ends up totally unusable. With this problem, what is an "acceptable" amount of loss (and possible packet duplication) for reliable multicast to remain reliable? Thanks Michael R. Eckhoff citigroup/Associates >From owner-rmt@listserv.lbl.gov Fri Jun 8 11:11:50 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f58IAvP03583; Fri, 8 Jun 2001 11:10:57 -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.11.2/8.11.2) with ESMTP id f58IAu103579 for ; Fri, 8 Jun 2001 11:10:56 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f58IAtG06619 for ; Fri, 8 Jun 2001 11:10:56 -0700 (PDT) Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f58IAs606607 for ; Fri, 8 Jun 2001 11:10:54 -0700 (PDT) Received: (qmail 16275 invoked from network); 8 Jun 2001 18:10:45 -0000 Received: from mail.intranet (10.1.1.37) by mx.digitalfountain.com with SMTP; 8 Jun 2001 18:10:45 -0000 Received: from nui (dhcp-10-1-3-239.intranet [10.1.3.239]) by mail.intranet (8.9.3/8.9.3) with SMTP id LAA08920 for ; Fri, 8 Jun 2001 11:10:19 -0700 X-Authentication-Warning: mail.intranet: Host dhcp-10-1-3-239.intranet [10.1.3.239] claimed to be nui From: "Gavin Vess" To: Subject: RE: Multicast and Cisco 6500 switches Date: Fri, 8 Jun 2001 11:10:18 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000A_01C0F00B.99EFF400" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C0F00B.99EFF400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGksDQoNCkEgZnJpZW5kIGZvcndhcmQgbWUgYSBjb3B5IG9mIHlvdXIgZW1haWwuICBJIGp1c3Qg c2F3IHNvbWV0aGluZyBlbHNlIHRoYXQgbWlnaHQgaW50ZXJlc3QgeW91IChhdHRhY2hlZCBiZWxv dykuICBJIGFtIHF1aXRlIGludGVyZXN0ZWQgaW4geW91ciBmaW5kaW5ncyB0aGlzIHdlZWtlbmQg cmVsYXRpbmcgdG8gTXVsdGljYXN0IGFuZCBDaXNjbyBzd2l0Y2hlcy4NCg0KUGVyaGFwcyB0aGUg YXR0YWNoZWQgbWF0cml4IG9mIHdoYXQgQ2lzY28gbW9kZWxzIGFuZCBJT1MncyBzdXBwb3J0IGZv ciBtdWx0aWNhc3Qgd2lsbCBiZSBvZiBpbnRlcmVzdCB0byB5b3U/DQoNCg0KPiBCdWcgcmVwb3J0 IG9uIHRoZSBPTlMgMTU0NTQgYW5kIDE1MzI3Og0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPg0KPiBPTlMgMTU0NTQgYW5kIE9OUyAxNTMyNzogRXRoZXJuZXQgTGlu ZSBDYXJkIFBhY2tldCBGb3J3YXJkaW5nIExpbWl0YXRpb25zDQo+ID09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+IGNhbiBjYXVz ZSBwcm9ibGVtcyB3aXRoIG11bHRpY2FzdCB0cmFmZmljDQo+IFVuaWNhc3QgcGFja2V0IGxvc3Mg Y2FuIG9jY3VyIHdoZW4gRmxvb2QNCj4gPC91bml2ZXJjZC9jYy90ZC9kb2MvY2lzaW50d2svaWNz L2NzMDA2Lmh0bT4gb3IgTXVsdGljYXN0IHRyYWZmaWMgaXMNCj4gcHJlc2VudC4NCj4NCj4gSWYg TXVsdGljYXN0IGlzIHVzZWQgZm9yIHN1Y2ggYXBwbGljYXRpb25zIGFzIHZpZGVvIGRpc3RyaWJ1 dGlvbiwNCj4gc2lnbmlmaWNhbnQgbG9zcyBvZiBVbmljYXN0IGFuZCBNdWx0aWNhc3QgdHJhZmZp YyB3aWxsIHJlc3VsdC4gVGhlc2UgY2FyZHMNCj4gd2VyZSBub3QgZGVzaWduZWQgZm9yIGFuZCBz aG91bGQgbm90IGJlIHVzZWQgZm9yIHN1Y2ggYXBwbGljYXRpb25zLg0KPg0KPiBJZiB0aGUgTXVs dGljYXN0IGFuZCBGbG9vZCB0cmFmZmljIGlzIHJhcmUgYW5kIGxvdy1yYXRlLCBhcyBvY2N1cnMg aW4gbW9zdA0KPiBuZXR3b3JrcyBkdWUgdG8gY2VydGFpbiBjb250cm9sIHByb3RvY29scyBhbmQg b2NjYXNpb25hbCBsZWFybmluZyBvZiBuZXcNCk1BQw0KPiBhZGRyZXNzZXMsIHRoZSBsb3NzIG9m IHVuaWNhc3QgZnJhbWVzIHdpbGwgYmUgcmFyZSBhbmQgbGlrZWx5IHVubm90aWNlYWJsZQ0KPiBo dHRwOi8vd3d3LmNpc2NvLmNvbS93YXJwL3B1YmxpYy83NzAvZm4xMzE3MS5zaHRtbA0KPg0KPiBN eSB1bmRlcnN0YW5kaW5nIGlzIHRoaXMgd2lsbCBiZSBmaXggd2l0aCBhIG5ldyByZWxlYXNlIG9m IHRoZSBFdGhlcm5ldA0KbGluZQ0KPiBjYXJkLg0KPg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IG93bmVyLXJtdEBsYmwuZ292IFttYWlsdG86b3duZXItcm10QGxibC5n b3ZdT24gQmVoYWxmIE9mIEVja2hvZmYsDQo+IE1pY2hhZWwNCj4gU2VudDogRnJpZGF5LCBKdW5l IDA4LCAyMDAxIDc6MjYgQU0NCj4gVG86ICdybXRAbGJsLmdvdicNCj4gU3ViamVjdDogTXVsdGlj YXN0IGFuZCBDaXNjbyA2NTAwIHN3aXRjaGVzDQo+IA0KPiANCj4gDQo+IElmIHRoaXMgcXVlc3Rp b24gaXMgd2F5IG91dCBvZiBsaW5lIGZvciB0aGlzIGdyb3VwLCBwbGVhc2UgYWR2aXNlLg0KPiAN Cj4gV2UgYXJlIG5vdGljaW5nIHNpZ25pZmljYW50IHByb2JsZW1zIHdpdGggbXVsdGljYXN0IG9u IENpc2NvIDY1MDAgc2VyaWVzDQo+IGxheWVyIDMgc3dpdGNoZXMgKHdpdGggZHVhbCBNU0ZDcyku ICBJIGFtIGdvaW5nIHRvIGRvIGFkZGl0aW9uYWwgDQo+IHRlc3RpbmcgYXQNCj4gb25lIG9mIENp c2NvJ3MgbGFicyB0aGlzIHdlZWtlbmQsIGJ1dCBpZiBhbnlvbmUgaGFzIGFueSBpbnB1dCBiZWZv cmVoYW5kLA0KPiBJJ2QgZ3JlYXRseSBhcHByZWNpYXRlIGl0LiAgQWxzbywgaWYgeW91IGhhdmUg dGhpcyB3b3JraW5nIHdlbGwsIA0KPiBpZiB5b3UgY2FuDQo+IGZvcndhcmQgYW55IGNvbmZpZ3Mv SU9TIHZlcnNpb25zL2V0Yy4gSSdkIGFwcHJlY2lhdGUgaXQuDQo+IA0KPiBXaGF0IEkgYW0gZXhw ZWN0aW5nIHRvIGZpbmQgaXMgZHVwbGljYXRlIHBhY2tldHMgb3IgZHJvcHBlZCBwYWNrZXRzIHVu ZGVyDQo+IGhpZ2ggdXRpbGl6YXRpb24uICBJIGhhdmUgZm91bmQgdGhhdCB0aGlzIGlzIG1vcmUg dGhhbiB3aGF0IGp1c3QgTFJNUCBjYW4NCj4gaGFuZGxlLiAgVGhlIGVuZCBhcHBsaWNhdGlvbiBl bmRzIHVwIHRvdGFsbHkgdW51c2FibGUuDQo+IA0KPiBXaXRoIHRoaXMgcHJvYmxlbSwgd2hhdCBp cyBhbiAiYWNjZXB0YWJsZSIgYW1vdW50IG9mIGxvc3MgKGFuZCBwb3NzaWJsZQ0KPiBwYWNrZXQg ZHVwbGljYXRpb24pIGZvciByZWxpYWJsZSBtdWx0aWNhc3QgdG8gcmVtYWluIHJlbGlhYmxlPw0K PiANCj4gVGhhbmtzDQo+IA0KPiBNaWNoYWVsIFIuIEVja2hvZmYNCj4gY2l0aWdyb3VwL0Fzc29j aWF0ZXMNCj4gDQo+IA== ------=_NextPart_000_000A_01C0F00B.99EFF400 Content-Type: text/html; name="Cisco Multicast Support Matrix.htm" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Cisco Multicast Support Matrix.htm" Cisco Multicast Support Matrix
3Dcc/pd/iosw
=20

Table of Contents

Reference Guide

Cisco Multicast Support Matrix

    Part=20 1--Table of Switch features related to IP Multicast
    Part=20 2--Cisco IOS Multicast Features
      Bi-Dir=20 12.1(2)T
      MBGP=20 12.0(7)T
      MDS/MDFS
      MMLS=20 12.0(5)T or 5.3 of C6K or 5.1 of C5K
      MRM=20 12.0(5)T and 12.0(5)S
      MSDP=20 12.0(7)T
      MvoIP=20 12.1(3)T
      PGM=20 Features
        PGM=20 Router Assist 12.0(5)T
        PGM=20 Host 12.1(1)T
      SSM=20 12.1(3)T
      UDLR=20 12.0(3)T.
      CBOS=20 commands
        Multicast=20 proxy support (IGMP Proxy) Release = 2.1.0
    Part=20 3--Multicast Documentation by Switch:
      1200:=20 Not Mentioned
      1420/1220:=20 Manual configuration
      1548:=20 Not mentioned
      1900/2820:=20 CGMP
      2100:=20 Manual configuration
      2800:=20 Manual configuration
      2900XL/3500XL:=20 CGMP
      2948G-L3:=20 CGMP server and Constrained Multicast Flooding = (CMF)
      5000,4000,2926G,2948G=20 and 2980G: CGMP, IGMP-Snooping, RGMP, GMRP
      6000:=20 IGMP-Snooping, RGMP, GMRP
      8500:=20 CMF
    Part=20 4--Glossary

    Reference Guide

    Cisco Multicast Support Matrix

    This document is intended as a quick reference for IP Multicast = features=20 supported by both Cisco IOS and Cisco Switching products.

    Part 1 is a table of IPmc features supported per Catalyst switch = family.

    Part 2 is a list of Cisco IOS IPmc features and their supported = release.

    Part 3 is a list of Catalyst documentation links.

    Part 4 is a glossary.

    Part 1--Table of Switch features related to IP = Multicast=20

      IGMP-Snooping CGMP RGMP**** CMF** GMRP***
    C85xx

    No

    No

    No

    Yes

    No

    C6K

    Yes

    No

    Yes

    No

    Yes

    C5K

    Yes*

    Yes

    Yes

    No

    Yes

    C4K

    No

    Yes

    No

    No

    Yes

    C29xxG

    No

    Yes

    No

    No

    Yes

    C29xx-L3

    No

    No

    No

    Yes

    No

    C29/35 XL

    No

    Yes

    No

    No

    No

    1900/2800

    No

    Yes

    No

    No

    No

    * Requires NFFC II =
    ** CMF is IOS's Router code performing IGMP snooping=20 function.
    *** GMRP requires Host NIC = support.
    **** RGMP inter-operates with RGMP capable routers

    Part 2--Cisco IOS Multicast Features

    Cisco IOS has supported IP multicast since version 10.2 released in = 1995.=20 Cisco IOS 12.0 is the recommended version for all IP multicast = implementations.=20 This is because it supports PIM-SM v2. This is the recommended version = of PIM if=20 interoperability with other vendors is required.

    There are minor incompatibilities when versions 1 and 2 of PIM-SM=20 inter-operate Cisco recommend to use PIM version 2.

    Please visit the IP Multicast Groups external home page. This page is = supported directly by the engineers in the Multicast group, so you can = always be=20 assured of the latest information. The URL is=20 ftp://ftpeng.cisco.com/ipmulticast/index.html

    Bi-Dir 12.1(2)T

    http://www.cisco.com/univercd/cc/td/doc/p= roduct/software/ios121/121newft/121t/121t2/dtbipim.htm

    MBGP 12.0(7)T

    http://www/univercd/cc/td/doc/product/software/ios120/= 120newft/120t/120t7/mbgp.htm

    MDS/MDFS

    Cisco IOS versions 11.1(25.2)CC, 12.0(3.7)S3, and 12.0(4.0.4)S

    http://www.cisco.com/univercd/cc/td/doc/= product/software/ios120/12cgcr/switch_c/xcprt6/xcmds.htm

    MMLS 12.0(5)T or 5.3 of C6K or 5.1 of = C5K

    http://www.cisco.com/univercd/cc/td/doc/= product/software/ios120/120newft/120t/120t5/ipmctmls.htm

    http://www.cisco.com/univercd/cc/td/doc/product/lan/= cat6000/sw_5_3/msfc/mcastmls.htm

    http://www.cisco.com/univercd/cc/td/doc/product/l= an/cat5000/rel_5_1/config/mcastmls.htm

    MRM 12.0(5)T and 12.0(5)S

    http://www/univercd/cc/td/doc/product/software= /ios120/120newft/120limit/120s/120s5/mrm.htm

    http://www/univercd/cc/td/doc/product/software/ios120/1= 20newft/120t/120t5/mrm.htm

    MSDP 12.0(7)T

    http://www/univercd/cc/td/doc/product/software/ios120/= 120newft/120t/120t7/msdp.htm

    MvoIP 12.1(3)T

    http://www.cisco.com/univercd/cc/td/doc/= product/software/ios121/121newft/121t/121t3/dtvmult3.htm

    PGM Features

    PGM Router Assist 12.0(5)T

    http://www/univercd/cc/td/doc/product/software/ios= 120/120newft/120t/120t5/pgmscale.htm

    PGM Host 12.1(1)T

    http://www.cisco.com/univercd/cc/td/doc/= product/software/ios121/121newft/121t/121t1/dtpgmhst.htm

    SSM 12.1(3)T

    http://www.cisco.com/univercd/cc/td/doc/pro= duct/software/ios121/121newft/121t/121t3/dtssm.htm

    UDLR 12.0(3)T.

    http://www.cisco.com/univercd/cc/td/doc/= product/software/ios120/120newft/120t/120t3/igmpudlr.htm

    CBOS commands

    The Cisco Broadband Operating System is modelled after Cisco's=20 Internetworking Operating System (IOS) and features a similar command = syntax and=20 format.

    Multicast proxy support (IGMP Proxy) Release=20 2.1.0

    This ability is also available in regular routers. As "ip igmp=20 helper-address"

    http://www.cisco.com/univercd/cc/td/doc/prod= uct/dsl_prod/c600s/cbos/cbo210rn.htm#xtocid54014

    ht= tp://www.cisco.com/univercd/cc/td/doc/pcat/675.htm#BABIGDDF

    ht= tp://www.cisco.com/univercd/cc/td/doc/pcat/673.htm#BABJFAEJ

    Part 3--Multicast Documentation by = Switch:

    1200: Not Mentioned

    http://www/univercd/cc/td/doc/product/lan/catalyst/ca= t12icg/78656.htm#xtocid1019923

    1420/1220: Manual configuration

    http://www/univercd/cc/td/doc/product/lan/14201220/1= 4_1220u/csoutb.htm#xtocid1901516

    1548: Not mentioned

    http://www/univercd/cc/td/doc/product/lan/ms1548m/cli/1548_cli.htm

    =

    1900/2820: CGMP

    http://www/univercd/cc/td/doc/product/lan/28= 201900/1928v9x/19icg9x/19icweb.htm#xtocid1273983

    http://www/univercd/cc/td/doc/product/lan/2= 8201900/1928v9x/28icg9x/28icoutb.htm#xtocid1786322

    2100: Manual configuration

    http://www/univercd/cc/td/doc/product/lan/cat2100/c21= 00ug/csfo_bnd.htm#xtocid467915

    2800: Manual configuration

    http://www/univercd/cc/td/doc/product/lan/cat2800/fs28/= fs28outb.htm#xtocid2576515

    2900XL/3500XL: CGMP

    http://www/univercd/cc/td/doc/product/lan/c2900xl= /29_35xp/scg/kiconfig.htm#xtocid109398

    2948G-L3: CGMP server and Constrained Multicast = Flooding=20 (CMF)

    http://www/univercd/cc/td/doc/product/l3sw/= 2948g-l3/rel_12_0/config/net_prot.htm#xtocid224329

    Note: Only 128 Multicast groups

    5000,4000,2926G,2948G and 2980G: CGMP, = IGMP-Snooping,=20 RGMP, GMRP

    http://www/univercd/cc/td/doc/product/lan/cat5000/rel_5_4/conf= ig/multi.htm

    Note: CGMP SW version 2.2, IGMP-snooping requires NFFC, GMRP requires = SW=20 5.1

    6000: IGMP-Snooping, RGMP, GMRP

    http://www/univercd/cc/td/doc/product/lan/cat6000/sw_5_4/config= /multi.htm

    8500: CMF

    http://www/univercd/cc/td/doc/product/l= 3sw/8540/rel_12_0/w5_6e/softcnfg/4cfg8500.htm#xtocid612722

    Part 4--Glossary

    Bi-Dir PIM:

    Bi-directional PIM creates a single forwarding tree that allows data = to flow=20 both up and down the tree. This is useful for reducing state in = routers.

    CGMP:

    Cisco Group Management Protocol. This is a Cisco proprietary = protocol. It was=20 designed to enable a Router to inform a Switch that a port associated = with a=20 particular Unicast MAC address requires a Multicast MAC address to be = added.=20 CGMP enables switches without the hardware to support IGMP-snooping to = constrain=20 Multicast data.

    CMF:

    Constrained Multicast Flooding is a CISCO IOS method to perform = IGMP-snooping=20 This was created for Cisco IOS L3 Switches.

    GMRP:

    GARP Multicast Registration Protocol. This is a extension to the GARP = protocol and requires that the Host NIC card inform the GMRP enabled = Switch=20 which group it requires data from. GARP is a layer 2 protocol and so = only=20 implemented on Switches and Host NIC cards.

    IGMP:

    Internet Group management Protocol as defined in RFC 1112 and 2236. = At=20 present there are two version of IGMP. IGMP version 2 incorporates fast = leave=20 capability.

    IGMP-snooping:

    This is not a standard, it is a methodology for switches to intercept = IGMP=20 host reports. If this is implemented In hardware it has no impact on=20 performance. However if this is implemented in Software then performance = of the=20 switch can be expected to decrease.

    MBGP:

    Multi-protocol BGP This enables BGP to carry routing information for = multiple=20 Network Layer protocols EG IPv6, IPX, etc. It can also carry routing = information=20 for Multicast Data. This Allows the use non-congruent multicast and = unicast=20 topologies.

    MDS/MDFS:

    Multicast Distributed Fast Switching. This provides support for = distributed=20 switching of multicast packets on VIPs in Cisco-75xx and on line cards = in the=20 Cisco-12xx.

    Multicast proxy/IGMP Proxy:

    This feature is also available in regular routers as "ip igmp=20 helper-address."

    MMLS:

    Multicast Multi Layer Switching. This is hardware based ASIC, Layer 3 = switching of IP multicast traffic.

    MRM:

    The Multicast Reach-ability Monitor. This feature provides a Traffic=20 Generator, Receiver and Management function. MRM utilizes RTCP data to = verify IP=20 Multicast data delivery throughout the network.

    MSDP:

    Multicast Source Discovery Protocol. This is a protocol to enable = RP's to=20 inform each other of active sources (SA) they are aware of.

    MVoip:

    Cisco MVoIP (Multicast Voice over IP), is used as a replacement for = the=20 traditional `Hoot and Holler' networks used in brokerage firms. Hoot and = Holler=20 systems provide continuous voice conference functionality between remote = sites.=20

    PGM:

    Pragmatic General Multicast. This is a reliable multicast transport = protocol.=20 Routers with the router assist function enabled become involved in the = efficient=20 re-delivery of PGM data. The router only keeps track of which interfaces = need to=20 receive re-transmitted data, they do NOT cache data.

    RGMP:

    RouterPort Group Management Protocol This Protocol is designed to = prevent=20 unwanted IP Multicast traffic from being sent to Multicast routers who = have no=20 requirement for it. It operates with PIM-SM only and requires both the = Switch=20 and the router to Support RGMP.

    SSM:

    Source Specific Multicast allows a hosts to explicitly define which = sources=20 it is interested in when joining a multicast group. IGMP v3, URL = Rendezvous=20 Directory (URD) and IGMP v3lite can all be used with SSM.

    UDLR:

    Unidirectional link routing. This provides a way to forward multicast = packets=20 over a physical unidirectional interface (such as a satellite link of = high=20 bandwidth) to stub networks that have a back channel.

    UDLR-Tunnels:

    Applies to unicast and multicast has limited scalability.

    IGMP-UDLR:

    Applies to multicast only, the preferred method.




    Posted: Mon Aug 21 14:34:09 PDT 2000
    Copyright=20 1989-2000=A9Cisco Systems Inc. =

    ------=_NextPart_000_000A_01C0F00B.99EFF400-- >From owner-rmt@listserv.lbl.gov Mon Jun 11 03:55:09 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f5BAk0q07147; Mon, 11 Jun 2001 03:46:00 -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.11.2/8.11.2) with ESMTP id f5BAjx107143 for ; Mon, 11 Jun 2001 03:45:59 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5BAjw526088 for ; Mon, 11 Jun 2001 03:45:58 -0700 (PDT) Received: from marratech.com (habanero.marratech.com [195.196.47.9] (may be forged)) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5BAjv626085 for ; Mon, 11 Jun 2001 03:45:57 -0700 (PDT) Received: from cdt.luth.se (dhcp025.lulea.marratech.com [195.196.47.25]) by marratech.com (8.9.3/8.9.3) with ESMTP id MAA31587; Mon, 11 Jun 2001 12:45:39 +0200 (CEST) Message-ID: <3B24A210.5276F01F@cdt.luth.se> Date: Mon, 11 Jun 2001 12:48:48 +0200 From: Jeremiah Scholl Reply-To: jeremiah@cdt.luth.se X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rmt@lbl.gov, peppar@cdt.luth.se Subject: PGMCC and unicast Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-rmt@lbl.gov Precedence: bulk I have a question for the group regarding the Internet-Draft for PGMCC that you has submitted for standardization. In PGMCC "the acker" (worst-case receiver) sends out an ack for each data packet received and the sender uses this information to adjust its send rate. The internet-draft for PGMCC does not specify if acks are unicast to the sender or if it is acceptable to multicast them to the entire group. This question is in regards to a joint project between Luleå Techinical University and Marratech AB. Marratech is an emeetings software company and the engineers here feel that due to the use of firewalls, it is not realistic to assume that unicast connections will be available when deploying their products on the Internet. Some clarification on this point would be helpfull. Thanks, Jeremiah >From owner-rmt@listserv.lbl.gov Mon Jun 11 14:48:07 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f5BLl9A10873; Mon, 11 Jun 2001 14:47: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.11.2/8.11.2) with ESMTP id f5BLl7110869 for ; Mon, 11 Jun 2001 14:47:07 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5BLl7W02297 for ; Mon, 11 Jun 2001 14:47:07 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5BLl5602290 for ; Mon, 11 Jun 2001 14:47:05 -0700 (PDT) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5BLko915722; Mon, 11 Jun 2001 14:46:50 -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 OAA01182; Mon, 11 Jun 2001 14:46:50 -0700 (PDT) Message-Id: <200106112146.OAA01182@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI] To: jeremiah@cdt.luth.se cc: rmt@lbl.gov, peppar@cdt.luth.se, luigi@iet.inipi.it Subject: Re: PGMCC and unicast In-Reply-To: Your message of "Mon, 11 Jun 2001 12:48:48 +0200." <3B24A210.5276F01F@cdt.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Mon, 11 Jun 2001 14:46:50 -0700 From: Lorenzo Vicisano Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by SpamWall.lbl.gov id f5BLl8110870 Sender: owner-rmt@lbl.gov Precedence: bulk Jeremiah, In message <3B24A210.5276F01F@cdt.luth.se>, Jeremiah Scholl writes: > I have a question for the group regarding the Internet-Draft for PGMCC > that you has submitted for standardization. In PGMCC "the acker" > (worst-case receiver) sends out an ack for each data packet received and > the sender uses this information to adjust its send rate. The > internet-draft for PGMCC does not specify if acks are unicast to the > sender or if it is acceptable to multicast them to the entire group. the assumption in the draft is that ACKs are sent unicast and we should make it clear if it currently isn't. Although there might be potential advantages in multicasting them to the entire session, I don't think that these pay off for the added overhead (i.e. significant amount of added traffic). Furthermore, a criteria defined in RMT is that protocols should work without multicast feedback, if possible. This requirement comes from network infrastructure consideration (e.g. some IP multicast protocol, like SSM, are asymmetric). > > This question is in regards to a joint project between Luleå Techinical > University and Marratech AB. Marratech is an emeetings software company > and the engineers here feel that due to the use of firewalls, it is not > realistic to assume that unicast connections will be available when > deploying their products on the Internet. Some clarification on this > point would be helpfull. Are you suggesting that potential PGM-receivers will be able to source multicast but will not be able to send unicast, or are you talking about the source-side ? thanks, Lorenzo >From owner-rmt@listserv.lbl.gov Mon Jun 11 15:18:43 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f5BMISX10940; Mon, 11 Jun 2001 15:18:28 -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.11.2/8.11.2) with ESMTP id f5BMIR110936 for ; Mon, 11 Jun 2001 15:18:27 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5BMIQG14291 for ; Mon, 11 Jun 2001 15:18:26 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5BMIO614283 for ; Mon, 11 Jun 2001 15:18:24 -0700 (PDT) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5BMHe910934; Mon, 11 Jun 2001 15:17:40 -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 PAA01273; Mon, 11 Jun 2001 15:17:35 -0700 (PDT) Message-Id: <200106112217.PAA01273@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI] to: jeremiah@cdt.luth.se cc: rmt@lbl.gov, peppar@cdt.luth.se, luigi@iet.unipi.it Subject: Re: PGMCC and unicast In-Reply-To: Your message of "Mon, 11 Jun 2001 14:46:50 PDT." <200106112146.OAA01182@lorenzo-u10.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Mon, 11 Jun 2001 15:17:35 -0700 From: Lorenzo Vicisano Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by SpamWall.lbl.gov id f5BMIR110937 Sender: owner-rmt@lbl.gov Precedence: bulk [resending with correct address list] In message <200106112146.OAA01182@lorenzo-u10.cisco.com>, Lorenzo Vicisano writes: > Jeremiah, > > In message <3B24A210.5276F01F@cdt.luth.se>, > Jeremiah Scholl writes: > > I have a question for the group regarding the Internet-Draft for PGMCC > > that you has submitted for standardization. In PGMCC "the acker" > > (worst-case receiver) sends out an ack for each data packet received and > > the sender uses this information to adjust its send rate. The > > internet-draft for PGMCC does not specify if acks are unicast to the > > sender or if it is acceptable to multicast them to the entire group. > > the assumption in the draft is that ACKs are sent unicast and > we should make it clear if it currently isn't. > Although there might be potential advantages in multicasting > them to the entire session, I don't think that these pay off > for the added overhead (i.e. significant amount of added traffic). > Furthermore, a criteria defined in RMT is that protocols should > work without multicast feedback, if possible. This requirement > comes from network infrastructure consideration (e.g. some > IP multicast protocol, like SSM, are asymmetric). > > > > > This question is in regards to a joint project between Luleå Techinical > > University and Marratech AB. Marratech is an emeetings software company > > and the engineers here feel that due to the use of firewalls, it is not > > realistic to assume that unicast connections will be available when > > deploying their products on the Internet. Some clarification on this > > point would be helpfull. > > Are you suggesting that potential PGM-receivers will be able to source > multicast but will not be able to send unicast, or are you talking about > the source-side ? > > thanks, > Lorenzo >From owner-rmt@listserv.lbl.gov Mon Jun 11 15:33:23 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f5BMXGt10968; Mon, 11 Jun 2001 15:33:16 -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.11.2/8.11.2) with ESMTP id f5BMXF110964 for ; Mon, 11 Jun 2001 15:33:15 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5BMXEA18947 for ; Mon, 11 Jun 2001 15:33:14 -0700 (PDT) Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5BMXD618942 for ; Mon, 11 Jun 2001 15:33:13 -0700 (PDT) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id AAA79639; Tue, 12 Jun 2001 00:28:56 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200106112228.AAA79639@info.iet.unipi.it> Subject: Re: PGMCC and unicast In-Reply-To: <200106112217.PAA01273@lorenzo-u10.cisco.com> from Lorenzo Vicisano at "Jun 11, 2001 03:17:35 pm" To: Lorenzo Vicisano Date: Tue, 12 Jun 2001 00:28:56 +0200 (CEST) CC: jeremiah@cdt.luth.se, rmt@lbl.gov, peppar@cdt.luth.se, luigi@iet.unipi.it 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 As Lorenzo said, ACKs are supposed to be unicast to the sender. I cannot see any advantage in multicasting them to the session (they cannot be used to elicit feedback from potential ackets, because in PGMCC the receivers do not have an RTT estimate). As for the firewall issue: I am unclear on what is your point when you say > and the engineers here feel that due to the use of firewalls, it is not > realistic to assume that unicast connections will be available when > deploying their products on the Internet. do you really mean unicast ? If you are afraid that netadmins are blindly blocking traffic and you have no input on what services to let through, then your only option is probably to encapsulate everything into UDP packets on port 53 (DNS) ... But if you want to use PGM, you need to tell the netadmin "listen, i need protocol 113 to get through, and bidirectional connectivity (for NAKs), at which point asking unicast is the least of your worries. cheers luigi > > In message <3B24A210.5276F01F@cdt.luth.se>, > > Jeremiah Scholl writes: > > > I have a question for the group regarding the Internet-Draft for PGMCC > > > that you has submitted for standardization. In PGMCC "the acker" -----------------------------------+------------------------------------- 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 Tue Jun 12 01:12:19 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f5C8B6i11849; Tue, 12 Jun 2001 01:11: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.11.2/8.11.2) with ESMTP id f5C8B4111845 for ; Tue, 12 Jun 2001 01:11:04 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5C8B4k17369 for ; Tue, 12 Jun 2001 01:11:04 -0700 (PDT) Received: from marratech.com (habanero.marratech.com [195.196.47.9] (may be forged)) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5C8B2617361 for ; Tue, 12 Jun 2001 01:11:03 -0700 (PDT) Received: from cdt.luth.se (dhcp025.lulea.marratech.com [195.196.47.25]) by marratech.com (8.9.3/8.9.3) with ESMTP id KAA42745 for ; Tue, 12 Jun 2001 10:10:55 +0200 (CEST) Message-ID: <3B25CF4F.6F930370@cdt.luth.se> Date: Tue, 12 Jun 2001 10:14:07 +0200 From: Jeremiah Scholl X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rmt@lbl.gov Subject: Re: PGMCC and unicast References: <200106112228.AAA79639@info.iet.unipi.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk I am asking these questions in regard to using PGMCC with SRM like protocols or more specifically NORM once it is standardized, not for use in conjunction with PGM. Marratech would like to make sure that it will be able to use the standardized NACK based protocol and standardized congestion control scheme that will accompany it. I proposed my question to the group because if PGMCC uses unicast we feel that it will not be compatible with Marratech's products. This is due to hosts often being on different networks with firewalls inbetween them. So, we will need an additional congestion control scheme to be standardized for use with NORM. I do have an idea for a solution to this problem and would really like some feedback from the group regarding it. PGMCC has the receiver unicast acks in order to get a more complete set of which packets are lost by the worst-case receiver. This information is not available in SRM due to the use of suppression timers. However, this same information can be made available to the sender in SRM by having the designated worst-case receiver stop using these suppression timers. All other receivers would still use suppression timers like normal and would have their NACKs suppressed. This solution has the benifit that it is low-weight and will also lead to faster recovery times for packets that are lost by the worst-case receiver. Since there will only be one worst-case receiver at any given time it should not lead to more redundant NACKs than SRM does. I realize that the solution does require us to wonder a bit away from the origional SRM framework so I would really like some comments on it. Can anyone give me a reason why this solution would not work? Some thoughts would be nice. Jeremiah Luigi Rizzo wrote: > As Lorenzo said, ACKs are supposed to be unicast to the sender. > I cannot see any advantage in multicasting them to the session > (they cannot be used to elicit feedback from potential ackets, > because in PGMCC the receivers do not have an RTT estimate). > > As for the firewall issue: I am unclear on what is your point when you say > > > and the engineers here feel that due to the use of firewalls, it is not > > realistic to assume that unicast connections will be available when > > deploying their products on the Internet. > > do you really mean unicast ? > > If you are afraid that netadmins are blindly blocking traffic and you > have no input on what services to let through, then your > only option is probably to encapsulate everything into > UDP packets on port 53 (DNS) ... > > But if you want to use PGM, you need to tell the netadmin "listen, > i need protocol 113 to get through, and bidirectional connectivity > (for NAKs), at which point asking unicast is the least of your > worries. > > cheers > luigi > > > > In message <3B24A210.5276F01F@cdt.luth.se>, > > > Jeremiah Scholl writes: > > > > I have a question for the group regarding the Internet-Draft for PGMCC > > > > that you has submitted for standardization. In PGMCC "the acker" > > -----------------------------------+------------------------------------- > 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 Tue Jun 12 04:04:53 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f5CB21l12025; Tue, 12 Jun 2001 04:02: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.11.2/8.11.2) with ESMTP id f5CB1x112021 for ; Tue, 12 Jun 2001 04:01:59 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5CB1w600073 for ; Tue, 12 Jun 2001 04:01:58 -0700 (PDT) Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5CB1v600070 for ; Tue, 12 Jun 2001 04:01:57 -0700 (PDT) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id MAA83432; Tue, 12 Jun 2001 12:57:42 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200106121057.MAA83432@info.iet.unipi.it> Subject: Re: PGMCC and unicast In-Reply-To: <3B25CF4F.6F930370@cdt.luth.se> from Jeremiah Scholl at "Jun 12, 2001 10:14:07 am" To: Jeremiah Scholl Date: Tue, 12 Jun 2001 12:57:42 +0200 (CEST) CC: rmt@lbl.gov 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 Jeremiah, i think you are addressing a few different issues in this msg. First one is "what kind of connectivity should we assume between source(s) and receiver(s) in NORM protocols." The (hidden) assumption in PGMCC is to have multicast downstream, and unicast upstream (plus optional multicast on the LAN, but only for nak suppression purposes). I think this is one of the least restrictive assumption you can make on availability of service. My feeling is that over time it will be less likely to have multicast in both directions (e.g. because of SSM, or asymmetric nets with satellite downlink and phone uplink, etc.). Of course you can tunnel your ACKs using whatever transport you have available, including multicast -- basically this is what you propose in the second part of your msg. You might lose some efficiency in the process, and put a lot more state in the net, but if you have no better alternative, what else you can do. Second issue is your proposal of using immediate feedback to trigger retransmissions. I think in some cases it might be better to wait a bit (which is a side effect of sending repairs in response to delayed NAKs). Examples: + in a context (such as PGM) where you have nodes doing selective forwarding, you want to retransmit only after receivers have had a chance to send out their NAKs (and install state in the filtering nodes). + if you use FEC-based repairs, you might want to count the amount of lost packets to select the most appropriate FEC parameters (block size, number of repair blocks, etc); + you still need to handle reordering in packet arrivals; using delayed NAKs frees you from counting N dup-acks for retransmission purposes. Third one: you say > PGMCC has the receiver unicast acks in > order to get a more complete set of which packets are lost by the worst-case > receiver. not exactly. Those acks really carry throughput estimates, and "tokens" to trigger the transmission of new traffic. They are not (meant to be) used at all for data integrity purposes. 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 Tue Jun 12 04:20:15 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f5CBJns12104; Tue, 12 Jun 2001 04:19:49 -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.11.2/8.11.2) with ESMTP id f5CBJl112100 for ; Tue, 12 Jun 2001 04:19:47 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5CBJlO01754 for ; Tue, 12 Jun 2001 04:19:47 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f5CBJj601750 for ; Tue, 12 Jun 2001 04:19:46 -0700 (PDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Jun 2001 12:19:22 +0100 To: Luigi Rizzo cc: Jeremiah Scholl , rmt@lbl.gov, J.Crowcroft@cs.ucl.ac.uk Subject: Re: PGMCC and unicast In-reply-to: Your message of "Tue, 12 Jun 2001 12:57:42 +0200." <200106121057.MAA83432@info.iet.unipi.it> Date: Tue, 12 Jun 2001 12:19:22 +0100 Message-ID: <17309.992344762@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk In message <200106121057.MAA83432@info.iet.unipi.it>, Luigi Rizzo typed: >>i think you are addressing a few different issues in this msg. >>First one is "what kind of connectivity should we assume between >>source(s) and receiver(s) in NORM protocols." >>The (hidden) assumption in PGMCC is to have multicast downstream, and >>unicast upstream (plus optional multicast on the LAN, but only for nak >>suppression purposes). >>I think this is one of the least restrictive assumption you can >>make on availability of service. My feeling is that over time it >>will be less likely to have multicast in both directions (e.g. >>because of SSM, or asymmetric nets with satellite downlink and >>phone uplink, etc.). >>Of course you can tunnel your ACKs using whatever transport you >>have available, including multicast -- basically this is what you >>propose in the second part of your msg. You might lose some efficiency >>in the process, and put a lot more state in the net, but if you >>have no better alternative, what else you can do. of course, in a genuine shared media net, it might make a lot of sense to multicast acks - it seems like it ought to be an option, but i agree 100% it is likely to be the exception jeremiah: also, in the case of firewalls, NATs etc, the chances are that multicast is MORE likely to be blocked first, and let through latest, rather than unicast, so i dont see the marratech objection here really finally, all the RMT work has moved away from SRM, temporarily, since we couldn't figure out congestion control for multiple sources, and several people of "importance" claimed that "there were'nt any compelling multiple source applications anyhow" :-) its not clear why having the PGMCC acker send data to all sources means much for a multiple sender session- if each source independantly adjusts its rate in a TCP-friendly way, you get the right effect, and given most delivery trees for steady traffic are going to be source based, they wont necessarily share bottlenecks very often (except perhaps at the receivers themselves) if you want to devise some applicatio nlayer rule about how to _couple_ the sending rates for a multi-sender applciation, then thats fine, but i dont see that it should be wired into the transport layer congestion control in anyway - it can easily be done as a higher layer policy, distributed in a session management protocol, and weighted into the rate computaton of PGMCC at each source >>Second issue is your proposal of using immediate feedback to trigger >>retransmissions. I think in some cases it might be better to wait >>a bit (which is a side effect of sending repairs in response to >>delayed NAKs). >> >>Examples: >> + in a context (such as PGM) where you have nodes doing selective >> forwarding, you want to retransmit only after receivers have had a >> chance to send out their NAKs (and install state in the filtering nodes). >> >> + if you use FEC-based repairs, you might want to count the amount of >> lost packets to select the most appropriate FEC parameters (block >> size, number of repair blocks, etc); >> >> + you still need to handle reordering in packet arrivals; using delayed >> NAKs frees you from counting N dup-acks for retransmission purposes. >> >>Third one: you say >> >>> PGMCC has the receiver unicast acks in >>> order to get a more complete set of which packets are lost by the worst-case >>> receiver. >> >>not exactly. Those acks really carry throughput estimates, and >>"tokens" to trigger the transmission of new traffic. They are not >>(meant to be) used at all for data integrity purposes. >> >> 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 >>-----------------------------------+------------------------------------- cheers jon >From owner-rmt@listserv.lbl.gov Tue Jun 12 08:12:53 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f5CFBJM13718; Tue, 12 Jun 2001 08:11: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.11.2/8.11.2) with ESMTP id f5CFBI113714 for ; Tue, 12 Jun 2001 08:11:18 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5CFBI303345 for ; Tue, 12 Jun 2001 08:11:18 -0700 (PDT) Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5CFBH603342 for ; Tue, 12 Jun 2001 08:11:17 -0700 (PDT) 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 LAA05871; Tue, 12 Jun 2001 11:10:56 -0400 (EDT) Mime-Version: 1.0 X-Sender: adamson@pop.itd.nrl.navy.mil Message-Id: In-Reply-To: <3B25CF4F.6F930370@cdt.luth.se> References: <200106112228.AAA79639@info.iet.unipi.it> <3B25CF4F.6F930370@cdt.luth.se> Date: Tue, 12 Jun 2001 11:10:57 -0400 To: Jeremiah Scholl From: Brian Adamson Subject: Re: PGMCC and unicast Cc: rmt@lbl.gov Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-rmt@lbl.gov Precedence: bulk With MDP, we have had networks where _only_ unicast feedback was possible _and_ we have had networks where _only_ multicast feedback has been possible so options exist to force all-unicast or all-multicast feedback from receivers ... By default, ACKS are unicast and NACKs tend to be multicast ... Although we _have_ now implemented NACK suppression for unicast feedback with suppression performance comparable to multicast NACK feedback suppression at the cost of an additional RTT delay (and for some topologies or multicast routing protocols (e.g. shared-tree) there may not be much difference at all) In the TFRC-like congestion control we have implemented in MDP, we do something like what you describe below ... A small subset of candidate worst-case receivers provide feedback (to congestion control probes interlaced with the senders' data transmissions) with no suppression timing ... (The sender adjusts its rate according to _the_ worst case receiver - we're still investigation the value of keeping congestion control state for multiple representatives instead of one as per PGMCC) ... As Luigi note for PGMCC, this does work independently of the reliability process although we do also piggy-back congestion control feedback (RTT, loss estimation feedback) on NACK messages ... I have considered NACK suppression schemes where the receivers' history of NACKing may weight their probability of NACKing to a shorter backoff time (or possibly none at all as you describe below) ... There is some danger in this (though some may be mitigated by the sender advertising the current designated zero-delay "nackers) ... However, in our experience on the MBONE, the statistics of loss don't appear to be stationary ... i.e. there doesn't seem to be much correlation between being the worst-case NACKer from one time period to the next ... this is probably not well understood for networks with lots of dynamic congestion-controlled flows either ... in congestion-control simulations we have done over topologies with multiple possible bottleneck and ongoing background flows and dynamically starting/stopping TCP/MDP flows, we tend to see dynamics in where the worst-case loss is occurring at any moment in time ... but we've had luck with the congestion-control being relatively stable I think since the loss interval is averaged over multiple intervals, each being multiple RTT in general ... At 10:14 AM +0200 6/12/01, Jeremiah Scholl wrote: >I am asking these questions in regard to using PGMCC with SRM like >protocols or >more specifically NORM once it is standardized, not for use in >conjunction with >PGM. Marratech would like to make sure that it will be able to use the >standardized NACK based protocol and standardized congestion control >scheme that >will accompany it. > >I proposed my question to the group because if PGMCC uses unicast we feel that >it will not be compatible with Marratech's products. This is due to >hosts often >being on different networks with firewalls inbetween them. So, we >will need an >additional congestion control scheme to be standardized for use with NORM. > >I do have an idea for a solution to this problem and would really like some >feedback from the group regarding it. PGMCC has the receiver unicast acks in >order to get a more complete set of which packets are lost by the worst-case >receiver. This information is not available in SRM due to the use of >suppression timers. However, this same information can be made >available to the >sender in SRM by having the designated worst-case receiver stop using these >suppression timers. All other receivers would still use suppression >timers like >normal and would have their NACKs suppressed. > >This solution has the benifit that it is low-weight and will also >lead to faster >recovery times for packets that are lost by the worst-case receiver. Since >there will only be one worst-case receiver at any given time it >should not lead >to more redundant NACKs than SRM does. I realize that the solution >does require >us to wonder a bit away from the origional SRM framework so I would >really like >some comments on it. > >Can anyone give me a reason why this solution would not work? Some thoughts >would be nice. > >Jeremiah > >Luigi Rizzo wrote: > >> As Lorenzo said, ACKs are supposed to be unicast to the sender. >> I cannot see any advantage in multicasting them to the session >> (they cannot be used to elicit feedback from potential ackets, >> because in PGMCC the receivers do not have an RTT estimate). >> >> As for the firewall issue: I am unclear on what is your point when you say >> >> > and the engineers here feel that due to the use of firewalls, it is not >> > realistic to assume that unicast connections will be available when >> > deploying their products on the Internet. >> >> do you really mean unicast ? >> >> If you are afraid that netadmins are blindly blocking traffic and you >> have no input on what services to let through, then your >> only option is probably to encapsulate everything into >> UDP packets on port 53 (DNS) ... >> >> But if you want to use PGM, you need to tell the netadmin "listen, >> i need protocol 113 to get through, and bidirectional connectivity >> (for NAKs), at which point asking unicast is the least of your >> worries. >> >> cheers >> luigi >> >> > > In message <3B24A210.5276F01F@cdt.luth.se>, >> > > Jeremiah Scholl writes: >> > > > I have a question for the group regarding the Internet-Draft for PGMCC >> > > > that you has submitted for standardization. In PGMCC "the acker" >> >> -----------------------------------+------------------------------------- >> 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 >> -----------------------------------+------------------------------------- -- Brian __________________________________ Brian Adamson >From owner-rmt@listserv.lbl.gov Tue Jun 12 15:51:32 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f5CMokL16724; Tue, 12 Jun 2001 15:50: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 (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5CMoj116720 for ; Tue, 12 Jun 2001 15:50:45 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5CMoid02829 for ; Tue, 12 Jun 2001 15:50:44 -0700 (PDT) Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5CMoh602821 for ; Tue, 12 Jun 2001 15:50:43 -0700 (PDT) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id AAA87649; Wed, 13 Jun 2001 00:46:25 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200106122246.AAA87649@info.iet.unipi.it> Subject: Re: PGMCC and unicast In-Reply-To: <17309.992344762@cs.ucl.ac.uk> from Jon Crowcroft at "Jun 12, 2001 12:19:22 pm" To: Jon Crowcroft Date: Wed, 13 Jun 2001 00:46:25 +0200 (CEST) CC: Jeremiah Scholl , rmt@lbl.gov 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 > of course, in a genuine shared media net, it might make a lot of sense > to multicast acks it really depends on the protocol. TFMCC "acks" (or whatever they are called) might be useful to other receivers too (as they contain a throughput estimate, so can be used for suppression etc.), but pgmcc acks are almost meaningless for other receivers, they only mean something (for CC purposes) for the one sender they are addressed to. cheers luigi >From owner-rmt@listserv.lbl.gov Wed Jun 13 12:47:16 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f5DJiDL23593; Wed, 13 Jun 2001 12:44:13 -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.11.2/8.11.2) with ESMTP id f5DJiC123589 for ; Wed, 13 Jun 2001 12:44:12 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5DJiB619856 for ; Wed, 13 Jun 2001 12:44:12 -0700 (PDT) Received: from typhoon.ocis.temple.edu (jmulik@typhoon.ocis.temple.edu [155.247.166.103]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5DJiA619841 for ; Wed, 13 Jun 2001 12:44:11 -0700 (PDT) Received: from localhost (jmulik@localhost) by typhoon.ocis.temple.edu (8.11.0/8.11.0) with ESMTP id f5DJi4112027 for ; Wed, 13 Jun 2001 15:44:04 -0400 (EDT) Date: Wed, 13 Jun 2001 15:44:04 -0400 (EDT) From: Jaiwant Mulik X-X-Sender: To: RMT Mailing List Subject: Status of the GRA draft. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rmt@lbl.gov Precedence: bulk Hi all, Has anyone head about any latest developments on the GRA draft ? The lastest draft has expired and I have hear it mentioned on the list that Tony Speakman wanted to revist it with new author(s). I am doing some research related to GRA, and would like to cite a reference. Any update on the status of the draft or reference to publication based on that draft would be highly welcome. bye, Jaiwant Mulik ----------------------------------------------------------------------- Email : jmulik@temple.edu (preferred), jmulik@acm.org Home page : http://unix.temple.edu/~jmulik Office hours : Wednesday, 1:30pm to 3:30pm Location : Room 1043/1044, Wachman Hall. Phones : (215) 204-3197 (o), (215) 777-4828 (r) ----------------------------------------------------------------------- Lekin woh zindagi he kya, jisme koi namumkin sapna na ho ? I have not failed. I've just found 10,000 ways that won't work. - Thomas Alva Edison >From owner-rmt@listserv.lbl.gov Wed Jun 13 16:47:21 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f5DNkZR24577; Wed, 13 Jun 2001 16:46: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.11.2/8.11.2) with ESMTP id f5DNkX124573 for ; Wed, 13 Jun 2001 16:46:33 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5DNkXm16220 for ; Wed, 13 Jun 2001 16:46:33 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5DNkW616212 for ; Wed, 13 Jun 2001 16:46:32 -0700 (PDT) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5DNkV900734 for ; Wed, 13 Jun 2001 16:46:31 -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 QAA09885 for ; Wed, 13 Jun 2001 16:46:26 -0700 (PDT) Message-Id: <200106132346.QAA09885@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI] To: rmt@lbl.gov Subject: Congestion Control BBs Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_14195296130" Date: Wed, 13 Jun 2001 16:46:26 -0700 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk This is a multipart MIME message. --==_Exmh_14195296130 Content-Type: text/plain; charset=us-ascii Hi, given the progress made on the CC BBs and the need to move forward with them, I'd like to reopen the discussion on the process to do this. At the last IETF I proposed to try and reach consensus on a "reference simulations" document to be used as a base for discussion in the evaluation of CC algorithms. I also proposed to submit CC BBs as Experimental RFC *first* and move them to standard track only after we have acquired some deployment experience in the network. Anyone has any opinion about this? As for the "reference simulations" document, we could use the attached document as a starting point. It comes from the notes of a meeting attended by some of us and its based on Mark's original notes. The document was edited by John Byers. thanks, Lorenzo --==_Exmh_14195296130 Content-Type: application/postscript ; name="mcc.ps" Content-Description: mcc.ps Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="mcc.ps" %!PS-Adobe-2.0 %%Creator: dvips(k) 5.86 Copyright 1999 Radical Eye Software %%Title: mcc.dvi %%Pages: 7 %%PageOrder: Ascend %%BoundingBox: 0 0 596 842 %%DocumentFonts: Times-Roman Times-Bold Times-Italic %%EndComments %DVIPSWebPage: (www.radicaleye.com) %DVIPSCommandLine: dvips mcc -o %DVIPSParameters: dpi=3D600, compressed %DVIPSSource: TeX output 2001.06.13:1443 %%BeginProcSet: texc.pro %! /TeXDict 300 dict def TeXDict begin/N{def}def/B{bind def}N/S{exch}N/X{S N}B/A{dup}B/TR{translate}N/isls false N/vsize 11 72 mul N/hsize 8.5 72 mul N/landplus90{false}def/@rigin{isls{[0 landplus90{1 -1}{-1 1}ifelse 0 0 0]concat}if 72 Resolution div 72 VResolution div neg scale isls{ landplus90{VResolution 72 div vsize mul 0 exch}{Resolution -72 div hsize mul 0}ifelse TR}if Resolution VResolution vsize -72 div 1 add mul TR[ matrix currentmatrix{A A round sub abs 0.00001 lt{round}if}forall round exch round exch]setmatrix}N/@landscape{/isls true N}B/@manualfeed{ statusdict/manualfeed true put}B/@copies{/#copies X}B/FMat[1 0 0 -1 0 0] N/FBB[0 0 0 0]N/nn 0 N/IEn 0 N/ctr 0 N/df-tail{/nn 8 dict N nn begin /FontType 3 N/FontMatrix fntrx N/FontBBox FBB N string/base X array /BitMaps X/BuildChar{CharBuilder}N/Encoding IEn N end A{/foo setfont}2 array copy cvx N load 0 nn put/ctr 0 N[}B/sf 0 N/df{/sf 1 N/fntrx FMat N df-tail}B/dfs{div/sf X/fntrx[sf 0 0 sf neg 0 0]N df-tail}B/E{pop nn A definefont setfont}B/Cw{Cd A length 5 sub get}B/Ch{Cd A length 4 sub get }B/Cx{128 Cd A length 3 sub get sub}B/Cy{Cd A length 2 sub get 127 sub} B/Cdx{Cd A length 1 sub get}B/Ci{Cd A type/stringtype ne{ctr get/ctr ctr 1 add N}if}B/id 0 N/rw 0 N/rc 0 N/gp 0 N/cp 0 N/G 0 N/CharBuilder{save 3 1 roll S A/base get 2 index get S/BitMaps get S get/Cd X pop/ctr 0 N Cdx 0 Cx Cy Ch sub Cx Cw add Cy setcachedevice Cw Ch true[1 0 0 -1 -.1 Cx sub Cy .1 sub]/id Ci N/rw Cw 7 add 8 idiv string N/rc 0 N/gp 0 N/cp 0 N{ rc 0 ne{rc 1 sub/rc X rw}{G}ifelse}imagemask restore}B/G{{id gp get/gp gp 1 add N A 18 mod S 18 idiv pl S get exec}loop}B/adv{cp add/cp X}B /chg{rw cp id gp 4 index getinterval putinterval A gp add/gp X adv}B/nd{ /cp 0 N rw exit}B/lsh{rw cp 2 copy get A 0 eq{pop 1}{A 255 eq{pop 254}{ A A add 255 and S 1 and or}ifelse}ifelse put 1 adv}B/rsh{rw cp 2 copy get A 0 eq{pop 128}{A 255 eq{pop 127}{A 2 idiv S 128 and or}ifelse} ifelse put 1 adv}B/clr{rw cp 2 index string putinterval adv}B/set{rw cp fillstr 0 4 index getinterval putinterval adv}B/fillstr 18 string 0 1 17 {2 copy 255 put pop}for N/pl[{adv 1 chg}{adv 1 chg nd}{1 add chg}{1 add chg nd}{adv lsh}{adv lsh nd}{adv rsh}{adv rsh nd}{1 add adv}{/rc X nd}{ 1 add set}{1 add clr}{adv 2 chg}{adv 2 chg nd}{pop nd}]A{bind pop} forall N/D{/cc X A type/stringtype ne{]}if nn/base get cc ctr put nn /BitMaps get S ctr S sf 1 ne{A A length 1 sub A 2 index S get sf div put }if put/ctr ctr 1 add N}B/I{cc 1 add D}B/bop{userdict/bop-hook known{ bop-hook}if/SI save N @rigin 0 0 moveto/V matrix currentmatrix A 1 get A mul exch 0 get A mul add .99 lt{/QV}{/RV}ifelse load def pop pop}N/eop{ SI restore userdict/eop-hook known{eop-hook}if showpage}N/@start{ userdict/start-hook known{start-hook}if pop/VResolution X/Resolution X 1000 div/DVImag X/IEn 256 array N 2 string 0 1 255{IEn S A 360 add 36 4 index cvrs cvn put}for pop 65781.76 div/vsize X 65781.76 div/hsize X}N /p{show}N/RMat[1 0 0 -1 0 0]N/BDot 260 string N/Rx 0 N/Ry 0 N/V{}B/RV/v{ /Ry X/Rx X V}B statusdict begin/product where{pop false[(Display)(NeXT) (LaserWriter 16/600)]{A length product length le{A length product exch 0 exch getinterval eq{pop true exit}if}{pop}ifelse}forall}{false}ifelse end{{gsave TR -.1 .1 TR 1 1 scale Rx Ry false RMat{BDot}imagemask grestore}}{{gsave TR -.1 .1 TR Rx Ry scale 1 1 false RMat{BDot} imagemask grestore}}ifelse B/QV{gsave newpath transform round exch round exch itransform moveto Rx 0 rlineto 0 Ry neg rlineto Rx neg 0 rlineto fill grestore}B/a{moveto}B/delta 0 N/tail{A/delta X 0 rmoveto}B/M{S p delta add tail}B/b{S p tail}B/c{-4 M}B/d{-3 M}B/e{-2 M}B/f{-1 M}B/g{0 M} B/h{1 M}B/i{2 M}B/j{3 M}B/k{4 M}B/w{0 rmoveto}B/l{p -4 w}B/m{p -3 w}B/n{ p -2 w}B/o{p -1 w}B/q{p 1 w}B/r{p 2 w}B/s{p 3 w}B/t{p 4 w}B/x{0 S rmoveto}B/y{3 2 roll p a}B/bos{/SS save N}B/eos{SS restore}B end %%EndProcSet %%BeginProcSet: 8r.enc % @@psencodingfile@{ % author =3D "S. Rahtz, P. MacKay, Alan Jeffrey, B. Horn, K. Berry", % version =3D "0.6", % date =3D "1 July 1998", % filename =3D "8r.enc", % email =3D "tex-fonts@@tug.org", % docstring =3D "Encoding for TrueType or Type 1 fonts % to be used with TeX." % @} % = % Idea is to have all the characters normally included in Type 1 fonts % available for typesetting. This is effectively the characters in Adobe % Standard Encoding + ISO Latin 1 + extra characters from Lucida. % = % Character code assignments were made as follows: % = % (1) the Windows ANSI characters are almost all in their Windows ANSI % positions, because some Windows users cannot easily reencode the % fonts, and it makes no difference on other systems. The only Windows % ANSI characters not available are those that make no sense for % typesetting -- rubout (127 decimal), nobreakspace (160), softhyphen % (173). quotesingle and grave are moved just because it's such an % irritation not having them in TeX positions. % = % (2) Remaining characters are assigned arbitrarily to the lower part % of the range, avoiding 0, 10 and 13 in case we meet dumb software. % = % (3) Y&Y Lucida Bright includes some extra text characters; in the % hopes that other PostScript fonts, perhaps created for public % consumption, will include them, they are included starting at 0x12. % = % (4) Remaining positions left undefined are for use in (hopefully) % upward-compatible revisions, if someday more characters are generally % available. % = % (5) hyphen appears twice for compatibility with both = % ASCII and Windows. % = /TeXBase1Encoding [ % 0x00 (encoded characters from Adobe Standard not in Windows 3.1) /.notdef /dotaccent /fi /fl /fraction /hungarumlaut /Lslash /lslash /ogonek /ring /.notdef /breve /minus /.notdef = % These are the only two remaining unencoded characters, so may as % well include them. /Zcaron /zcaron = % 0x10 /caron /dotlessi = % (unusual TeX characters available in, e.g., Lucida Bright) /dotlessj /ff /ffi /ffl = /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef % very contentious; it's so painful not having quoteleft and quoteright % at 96 and 145 that we move the things normally found there to here. /grave /quotesingle = % 0x20 (ASCII begins) /space /exclam /quotedbl /numbersign /dollar /percent /ampersand /quoteright /parenleft /parenright /asterisk /plus /comma /hyphen /period /slash % 0x30 /zero /one /two /three /four /five /six /seven /eight /nine /colon /semicolon /less /equal /greater /question % 0x40 /at /A /B /C /D /E /F /G /H /I /J /K /L /M /N /O % 0x50 /P /Q /R /S /T /U /V /W /X /Y /Z /bracketleft /backslash /bracketright /asciicircum /underscore % 0x60 /quoteleft /a /b /c /d /e /f /g /h /i /j /k /l /m /n /o % 0x70 /p /q /r /s /t /u /v /w /x /y /z /braceleft /bar /braceright /asciitilde /.notdef % rubout; ASCII ends % 0x80 /.notdef /.notdef /quotesinglbase /florin /quotedblbase /ellipsis /dagger /daggerdbl /circumflex /perthousand /Scaron /guilsinglleft /OE /.notdef /.notdef /.notdef % 0x90 /.notdef /.notdef /.notdef /quotedblleft /quotedblright /bullet /endash /emdash /tilde /trademark /scaron /guilsinglright /oe /.notdef /.notdef /Ydieresis % 0xA0 /.notdef % nobreakspace /exclamdown /cent /sterling /currency /yen /brokenbar /section /dieresis /copyright /ordfeminine /guillemotleft /logicalnot /hyphen % Y&Y (also at 45); Windows' softhyphen /registered /macron % 0xD0 /degree /plusminus /twosuperior /threesuperior /acute /mu /paragraph /periodcentered /cedilla /onesuperior /ordmasculine /guillemotright /onequarter /onehalf /threequarters /questiondown % 0xC0 /Agrave /Aacute /Acircumflex /Atilde /Adieresis /Aring /AE /Ccedilla /Egrave /Eacute /Ecircumflex /Edieresis /Igrave /Iacute /Icircumflex /Idieresis % 0xD0 /Eth /Ntilde /Ograve /Oacute /Ocircumflex /Otilde /Odieresis /multiply /Oslash /Ugrave /Uacute /Ucircumflex /Udieresis /Yacute /Thorn /germandbls % 0xE0 /agrave /aacute /acircumflex /atilde /adieresis /aring /ae /ccedilla /egrave /eacute /ecircumflex /edieresis /igrave /iacute /icircumflex /idieresis % 0xF0 /eth /ntilde /ograve /oacute /ocircumflex /otilde /odieresis /divide /oslash /ugrave /uacute /ucircumflex /udieresis /yacute /thorn /ydieresis ] def %%EndProcSet %%BeginProcSet: texps.pro %! TeXDict begin/rf{findfont dup length 1 add dict begin{1 index/FID ne 2 index/UniqueID ne and{def}{pop pop}ifelse}forall[1 index 0 6 -1 roll exec 0 exch 5 -1 roll VResolution Resolution div mul neg 0 0]/Metrics exch def dict begin Encoding{exch dup type/integertype ne{pop pop 1 sub dup 0 le{pop}{[}ifelse}{FontMatrix 0 get div Metrics 0 get div def} ifelse}forall Metrics/Metrics currentdict end def[2 index currentdict end definefont 3 -1 roll makefont/setfont cvx]cvx def}def/ObliqueSlant{ dup sin S cos div neg}B/SlantFont{4 index mul add}def/ExtendFont{3 -1 roll mul exch}def/ReEncodeFont{CharStrings rcheck{/Encoding false def dup[exch{dup CharStrings exch known not{pop/.notdef/Encoding true def} if}forall Encoding{]exch pop}{cleartomark}ifelse}if/Encoding exch def} def end %%EndProcSet %%BeginProcSet: special.pro %! TeXDict begin/SDict 200 dict N SDict begin/@SpecialDefaults{/hs 612 N /vs 792 N/ho 0 N/vo 0 N/hsc 1 N/vsc 1 N/ang 0 N/CLIP 0 N/rwiSeen false N /rhiSeen false N/letter{}N/note{}N/a4{}N/legal{}N}B/@scaleunit 100 N /@hscale{@scaleunit div/hsc X}B/@vscale{@scaleunit div/vsc X}B/@hsize{ /hs X/CLIP 1 N}B/@vsize{/vs X/CLIP 1 N}B/@clip{/CLIP 2 N}B/@hoffset{/ho X}B/@voffset{/vo X}B/@angle{/ang X}B/@rwi{10 div/rwi X/rwiSeen true N}B /@rhi{10 div/rhi X/rhiSeen true N}B/@llx{/llx X}B/@lly{/lly X}B/@urx{ /urx X}B/@ury{/ury X}B/magscale true def end/@MacSetUp{userdict/md known {userdict/md get type/dicttype eq{userdict begin md length 10 add md maxlength ge{/md md dup length 20 add dict copy def}if end md begin /letter{}N/note{}N/legal{}N/od{txpose 1 0 mtx defaultmatrix dtransform S atan/pa X newpath clippath mark{transform{itransform moveto}}{transform{ itransform lineto}}{6 -2 roll transform 6 -2 roll transform 6 -2 roll transform{itransform 6 2 roll itransform 6 2 roll itransform 6 2 roll curveto}}{{closepath}}pathforall newpath counttomark array astore/gc xdf pop ct 39 0 put 10 fz 0 fs 2 F/|______Courier fnt invertflag{PaintBlack} if}N/txpose{pxs pys scale ppr aload pop por{noflips{pop S neg S TR pop 1 -1 scale}if xflip yflip and{pop S neg S TR 180 rotate 1 -1 scale ppr 3 get ppr 1 get neg sub neg ppr 2 get ppr 0 get neg sub neg TR}if xflip yflip not and{pop S neg S TR pop 180 rotate ppr 3 get ppr 1 get neg sub neg 0 TR}if yflip xflip not and{ppr 1 get neg ppr 0 get neg TR}if}{ noflips{TR pop pop 270 rotate 1 -1 scale}if xflip yflip and{TR pop pop 90 rotate 1 -1 scale ppr 3 get ppr 1 get neg sub neg ppr 2 get ppr 0 get neg sub neg TR}if xflip yflip not and{TR pop pop 90 rotate ppr 3 get ppr 1 get neg sub neg 0 TR}if yflip xflip not and{TR pop pop 270 rotate ppr 2 get ppr 0 get neg sub neg 0 S TR}if}ifelse scaleby96{ppr aload pop 4 -1 roll add 2 div 3 1 roll add 2 div 2 copy TR .96 dup scale neg S neg S TR}if}N/cp{pop pop showpage pm restore}N end}if}if}N/normalscale{ Resolution 72 div VResolution 72 div neg scale magscale{DVImag dup scale }if 0 setgray}N/psfts{S 65781.76 div N}N/startTexFig{/psf$SavedState save N userdict maxlength dict begin/magscale true def normalscale currentpoint TR/psf$ury psfts/psf$urx psfts/psf$lly psfts/psf$llx psfts /psf$y psfts/psf$x psfts currentpoint/psf$cy X/psf$cx X/psf$sx psf$x psf$urx psf$llx sub div N/psf$sy psf$y psf$ury psf$lly sub div N psf$sx psf$sy scale psf$cx psf$sx div psf$llx sub psf$cy psf$sy div psf$ury sub TR/showpage{}N/erasepage{}N/copypage{}N/p 3 def @MacSetUp}N/doclip{ psf$llx psf$lly psf$urx psf$ury currentpoint 6 2 roll newpath 4 copy 4 2 roll moveto 6 -1 roll S lineto S lineto S lineto closepath clip newpath moveto}N/endTexFig{end psf$SavedState restore}N/@beginspecial{SDict begin/SpecialSave save N gsave normalscale currentpoint TR @SpecialDefaults count/ocount X/dcount countdictstack N}N/@setspecial{ CLIP 1 eq{newpath 0 0 moveto hs 0 rlineto 0 vs rlineto hs neg 0 rlineto closepath clip}if ho vo TR hsc vsc scale ang rotate rwiSeen{rwi urx llx sub div rhiSeen{rhi ury lly sub div}{dup}ifelse scale llx neg lly neg TR }{rhiSeen{rhi ury lly sub div dup scale llx neg lly neg TR}if}ifelse CLIP 2 eq{newpath llx lly moveto urx lly lineto urx ury lineto llx ury lineto closepath clip}if/showpage{}N/erasepage{}N/copypage{}N newpath}N /@endspecial{count ocount sub{pop}repeat countdictstack dcount sub{end} repeat grestore SpecialSave restore end}N/@defspecial{SDict begin}N /@fedspecial{end}B/li{lineto}B/rl{rlineto}B/rc{rcurveto}B/np{/SaveX currentpoint/SaveY X N 1 setlinecap newpath}N/st{stroke SaveX SaveY moveto}N/fil{fill SaveX SaveY moveto}N/ellipse{/endangle X/startangle X /yrad X/xrad X/savematrix matrix currentmatrix N TR xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix}N end %%EndProcSet TeXDict begin 39158280 55380996 1000 600 600 (mcc.dvi) @start %DVIPSBitmapFont: Fa cmmi10 10.95 1 /Fa 1 108 df107 D E %EndDVIPSBitmapFont /Fb 136[54 37 37 21 29 25 37 37 37 37 1[21 37 1[21 37 37 25 33 37 33 37 33 18[54 66 27[37 37 1[19 1[19 44[{ TeXBase1Encoding ReEncodeFont}27 74.7198 /Times-Roman rf /Fc 206[25 49[{TeXBase1Encoding ReEncodeFont}1 49.8132 /Times-Roman rf /Fd 206[33 49[{TeXBase1Encoding ReEncodeFont}1 66.4176 /Times-Roman rf /Fe 139[30 4[45 6[51 5[51 98[{ TeXBase1Encoding ReEncodeFont}4 90.9091 /Times-Bold rf %DVIPSBitmapFont: Ff cmsy10 10.95 1 /Ff 1 16 df15 D E %EndDVIPSBitmapFont /Fg 135[40 3[25 35 35 1[45 45 45 66 3[25 45 2[40 3[45 97[{TeXBase1Encoding ReEncodeFont}12 90.9091 /Times-Italic rf /Fh 133[40 45 45 66 45 45 25 35 30 45 45 45 45 71 25 45 25 25 45 45 30 40 45 40 45 40 9[86 66 66 56 51 61 66 51 1[66 81 56 66 1[30 66 66 51 56 66 61 61 66 5[25 25 45 45 45 45 45 45 45 45 45 45 25 23 30 23 51 1[30 30 30 1[76 33[51 51 2[{TeXBase1Encoding ReEncodeFont}70 90.9091 /Times-Roman rf /Fi 135[60 1[60 66 40 47 53 1[66 60 66 100 33 2[33 66 60 1[53 66 53 1[60 9[120 2[80 4[93 1[113 7[80 86 86 15[60 60 60 9[40 39[{TeXBase1Encoding ReEncodeFont}29 119.552 /Times-Bold rf /Fj 140[32 4[42 110[{ TeXBase1Encoding ReEncodeFont}2 83.022 /Times-Italic rf /Fk 133[37 42 42 60 42 42 23 32 28 1[42 42 42 65 23 42 1[23 42 42 28 37 42 37 42 37 3[28 1[28 3[78 60 1[51 46 2[46 2[74 51 1[32 28 60 60 46 1[60 1[55 60 5[23 1[42 42 3[42 42 42 1[42 1[21 28 21 44[{TeXBase1Encoding ReEncodeFont}51 83.022 /Times-Roman rf /Fl 139[28 32 37 14[37 46 42 31[60 65[{TeXBase1Encoding ReEncodeFont}7 83.022 /Times-Bold rf /Fm 138[50 28 39 33 2[50 50 78 28 2[28 1[50 33 44 3[44 18[72 7[55 1[72 2[72 8[50 5[50 1[50 3[25 44[{ TeXBase1Encoding ReEncodeFont}21 99.6264 /Times-Roman rf /Fn 138[72 40 56 48 2[72 72 112 40 2[40 72 72 48 64 1[64 72 64 12[88 80 96 4[128 9[96 67[{TeXBase1Encoding ReEncodeFont}21 143.462 /Times-Roman rf end %%EndProlog %%BeginSetup %%Feature: *Resolution 600dpi TeXDict begin %%PaperSize: A4 %%EndSetup %%Page: 1 1 1 0 bop 99 456 a Fn(More)35 b(Thoughts)f(on)h(Reference)e(Simulations)h (for)h(Reliable)f(Multicast)1113 638 y(Congestion)g(Control)g(Schemes) 748 891 y Fm(Notes)25 b(from)f(a)h(meeting)f(at)h(Digital)f(F)o (ountain)f(on)i(August)f(8,)g(2000)1796 1202 y Fl(Abstract)352 1335 y Fk(This)c(document)e(summarizes)h(the)i(output)d(of)i(a)h (meeting)e(held)h(at)g(Digital)h(F)o(ountain,)d(Inc.)24 b(on)c(August)g(8,)g(2000)227 1435 y(to)26 b(e)o(xpand)d(upon)h(the)i (w)o(ork)e(initiated)h(by)g(Mark)g(Handle)o(y)f(to)i(de)n(v)o(elop)d(a) j(set)g(of)f(reference)f(simulations)h(for)f(reli-)227 1535 y(able)f(multicast)f(congestion)f(control)g(schemes)h([H99].)31 b(P)o(articipants)22 b(included)f(John)h(Byers,)h(Ga)n(vin)f(Horn,)g (Mark)227 1634 y(Handle)o(y)-5 b(,)28 b(Michael)f(Luby)-5 b(,)28 b(W)m(ill)g(Sha)n(v)o(er)f(and)g(Lorenzo)f(V)-5 b(icisano.)47 b(This)28 b(outline)f(sk)o(etches)h(a)g(set)g(of)g (additional)227 1734 y(e)o(xperiments)17 b(which)g(the)i(meeting)e (participants)g(generally)g(deemed)g(useful,)h(and)g(pro)o(vides)e (guidelines)i(for)f(setting)227 1833 y(up)29 b(appropriate)d Fj(ns)j Fk(simulations)f(in)h(which)f(to)h(perform)e(these)i(e)o (xperiments.)48 b(This)29 b(w)o(ork)f(is)i(not)e(a)i(standalone)227 1933 y(document;)d(our)e(plan)h(is)h(to)f(inte)o(grate)f(the)h (suggestions)f(it)h(contains)g(into)f(an)h(updated)f(v)o(ersion)f(of)i (the)g(reference)227 2033 y(simulations)20 b(draft.)0 2321 y Fi(1)119 b(Methodological)31 b(Considerations)0 2528 y Fh(Before)19 b(a)e(successful)k(e)o(xperiment)f(can)f(be)f (undertak)o(en)j(in)d Fg(ns)g Fh(to)g(measure)i(the)e(performance)j(of) d(a)f(multicast)j(congestion)0 2641 y(control)26 b(strate)o(gy)-6 b(,)26 b(there)f(are)g(a)f(substantial)j(number)f(of)e(parameters)i (which)f(must)f(be)h(set)f(carefully)j(to)d(ensure)i(that)f(the)0 2754 y(e)o(xperiment)j(is)e(measuring)j(something)f(useful.)39 b(W)-7 b(e)26 b(enumerate)i(these)f(here,)h(be)o(ginning)h(with)d (principles)j(that)e(apply)0 2867 y(to)c(congestion)k(control)e (studies)h(in)d(general,)i(then)f(continuing)j(with)c(principles)k (speci\002c)d(to)g(multicast:)136 3055 y Ff(\017)46 b Fh(Correct)24 b(queue)h(sizing.)k(The)23 b(minimum)g(queue)h(size)g (for)f(which)h(TCP)d(congestion)26 b(control)f(beha)n(v)o(es)g (according)227 3168 y(to)34 b(ideal)h(sa)o(wtooth)g(beha)n(vior)i(is)c (one)i(in)f(which)g(the)g(bottleneck)j(gate)n(w)o(ay)e(has)f(a)g(queue) h(sized)g(equal)g(to)f(the)227 3281 y(bandwidth-delay)j(product)d(of)e (the)g(connection.)58 b(F)o(or)31 b(drop-tail)j(gate)n(w)o(ays,)h(we)c (recommend)j(testing)g(at)e(that)227 3394 y(setting,)h(and)d(with)g(a)f (queue)i(size)g(four)f(times)g(lar)n(ger)l(,)j(i.e.)47 b(four)31 b(times)f(the)g(bandwidth-delay)k(product.)49 b(RED)227 3507 y(gate)n(w)o(ay)24 b(settings)i(are)e(discussed)i(in)d (more)h(detail)g(belo)n(w)136 3686 y Ff(\017)46 b Fh(TCP)29 b(type)i(and)g(settings.)51 b(In)30 b(order)i(of)e(importance,)k(we)29 b(recommend)j(running)h(tests)e(with)f(TCP)e(SA)l(CK)h(and)227 3799 y(TCP)c(Reno;)k(the)e(former)h(pro)o(viding)h(rob)n(ustness)h(to)d (multiple)h(losses)g(per)f(windo)n(w)-6 b(,)28 b(the)f(latter)h(being)g (the)f(most)227 3912 y(widely)37 b(deplo)o(yed)h(v)o(ersion)f(of)f(TCP) e(today)-6 b(.)67 b(The)35 b(clock)i(granularity)i(of)d(TCP)e(must)i (be)f(set)h(appropriately)-6 b(.)227 4025 y(The)32 b(TCP)e(recei)n(v)o (er)j(windo)n(w)f(should)h(be)f(set)g(to)g(be)g(lar)n(ge)h(enough)h(to) e(a)n(v)n(oid)i(impacting)f(congestion)i(control)227 4138 y(algorithms)g(\(10000)g(pack)o(ets\).)59 b(Unless)33 b(the)g(goal)h(of)e(the)h(e)o(xperiment)i(is)e(to)g(e)o(xplore)h (interaction)i(with)c(TCP)227 4251 y(slo)n(w)24 b(start)i(dynamics,)g (suf)n(\002cient)f(time)g(\(15)g(seconds\))h(should)h(elapse)e(after)h (a)e(TCP)e(connection)28 b(is)c(established)227 4364 y(before)h(measurements)h(are)e(tak)o(en.)136 4543 y Ff(\017)46 b Fh(Bottleneck)39 b(bandwidth.)68 b(It)36 b(is)h(imperati)n(v)o(e)g(to)f(test)h(congestion)i(control)f(strate)o (gies)h(o)o(v)o(er)d(a)g(wide)g(range)h(of)227 4656 y(bottleneck)d (bandwidths.)54 b(W)-7 b(e)30 b(recommend)i(testing)h(with)e (bottleneck)j(bandwidths)f(of)e(200Kbps,)j(500Kbps,)227 4769 y(1Mbps,)24 b(8Mbps)h(and)f(64Mbps.)136 4948 y Ff(\017)46 b Fh(Randomization.)c Fg(ns)27 b Fh(and)g(other)h(e)n(v)o(ent-dri)n(v)o (en)h(simulators)g(are)e(prone)h(to)f(simulation)i(artif)o(acts)g(such) e(as)g(phase)227 5061 y(ef)n(fects)i(that)f(may)f(not)h(be)f(present)i (in)e(the)h(real)g(w)o(orld.)40 b(W)-7 b(e)27 b(recommend)h(the)g(use)g (of)f(randomization)k(in)c(simu-)227 5174 y(lations)f(to)e(remo)o(v)o (e)g(these)i(ef)n(fects.)31 b(Some)24 b(tactics)i(for)e(doing)h(so)g (include)h(the)e(use)h(of)f(RED)e(gate)n(w)o(ays,)j(adding)h(a)227 5287 y(random)j(error)f(term)g(to)f(pack)o(et)i(transmission)i(times,)d (or)g(injecting)i(a)d(small)h(amount)g(of)g(random)g(cross-traf)n (\002c)227 5400 y(on)c(the)g(forw)o(ard)g(path.)1927 5649 y(1)p eop %%Page: 2 2 2 1 bop 136 91 a Ff(\017)46 b Fh(Queueing)21 b(policies.)30 b(The)19 b(impact)h(of)g(both)g(drop-tail)i(and)e(RED)d(gate)n(w)o(ays) k(on)e(the)h(congestion)j(control)e(protocol)227 204 y(should)26 b(be)e(studied,)i(compliance)g(with)e(drop-tail)j(being)e (the)f(more)h(important)g(gi)n(v)o(en)g(its)f(wider)h(deplo)o(yment)h (at)227 317 y(present.)50 b(When)30 b(RED)e(gate)n(w)o(ays)j(are)f (used,)i(a)e(number)h(of)f(parameters)i(must)e(be)g(set)g(carefully)i (to)e(pro)o(vide)i(a)227 430 y(meaningful)c(simulation.)36 b(Recommended)27 b(settings)h(include:)35 b(sizing)27 b(the)e(queue)i(to)e(be)h(twice)f(the)h(bandwidth-)227 543 y(delay)31 b(product,)h(setting)f Fg(minthr)m(esh)g Fh(to)e(be)h(5\045)f(of)g(the)h(queue)g(size)g(and)g Fg(maxthr)m(esh)h Fh(to)e(be)h(50\045)f(of)g(the)h(queue)227 656 y(size,)38 b(setting)f Fg(maxp)e Fh(to)f(be)h(approximately)j (equal)e(to)f(the)g(standing)i(queue)f(size,)i(or)d(roughly)i (\(minthresh)g(+)227 769 y(maxthresh\))26 b(/)d(2,)g(and)h(turning)h (the)f(gentle)h(setting)g(on.)136 956 y Ff(\017)46 b Fh(Multicast)26 b(routing)f(protocol)h(setup.)k Fg(ns)24 b Fh(pro)o(vides)h(a)f(number)g(of)g(possible)i(multicast)f(routing)g (options,)h(none)e(of)227 1069 y(which)g(f)o(aithfully)j(reproduce)f (the)e(beha)n(vior)j(of)c(these)i(protocols)i(on)d(real)g(netw)o(orks.) 31 b(P)o(articularly)26 b(problematic)227 1182 y(is)d(the)g(f)o(ailure) i(of)e Fg(ns)g Fh(to)g(simulate)h(control)h(traf)n(\002c)e(correctly)-6 b(.)31 b(W)-7 b(e)22 b(recommend)i(using)g(the)g(PIM-SM)d(centralized) 227 1295 y(routing)26 b(setup,)e(on)g(top)g(of)f(which)h(control)h (message)g(latenc)o(y)g(is)e(simulated)i(\(see)g(ne)o(xt)e(item\).)136 1483 y Ff(\017)46 b Fh(Correct)27 b(modeling)g(of)f(join)g(and)g(lea)n (v)o(e)h(latencies.)37 b Fg(ns)26 b Fh(does)g(not)h(pro)o(vide)g(an)e (accurate)j(model)e(for)g(propagation)227 1596 y(of)i(IGMP)f(join)i (and)g(lea)n(v)o(e)g(requests,)i(nor)e(does)g(it)f(pro)o(vide)i(an)e (accurate)j(model)d(of)h(latencies)h(of)e(PIM)f(control)227 1709 y(messages.)59 b(Lea)n(v)o(e)33 b(latencies)i(can)f(be)e (especially)k(substantial)g(and)e(must)f(be)g(tested.)58 b(W)-7 b(e)32 b(recommend)i(tests)227 1822 y(which)e(in)l(v)n(olv)o(e)h (a)e(four)h(to)g(six)f(second)i(IGMP)d(lea)n(v)o(e)i(latenc)o(y)h(and)f (PIM)e(prune)j(messages)f(which)g(tak)o(e)g(three)227 1934 y(seconds)26 b(to)d(tra)n(v)o(erse)j(a)d(LAN.)e(These)j(latencies) i(are)d(in)h(addition)h(to)f(hop-by-hop)j(propagation)f(delay)-6 b(.)136 2122 y Ff(\017)46 b Fh(Pruning)29 b(traf)n(\002c)f(back)h(to)f (the)g(source.)44 b(Protocols)30 b(using)f(layered)h(multicast)f(for)f (congestion)j(control)f(must)e(be)227 2235 y(careful)i(to)d(prune)j (unw)o(anted)f(traf)n(\002c)f(all)g(the)g(w)o(ay)g(back)g(to)g(the)g (source)i(to)d(a)n(v)n(oid)j(unintended)h(side)d(ef)n(fects.)43 b(In)227 2348 y(some)24 b(situations,)i(co-locating)h(a)c(router)i (with)e(the)h(source)h(is)e(a)g(simple)h(w)o(ay)g(to)f(perform)i(this)f (pruning)h(step.)0 2640 y Fi(2)119 b(Experiments)0 2847 y Fh(W)-7 b(e)34 b(no)n(w)g(pro)o(vide)i(a)e(list)h(of)f(potentially)k (interesting)f(and)e(useful)h(e)o(xperiments)g(with)f(which)g(to)f (test)h(a)f(congestion)0 2960 y(control)28 b(strate)o(gy)-6 b(.)37 b(There)27 b(are)f(se)n(v)o(eral)h(principles)h(which)f(loosely) g(guided)h(the)e(mak)o(eup)h(and)g(ordering)h(of)e(these)h(tests.)0 3073 y(First,)h(we)f(intended)i(the)f(test)g(suite)g(to)g(be)o(gin)g (with)f(tests)h(of)g(v)o(ery)f(basic)i(principles,)i(and)d(to)f(ha)n(v) o(e)h(later)g(tests)g(become)0 3186 y(richer)38 b(in)e(scope,)k(often)e (with)e(the)h(assumption)h(that)f(earlier)h(tests)f(had)g(completed)h (correctly)-6 b(.)70 b(Second,)40 b(virtually)0 3299 y(e)n(v)o(ery)23 b(e)o(xperiment)i(w)o(as)e(designed)i(with)e(a)g (speci\002c)g(point)h(in)f(mind,)g(and)h(the)f(names)g(we)g(attrib)n (ute)i(to)e(the)g(e)o(xperiments)0 3412 y(attempt)33 b(to)f(re\003ect)h(this.)55 b(Finally)-6 b(,)35 b(for)d(the)h(adv)n (anced)h(tests,)h(we)c(made)h(some)h(ef)n(fort)g(to)f(classify)i(them)e (into)h(coarse)0 3525 y(classi\002cations,)27 b(which)c(were)h(tests)g (of)g(1\))f(scaling)i(beha)n(vior)l(,)h(2\))e(heterogeneity)j(and)d (3\))g(f)o(airness.)141 3638 y(In)36 b(most)h(cases,)j(the)c(tests)h (are)g(equally)h(v)n(alid)f(for)f(single-rate)j(and)e(multi-rate)h (congestion)h(control)f(schemes,)0 3751 y(although)25 b(the)f(e)o(xpected)h(outcomes)f(of)f(the)h(e)o(xperiments)h(in)e (those)h(tw)o(o)f(domains)h(may)f(v)n(ary)-6 b(.)29 b(Unless)24 b(otherwise)g(spec-)0 3864 y(i\002ed,)h(all)f(of)h(the)g (methodological)k(considerations)g(described)e(in)e(the)g(pre)n(vious)h (section)h(apply)-6 b(.)33 b(When)25 b(not)h(otherwise)0 3977 y(speci\002ed,)38 b(we)c(use)g(a)g(def)o(ault)i(setting)g(of)f (10ms)f(latenc)o(y)i(on)e(all)h(links,)j(1KB)33 b(pack)o(et)j(size)f (including)i(headers)f(and)0 4089 y(100Mbps)25 b(bandwidth)h(on)d (links)i(which)f(are)g(not)f(bottleneck)k(links.)141 4202 y(The)h(e)o(xperiments)j(we)d(emplo)o(y)h(ha)n(v)o(e)h(tw)o(o)e(v) o(ery)h(dif)n(ferent)h(sources)h(of)d(pack)o(et)i(loss.)45 b(In)29 b(some)f(e)o(xperiments,)k(we)0 4315 y(ha)n(v)o(e)24 b(a)f(lar)n(ge)i(amount)f(of)f(a)n(v)n(ailable)j(bandwidth)f(to)e (support)j(the)d(\003o)n(ws)g(and)g(emplo)o(y)i(random)f(dropping)i(of) d(pack)o(ets)i(at)0 4428 y(links)h(to)f(achie)n(v)o(e)i(loss.)34 b(In)25 b(other)i(e)o(xperiments,)g(we)e(study)h(the)g(queuing)h(beha)n (vior)h(of)d(the)g(system,)i(dropping)g(pack)o(ets)0 4541 y(only)d(when)g(queues)h(o)o(v)o(er\003o)n(w)e(\(or)h(in)f(the)h (case)g(of)g(RED,)d(only)j(when)g(queues)h(elect)g(to)e(drop)h(pack)o (ets\).)114 4754 y(1.)45 b(Sanity)29 b(check)g(\(Figure)g(1\).)42 b(A)27 b(single)j(multicast)f(sender)h(and)e(a)g(single)h(multicast)h (recei)n(v)o(er)f(be)o(gin)g(to)f(commu-)227 4867 y(nicate)f(o)o(v)o (er)f(a)g(three)g(hop)h(path)f(with)g(bottleneck)i(bandwidth)g(1Mbps.) 37 b(After)25 b(30)h(seconds,)i(a)e(CBR)e(\003o)n(w)g(emits)227 4979 y(cross)29 b(traf)n(\002c)f(o)o(v)o(er)g(the)g(bottleneck)j(link)d (at)g(rate)g(500Kbps.)44 b(After)28 b(60)g(seconds,)i(the)e(CBR)e (\003o)n(w)h(decreases)j(its)227 5092 y(rate)35 b(to)f(250Kbps.)62 b(Expected)36 b(beha)n(vior:)53 b(The)34 b(multicast)h(\003o)n(w)e (should)j(adapt)f(to)f(the)h(a)n(v)n(ailable)h(bottleneck)227 5205 y(bandwidth)26 b(smoothly)f(and)f(ef)n(\002ciently)-6 b(.)1927 5649 y(2)p eop %%Page: 3 3 3 2 bop 114 91 a Fh(2.)45 b(Correlated)24 b(loss.)29 b(Referring)24 b(to)d(Figure)i(2,)f(a)f(sender)j(transmits)f(to)f (three)h(recei)n(v)o(ers)h(o)o(v)o(er)e(a)f(binary)j(tree)e(of)g(depth) 227 204 y(3)27 b(\(the)h(link)g(nearest)g(the)g(sender)g(is)f(shared)i (by)e(all)g(three)h(paths\).)41 b(Then)27 b(we)g(run)g(three)h(dif)n (ferent)h(e)o(xperiments.)227 317 y(In)c(e)o(xperiment)h(A,)d(the)h (shared)i(link)f(e)o(xperiences)i(random)f(loss)e(of)h(10\045.)31 b(In)24 b(e)o(xperiment)i(B,)d(the)i(shared)g(e)o(xpe-)227 430 y(riences)h(0\045)d(pack)o(et)i(loss,)f(b)n(ut)g(the)h(binary)g (branches)h(at)d(the)h(ne)o(xt)g(le)n(v)o(el)g Fe(both)f Fh(e)o(xperience)j(10\045)e(pack)o(et)h(loss.)30 b(In)227 543 y(e)o(xperiment)22 b(C,)d(the)i(three)g(links)h(closest)g(to)e(the) h(recei)n(v)o(ers)h(e)o(xperience)h(10\045)d(pack)o(et)i(loss)3112 510 y Fd(1)3151 543 y Fh(.)27 b(Expected)21 b(beha)n(vior:)227 656 y(The)h(multicast)i(\003o)n(ws)e(should)i(produce)g(similar)f(mean) g(bandwidth)h(in)f(all)f(three)i(e)o(xperiments)g(whether)g(the)f(loss) 227 769 y(is)k(correlated)j(\(A\))c(or)h(uncorrelated)k(\(B)26 b(and)h(C\).)f(This)h(mean)g(bandwidth)i(should)g(be)e(approximately)j (equal)e(to)227 882 y(that)c(of)g(a)f(TCP)e(connection)27 b(along)e(the)f(same)f(path)h(\(tested)h(later\).)114 1065 y(3.)45 b(Heterogeneous)33 b(loss.)48 b(Referring)31 b(Figure)f(2,)h(reproduce)h(e)o(xperiment)g(\(B\))d(from)g(the)h(loss)g (correlation)j(e)o(xper)n(-)227 1178 y(iment,)h(b)n(ut)e(reduce)h(the)e (link)h(loss)h(rate)e(en)h(route)g(to)g(recei)n(v)o(er)h(3)e(to)g (5\045.)52 b(Then,)33 b(rerun)f(the)g(e)o(xperiment)h(after)227 1291 y(separating)d(the)e(remaining)h(10\045)d(loss)i(se)o(gment)g (into)g(tw)o(o)f(5\045)f(loss)i(se)o(gments,)h(the)e(second)i(of)e (which)g(is)g(used)227 1404 y(only)k(by)f(recei)n(v)o(er)h(1.)47 b(In)29 b(the)h(latter)h(con\002guration,)j(recei)n(v)o(er)d(1)e(has)h (tw)o(o)g(5\045)f(loss)h(se)o(gments,)i(recei)n(v)o(er)f(2)f(has)227 1517 y(a)d(single)i(5\045)d(loss)i(se)o(gment)g(shared)g(with)f(recei)n (v)o(er)i(1,)e(and)h(recei)n(v)o(er)g(3)f(has)h(an)f(uncorrelated)j (loss)e(se)o(gment)g(of)227 1630 y(5\045.)j(Expected)26 b(beha)n(vior:)34 b(F)o(or)23 b(single-rate)k(multicast)f(congestion)i (control,)e(the)f(mean)f(throughput)k(should)e(be)227 1742 y(similar)k(to)e(that)h(of)g(a)f(TCP)f(connection)32 b(to)c(the)h(recei)n(v)o(er)h(e)o(xperiencing)i(10\045)c(loss)i(in)e (both)i(e)o(xperiments.)46 b(F)o(or)227 1855 y(multi-rate)25 b(congestion)g(control,)g(paths)e(to)g(recei)n(v)o(ers)h(with)f(5\045)f (loss)h(rates)h(should)g(ideally)g(recei)n(v)o(e)g(commensu-)227 1968 y(rately)h(better)g(throughput)h(than)f(paths)f(to)g(those)g (recei)n(v)o(ers)i(e)o(xperiencing)h(10\045)c(loss)h(rates.)114 2151 y(4.)45 b(Heterogeneous)32 b(latenc)o(y)e(\(hard\).)44 b(T)-7 b(ak)o(e)28 b(a)g(topology)j(with)d(a)g(single)h(multicast)h (sender)g(and)f(tw)o(o)f(recei)n(v)o(ers.)44 b(A)227 2264 y(100)25 b(Mbps)f(link)h(with)f(10\045)f(pack)o(et)j(loss)e(is)g (placed)i(along)f(the)f(shared)i(se)o(gment)e(of)g(the)h(tree.)30 b(The)24 b(independent)227 2377 y(se)o(gments)30 b(of)e(the)g(tree)g (each)h(ha)n(v)o(e)g(100Mbps)h(bandwidth,)h(1\045)c(pack)o(et)j(loss)e (rates,)i(b)n(ut)f(ha)n(v)o(e)f(latencies)j(which)227 2490 y(dif)n(fer)24 b(by)f(an)f(order)i(of)f(magnitude.)30 b(The)23 b(link)g(to)g(recei)n(v)o(er)h(1)e(has)h(20ms)g(latenc)o(y)h (and)f(the)g(link)h(to)e(recei)n(v)o(er)i(2)f(has)227 2603 y(200ms)e(latenc)o(y)-6 b(.)30 b(Measure)21 b(scenarios)i(in)d (which)h(recei)n(v)o(er)h(1)e(arri)n(v)o(es)h(\002rst)g(and)f(in)h (which)g(recei)n(v)o(er)g(2)f(arri)n(v)o(es)i(\002rst.)227 2716 y(Desired)k(beha)n(vior:)34 b(Deli)n(v)o(er)24 b(mean)h (throughput)j(to)c(both)i(recei)n(v)o(ers)g(which)f(is)f(approximately) k(equal)e(to)e(that)h(of)227 2829 y(a)30 b(TCP)e(connection)33 b(along)f(the)e(higher)i(latenc)o(y)f(path.)50 b(F)o(or)29 b(multi-rate)j(congestion)h(control,)g(simultaneously)227 2942 y(deli)n(v)o(er)25 b(better)g(performance)h(to)d(recei)n(v)o(er)i (1.)114 3125 y(5.)45 b(Simple)19 b(TCP)d(f)o(airness)k(\(Figure)g(3\).) 27 b(Construct)20 b(a)e(double)i(star)f(topology)i(with)d(senders)i(on) f(the)g(left)g(and)g(recei)n(v)o(ers)227 3238 y(on)27 b(the)g(right)h(sharing)h(a)d(bottleneck)k(link.)39 b(F)o(or)26 b(each)h(of)g(the)g(bottleneck)j(bandwidths)f(suggested,)h(initiate)f (tw)o(o)227 3351 y(TCP)f(\003o)n(ws)h(and)i(ten)f(seconds)i(later)l(,)h (initiate)e(a)f(multicast)i(\003o)n(w)c(to)i(tw)o(o)g(recei)n(v)o(ers.) 50 b(Expected)31 b(beha)n(vior:)45 b(An)227 3464 y(equilibrium)30 b(should)f(quickly)g(be)e(reached)i(in)e(which)g(the)g(multicast)i (\003o)n(w)d(recei)n(v)o(es)i(approximately)j(one-third)227 3577 y(of)24 b(the)g(a)n(v)n(ailable)h(bandwidth.)114 3760 y(6.)45 b(TCP)18 b(f)o(airness)j(with)f(high)g(multiple)o(xing.)30 b(Same)18 b(topology)k(and)e(general)i(set-up)f(as)e(in)g(the)h(pre)n (vious)i(e)o(xperiment,)227 3873 y(b)n(ut)36 b(scale)h(up)f(the)g (number)g(of)g(TCP)d(\003o)n(ws)i(as)g(the)h(bottleneck)j(bandwidth)e (increases,)k(and)36 b(v)o(erify)h(that)f(the)227 3986 y(multicast)25 b(session)h(still)e(recei)n(v)o(es)h(\(only\))g(its)e(f) o(air)h(share.)114 4169 y(7.)45 b(Inter)n(-session)23 b(f)o(airness.)29 b(Same)18 b(topology)j(and)e(general)i(set-up)f(as)f (in)f(the)h(pre)n(vious)i(tw)o(o)d(e)o(xperiments,)k(b)n(ut)d(1\))g (use)227 4282 y(multicast)j(\003o)n(ws)e(e)o(xclusi)n(v)o(ely)i(and)f (2\))g(scale)g(up)f(the)h(number)g(of)g(multicast)h(\003o)n(ws)d(and)i (TCP)d(\003o)n(ws)i(concurrently)-6 b(.)114 4465 y(8.)45 b(Heterogeneous)30 b(f)o(airness.)38 b(Be)o(gin)26 b(with)g(the)g (double)i(star)f(topology)h(used)f(in)f(the)g(simple)h(TCP)d(f)o (airness)k(e)o(xper)n(-)227 4578 y(iment.)39 b(No)n(w)26 b(mak)o(e)h(the)g(round-trip)j(times)d(that)h(\003o)n(ws)d(e)o (xperience)30 b(heterogeneous)h(by)c(v)n(arying)i(the)e(latencies)227 4691 y(on)k(the)h(last)f(hops)h(to)f(the)g(recei)n(v)o(ers.)52 b(W)l(ith)32 b(tw)o(o)e(TCP)f(\003o)n(ws)h(and)h(one)h(multicast)g (\003o)n(w)e(to)g(tw)o(o)h(recei)n(v)o(ers,)j(al-)227 4804 y(lo)n(w)f(one)i(of)f(each)g(type)h(of)f(recei)n(v)o(er)h(to)f(ha) n(v)o(e)h(a)e(short)i(last)g(hop)f(\(10ms\))h(and)f(one)h(to)e(ha)n(v)o (e)i(a)e(long)i(last)g(hop)227 4917 y(\(100ms\).)41 b(Expected)29 b(beha)n(vior:)39 b(F)o(or)26 b(single-rate)k(congestion)g(control,)g (the)d(multicast)i(throughput)h(should)f(be)227 5030 y(comparable)g(to)d(the)h(mean)f(throughput)k(achie)n(v)o(ed)e(by)e (the)h(TCP)d(\003o)n(w)h(with)h(the)h(long)g(last)g(hop.)38 b(F)o(or)25 b(multi-rate)227 5143 y(congestion)h(control,)d(the)g(tw)o (o)f(short)h(recei)n(v)o(ers)h(and)e(the)h(tw)o(o)f(long)h(recei)n(v)o (ers)g(should)h(ideally)g(ha)n(v)o(e)f(comparable)227 5256 y(mean)h(throughput)j(v)n(alues.)p 0 5313 1560 4 v 105 5368 a Fc(1)134 5400 y Fb(Note)19 b(that)g(the)g(link)g (bandwidths)h(should)g(be)f(set)g(to)g(be)g(lar)o(ge)g(enough)i(to)d(a) o(v)o(oid)h(queuing)i(ef)n(fects,)d(i.e.)23 b(100Mbps)1927 5649 y Fh(3)p eop %%Page: 4 4 4 3 bop 114 91 a Fh(9.)45 b(Augmented)27 b(sanity)f(check)g (\(scalability\).)37 b(Build)25 b(a)g(binary)h(tree)g(with)f(recei)n(v) o(ers)h(at)f(the)h(lea)n(v)o(es,)g(scaling)h(the)e(set)227 204 y(of)h(recei)n(v)o(ers)h(up)f(to)g(hundreds)i(of)e(recei)n(v)o (ers.)37 b(Place)26 b(the)g(source)h(one)f(hop)g(a)o(w)o(ay)g(from)f (the)i(root)f(of)g(this)g(tree)g(on)227 317 y(a)h(1Mbps)h(link.)41 b(No)n(w)26 b(initiate)j(a)e(multicast)h(session)h(to)f(these)g(recei)n (v)o(ers.)42 b(After)27 b(30)g(seconds,)j(inject)f(500Kbps)227 430 y(CBR)20 b(cross)i(traf)n(\002c)f(on)g(the)h(shared)h(link)f (adjoining)h(the)f(source.)29 b(After)22 b(60)f(seconds,)i(reduce)g (this)f(cross)g(traf)n(\002c)f(to)227 543 y(250Kbps.)37 b(Expected)28 b(beha)n(vior:)36 b(Ideally)28 b(the)e(mean)g(throughput) j(seen)d(by)g(the)g(recei)n(v)o(ers)i(should)f(be)f(the)g(same)227 656 y(as)c(in)g(the)h(basic)g(sanity)g(check.)30 b(Be)21 b(sure)i(to)f(measure)h(the)g(dif)n(ference)h(in)e(responsi)n(v)o (eness)k(from)c(the)h(basic)g(sanity)227 769 y(check,)i(and)f (demonstrate)i(the)e(scalability)i(of)e(the)f(re)n(v)o(erse)i(path)f (traf)n(\002c)g(\(A)l(CKs,)e(N)m(AKs,)g(etc.\).)68 956 y(10.)46 b(Throughput-loss)32 b(curv)o(e.)43 b(W)l(ith)29 b(a)e(single)j(sender)f(and)f(recei)n(v)o(er)i(setup)f(as)f(in)g(the)g (basic)h(sanity)g(check)g(\(Figure)227 1069 y(1\),)36 b(set)d(the)h(bottleneck)i(bandwidth)g(to)d(be)g(lar)n(ge)i(\(100)f (Mbps\).)59 b(Then)33 b(v)n(ary)h(the)g(random)g(loss)g(rate)g(and)g (the)227 1182 y(round-trip)g(time)e(on)f(the)h(bottleneck)i(link)e(and) f(plot)h(the)g(throughput-loss)k(curv)o(e)c(of)f(the)h(congestion)i (control)227 1295 y(protocol.)68 1483 y(11.)46 b(Bandwidth)35 b(absorption.)63 b(Ne)n(v)o(er)33 b(fully)i(speci\002ed.)61 b(W)-7 b(e)33 b(had)h(a)f(half-bak)o(ed)k(idea)d(of)g(using)h(the)f (basic)h(sanity)227 1596 y(check)28 b(set-up)g(and)f(measuring)h(the)f (mean)g(throughput)i(achie)n(v)o(ed)g(by)d(a)g(multicast)i(session)h (vs.)37 b(an)27 b(unspeci\002ed)227 1709 y(deterministic)40 b(VBR)34 b(\003o)n(w)-6 b(.)66 b(The)36 b(main)h(point)g(of)f(this)h(e) o(xperiment)i(w)o(ould)e(be)f(to)g(demonstrate)j(reasonable)227 1822 y(responsi)n(v)o(eness)28 b(to)23 b(changing)j(netw)o(ork)f (circumstances.)68 2009 y(12.)46 b(Correct)23 b(loss)f(aggre)o(gation)j (\(Figure)e(4\).)28 b(Build)22 b(a)f(tree)i(with)e(a)h(sequence)i(of)e (lossy)h(links)g(f)o(alling)g(from)f(5\045)f(to)h(1\045)227 2122 y(at)k(1\045)g(interv)n(als.)38 b(Place)26 b(a)g(single)h(client)h (do)n(wnstream)f(of)f(each)h(lossy)g(link)g(\(\002)n(v)o(e)e(in)h (all\).)37 b(Expected)27 b(beha)n(vior:)227 2235 y(The)21 b(w)o(orst-case)h(client)g(e)o(xperiences)i(15\045)d(pack)o(et)h(loss)g (and)f(should)h(be)f(accorded)i(an)e(appropriate)j(throughput.)68 2423 y(13.)46 b(Drop-to-zero.)c(Build)28 b(a)e(star)i(topology)h(for)e (a)g(multicast)i(session)f(with)f(50)g(recei)n(v)o(ers,)j(each)d(e)o (xperiencing)k(5\045)227 2535 y(pack)o(et)24 b(loss)f(o)o(v)o(er)g (uncorrelated)j(links.)j(In)22 b(a)g(second)i(e)o(xperiment,)g(let)f (the)g(50th)g(recei)n(v)o(er)g(e)o(xperience)i(20\045)e(loss)227 2648 y(rather)33 b(than)f(5\045.)52 b(Compare)33 b(the)e(throughput)k (to)d(the)f(throughput)k(that)d(a)f(TCP)f(\003o)n(w)g(e)o(xperiencing) 35 b(identical)227 2761 y(conditions)k(w)o(ould)d(recei)n(v)o(e.)66 b(Expected)38 b(beha)n(vior:)56 b(The)35 b(session)i(rate)g(should)g (not)f(drop)g(to)g(zero)g(in)g(either)227 2874 y(case;)j(in)33 b(the)g(second)i(e)o(xperiment,)h(single-rate)g(congestion)g(control)f (schemes)f(should)h(reduce)f(their)g(rate)f(to)227 2987 y(compensate)26 b(for)e(the)g(lossy)g(recei)n(v)o(er)-5 b(.)68 3175 y(14.)46 b(Anticorrelated)29 b(loss.)35 b(Build)25 b(a)g(star)h(topology)i(for)d(a)g(multicast)i(session)g(with)e(20)h (recei)n(v)o(ers.)35 b(At)25 b(an)o(y)g(instant)i(in)227 3288 y(time,)e(19)f(of)h(the)f(recei)n(v)o(ers)j(will)d(e)o(xperience)j (1\045)d(pack)o(et)i(loss,)f(while)g(the)g(twentieth)h(recei)n(v)o(er)f (will)g(e)o(xperience)227 3401 y(5\045)32 b(pack)o(et)j(loss.)57 b(The)32 b(location)j(of)e(the)g(lossy)h(recei)n(v)o(er)g Fg(r)l(otates)g Fh(e)n(v)o(ery)g Fa(k)h Fh(seconds,)i(where)c Fa(k)i Fh(is)e(either)h(0.5,)227 3513 y(5,)28 b(or)f(15.)40 b(This)27 b(particular)i(protocol)h(must)d(be)g(tested)h(with)f (accurate)j(modeling)e(of)g(IGMP)d(lea)n(v)o(e)j(latenc)o(y)h(and)227 3626 y(throughput)34 b(should)e(again)f(be)g(compared)h(with)e(TCP)f (\003o)n(ws)g(e)o(xperiencing)34 b(identical)f(conditions.)53 b(Expected)227 3739 y(beha)n(vior:)40 b(W)l(ith)28 b(single-rate)i (congestion)h(control,)f(the)e(session)h(rate)f(must)g(cater)g(to)g (the)g(lossy)g(recei)n(v)o(er;)j(with)227 3852 y(multi-rate,)25 b(the)f(e)o(xperiment)h(tests)g(tolerance)h(to)d(IGMP)f(lea)n(v)o(e)j (latenc)o(y)-6 b(.)68 4040 y(15.)46 b(Multiple)37 b(bottlenecks)i (\(Figure)d(5\).)65 b(Build)35 b(a)g(binary)i(tree)f(with)f(8)g(lea)n (v)o(es)i(and)f(label)g(the)g(links)h(of)e(the)h(tree)227 4153 y(with)27 b(their)g(loss)g(rates.)39 b(The)26 b(four)i(lossy)f (links)h(include)g(the)f(tw)o(o)g(links)g(adjoining)i(the)e(root,)h (with)e(loss)i(rate)f(4\045)227 4266 y(and)j(1\045)e(respecti)n(v)o (ely)-6 b(,)34 b(a)28 b(link)i(with)f(2\045)g(loss)g(immediately)i (belo)n(w)f(the)f(link)h(with)f(4\045)f(loss,)j(and)f(a)f(link)g(with) 227 4379 y(9\045)e(adjoining)j(a)e(client)g(under)h(the)f(1\045)f (subtree.)43 b(Initiate)29 b(a)e(multicast)i(session)h(with)d(recei)n (v)o(ers)i(located)h(at)d(all)227 4491 y(eight)k(lea)n(v)o(es,)h(and)f (run)f(four)g(TCP)e(sessions)k(from)e(the)g(source)h(to)f(a)f(client)i (in)f(each)h(of)e(the)h(four)h(distinct)h(loss)227 4604 y(re)o(gions)k(\(totaling)g(4\045,)g(6\045,)g(1\045,)f(and)g(10\045\).) 60 b(Expected)36 b(beha)n(vior)g(for)f(multi-rate)g(sessions:)53 b(comparable)227 4717 y(mean)24 b(throughput)j(at)c(each)h(recei)n(v)o (er)h(for)f(their)g(multicast)h(session)h(and)e(their)g(TCP)d(\003o)n (w)-6 b(.)68 4905 y(16.)46 b(PIM/IGMP)30 b(issues.)55 b(W)-7 b(e)31 b(suggested)j(a)d(topology)j(which)e(is)g(be)o(yond)h (the)f(scope)h(of)e(a)h(te)o(xtual)h(writeup.)54 b(The)227 5018 y(main)29 b(point)h(of)e(this)i(comple)o(x)f(scenario)i(w)o(as)d (to)h(v)o(erify)g(TCP-friendliness)i(e)n(v)o(en)e(when)g(issues)h(of)f (IGMP)e(and)227 5131 y(PIM)g(latenc)o(y)i(are)g(apparent.)44 b(The)27 b(topology)k(we)c(considered)k(included)f(three)f(nasty)g (beasts)h(in)d(succession:)42 b(a)227 5244 y(LAN)30 b(which)i(PIM)e (messages)j(needed)g(to)f(tra)n(v)o(erse)h(\(3)f(seconds\),)j(a)c(high) i(latenc)o(y)f(link)h(\(100ms\))f(and)g(a)f(last-)227 5357 y(hop)22 b(router)g(which)f(processed)j(IGMP)c(messages)i(\(3-9)g (seconds\).)30 b(W)-7 b(e)20 b(adv)n(ocated)k(putting)f(a)d(multicast)j (recei)n(v)o(er)1927 5649 y(4)p eop %%Page: 5 5 5 4 bop 585 1534 a @beginspecial 0 @llx 0 @lly 452 @urx 254 @ury 3276 @rwi @setspecial %%BeginDocument: topo1.eps %!PS-Adobe-2.0 EPSF-2.0 %%Title: topo1.eps %%Creator: fig2dev Version 3.2 Patchlevel 3c %%CreationDate: Wed Jun 13 13:51:26 2001 %%For: lorenzo@adsl-64-169-54-2.dsl.snfc21.pacbell.net (Lorenzo Vicisano)= %%BoundingBox: 0 0 452 254 %%Magnification: 1.0000 %%EndComments /$F2psDict 200 dict def $F2psDict begin $F2psDict /mtrx matrix put /col-1 {0 setgray} bind def /col0 {0.000 0.000 0.000 srgb} bind def /col1 {0.000 0.000 1.000 srgb} bind def /col2 {0.000 1.000 0.000 srgb} bind def /col3 {0.000 1.000 1.000 srgb} bind def /col4 {1.000 0.000 0.000 srgb} bind def /col5 {1.000 0.000 1.000 srgb} bind def /col6 {1.000 1.000 0.000 srgb} bind def /col7 {1.000 1.000 1.000 srgb} bind def /col8 {0.000 0.000 0.560 srgb} bind def /col9 {0.000 0.000 0.690 srgb} bind def /col10 {0.000 0.000 0.820 srgb} bind def /col11 {0.530 0.810 1.000 srgb} bind def /col12 {0.000 0.560 0.000 srgb} bind def /col13 {0.000 0.690 0.000 srgb} bind def /col14 {0.000 0.820 0.000 srgb} bind def /col15 {0.000 0.560 0.560 srgb} bind def /col16 {0.000 0.690 0.690 srgb} bind def /col17 {0.000 0.820 0.820 srgb} bind def /col18 {0.560 0.000 0.000 srgb} bind def /col19 {0.690 0.000 0.000 srgb} bind def /col20 {0.820 0.000 0.000 srgb} bind def /col21 {0.560 0.000 0.560 srgb} bind def /col22 {0.690 0.000 0.690 srgb} bind def /col23 {0.820 0.000 0.820 srgb} bind def /col24 {0.500 0.190 0.000 srgb} bind def /col25 {0.630 0.250 0.000 srgb} bind def /col26 {0.750 0.380 0.000 srgb} bind def /col27 {1.000 0.500 0.500 srgb} bind def /col28 {1.000 0.630 0.630 srgb} bind def /col29 {1.000 0.750 0.750 srgb} bind def /col30 {1.000 0.880 0.880 srgb} bind def /col31 {1.000 0.840 0.000 srgb} bind def end save newpath 0 254 moveto 0 0 lineto 452 0 lineto 452 254 lineto closepath cli= p newpath -35.0 253.0 translate 1 -1 scale /cp {closepath} bind def /ef {eofill} bind def /gr {grestore} bind def /gs {gsave} bind def /sa {save} bind def /rs {restore} bind def /l {lineto} bind def /m {moveto} bind def /rm {rmoveto} bind def /n {newpath} bind def /s {stroke} bind def /sh {show} bind def /slc {setlinecap} bind def /slj {setlinejoin} bind def /slw {setlinewidth} bind def /srgb {setrgbcolor} bind def /rot {rotate} bind def /sc {scale} bind def /sd {setdash} bind def /ff {findfont} bind def /sf {setfont} bind def /scf {scalefont} bind def /sw {stringwidth} bind def /tr {translate} bind def /tnt {dup dup currentrgbcolor 4 -2 roll dup 1 exch sub 3 -1 roll mul add 4 -2 roll dup 1 exch sub 3 -1 roll mul add 4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb} bind def /shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul 4 -2 roll mul srgb} bind def /DrawEllipse { /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y tr xrad yrad sc 0 0 1 startangle endangle arc closepath savematrix setmatrix } def /$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def /$F2psEnd {$F2psEnteredState restore end} def $F2psBegin %%Page: 1 1 10 setmiterlimit 0.06000 0.06000 sc % % Fig objects follow % /Courier ff 270.00 scf sf 2625 1890 m gs 1 -1 sc (1) col0 sh gr /Courier ff 270.00 scf sf 1725 2115 m gs 1 -1 sc (1) col0 sh gr /Courier ff 360.00 scf sf 7050 2025 m gs 1 -1 sc (r) col0 sh gr /Courier ff 270.00 scf sf 7275 2115 m gs 1 -1 sc (1) col0 sh gr 30.000 slw % Ellipse n 3546 1954 404 404 0 360 DrawEllipse gs col0 s gr % Ellipse n 5496 1954 404 404 0 360 DrawEllipse gs col0 s gr % Polyline n 7500 2325 m 7712 1943 l 7487 1568 l 7050 1575 l 6838 1957 l 7063 2332 l= cp gs col0 s gr = % Polyline 15.000 slw n 2175 1950 m 3150 1950 l gs col0 s gr = % Polyline n 3975 1950 m 5100 1950 l gs col0 s gr = % Polyline n 5925 1950 m 6825 1950 l gs col0 s gr = % Polyline 30.000 slw n 1937 2318 m 2149 1936 l 1924 1561 l 1487 1568 l 1275 1950 l 1500 2325 l= cp gs col0 s gr = % Polyline 0.000 slw n 600 0 m 8100 0 l 8100 4200 l 600 4200 l cp = /Courier ff 360.00 scf sf 4275 1800 m gs 1 -1 sc (L) col0 sh gr /Courier ff 270.00 scf sf 4500 1890 m gs 1 -1 sc (2) col0 sh gr /Courier ff 360.00 scf sf 6225 1800 m gs 1 -1 sc (L) col0 sh gr /Courier ff 270.00 scf sf 6450 1890 m gs 1 -1 sc (3) col0 sh gr /Courier ff 360.00 scf sf 2400 1800 m gs 1 -1 sc (L) col0 sh gr /Courier ff 360.00 scf sf 1500 2025 m gs 1 -1 sc (s) col0 sh gr $F2psEnd rs %%EndDocument @endspecial 1488 1830 a Fh(Figure)24 b(1:)29 b Fk(single)20 b(bottleneck)p 0 1943 3900 5 v 227 2200 a Fh(behind)i(each)e(of)g (these)h(obstacles,)i(then)d(running)i(a)e(multicast)h(session)h(to)e (these)h(recei)n(v)o(ers)g(alongside)i(indi)n(vidual)227 2313 y(TCP)f(\003o)n(ws.)29 b(It)23 b(is)h(of)g(course)h(necessary)h (to)e(perform)h(hop-by-hop)i(modeling)f(of)e(control)h(messages)h(to)d (run)i(this)227 2426 y(simulation.)31 b(Expected)25 b(beha)n(vior:)32 b(good)24 b(luck.)0 2818 y Fi(3)119 b(Outcomes)30 b(and)g(T)-11 b(opics)30 b(W)-8 b(e)30 b(Didn't)h(Co)o(v)o(er)0 3025 y Fh(In)20 b(most)f(cases,)i(the)f(e)o(xperiments)i(we)d(ha)n(v)o(e)h (enumerated)i(here)e(ha)n(v)o(e)g(been)h(designed)h(with)d(a)g(primary) i(goal)f(of)g(attaining)0 3138 y(an)34 b(appropriate)i(mean)e (throughput)j(v)n(alue)d(o)o(v)o(er)g(reasonable)j(time)c(scales)i(at)e (each)i(recei)n(v)o(er)-5 b(.)60 b(W)-7 b(e)33 b(often)h(implicitly)0 3251 y(mak)o(e)29 b(the)h(assumption)i(that)d(compatibility)k(with)c(a) g(TCP)e(\003o)n(w)h(operating)j(in)f(the)f(same)g(en)l(vironment)k(is)c (equi)n(v)n(alent)0 3364 y(to)j(a)g(successful)i(outcome.)56 b(Ho)n(we)n(v)o(er)l(,)34 b(we)d(emphasize)j(that)e(we)g(do)g(not)g (intend)i(for)e(this)g(objecti)n(v)o(e)i(to)e(be)g(attained)0 3477 y(by)d(incurring)i(performance)g(penalties)g(which)f(were)e(not)h (e)o(xplicitly)i(mentioned)g(in)e(the)g(writeup.)45 b(When)29 b(e)n(v)n(aluating)0 3590 y(a)f(multicast)i(congestion)h(control)f (protocol,)i(it)c(is)g(essential)j(to)d(measure)i(its)e(other)i (impacts,)g(such)f(as)f(the)h(amount)g(of)0 3702 y(traf)n(\002c)i(it)f (generates)k(on)d(the)g(re)n(v)o(erse)h(path,)h(or)e(the)g(amount)g(of) g(control)i(traf)n(\002c)e(it)f(generates.)53 b(W)-7 b(e)30 b(also)i(recommend)0 3815 y(quantifying)27 b(the)d(protocol')-5 b(s)26 b(responsi)n(v)o(eness,)h(especially)g(the)c(time)h(it)f(tak)o (es)i(to)e(react)h(to)g(congestion.)141 3928 y(While)g(this)f(list)h (of)f(e)o(xperiments)i(is)e(incomplete)j(and)e(should)g(be)g(vie)n(wed) f(as)g(a)g(w)o(ork)g(in)g(progress,)j(there)e(are)f(some)0 4041 y(omissions)k(which)f(are)g(intentional.)38 b(W)-7 b(e)24 b(did)i(not)g(consider)i(simulations)g(which)e(co)o(v)o(er)g(f)o (ailure)h(cases,)f(including)j(link)0 4154 y(f)o(ailure,)i(recei)n(v)o (er)f(f)o(ailure)g(and)f(aggre)o(gation)i(node)f(f)o(ailure.)46 b(W)-7 b(e)27 b(also)j(did)f(not)f(consider)j(simulations)g(which)e (include)0 4267 y(changes)36 b(in)e(the)g(topology)i(during)g (simulation.)62 b(Finally)-6 b(,)37 b(we)c(did)h(not)g(consider)i (simulations)h(which)d(studied)i(rich)0 4380 y(netw)o(ork)29 b(topologies.)45 b(An)o(y)27 b(successful)k(multicast)e(congestion)i (control)f(protocols)g(will)e(be)g(e)o(xpected)i(to)d(address)j(all)0 4493 y(of)23 b(these)i(cases.)1927 5649 y(5)p eop %%Page: 6 6 6 5 bop 585 1896 a @beginspecial 0 @llx 0 @lly 452 @urx 254 @ury 3276 @rwi @setspecial %%BeginDocument: topo2.eps %!PS-Adobe-2.0 EPSF-2.0 %%Title: topo2.eps %%Creator: fig2dev Version 3.2 Patchlevel 3c %%CreationDate: Wed Jun 13 13:50:49 2001 %%For: lorenzo@adsl-64-169-54-2.dsl.snfc21.pacbell.net (Lorenzo Vicisano)= %%BoundingBox: 0 0 452 254 %%Magnification: 1.0000 %%EndComments /$F2psDict 200 dict def $F2psDict begin $F2psDict /mtrx matrix put /col-1 {0 setgray} bind def /col0 {0.000 0.000 0.000 srgb} bind def /col1 {0.000 0.000 1.000 srgb} bind def /col2 {0.000 1.000 0.000 srgb} bind def /col3 {0.000 1.000 1.000 srgb} bind def /col4 {1.000 0.000 0.000 srgb} bind def /col5 {1.000 0.000 1.000 srgb} bind def /col6 {1.000 1.000 0.000 srgb} bind def /col7 {1.000 1.000 1.000 srgb} bind def /col8 {0.000 0.000 0.560 srgb} bind def /col9 {0.000 0.000 0.690 srgb} bind def /col10 {0.000 0.000 0.820 srgb} bind def /col11 {0.530 0.810 1.000 srgb} bind def /col12 {0.000 0.560 0.000 srgb} bind def /col13 {0.000 0.690 0.000 srgb} bind def /col14 {0.000 0.820 0.000 srgb} bind def /col15 {0.000 0.560 0.560 srgb} bind def /col16 {0.000 0.690 0.690 srgb} bind def /col17 {0.000 0.820 0.820 srgb} bind def /col18 {0.560 0.000 0.000 srgb} bind def /col19 {0.690 0.000 0.000 srgb} bind def /col20 {0.820 0.000 0.000 srgb} bind def /col21 {0.560 0.000 0.560 srgb} bind def /col22 {0.690 0.000 0.690 srgb} bind def /col23 {0.820 0.000 0.820 srgb} bind def /col24 {0.500 0.190 0.000 srgb} bind def /col25 {0.630 0.250 0.000 srgb} bind def /col26 {0.750 0.380 0.000 srgb} bind def /col27 {1.000 0.500 0.500 srgb} bind def /col28 {1.000 0.630 0.630 srgb} bind def /col29 {1.000 0.750 0.750 srgb} bind def /col30 {1.000 0.880 0.880 srgb} bind def /col31 {1.000 0.840 0.000 srgb} bind def end save newpath 0 254 moveto 0 0 lineto 452 0 lineto 452 254 lineto closepath cli= p newpath -35.0 253.0 translate 1 -1 scale /cp {closepath} bind def /ef {eofill} bind def /gr {grestore} bind def /gs {gsave} bind def /sa {save} bind def /rs {restore} bind def /l {lineto} bind def /m {moveto} bind def /rm {rmoveto} bind def /n {newpath} bind def /s {stroke} bind def /sh {show} bind def /slc {setlinecap} bind def /slj {setlinejoin} bind def /slw {setlinewidth} bind def /srgb {setrgbcolor} bind def /rot {rotate} bind def /sc {scale} bind def /sd {setdash} bind def /ff {findfont} bind def /sf {setfont} bind def /scf {scalefont} bind def /sw {stringwidth} bind def /tr {translate} bind def /tnt {dup dup currentrgbcolor 4 -2 roll dup 1 exch sub 3 -1 roll mul add 4 -2 roll dup 1 exch sub 3 -1 roll mul add 4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb} bind def /shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul 4 -2 roll mul srgb} bind def /DrawEllipse { /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y tr xrad yrad sc 0 0 1 startangle endangle arc closepath savematrix setmatrix } def /$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def /$F2psEnd {$F2psEnteredState restore end} def $F2psBegin %%Page: 1 1 10 setmiterlimit 0.06000 0.06000 sc % % Fig objects follow % /Courier ff 270.00 scf sf 6825 3615 m gs 1 -1 sc (3) col0 sh gr /Courier ff 270.00 scf sf 1425 2115 m gs 1 -1 sc (1) col0 sh gr % Polyline 30.000 slw n 1637 2318 m 1849 1936 l 1624 1561 l 1187 1568 l 975 1950 l 1200 2325 l cp gs col0 s gr = /Courier ff 360.00 scf sf 2025 1725 m gs 1 -1 sc (L) col0 sh gr /Courier ff 270.00 scf sf 2250 1815 m gs 1 -1 sc (1) col0 sh gr % Ellipse n 3171 1954 404 404 0 360 DrawEllipse gs col0 s gr % Ellipse n 4971 1054 404 404 0 360 DrawEllipse gs col0 s gr % Ellipse n 4971 2854 404 404 0 360 DrawEllipse gs col0 s gr % Polyline 0.000 slw n 600 0 m 8100 0 l 8100 4200 l 600 4200 l cp = % Polyline 15.000 slw n 1875 1950 m 2775 1950 l gs col0 s gr = % Polyline n 3450 1650 m 4575 1200 l gs col0 s gr = % Polyline n 3525 2250 m 4575 2700 l gs col0 s gr = % Polyline n 5325 825 m 6375 450 l gs col0 s gr = % Polyline n 5325 1275 m 6375 1650 l gs col0 s gr = % Polyline n 5325 3075 m 6375 3450 l gs col0 s gr = % Polyline 30.000 slw n 7037 2018 m 7249 1636 l 7024 1261 l 6587 1268 l 6375 1650 l 6600 2025 l= cp gs col0 s gr = % Polyline n 7037 818 m 7249 436 l 7024 61 l 6587 68 l 6375 450 l 6600 825 l cp gs col0 s gr = % Polyline n 7037 3818 m 7249 3436 l 7024 3061 l 6587 3068 l 6375 3450 l 6600 3825 l= cp gs col0 s gr = /Courier ff 360.00 scf sf 3825 1050 m gs 1 -1 sc (L) col0 sh gr /Courier ff 270.00 scf sf 4050 1140 m gs 1 -1 sc (2) col0 sh gr /Courier ff 360.00 scf sf 3825 2175 m gs 1 -1 sc (L) col0 sh gr /Courier ff 270.00 scf sf 4050 2265 m gs 1 -1 sc (3) col0 sh gr /Courier ff 360.00 scf sf 5550 375 m gs 1 -1 sc (L) col0 sh gr /Courier ff 270.00 scf sf 5775 465 m gs 1 -1 sc (4) col0 sh gr /Courier ff 360.00 scf sf 5550 1125 m gs 1 -1 sc (L) col0 sh gr /Courier ff 270.00 scf sf 5775 1215 m gs 1 -1 sc (5) col0 sh gr /Courier ff 360.00 scf sf 5550 2925 m gs 1 -1 sc (L) col0 sh gr /Courier ff 270.00 scf sf 5775 3015 m gs 1 -1 sc (6) col0 sh gr /Courier ff 360.00 scf sf 6600 1725 m gs 1 -1 sc (r) col0 sh gr /Courier ff 270.00 scf sf 6825 1815 m gs 1 -1 sc (2) col0 sh gr /Courier ff 360.00 scf sf 6600 525 m gs 1 -1 sc (r) col0 sh gr /Courier ff 270.00 scf sf 6825 615 m gs 1 -1 sc (1) col0 sh gr /Courier ff 360.00 scf sf 6600 3525 m gs 1 -1 sc (r) col0 sh gr /Courier ff 360.00 scf sf 1200 2025 m gs 1 -1 sc (s) col0 sh gr $F2psEnd rs %%EndDocument @endspecial 1530 2192 a Fh(Figure)24 b(2:)29 b Fk(tree)20 b(of)g(depth)f(3)p 0 2305 3900 5 v 585 4629 a @beginspecial 0 @llx 0 @lly 452 @urx 254 @ury 3276 @rwi @setspecial %%BeginDocument: topo3.eps %!PS-Adobe-2.0 EPSF-2.0 %%Title: topo3.eps %%Creator: fig2dev Version 3.2 Patchlevel 3c %%CreationDate: Wed Jun 13 14:19:27 2001 %%For: lorenzo@adsl-64-169-54-2.dsl.snfc21.pacbell.net (Lorenzo Vicisano)= %%BoundingBox: 0 0 452 254 %%Magnification: 1.0000 %%EndComments /$F2psDict 200 dict def $F2psDict begin $F2psDict /mtrx matrix put /col-1 {0 setgray} bind def /col0 {0.000 0.000 0.000 srgb} bind def /col1 {0.000 0.000 1.000 srgb} bind def /col2 {0.000 1.000 0.000 srgb} bind def /col3 {0.000 1.000 1.000 srgb} bind def /col4 {1.000 0.000 0.000 srgb} bind def /col5 {1.000 0.000 1.000 srgb} bind def /col6 {1.000 1.000 0.000 srgb} bind def /col7 {1.000 1.000 1.000 srgb} bind def /col8 {0.000 0.000 0.560 srgb} bind def /col9 {0.000 0.000 0.690 srgb} bind def /col10 {0.000 0.000 0.820 srgb} bind def /col11 {0.530 0.810 1.000 srgb} bind def /col12 {0.000 0.560 0.000 srgb} bind def /col13 {0.000 0.690 0.000 srgb} bind def /col14 {0.000 0.820 0.000 srgb} bind def /col15 {0.000 0.560 0.560 srgb} bind def /col16 {0.000 0.690 0.690 srgb} bind def /col17 {0.000 0.820 0.820 srgb} bind def /col18 {0.560 0.000 0.000 srgb} bind def /col19 {0.690 0.000 0.000 srgb} bind def /col20 {0.820 0.000 0.000 srgb} bind def /col21 {0.560 0.000 0.560 srgb} bind def /col22 {0.690 0.000 0.690 srgb} bind def /col23 {0.820 0.000 0.820 srgb} bind def /col24 {0.500 0.190 0.000 srgb} bind def /col25 {0.630 0.250 0.000 srgb} bind def /col26 {0.750 0.380 0.000 srgb} bind def /col27 {1.000 0.500 0.500 srgb} bind def /col28 {1.000 0.630 0.630 srgb} bind def /col29 {1.000 0.750 0.750 srgb} bind def /col30 {1.000 0.880 0.880 srgb} bind def /col31 {1.000 0.840 0.000 srgb} bind def end save newpath 0 254 moveto 0 0 lineto 452 0 lineto 452 254 lineto closepath cli= p newpath -35.0 253.0 translate 1 -1 scale /cp {closepath} bind def /ef {eofill} bind def /gr {grestore} bind def /gs {gsave} bind def /sa {save} bind def /rs {restore} bind def /l {lineto} bind def /m {moveto} bind def /rm {rmoveto} bind def /n {newpath} bind def /s {stroke} bind def /sh {show} bind def /slc {setlinecap} bind def /slj {setlinejoin} bind def /slw {setlinewidth} bind def /srgb {setrgbcolor} bind def /rot {rotate} bind def /sc {scale} bind def /sd {setdash} bind def /ff {findfont} bind def /sf {setfont} bind def /scf {scalefont} bind def /sw {stringwidth} bind def /tr {translate} bind def /tnt {dup dup currentrgbcolor 4 -2 roll dup 1 exch sub 3 -1 roll mul add 4 -2 roll dup 1 exch sub 3 -1 roll mul add 4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb} bind def /shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul 4 -2 roll mul srgb} bind def /DrawEllipse { /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y tr xrad yrad sc 0 0 1 startangle endangle arc closepath savematrix setmatrix } def /$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def /$F2psEnd {$F2psEnteredState restore end} def $F2psBegin %%Page: 1 1 10 setmiterlimit 0.06000 0.06000 sc % % Fig objects follow % /Courier ff 270.00 scf sf 7275 1740 m gs 1 -1 sc (2) col0 sh gr /Courier ff 270.00 scf sf 1800 765 m gs 1 -1 sc (1) col0 sh gr % Polyline 30.000 slw n 2012 968 m 2224 586 l 1999 211 l 1562 218 l 1350 600 l 1575 975 l cp gs col0 s gr = /Courier ff 360.00 scf sf 7050 675 m gs 1 -1 sc (r) col0 sh gr /Courier ff 270.00 scf sf 7275 765 m gs 1 -1 sc (1) col0 sh gr % Polyline n 7500 975 m 7712 593 l 7487 218 l 7050 225 l 6838 607 l 7063 982 l cp gs col0 s gr = % Ellipse n 3546 1954 404 404 0 360 DrawEllipse gs col0 s gr % Ellipse n 5496 1954 404 404 0 360 DrawEllipse gs col0 s gr % Polyline 15.000 slw n 3975 1950 m 5100 1950 l gs col0 s gr = % Polyline 0.000 slw n 600 0 m 8100 0 l 8100 4200 l 600 4200 l cp = % Polyline 30.000 slw n 2012 1943 m 2224 1561 l 1999 1186 l 1562 1193 l 1350 1575 l 1575 1950 l= cp gs col0 s gr = % Polyline n 2012 3743 m 2224 3361 l 1999 2986 l 1562 2993 l 1350 3375 l 1575 3750 l= cp gs col0 s gr = % Polyline n 7500 3750 m 7712 3368 l 7487 2993 l 7050 3000 l 6838 3382 l 7063 3757 l= cp gs col0 s gr = % Polyline n 7500 1950 m 7712 1568 l 7487 1193 l 7050 1200 l 6838 1582 l 7063 1957 l= cp gs col0 s gr = % Polyline 15.000 slw n 2250 600 m 3300 1650 l gs col0 s gr = % Polyline n 2250 1575 m 3150 1800 l gs col0 s gr = % Polyline n 2250 3375 m 3300 2250 l gs col0 s gr = % Polyline n 6900 3375 m 5775 2250 l gs col0 s gr = % Polyline n 6825 1575 m 5850 1800 l gs col0 s gr = % Polyline n 6825 600 m 5775 1650 l gs col0 s gr = % Polyline [90] 0 sd n 3150 2025 m 2175 2100 l gs col0 s gr [] 0 sd % Polyline [90] 0 sd n 3150 2175 m 2100 2625 l gs col0 s gr [] 0 sd % Polyline [90] 0 sd n 5925 2025 m 6900 2250 l gs col0 s gr [] 0 sd % Polyline [90] 0 sd n 5850 2175 m 6825 2700 l gs col0 s gr [] 0 sd /Courier ff 360.00 scf sf 1575 1650 m gs 1 -1 sc (s) col0 sh gr /Courier ff 270.00 scf sf 1800 1740 m gs 1 -1 sc (2) col0 sh gr /Courier ff 360.00 scf sf 1575 3450 m gs 1 -1 sc (s) col0 sh gr /Courier ff 270.00 scf sf 1800 3540 m gs 1 -1 sc (n) col0 sh gr /Courier ff 360.00 scf sf 7050 3450 m gs 1 -1 sc (r) col0 sh gr /Courier ff 270.00 scf sf 7275 3540 m gs 1 -1 sc (n) col0 sh gr /Courier ff 360.00 scf sf 7050 1650 m gs 1 -1 sc (r) col0 sh gr /Courier ff 360.00 scf sf 1575 675 m gs 1 -1 sc (s) col0 sh gr $F2psEnd rs %%EndDocument @endspecial 1587 4925 a Fh(Figure)24 b(3:)29 b Fk(double)19 b(star)p 0 5038 V 1927 5649 a Fh(6)p eop %%Page: 7 7 7 6 bop 585 1453 a @beginspecial 0 @llx 0 @lly 556 @urx 254 @ury 3276 @rwi @setspecial %%BeginDocument: topo4.eps %!PS-Adobe-2.0 EPSF-2.0 %%Title: topo3.eps %%Creator: fig2dev Version 3.2 Patchlevel 3c %%CreationDate: Wed Jun 13 13:57:20 2001 %%For: lorenzo@adsl-64-169-54-2.dsl.snfc21.pacbell.net (Lorenzo Vicisano)= %%BoundingBox: 0 0 556 254 %%Magnification: 1.0000 %%EndComments /$F2psDict 200 dict def $F2psDict begin $F2psDict /mtrx matrix put /col-1 {0 setgray} bind def /col0 {0.000 0.000 0.000 srgb} bind def /col1 {0.000 0.000 1.000 srgb} bind def /col2 {0.000 1.000 0.000 srgb} bind def /col3 {0.000 1.000 1.000 srgb} bind def /col4 {1.000 0.000 0.000 srgb} bind def /col5 {1.000 0.000 1.000 srgb} bind def /col6 {1.000 1.000 0.000 srgb} bind def /col7 {1.000 1.000 1.000 srgb} bind def /col8 {0.000 0.000 0.560 srgb} bind def /col9 {0.000 0.000 0.690 srgb} bind def /col10 {0.000 0.000 0.820 srgb} bind def /col11 {0.530 0.810 1.000 srgb} bind def /col12 {0.000 0.560 0.000 srgb} bind def /col13 {0.000 0.690 0.000 srgb} bind def /col14 {0.000 0.820 0.000 srgb} bind def /col15 {0.000 0.560 0.560 srgb} bind def /col16 {0.000 0.690 0.690 srgb} bind def /col17 {0.000 0.820 0.820 srgb} bind def /col18 {0.560 0.000 0.000 srgb} bind def /col19 {0.690 0.000 0.000 srgb} bind def /col20 {0.820 0.000 0.000 srgb} bind def /col21 {0.560 0.000 0.560 srgb} bind def /col22 {0.690 0.000 0.690 srgb} bind def /col23 {0.820 0.000 0.820 srgb} bind def /col24 {0.500 0.190 0.000 srgb} bind def /col25 {0.630 0.250 0.000 srgb} bind def /col26 {0.750 0.380 0.000 srgb} bind def /col27 {1.000 0.500 0.500 srgb} bind def /col28 {1.000 0.630 0.630 srgb} bind def /col29 {1.000 0.750 0.750 srgb} bind def /col30 {1.000 0.880 0.880 srgb} bind def /col31 {1.000 0.840 0.000 srgb} bind def end save newpath 0 254 moveto 0 0 lineto 556 0 lineto 556 254 lineto closepath cli= p newpath -35.0 253.0 translate 1 -1 scale /cp {closepath} bind def /ef {eofill} bind def /gr {grestore} bind def /gs {gsave} bind def /sa {save} bind def /rs {restore} bind def /l {lineto} bind def /m {moveto} bind def /rm {rmoveto} bind def /n {newpath} bind def /s {stroke} bind def /sh {show} bind def /slc {setlinecap} bind def /slj {setlinejoin} bind def /slw {setlinewidth} bind def /srgb {setrgbcolor} bind def /rot {rotate} bind def /sc {scale} bind def /sd {setdash} bind def /ff {findfont} bind def /sf {setfont} bind def /scf {scalefont} bind def /sw {stringwidth} bind def /tr {translate} bind def /tnt {dup dup currentrgbcolor 4 -2 roll dup 1 exch sub 3 -1 roll mul add 4 -2 roll dup 1 exch sub 3 -1 roll mul add 4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb} bind def /shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul 4 -2 roll mul srgb} bind def /DrawEllipse { /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y tr xrad yrad sc 0 0 1 startangle endangle arc closepath savematrix setmatrix } def /$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def /$F2psEnd {$F2psEnteredState restore end} def $F2psBegin %%Page: 1 1 10 setmiterlimit 0.06000 0.06000 sc % % Fig objects follow % /Courier ff 270.00 scf sf 9375 2115 m gs 1 -1 sc (5) col0 sh gr /Courier ff 270.00 scf sf 1725 2115 m gs 1 -1 sc (1) col0 sh gr /Courier ff 360.00 scf sf 3075 3375 m gs 1 -1 sc (r) col0 sh gr /Courier ff 270.00 scf sf 3300 3465 m gs 1 -1 sc (1) col0 sh gr 30.000 slw % Ellipse n 3300 1950 404 404 0 360 DrawEllipse gs col0 s gr % Ellipse n 4800 1950 404 404 0 360 DrawEllipse gs col0 s gr % Ellipse n 6300 1950 404 404 0 360 DrawEllipse gs col0 s gr % Ellipse n 7800 1950 404 404 0 360 DrawEllipse gs col0 s gr % Polyline n 1937 2318 m 2149 1936 l 1924 1561 l 1487 1568 l 1275 1950 l 1500 2325 l= cp gs col0 s gr = % Polyline 0.000 slw n 600 0 m 8100 0 l 8100 4200 l 600 4200 l cp = % Polyline 15.000 slw n 2175 1950 m 2925 1950 l gs col0 s gr = % Polyline n 3750 1950 m 4425 1950 l gs col0 s gr = % Polyline n 5250 1950 m 5850 1950 l gs col0 s gr = % Polyline n 6750 1950 m 7425 1950 l gs col0 s gr = % Polyline n 8250 1950 m 8925 1950 l gs col0 s gr = % Polyline 30.000 slw n 3525 3675 m 3737 3293 l 3512 2918 l 3075 2925 l 2863 3307 l 3088 3682 l= cp gs col0 s gr = % Polyline n 5025 3675 m 5237 3293 l 5012 2918 l 4575 2925 l 4363 3307 l 4588 3682 l= cp gs col0 s gr = % Polyline n 6525 3675 m 6737 3293 l 6512 2918 l 6075 2925 l 5863 3307 l 6088 3682 l= cp gs col0 s gr = % Polyline n 8025 3675 m 8237 3293 l 8012 2918 l 7575 2925 l 7363 3307 l 7588 3682 l= cp gs col0 s gr = % Polyline n 9600 2325 m 9812 1943 l 9587 1568 l 9150 1575 l 8938 1957 l 9163 2332 l= cp gs col0 s gr = % Polyline 15.000 slw n 3300 2400 m 3300 2925 l gs col0 s gr = % Polyline n 4800 2400 m 4800 2925 l gs col0 s gr = % Polyline n 6300 2400 m 6300 2925 l gs col0 s gr = % Polyline n 7800 2400 m 7800 2925 l gs col0 s gr = /Courier ff 360.00 scf sf 2325 1725 m gs 1 -1 sc (5%) col0 sh gr /Courier ff 360.00 scf sf 3825 1800 m gs 1 -1 sc (4%) col0 sh gr /Courier ff 360.00 scf sf 5400 1800 m gs 1 -1 sc (3%) col0 sh gr /Courier ff 360.00 scf sf 6900 1800 m gs 1 -1 sc (2%) col0 sh gr /Courier ff 360.00 scf sf 8400 1800 m gs 1 -1 sc (1%) col0 sh gr /Courier ff 360.00 scf sf 4575 3375 m gs 1 -1 sc (r) col0 sh gr /Courier ff 270.00 scf sf 4800 3465 m gs 1 -1 sc (2) col0 sh gr /Courier ff 360.00 scf sf 6075 3375 m gs 1 -1 sc (r) col0 sh gr /Courier ff 270.00 scf sf 6300 3465 m gs 1 -1 sc (3) col0 sh gr /Courier ff 360.00 scf sf 7575 3375 m gs 1 -1 sc (r) col0 sh gr /Courier ff 270.00 scf sf 7800 3465 m gs 1 -1 sc (4) col0 sh gr /Courier ff 360.00 scf sf 9150 2025 m gs 1 -1 sc (r) col0 sh gr /Courier ff 360.00 scf sf 1500 2025 m gs 1 -1 sc (s) col0 sh gr $F2psEnd rs %%EndDocument @endspecial 1397 1749 a Fh(Figure)24 b(4:)29 b Fk(cascade)20 b(of)g(bottlenecks)p 0 1862 3900 5 v 585 4785 a @beginspecial 0 @llx 0 @lly 479 @urx 429 @ury 3276 @rwi @setspecial %%BeginDocument: topo5.eps %!PS-Adobe-2.0 EPSF-2.0 %%Title: topo4.eps %%Creator: fig2dev Version 3.2 Patchlevel 3c %%CreationDate: Wed Jun 13 13:49:56 2001 %%For: lorenzo@adsl-64-169-54-2.dsl.snfc21.pacbell.net (Lorenzo Vicisano)= %%BoundingBox: 0 0 479 429 %%Magnification: 1.0000 %%EndComments /$F2psDict 200 dict def $F2psDict begin $F2psDict /mtrx matrix put /col-1 {0 setgray} bind def /col0 {0.000 0.000 0.000 srgb} bind def /col1 {0.000 0.000 1.000 srgb} bind def /col2 {0.000 1.000 0.000 srgb} bind def /col3 {0.000 1.000 1.000 srgb} bind def /col4 {1.000 0.000 0.000 srgb} bind def /col5 {1.000 0.000 1.000 srgb} bind def /col6 {1.000 1.000 0.000 srgb} bind def /col7 {1.000 1.000 1.000 srgb} bind def /col8 {0.000 0.000 0.560 srgb} bind def /col9 {0.000 0.000 0.690 srgb} bind def /col10 {0.000 0.000 0.820 srgb} bind def /col11 {0.530 0.810 1.000 srgb} bind def /col12 {0.000 0.560 0.000 srgb} bind def /col13 {0.000 0.690 0.000 srgb} bind def /col14 {0.000 0.820 0.000 srgb} bind def /col15 {0.000 0.560 0.560 srgb} bind def /col16 {0.000 0.690 0.690 srgb} bind def /col17 {0.000 0.820 0.820 srgb} bind def /col18 {0.560 0.000 0.000 srgb} bind def /col19 {0.690 0.000 0.000 srgb} bind def /col20 {0.820 0.000 0.000 srgb} bind def /col21 {0.560 0.000 0.560 srgb} bind def /col22 {0.690 0.000 0.690 srgb} bind def /col23 {0.820 0.000 0.820 srgb} bind def /col24 {0.500 0.190 0.000 srgb} bind def /col25 {0.630 0.250 0.000 srgb} bind def /col26 {0.750 0.380 0.000 srgb} bind def /col27 {1.000 0.500 0.500 srgb} bind def /col28 {1.000 0.630 0.630 srgb} bind def /col29 {1.000 0.750 0.750 srgb} bind def /col30 {1.000 0.880 0.880 srgb} bind def /col31 {1.000 0.840 0.000 srgb} bind def end save newpath 0 429 moveto 0 0 lineto 479 0 lineto 479 429 lineto closepath cli= p newpath -80.0 484.0 translate 1 -1 scale /cp {closepath} bind def /ef {eofill} bind def /gr {grestore} bind def /gs {gsave} bind def /sa {save} bind def /rs {restore} bind def /l {lineto} bind def /m {moveto} bind def /rm {rmoveto} bind def /n {newpath} bind def /s {stroke} bind def /sh {show} bind def /slc {setlinecap} bind def /slj {setlinejoin} bind def /slw {setlinewidth} bind def /srgb {setrgbcolor} bind def /rot {rotate} bind def /sc {scale} bind def /sd {setdash} bind def /ff {findfont} bind def /sf {setfont} bind def /scf {scalefont} bind def /sw {stringwidth} bind def /tr {translate} bind def /tnt {dup dup currentrgbcolor 4 -2 roll dup 1 exch sub 3 -1 roll mul add 4 -2 roll dup 1 exch sub 3 -1 roll mul add 4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb} bind def /shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul 4 -2 roll mul srgb} bind def /DrawEllipse { /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y tr xrad yrad sc 0 0 1 startangle endangle arc closepath savematrix setmatrix } def /$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def /$F2psEnd {$F2psEnteredState restore end} def $F2psBegin %%Page: 1 1 10 setmiterlimit 0.06000 0.06000 sc % % Fig objects follow % /Courier ff 270.00 scf sf 8850 7815 m gs 1 -1 sc (8) col0 sh gr /Courier ff 270.00 scf sf 2100 4665 m gs 1 -1 sc (1) col0 sh gr % Polyline 30.000 slw n 2312 4868 m 2524 4486 l 2299 4111 l 1862 4118 l 1650 4500 l 1875 4875 l= cp gs col0 s gr = % Ellipse n 5721 6304 404 404 0 360 DrawEllipse gs col0 s gr % Ellipse n 7221 7204 404 404 0 360 DrawEllipse gs col0 s gr % Ellipse n 7221 5404 404 404 0 360 DrawEllipse gs col0 s gr % Ellipse n 7221 3604 404 404 0 360 DrawEllipse gs col0 s gr % Ellipse n 7221 1804 404 404 0 360 DrawEllipse gs col0 s gr % Ellipse n 3846 4504 404 404 0 360 DrawEllipse gs col0 s gr % Ellipse n 5721 2779 404 404 0 360 DrawEllipse gs col0 s gr % Polyline 15.000 slw n 8400 1350 m 7575 1575 l gs col0 s gr = % Polyline n 7575 2025 m 8400 2250 l gs col0 s gr = % Polyline n 7575 3375 m 8400 3150 l gs col0 s gr = % Polyline n 7575 3825 m 8400 4050 l gs col0 s gr = % Polyline n 7575 5175 m 8400 4950 l gs col0 s gr = % Polyline n 7575 5625 m 8400 5850 l gs col0 s gr = % Polyline n 7575 6975 m 8400 6750 l gs col0 s gr = % Polyline n 7575 7425 m 8400 7650 l gs col0 s gr = % Polyline n 4125 4200 m 5400 3000 l gs col0 s gr = % Polyline n 4125 4800 m 5400 6000 l gs col0 s gr = % Polyline n 6000 2475 m 6825 1950 l gs col0 s gr = % Polyline n 6000 3075 m 6825 3450 l gs col0 s gr = % Polyline n 6075 6075 m 6825 5625 l gs col0 s gr = % Polyline n 6000 6600 m 6900 7050 l gs col0 s gr = % Polyline n 2550 4500 m 3450 4500 l gs col0 s gr = % Polyline 30.000 slw n 9062 1718 m 9274 1336 l 9049 961 l 8612 968 l 8400 1350 l 8625 1725 l cp gs col0 s gr = % Polyline n 9062 2618 m 9274 2236 l 9049 1861 l 8612 1868 l 8400 2250 l 8625 2625 l= cp gs col0 s gr = % Polyline n 9062 3518 m 9274 3136 l 9049 2761 l 8612 2768 l 8400 3150 l 8625 3525 l= cp gs col0 s gr = % Polyline n 9062 4418 m 9274 4036 l 9049 3661 l 8612 3668 l 8400 4050 l 8625 4425 l= cp gs col0 s gr = % Polyline n 9062 5318 m 9274 4936 l 9049 4561 l 8612 4568 l 8400 4950 l 8625 5325 l= cp gs col0 s gr = % Polyline n 9062 6218 m 9274 5836 l 9049 5461 l 8612 5468 l 8400 5850 l 8625 6225 l= cp gs col0 s gr = % Polyline n 9062 7118 m 9274 6736 l 9049 6361 l 8612 6368 l 8400 6750 l 8625 7125 l= cp gs col0 s gr = % Polyline n 9062 8018 m 9274 7636 l 9049 7261 l 8612 7268 l 8400 7650 l 8625 8025 l= cp gs col0 s gr = % Polyline 0.000 slw n 1350 1725 m 8850 1725 l 8850 5925 l 1350 5925 l cp = /Courier ff 360.00 scf sf 4800 5250 m gs 1 -1 sc (1%) col0 sh gr /Courier ff 360.00 scf sf 4800 3975 m gs 1 -1 sc (4%) col0 sh gr /Courier ff 360.00 scf sf 6375 2625 m gs 1 -1 sc (2%) col0 sh gr /Courier ff 360.00 scf sf 7725 4875 m gs 1 -1 sc (9%) col0 sh gr /Courier ff 360.00 scf sf 8625 1425 m gs 1 -1 sc (r) col0 sh gr /Courier ff 270.00 scf sf 8850 1515 m gs 1 -1 sc (1) col0 sh gr /Courier ff 360.00 scf sf 8625 2325 m gs 1 -1 sc (r) col0 sh gr /Courier ff 270.00 scf sf 8850 2415 m gs 1 -1 sc (2) col0 sh gr /Courier ff 360.00 scf sf 8625 3225 m gs 1 -1 sc (r) col0 sh gr /Courier ff 270.00 scf sf 8850 3315 m gs 1 -1 sc (3) col0 sh gr /Courier ff 360.00 scf sf 8625 4125 m gs 1 -1 sc (r) col0 sh gr /Courier ff 270.00 scf sf 8850 4215 m gs 1 -1 sc (4) col0 sh gr /Courier ff 360.00 scf sf 8625 5025 m gs 1 -1 sc (r) col0 sh gr /Courier ff 270.00 scf sf 8850 5115 m gs 1 -1 sc (5) col0 sh gr /Courier ff 360.00 scf sf 8625 5925 m gs 1 -1 sc (r) col0 sh gr /Courier ff 270.00 scf sf 8850 6015 m gs 1 -1 sc (6) col0 sh gr /Courier ff 360.00 scf sf 8625 6825 m gs 1 -1 sc (r) col0 sh gr /Courier ff 270.00 scf sf 8850 6915 m gs 1 -1 sc (7) col0 sh gr /Courier ff 360.00 scf sf 8625 7725 m gs 1 -1 sc (r) col0 sh gr /Courier ff 360.00 scf sf 1875 4575 m gs 1 -1 sc (s) col0 sh gr $F2psEnd rs %%EndDocument @endspecial 1530 5081 a Fh(Figure)k(5:)29 b Fk(tree)20 b(of)g(depth)f(4)p 0 5194 V 1927 5649 a Fh(7)p eop %%Trailer end userdict /end-hook known{end-hook}if %%EOF --==_Exmh_14195296130-- >From owner-rmt@listserv.lbl.gov Wed Jun 13 18:30:56 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f5E1UPH24723; Wed, 13 Jun 2001 18:30: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.11.2/8.11.2) with ESMTP id f5E1UN124719 for ; Wed, 13 Jun 2001 18:30:24 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E1UN707859 for ; Wed, 13 Jun 2001 18:30:23 -0700 (PDT) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E1UM607856 for ; Wed, 13 Jun 2001 18:30:23 -0700 (PDT) Received: from localhost (speakman@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id SAA03290; Wed, 13 Jun 2001 18:30:11 -0700 (PDT) Message-Id: <200106140130.SAA03290@cisco.com> To: Jaiwant Mulik cc: RMT Mailing List Subject: Re: Status of the GRA draft. Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Date: Wed, 13 Jun 2001 18:30:11 -0700 From: Tony Speakman Sender: owner-rmt@lbl.gov Precedence: bulk > Has anyone head about any latest developments on the GRA draft ? The > lastest draft has expired and I have hear it mentioned on the list that > Tony Speakman wanted to revist it with new author(s). Yep, we'll re-submit a revision by the London IETF deadline at the latest, and if it's reviewable any earlier, I'll let you know. Tony S > > I am doing some research related to GRA, and would like to cite a > reference. > > Any update on the status of the draft or reference to publication based on > that draft would be highly welcome. > > bye, > > Jaiwant Mulik > ----------------------------------------------------------------------- > Email : jmulik@temple.edu (preferred), jmulik@acm.org > Home page : http://unix.temple.edu/~jmulik > Office hours : Wednesday, 1:30pm to 3:30pm > Location : Room 1043/1044, Wachman Hall. > Phones : (215) 204-3197 (o), (215) 777-4828 (r) > ----------------------------------------------------------------------- > Lekin woh zindagi he kya, jisme koi namumkin sapna na ho ? > > I have not failed. I've just found 10,000 ways that won't work. > - Thomas Alva Edison >From owner-rmt@listserv.lbl.gov Wed Jun 13 23:18:40 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f5E6IFS25010; Wed, 13 Jun 2001 23:18:15 -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.11.2/8.11.2) with ESMTP id f5E6ID125006 for ; Wed, 13 Jun 2001 23:18:13 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E6IDa04713 for ; Wed, 13 Jun 2001 23:18:13 -0700 (PDT) Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.2.33]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f5E6IC604710 for ; Wed, 13 Jun 2001 23:18:12 -0700 (PDT) Received: from ren.eecis.udel.edu by mail.eecis.udel.edu id aa02889; 14 Jun 2001 02:17 EDT Date: Thu, 14 Jun 2001 02:17:56 -0400 (EDT) From: Xinming He To: rmt@lbl.gov MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Subject: a question about NCF in PGM Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rmt@lbl.gov Precedence: bulk When a network element receives a NAK on the same interface on which it has previously received a NAK for the same packet, what should it do? Should it ignore this NAK and not multicast a NCF out (as it has already sent out a NCF before as a result of the previous NAK) for optimization, at least for a certain time period? Thanks. >From owner-rmt@listserv.lbl.gov Thu Jun 14 01:33:50 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f5E8VmI25074; Thu, 14 Jun 2001 01:31: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.11.2/8.11.2) with ESMTP id f5E8Vk125070 for ; Thu, 14 Jun 2001 01:31:47 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E8Vkr14919 for ; Thu, 14 Jun 2001 01:31:46 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f5E8Vj614913 for ; Thu, 14 Jun 2001 01:31:45 -0700 (PDT) Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 14 Jun 2001 09:31:39 +0100 To: Lorenzo Vicisano cc: rmt@lbl.gov Subject: Re: Congestion Control BBs In-reply-to: Your message of "Wed, 13 Jun 2001 16:46:26 PDT." <200106132346.QAA09885@lorenzo-u10.cisco.com> Date: Thu, 14 Jun 2001 09:31:38 +0100 Message-ID: <11019.992507498@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk a LOT of problems exist in the inter-domain groups i think we should also specifiy what an CC BB does in the case of receivers in other domains and broken or poorly behaving inter-domain multicast (because it is actually an unfortuantell common case. In message <200106132346.QAA09885@lorenzo-u10.cisco.com>, Lorenzo Vicisano type d: >>given the progress made on the CC BBs and the need to >>move forward with them, I'd like to reopen the discussion >>on the process to do this. >> >>At the last IETF I proposed to try and reach consensus on a >>"reference simulations" document to be used as a base for >>discussion in the evaluation of CC algorithms. I also proposed >>to submit CC BBs as Experimental RFC *first* and move them to >>standard track only after we have acquired some deployment >>experience in the network. >> >>Anyone has any opinion about this? >> >>As for the "reference simulations" document, we could >>use the attached document as a starting point. It comes >>from the notes of a meeting attended by some of us and its based on >>Mark's original notes. The document was edited by John Byers. >> >> thanks, >> Lorenzo >> cheers jon >From owner-rmt@listserv.lbl.gov Thu Jun 14 02:14:54 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f5E9DRF25203; Thu, 14 Jun 2001 02:13:27 -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.11.2/8.11.2) with ESMTP id f5E9DP125199 for ; Thu, 14 Jun 2001 02:13:25 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E9DPc18686 for ; Thu, 14 Jun 2001 02:13:25 -0700 (PDT) Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E9DN618683 for ; Thu, 14 Jun 2001 02:13:24 -0700 (PDT) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id LAA00663; Thu, 14 Jun 2001 11:08:57 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200106140908.LAA00663@info.iet.unipi.it> Subject: Re: Congestion Control BBs In-Reply-To: <11019.992507498@cs.ucl.ac.uk> from Jon Crowcroft at "Jun 14, 2001 09:31:38 am" To: Jon Crowcroft Date: Thu, 14 Jun 2001 11:08:57 +0200 (CEST) CC: Lorenzo Vicisano , rmt@lbl.gov 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 > > a LOT of problems exist in the inter-domain groups > > i think we should also specifiy what an CC BB does in the case of > receivers in other domains and broken or poorly behaving inter-domain > multicast (because it is actually an unfortuantell common case. but... isn't this the wrong layer to approach the problem ? broken interdomain routing requiring patches in the transport protocol ? [that reminds me... in the PicoBSD floppy image for pgmcc, i rate-limited the sender to avoid ethernet capture effect that you could see on some hardware...] cheers luigi > In message <200106132346.QAA09885@lorenzo-u10.cisco.com>, Lorenzo Vicisano type > d: > > >>given the progress made on the CC BBs and the need to > >>move forward with them, I'd like to reopen the discussion > >>on the process to do this. > >> > >>At the last IETF I proposed to try and reach consensus on a > >>"reference simulations" document to be used as a base for > >>discussion in the evaluation of CC algorithms. I also proposed > >>to submit CC BBs as Experimental RFC *first* and move them to > >>standard track only after we have acquired some deployment > >>experience in the network. > >> > >>Anyone has any opinion about this? > >> > >>As for the "reference simulations" document, we could > >>use the attached document as a starting point. It comes > >>from the notes of a meeting attended by some of us and its based on > >>Mark's original notes. The document was edited by John Byers. > >> > >> thanks, > >> Lorenzo > >> > > cheers > > jon > > >From owner-rmt@listserv.lbl.gov Thu Jun 14 02:16:58 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f5E9FLg25215; Thu, 14 Jun 2001 02:15:21 -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.11.2/8.11.2) with ESMTP id f5E9FJ125211 for ; Thu, 14 Jun 2001 02:15:19 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E9FJL18752 for ; Thu, 14 Jun 2001 02:15:19 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f5E9FI618749 for ; Thu, 14 Jun 2001 02:15:18 -0700 (PDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 14 Jun 2001 10:14:56 +0100 To: Luigi Rizzo cc: rmt@lbl.gov Subject: Re: Congestion Control BBs In-reply-to: Your message of "Thu, 14 Jun 2001 11:08:57 +0200." <200106140908.LAA00663@info.iet.unipi.it> Date: Thu, 14 Jun 2001 10:14:57 +0100 Message-ID: <9607.992510097@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk In message <200106140908.LAA00663@info.iet.unipi.it>, Luigi Rizzo typed: >>> a LOT of problems exist in the inter-domain groups >>> i think we should also specifiy what an CC BB does in the case of >>> receivers in other domains and broken or poorly behaving inter-domain >>> multicast (because it is actually an unfortuantell common case. >>but... isn't this the wrong layer to approach the problem ? >>broken interdomain routing requiring patches in the transport >>protocol ? well, TCP works in the presence of BGP poor convergence, so.... >>[that reminds me... in the PicoBSD floppy image for >>pgmcc, i rate-limited the sender to avoid ethernet capture >>effect that you could see on some hardware...] cool >> >>> In message <200106132346.QAA09885@lorenzo-u10.cisco.com>, Lorenzo Vicisano type >>> d: >>> >>> >>given the progress made on the CC BBs and the need to >>> >>move forward with them, I'd like to reopen the discussion >>> >>on the process to do this. >>> >> >>> >>At the last IETF I proposed to try and reach consensus on a >>> >>"reference simulations" document to be used as a base for >>> >>discussion in the evaluation of CC algorithms. I also proposed >>> >>to submit CC BBs as Experimental RFC *first* and move them to >>> >>standard track only after we have acquired some deployment >>> >>experience in the network. >>> >> >>> >>Anyone has any opinion about this? >>> >> >>> >>As for the "reference simulations" document, we could >>> >>use the attached document as a starting point. It comes >>> >>from the notes of a meeting attended by some of us and its based on >>> >>Mark's original notes. The document was edited by John Byers. >>> >> >>> >> thanks, >>> >> Lorenzo >>> >> >>> >>> cheers >>> >>> jon >>> >>> >> cheers jon >From owner-rmt@listserv.lbl.gov Thu Jun 14 02:42:27 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f5E9ekw25298; Thu, 14 Jun 2001 02:40: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 (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E9ej125294 for ; Thu, 14 Jun 2001 02:40:45 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E9eiM21461 for ; Thu, 14 Jun 2001 02:40:44 -0700 (PDT) Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E9eh621458 for ; Thu, 14 Jun 2001 02:40:43 -0700 (PDT) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id LAA00749; Thu, 14 Jun 2001 11:36:23 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200106140936.LAA00749@info.iet.unipi.it> Subject: Re: Congestion Control BBs In-Reply-To: <9607.992510097@cs.ucl.ac.uk> from Jon Crowcroft at "Jun 14, 2001 10:14:57 am" To: Jon Crowcroft Date: Thu, 14 Jun 2001 11:36:23 +0200 (CEST) CC: rmt@lbl.gov 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 > >>but... isn't this the wrong layer to approach the problem ? > >>broken interdomain routing requiring patches in the transport > >>protocol ? > > well, TCP works in the presence of BGP poor convergence, so.... i would say "happens to work", not because of specific countermeasures, but because with only one receiver, any breakage is going to hit in the right place. But in absence of group membership info, you cannot do much anywyas. 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 Jun 14 03:11:51 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f5EAANH25353; Thu, 14 Jun 2001 03:10:23 -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.11.2/8.11.2) with ESMTP id f5EAAM125349 for ; Thu, 14 Jun 2001 03:10:22 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5EAAMC22868 for ; Thu, 14 Jun 2001 03:10:22 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f5EAAL622865 for ; Thu, 14 Jun 2001 03:10:21 -0700 (PDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 14 Jun 2001 11:10:14 +0100 To: Luigi Rizzo cc: rmt@lbl.gov Subject: Re: Congestion Control BBs In-reply-to: Your message of "Thu, 14 Jun 2001 11:36:23 +0200." <200106140936.LAA00749@info.iet.unipi.it> Date: Thu, 14 Jun 2001 11:10:15 +0100 Message-ID: <12873.992513415@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-rmt@lbl.gov Precedence: bulk In message <200106140936.LAA00749@info.iet.unipi.it>, Luigi Rizzo typed: >>> >>but... isn't this the wrong layer to approach the problem ? >>> >>broken interdomain routing requiring patches in the transport >>> >>protocol ? >>> well, TCP works in the presence of BGP poor convergence, so.... >>i would say "happens to work", not because of specific countermeasures, >>but because with only one receiver, any breakage is going to hit in >>the right place. >>But in absence of group membership info, you cannot do much anywyas. i guess what i am after is the fact that some of the itner-domain routes lead to big steps in delays for some receivers and possibly big steps in reported loss every now and then - we may wany yo specify smart filters at single rate based senders, or in layer joins in receivers, in the same way that TCP has all the dupack threshold type mechanisms... cheers jon >From owner-rmt@listserv.lbl.gov Thu Jun 14 10:58:56 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f5EHvxh26973; Thu, 14 Jun 2001 10:57:59 -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.11.2/8.11.2) with ESMTP id f5EHvv126969 for ; Thu, 14 Jun 2001 10:57:58 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5EHvv700765 for ; Thu, 14 Jun 2001 10:57:57 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5EHrG628770 for ; Thu, 14 Jun 2001 10:53:17 -0700 (PDT) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5EHr9922525; Thu, 14 Jun 2001 10:53:09 -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 KAA12708; Thu, 14 Jun 2001 10:53:09 -0700 (PDT) Message-Id: <200106141753.KAA12708@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI] To: Jon Crowcroft cc: Luigi Rizzo , rmt@lbl.gov Subject: Re: Congestion Control BBs In-Reply-To: Your message of "Thu, 14 Jun 2001 11:10:15 BST." <12873.992513415@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Jun 2001 10:53:09 -0700 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk An important point seemed to have emerged from this thread (and from some private emails): simulations will not be able to test many issues present in real-networks. My suggestion of proceeding by steps (first experimental and then standard track) addresses this somewhat.. however it does not seem sufficient. Other possible actions are: a) add a disclaimer in the simulation document b) add recommendations for designers, to cope with known real-network issues (we could start making a list by putting together our experiences) c) encourage real-network tests.. (large scale test are always hard to setup, 'though). My opinion about the specific inter-domain issue, is that it would probably be very hard to design for some current inter-domain pathologies (e.g. those caused by msdp). I'm not sure if we should ignore the problem --and hope they will disappear when RMT protocols start being deployed inter-domain (SSM should help)-- or spend a lot of efforts in trying to cope with this. For sure I would *not mandate* that CC algorithms work in the presence of these inter-domain anomalies. Lorenzo In message <12873.992513415@cs.ucl.ac.uk>, Jon Crowcroft writes: > > In message <200106140936.LAA00749@info.iet.unipi.it>, Luigi Rizzo typed: > > >>> >>but... isn't this the wrong layer to approach the problem ? > >>> >>broken interdomain routing requiring patches in the transport > >>> >>protocol ? > > >>> well, TCP works in the presence of BGP poor convergence, so.... > > >>i would say "happens to work", not because of specific countermeasures, > >>but because with only one receiver, any breakage is going to hit in > >>the right place. > > >>But in absence of group membership info, you cannot do much anywyas. > > i guess what i am after is the fact that some of the itner-domain > routes lead to big steps in delays for some receivers and possibly big > steps in reported loss every now and then - we may wany yo specify > smart filters at single rate based senders, or in layer joins in > receivers, in the same way that TCP has all the dupack threshold type > mechanisms... > > cheers > > jon >From owner-rmt@listserv.lbl.gov Thu Jun 14 11:43:41 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f5EIhTq27200; Thu, 14 Jun 2001 11:43:29 -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.11.2/8.11.2) with ESMTP id f5EIhS127196 for ; Thu, 14 Jun 2001 11:43:28 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5EIhRX19397 for ; Thu, 14 Jun 2001 11:43:27 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5EIhQ619386 for ; Thu, 14 Jun 2001 11:43:26 -0700 (PDT) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5EIhK904693; Thu, 14 Jun 2001 11:43:20 -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 LAA12830; Thu, 14 Jun 2001 11:43:20 -0700 (PDT) Message-Id: <200106141843.LAA12830@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI] To: "terry martin" cc: rmt@lbl.gov Subject: Re: Congestion Control BBs In-Reply-To: Your message of "Thu, 14 Jun 2001 09:00:38 PDT." <001501c0f4eb$29827000$8f3918ac@talent> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Jun 2001 11:43:20 -0700 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk In message <001501c0f4eb$29827000$8f3918ac@talent>, "terry martin" writes: > Can you convert to HTTP? http://www.employees.org/~lorenzo/mcc/ Lorenzo > > Terry Martin > > ----- Original Message ----- > From: "Lorenzo Vicisano" > To: > Sent: Wednesday, June 13, 2001 4:46 PM > Subject: Congestion Control BBs > > > > Hi, > > > > given the progress made on the CC BBs and the need to > > move forward with them, I'd like to reopen the discussion > > on the process to do this. > > > > At the last IETF I proposed to try and reach consensus on a > > "reference simulations" document to be used as a base for > > discussion in the evaluation of CC algorithms. I also proposed > > to submit CC BBs as Experimental RFC *first* and move them to > > standard track only after we have acquired some deployment > > experience in the network. > > > > Anyone has any opinion about this? > > > > As for the "reference simulations" document, we could > > use the attached document as a starting point. It comes > > from the notes of a meeting attended by some of us and its based on > > Mark's original notes. The document was edited by John Byers. > > > > thanks, > > Lorenzo > > > > >From owner-rmt@listserv.lbl.gov Fri Jul 6 04:54:42 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f66BqqJ05110; Fri, 6 Jul 2001 04:52: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.11.2/8.11.2) with ESMTP id f66BqoT05106 for ; Fri, 6 Jul 2001 04:52:50 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f66BqoU19170 for ; Fri, 6 Jul 2001 04:52:50 -0700 (PDT) Received: from smtp-hub.mrf.mail.rcn.net (smtp-hub.mrf.mail.rcn.net [207.172.4.107]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f66Bqn919165 for ; Fri, 6 Jul 2001 04:52:49 -0700 (PDT) Received: from smtp01.mrf.mail.rcn.net ([207.172.4.60]) by smtp-hub.mrf.mail.rcn.net with esmtp (Exim 3.30 #2) id 15IUAC-00046e-00 for RMT@lbl.gov; Fri, 06 Jul 2001 07:52:48 -0400 Received: from 66-44-60-143.s143.tnt4.lnhva.md.dialup.rcn.com ([66.44.60.143] helo=eagle) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.30 #2) id 15IUAA-00047S-00 for RMT@LBL.GOV; Fri, 06 Jul 2001 07:52:47 -0400 Message-ID: <261122001756114422270@eagle> X-EM-Version: 5, 0, 0, 19 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 Reply-To: res02mg1@gte.net X-MSMail-Priority: Normal From: "David C. Dickson" To: RMT@lbl.gov Subject: NETWORK AND INFO SYSTEMS SECURITY TRAINING CONFERENCE - WASH DC, 16 JULY 2001 Date: Fri, 6 Jul 2001 07:44:22 -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 SpamWall.lbl.gov id f66BqpT05107 Sender: owner-rmt@lbl.gov Precedence: bulk To: RMT@LBL.GOV NEW SPEAKERS ADDED PLEASE FORWARD THIS TO YOUR MANAGER OF SYSTEMS SECURITY AND SECURITY TECHNOLOGIES GROUP. Market*Access International is proud to present .... NETWORK AND INFORMATION SYSTEMS SECURITY - TRAINING CONFERENCE AGENCY INTRUSION DETECTION REQUIREMENTS and TECHNOLOGY SOLUTIONS Date: July 16, 2001 Ronald Reagan Building and International Trade Center 1300 Pennsylvania Avenue Washington D.C. Atrium Ballroom Time: 7:30 AM Registration and Continental Breakfast Program Starts: 8:30 AM Wrap-up: 4:15 PM About this Conference: As government becomes more dependent on e-business, databases, information storehouses, mission critical information storage and information sharing, new risks are posed. These risks may come from student hackers, foreign governments or foreign military, terrorist organizations or even internal users. With the new e-Government applications and communications, computer security has emerged as a top issue and challenge. This conference will highlight the risks, opportunities and innovative management and technical approaches to the detection and response to unauthorized intrusions into agency data. The conference will focus on business and military applications and agency plans and programs for securing these applications. A highlight of this conference will be a section on AGENCY REQUIREMENTS AND NEW TECHNOLOGIES and strategies of coping with unauthorized attempts to compromise agency and DoD systems and data. SPEAKERS WILL REPRESENT THE FOLLOWING AGENCIES/COMPANIES: Navy NMCI ^Ö Mark Lavoie ^Ö Communications Officer, CDR, USNR PEO IT (Program Executive Office of Information Technology). Department of Transportation - Bonnie Fisher ^Ö Director, TASC Millennium Solutions Center National Science Foundation - Dara Murry ^Ö Director, ADP Security FBI - James Burrell ^Ö Acting Unit Chief, Computer Investigation Unit DARPA - Jim Webster ^Ö Manager, Information Assurance Office GSA/FedCIRC - Larry Hale ^Ö Liaison Director, Federal Computer Incident Response Center DOJ ^Ö TBD DISA ^Ö TBD Gartner ^Ö Keynote ^Ö TBD Guardant ^Ö Robert Lee ^Ö Director, Senior Principal Consultant Global Integrity - Errol Weiss, Bill Morgan Verizon, Federal Network Systems - Char Sample ^Ö Raytheon ^Ö Barton Abbott ^Ö Director, Information Assurance, Navy /USMC Intranet, Information Strike Force Symantec - TBD For more information on speakers and the conference agenda, please visit our web site at www.marketaccess.org. Who should attend: * Agency IT Executives, Managers, and Staff * Agency Security Executives, Managers and Staff * Agency information systems program managers * Agency Telecommunications Executives, Managers and Staff * Tele-work and Telecomm Directors, Managers, and Staff * Functional area managers * Systems integrators that support federal agency security requirements * Hardware and software solutions providers What you will learn: * Agency plans, programs and priorities * Successes and Lessons learned * Innovative government intrusion detection security approaches and applications * New technologies and strategies - what is on the drawing boards * How the military approaches network security and intrusion detection * Security of remote database management * How to structure intrusion detection solutions * Risks, sources of attacks... the internal risk * Commercial and government best practices Corporate Sponsors: * Symantec * Verizon * Market*Access .... others to be announced Organizational Sponsors: * Department of Transportation * INPUT Government ....other sponsors to be announced. Please register early. The conference area has limited seating available and we anticipate a sell out. Points of Contact: * For technical support with this web site, please contact Mr. Parrish Knight, 703/807-2748 * For general information about this event, please contact Ms. Kristen Brooks, 703/807-2745 * For information on sponsorship opportunities & exhibitor arrangements, please contact Ms. Cara Lombardi at 703/807-2743 The registration fee for this important training conference is: * Government Credit Card or Check in Advance: $395 * Government Training Forms/Invoice: $445 * Industry and Federal Contractors, Payment in Advance: $595 * Industry and Federal Contractors/Invoice: $645 We accept government training forms and government and commercial credit cards (VISA, MC, American Express). Options: [1] Phone: 703-807-2745 and speak with Ms. Kristen Brooks. [2] Email: kbrooks@marketaccess.org [3] Register online: Use our online booking form to register and pay by credit card electronically. To register, go to www.marketaccess.org. [4] Fax: registration form to 301-652-0914. [5] Mail: registration form to: Market*Access International, Inc. 4301 Wilson Blvd. #1003 Arlington, VA 22203 Sponsorships Available! For sponsorship information, please contact: Cara Lombardi Market*Access International 4301 Wilson Blvd. #1003 Arlington, VA 22203 Phone (703) 807-2743 Fax (703) 807-2728 clombardi@marketaccess.org If you wish to be REMOVED from this list, please REPLY and place REMOVE in the SUBJECT line. Thank you >From owner-rmt@listserv.lbl.gov Sat Jul 7 20:28:10 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f683Q1Y25503; Sat, 7 Jul 2001 20:26:01 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal2.lbl.gov (postal2.lbl.gov [131.243.248.26]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f683Q0T25499 for ; Sat, 7 Jul 2001 20:26:00 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal2.lbl.gov (8.11.2/8.11.2) with ESMTP id f683Px002962 for ; Sat, 7 Jul 2001 20:25:59 -0700 (PDT) Received: from yourwebsite.com (cd-179-62.ra30.dc.capu.net [64.50.179.62]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f683Pv602959 for ; Sat, 7 Jul 2001 20:25:58 -0700 (PDT) Message-Id: <200107080325.f683Pv602959@SpamWall.lbl.gov> Reply-To: lprice@capu.net From: lprice@capu.net To: rmt@lbl.gov Subject: Ride the Wave of Success!!/FREE MEMBERSHIP!!! Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 7 Jul 2001 23:21:46 -0400 Sender: owner-rmt@lbl.gov Precedence: bulk JOIN NOW FOR FREE!!! SERIOUS ONLINE INCOME: NO PRODUCTS TO SELL, NO MEETING TO ATTEND, NO MONTHLY QUOTAS We are a FOUR 4 YEAR OLD INTERNET BUSINESS AND GROWING VERY FAST. WE HAD OVER 60,000 VIPS SIGNUP COMPANY WIDE IN THE MONTH OF JUNE 2001. SEE WHY THOUSANDS OF PEOPLE FROM ALL OVER THE WORLD ARE JOINING US AT RECORD RATES.; THE MEMBERSHIP IS FREE at. http://onlineprofits.50megs.com. . Enter your first and last name and email address. Afterwards you will start recieving various emails about company and the business opportunity. Also, you will become a FREE MEMBER and you can START SHOPPING from at least 70 brand name online stores and BE ENTERED in our monthly $100 shopping spree!. Take your time and review our company's benefits and opportunities. . GUARANTEED minimum commission every month . you can get 200 members a month added to you downline . Free Software . and a strong team support Now remember anybody that signs up after you will be in your downline. This is very important if you want join our company and get a monthly check. Don't pass this one up. GET YOUR FREE MEMBERSHIP AT: http://onlineprofits.50megs.com --- type in your name and email address and hit the submit botton. We will talk soon, GIVIE IT A TRY, YOU HAVE NOTHING TO LOSE AND POSSIBLE A LOT TO GAIN. >From owner-rmt@listserv.lbl.gov Wed Jul 11 18:47:28 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6C1iq910783; Wed, 11 Jul 2001 18:44: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.11.2/8.11.2) with ESMTP id f6C1io410779 for ; Wed, 11 Jul 2001 18:44:50 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6C1ioU23145 for ; Wed, 11 Jul 2001 18:44:50 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6C1in923140 for ; Wed, 11 Jul 2001 18:44:49 -0700 (PDT) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6C1irj02234; Wed, 11 Jul 2001 18:44:53 -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 SAA28759; Wed, 11 Jul 2001 18:44:43 -0700 (PDT) Message-Id: <200107120144.SAA28759@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI] To: rmt@lbl.gov cc: roger.kermode@motorola.com, lorenzo@cisco.com Subject: RMT: call for agenda items Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Jul 2001 18:44:43 -0700 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk The London IETF is approaching and we have requested two RMT meeting slots. We are now accepting requests for items to be included in the agenda. Please remind the usual guidelines when planning your presentations (provide update and limit technical presentations to core points of general interest and/or controversial issues). thanks, the RMT chairs. >From owner-rmt@listserv.lbl.gov Tue Jul 17 13:52:31 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6HKl3327530; Tue, 17 Jul 2001 13:47: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.11.2/8.11.2) with ESMTP id f6HKl2R27526 for ; Tue, 17 Jul 2001 13:47:02 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6HKl1J00349 for ; Tue, 17 Jul 2001 13:47:01 -0700 (PDT) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6HKl0A00340 for ; Tue, 17 Jul 2001 13:47:00 -0700 (PDT) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.10.0/8.10.0) id f6HKl0b02414; Tue, 17 Jul 2001 13:47:00 -0700 (PDT) Message-Id: <200107172047.f6HKl0b02414@daffy.ee.lbl.gov> To: rmt@lbl.gov Subject: Fwd: Note Well Date: Tue, 17 Jul 2001 13:47:00 PDT From: Vern Paxson Sender: owner-rmt@lbl.gov Precedence: bulk [manually forwarded, since the mailbot decided to bounce it due to the huge To: field] ------- Forwarded Message >From owner-rmt Tue Jul 17 10:46:49 2001 From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Subject: Note Well Message-Id: Sender: Randy Bush Date: Tue, 17 Jul 2001 13:25:25 -0400 Greetings, This is the revised text of the NOTE WELL statement. - ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ------- End of Forwarded Message >From owner-rmt@listserv.lbl.gov Wed Jul 18 04:06:34 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6IB2sJ20388; Wed, 18 Jul 2001 04:02:54 -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.11.2/8.11.2) with ESMTP id f6IB2qR20384 for ; Wed, 18 Jul 2001 04:02:52 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6IB2on05378 for ; Wed, 18 Jul 2001 04:02:50 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6IB2nA05364 for ; Wed, 18 Jul 2001 04: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 HAA26996; Wed, 18 Jul 2001 07:01:54 -0400 (EDT) Message-Id: <200107181101.HAA26996@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-fspec-00.txt,.ps Date: Wed, 18 Jul 2001 07:01:53 -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 - Functional Specification Author(s) : K. Calvert et al. Filename : draft-ietf-rmt-gra-fspec-00.txt,.ps Pages : 15 Date : 17-Jul-01 This draft specifies the functional requirements which any implementation of GRA must meet. It broadly describes the context in which GRA operates, and it specifies the contents of GRA headers and GRA filter specifications. In the process, it specifies some principles of operation for GRA in the context of a router. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-gra-fspec-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-fspec-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-fspec-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: <20010717134012.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-gra-fspec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-gra-fspec-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717134012.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Thu Jul 19 17:10:56 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6K08Vo28840; Thu, 19 Jul 2001 17:08:31 -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.11.2/8.11.2) with ESMTP id f6K08TR28836 for ; Thu, 19 Jul 2001 17:08:29 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6K08Sw20581 for ; Thu, 19 Jul 2001 17:08:28 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6K08RA20578 for ; Thu, 19 Jul 2001 17:08:27 -0700 (PDT) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6K08DX15867; Thu, 19 Jul 2001 17:08:14 -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 RAA01799; Thu, 19 Jul 2001 17:07:44 -0700 (PDT) Message-Id: <200107200007.RAA01799@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI] To: internet-drafts@ietf.org cc: luby@digitalfountain.com, jgemmell@MICROSOFT.com, luigi@iet.unipi.it, mjh@aciri.org, J.Crowcroft@cs.ucl.ac.uk, lorenzo@cisco.com, rmt@lbl.gov Subject: draft-ietf-rmt-bb-lct-01.txt Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_5195028970" Date: Thu, 19 Jul 2001 17:07:44 -0700 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk This is a multipart MIME message. --==_Exmh_5195028970 Content-Type: text/plain; charset=us-ascii Please post this draft on the IETF Internet Drafts archive. This is an update of an existing WG draft (RMT). Thank you, Lorenzo Vicisano --==_Exmh_5195028970 Content-Type: text/plain ; name="draft-ietf-rmt-bb-lct-01.txt"; charset=us-ascii Content-Description: draft-ietf-rmt-bb-lct-01.txt Content-Disposition: attachment; filename="draft-ietf-rmt-bb-lct-01.txt" Internet Engineering Task Force RMT WG INTERNET-DRAFT M.Luby/Digital Fountain draft-ietf-rmt-bb-lct-01.txt J.Gemmell/Microsoft L.Vicisano/Cisco L.Rizzo/ACIRI and Univ. Pisa M.Handley/ACIRI J. Crowcroft/UCL 19 July 2001 Expires: January 2002 Layered Coding Transport: A massively scalable content delivery transport Status of this Document 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". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This document is a product of the IETF RMT WG. Comments should be addressed to the authors, or the WG's mailing list at rmt@lbl.gov. Abstract This document describes Layered Coding Transport, a massively scalable reliable content delivery and stream delivery Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft [Page 1] ^L INTERNET-DRAFT Expires: January 2002 July 2001 transport, hereafter referred to as LCT. LCT can be used for multi-rate delivery to large sets of receivers. In LCT, scalability and congestion control are supported through the use of layered coding techniques. Coding techniques can be combined with LCT to provide support for reliability. Congestion control is receiver driven, and is achieved by sending packets in the session to multiple ``LCT channels'', and having receivers join and leave LCT channels (thus adjusting their reception rate) in reaction to network conditions in a manner that is network friendly. Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft [Page 2] ^L INTERNET-DRAFT Expires: January 2002 July 2001 Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 1.1. Related Documents. . . . . . . . . . . . . . . . . . 6 1.2. Environmental Requirements and Considerations. . . . 6 2. General Architecture. . . . . . . . . . . . . . . . . . 8 2.1. Delivery service models. . . . . . . . . . . . . . . 10 2.2. Congestion Control . . . . . . . . . . . . . . . . . 11 3. LCT packets . . . . . . . . . . . . . . . . . . . . . . 11 3.1. LCT packet format. . . . . . . . . . . . . . . . . . 12 3.2. LCT packet header fields . . . . . . . . . . . . . . 13 3.3. Header-Extension Fields. . . . . . . . . . . . . . . 16 4. Procedures. . . . . . . . . . . . . . . . . . . . . . . 19 4.1. Sender Operation . . . . . . . . . . . . . . . . . . 19 4.2. Receiver Operation . . . . . . . . . . . . . . . . . 21 5. Security Considerations . . . . . . . . . . . . . . . . 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . 22 7. Intellectual Property Issues. . . . . . . . . . . . . . 22 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 23 9. Authors' Addresses. . . . . . . . . . . . . . . . . . . 24 10. Full Copyright Statement . . . . . . . . . . . . . . . 26 Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft [Page 3] ^L INTERNET-DRAFT Expires: January 2002 July 2001 1. Introduction This document describes a massively scalable reliable content delivery and stream delivery transport, Layered Coding Transport (LCT), for multi-rate content delivery primarily designed to be used with the IP multicast network service, but MAY also be used with other basic underlying network or transport services such as unicast UDP. LCT supports both reliable and unreliable delivery, and supports congestion control mechanisms which conform to RFC2357. LCT is a building block as defined in RFC3048. Complete protocol instantiations MAY be built by combining the LCT framework with other components. A complete protocol instantiation that uses LCT MUST include a congestion control protocol that is compatible with LCT and that conforms to RFC2357. A complete protocol instantiation that uses LCT MAY include a scalable reliability protocol that is compatible with LCT, it MAY include an session control protocol that is compatible with LCT, and it MAY include other protocols such as security protocols. LCT is presumed to be used with an underlying network or transport service that is a "best effort" service that does not guarantee packet reception, packet reception order, and which does not have any support for flow or congestion control. For example, the Any-Source Multicast (ASM) model of IP multicast as defined in RFC1112 is such a "best effort" network service. While the basic service provided by RFC1112 is largely scalable, providing congestion control or reliability should be done carefully to avoid severe scalability limitations, especially in presence of heterogeneous sets of receivers. Scalability refers to the behavior of the protocol in relation to the number of receivers and network paths, their heterogeneity, and the ability to accommodate dynamically variable sets of receivers. Scalability limitations can come from memory or processing requirements, or from the amount of packet traffic generated by the protocol. In turn, such limitations may be a consequence of the features that a complete reliable content delivery or stream delivery protocol is expected to provide. Congestion control refers to the ability of the protocol to adapt its throughput to the available bandwidth on the path to the receivers, and to share bandwidth fairly with competing flows such as TCP. It is REQUIRED that protocols implement some form of congestion control on each session so that they not compete unfairly with existing and adaptive protocols such as TCP. For multi-rate protocols, the sender typically sends packets at a constant aggregate rate to multiple channels, but individual receivers adjust which portion of these packets they attempt to receive by Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 1. [Page 4] ^L INTERNET-DRAFT Expires: January 2002 July 2001 adjusting which set of channels they are joined to at each point in time depending on the available bandwidth between the receiver and the sender, but independent of all other receivers. Thus, for multi-rate protocols, the packet reception rate of each receiver may vary dynamically according to the available bandwidth between each receiver and the sender, independent of the other receivers. For single-rate protocols, the sender typically sends packets to one channel at variable rates over time depending on feedback from receivers, and all receivers attempt to receive all packets transmitted by the sender at all points in time. Thus, for single-rate protocols, the packet reception rate of all receivers may vary dynamically over time in exactly the same way dependent on the feedback of other receivers to the sender. Generally, a multi-rate protocol is preferable to a single-rate protocol in a heterogeneous receiver environment, but only if it can be achieved without sacrificing scalability. Layered coding refers to the ability to produce a coded stream that can be split into multiple layers that can be sent to different channels. The coded stream can be generated either from a fixed piece of content, or from an ongoing data stream, and has the property that the quality experienced by a receiver (in terms of quality of playout, or overall transfer speed) is proportional to how many of the layers the receiver is joined to. LCT MAY be combined with a reliability protocol such as the general class of protocols described in [7]. LCT MUST be combined with a congestion control protocol that is compliant with RFC2357, and this MAY be either single-rate or multi-rate congestion control over the entire session. It is most compelling to use LCT in conjunction with a layered congestion control protocol such as the class of protocols described in [9], and specified in [9], which are multi-rate congestion control protocols. The concept of layered coding was first introduced with reference to audio and video streams. For example, the information associated with a TV broadcast can be partitioned into three layers, corresponding to black and white, color, and HDTV quality. Receivers can experience different quality without the need for the sender to replicate information in the different layers. The concept of layered coding can be naturally extended to reliable content delivery protocols when Forward Error Correction (FEC) techniques are used for coding the data stream [12] [10] [3] [14] [15] [1]. By using FEC, the data stream is transformed in such a way that reconstruction of a data object does not depend on the reception of specific data packets, but only on the number of different packets received. As a result, by increasing the number of layers a receiver is receiving from, the receiver can reduce the transfer time accordingly. More details on the use of FEC for reliable content delivery can be found in [6]. Reliable protocols aim at giving guarantees on the Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 1. [Page 5] ^L INTERNET-DRAFT Expires: January 2002 July 2001 reliable delivery of data from the sender to the intended recipients. Guarantees vary from simple packet data integrity to reliable delivery of a precise copy of a data object to all intended recipients. Several reliable content delivery protocols have been built on top of IP multicast, but scalability was not a design goal for many of them. In some cases, scalability is achieved by introducing changes to routers or other infrastructure (see for example [13] ), an approach which has an impact on near term deployment across the Internet. Two of the key difficulties in scaling reliable content delivery using IP multicast are dealing with the amount of data that flows from receivers back to the sender, and the associated response (generally data retransmissions) from the sender. Protocols that avoid any such feedback, and minimize the amount of retransmissions, can be massively scalable. LCT relies on the availability of FEC codes or a layered codec to achieve reliability with little or no feedback. In this document we present the architecture and abstract LCT packet structure, and illustrate its support for multi-rate layered congestion control. 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 RFC2119. 1.1. Related Documents A more in-depth description of the use of FEC in Reliable Multicast Transport (RMT) protocols is given in [6]. Some of the FEC codecs that MAY be used by LCT for reliable content delivery are specified in [7]. LCT reserves opaque header fields that can be used to transport information related to the payload encoding. Implementors of LCT MUST also implement congestion control in accordance to RFC2357, where the congestion control is over the entire session. Some possible schemes are specified in [9]. LCT reserves opaque header fields that can be used by the congestion control scheme to transport information related to congestion control. It is RECOMMENDED that LCT implementors use some authentication scheme to protect the protocol from attacks. An example of a possibly suitable scheme is described in [11]. 1.2. Environmental Requirements and Considerations LCT is intended for congestion controlled, multi-rate delivery of objects and streams (both reliable content delivery and streaming of Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 1.2. [Page 6] ^L INTERNET-DRAFT Expires: January 2002 July 2001 multimedia information). LCT is most applicable for delivery of objects or streams of substantial length, i.e., objects or streams that range in length from hundreds of kilobytes to many gigabytes, and whose transfer time is in the order of tens of seconds or more. LCT is directly applicable to all multicast enabled networks, including asymmetric networks, wireless networks, and satellite networks. Thus, the inherent raw scalability of LCT is unlimited. However, when other specific applications are built on top of LCT, then these applications by their very nature may limit scalability. For example, if an application requires receivers to retrieve 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. LCT requires that the underlying network or transport layer can deliver and demultiplex LCT packets for a given LCT session, and supply packet length information to the LCT receiver. In IP networks, this is often achieved by using UDP, or any protocol that can provide an equivalent service, as the underlying transport protocol. In this document, we refer to the original multicast service model defined in RFC1112 as Any-Source Multicast, or ASM for short. We refer to the multicast service model defined in [5] as Source-Specific Multicast, or SSM for short. LCT does not require reverse multicast connectivity, i.e. LCT receivers do not send multicast traffic. As such, LCT works with both ASM and SSM. The definition of an LCT channel used throughout this document is slightly different with ASM and with SSM. When using ASM, a sender S sends LCT packets to a multicast group G, and the LCT channel address consists of the pair (S,G), where S is the IP address of the sender and G is a multicast group address. When using SSM, a sender S sends LCT packets to an SSM channel (S,G), and the LCT channel address coincides with the SSM channel address. SSM is more attractive to deployment of LCT than ASM for several reasons. First, a sender may allocate and use several LCT channels in a session, sessions may come and go dynamically. A sender can locally allocate unique SSM channel addresses, and this makes allocation of LCT channel addresses easy with SSM. To allocate LCT channel addresses using ASM, the sender must uniquely chose the ASM multicast group address across the scope of the group, and this makes allocation of LCT channel addresses more difficult with ASM. Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 1.2. [Page 7] ^L INTERNET-DRAFT Expires: January 2002 July 2001 In general SSM performs well even in presence of very large and dynamically changing receiver sets. 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), whereas with ASM changes can be heavier weight (involving transitions from a (*,G)-tree rooted at an RP to the tree rooted at S). This efficiency is important when a congestion control protocol is used with LCT that relies upon joining and leaving channels to nimbly increase and decrease reception rate. LCT channels and SSM channels coincide, and thus the receiver will only receive packets sent to the requested LCT channel. With ASM, the receiver joins an LCT channel by joining a multicast group G, and all packets sent to G, regardless of the sender, may be received by the receiver. In either case, receivers should use mechanisms to filter out packets from unwanted sources. Thus, SSM has compelling security advantages over ASM for prevention of denial of service attacks. LCT also requires receivers to obtain Session Description Information before joining a session, as described in Section 4.1. The session description could be in a form such as SDP as defined in RFC2327, or XML metadata, or HTTP/Mime headers as defined in RFC2068, and distributed with SAP [4], using RCCP [8], HTTP, or in other ways. The particular layered encoder and congestion control protocols used with LCT have an impact on the performance and applicability of LCT. For example, some layered encoders used for video and audio streams can produce a very limited number of substreams, thus providing a very coarse control in the reception rate of packets by receivers in a session. When LCT is used for reliable data transfer, some FEC codecs 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 LCT. 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. 2. General Architecture An LCT session comprises all LCT packets sent to one or more LCT channels from a single sender, and pertaining to the transmission of one or more objects that can be of interest for the receivers. For example, an LCT session could be used to deliver a TV channel using Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 2. [Page 8] ^L INTERNET-DRAFT Expires: January 2002 July 2001 three channels. Receiving the first channel could allow black and white reception, receiving the first two channels would permit color reception, whereas receiving the set of three channels delivers HDTV quality images. Objects in this example could correspond to individual programs (movies, news, commercial) being transmitted. As another example, a reliable LCT session could be used to reliably deliver hourly-updated weather maps (objects) using ten LCT channels at different rates, using FEC coding. A receiver MAY join and concurrently receive LCT packets from subsets of these channels, until it has enough packets in total to recover the object, then leave the session (or remain there listening to control information only) until it is time to receive the next object. In this case, the quality metric is the time required to receive each object. Before joining a session, the receivers MUST obtain a session description, which MUST include the relevant session parameters needed by a receiver to participate in the session. The session description is determined and agreed upon by the senders, and typically communicated to the receivers out of band. In some cases, part of the session description MAY be included in the LCT packet. An encoder MAY be used to generate the data that is placed in the LCT packet payload in order to provide reliability. A suitable decoder is used to reproduce the original information from the payload. There MAY be a reliability packet header that follows the LCT packet header if such an encoder and decoder is used. The reliability packet header helps to describe the encoding data carried in the payload of the packet. The format of the reliability packet header depends on the coding used, and this is negotiated out-of-band. As an example, one of the FEC packet headers described in [7] could be used. For LCT, when layered congestion control is used, congestion control is achieved by sending LCT packets associated with a given session to several LCT channels. Individual receivers dynamically join one or more of these channels, according to the network congestion as seen by the receiver. LCT packet headers include an opaque field which MUST be used to convey congestion control information to the receivers. The actual congestion control scheme to use with LCT is negotiated out-of-band. Some examples of congestion control protocols that MAY be suitable for content delivery are described in [9]. Other congestion controls MAY be suitable when LCT is used for a streaming application. LCT can be used with other congestion control protocols such as the one described in [14], or router-assisted schemes where the selection of which packets to forward is performed by routers. This latter approach potentially allows for finer grain congestion control and a faster reaction to network congestion, but requires changes to the router Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 2. [Page 9] ^L INTERNET-DRAFT Expires: January 2002 July 2001 infrastructure. See [2] for a preliminary design description. We do not discuss this approach further in this document. 2.1. Delivery service models LCT can support several different delivery service models. Two examples are briefly described here. Push service model. One way a push service model can be used for reliable content delivery is to deliver a series of objects. For example, a receiver could join the session and dynamically adapt the number of LCT channels the receiver is joined to until enough packets have been received to reconstruct an object. After reconstructing the object the receiver may stay in the session and wait for the transmission of the next object. The push model is particularly attractive in satellite networks and wireless networks. In these cases, a session may consist of one fixed rate LCT channel. On-demand content delivery model. For an on-demand content delivery service model, senders typically transmit for some given time period selected to be long enough to allow all the intended receivers to join the session and recover the object. For example a popular software update might be transmitted using LCT for several days, even though a receiver may be able to complete the download in one hour total of connection time, perhaps spread over several intervals of time. In this case the receivers join the session, and dynamically adapt the number of LCT channels they subscribe to (and the reception quality) according to the available bandwidth. Receivers then drop from the session when they have received enough packets to recover the object. As an example, assume that an object is 50 MB. The sender could set the data rate on the lowest LCT channel to 50 1KB packets per second, so that receivers using just this LCT channel could complete reception of the object in 1,000 seconds in absence of loss, and would be able to complete reception even in presence of some substantial amount of losses with the use of coding for reliability. Furthermore, the sender could use a number of LCT channels such that the aggregate data rate when using all LCT channels is 1,000 1KB packets per second, so that a receiver could be able to complete reception of the object in as little Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 2.1. [Page 10] ^L INTERNET-DRAFT Expires: January 2002 July 2001 50 seconds (assuming no loss and that the congestion control mechanism immediately converges to the use of all LCT channels). Other service models. There are many other delivery service models that LCT can be used for that are not covered above. As examples, a live streaming or an on- demand archival content streaming service model. The description of the many potential applications, the appropriate delivery service model, and the additional mechanisms to support such functionalities when combined with LCT is beyond the scope of this document. This document only attempts to describe the minimal common scalable elements to these diverse applications using LCT as the delivery transport. 2.2. Congestion Control The specific congestion control protocol to be used for LCT sessions depends on the type of content to be delivered. While the general behavior of the congestion control protocol is to reduce the throughput in presence of congestion and gradually increase it in the absence of congestion, the actual dynamic behavior (e.g. response to single losses) can vary. Some possible congestion control protocols for reliable content delivery using LCT are described in [9]. Different delivery service models might require a different congestion control protocols. 3. LCT packets The type of packet used by LCT sessions is "LCT Packet". LCT packets are sent by senders to LCT channels. Some instances of LCT sessions MAY require the generation of feedback from the receivers to the sender. However, the mechanism for doing this is outside the scope of LCT. The LCT packet format described in this document is intended to be used in conjunction with the UDP transport protocol as defined in RFC768 or other transport protocols that satisfy the requirements stated in Section 1.2, specifically about demultiplexing and delivery of packet size information. LCT packets consist of an LCT packet header and an OPTIONAL LCT packet payload, as shown in Figure 1. When present, the LCT packet payload Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3. [Page 11] ^L INTERNET-DRAFT Expires: January 2002 July 2001 immediately follows the LCT packet header. The LCT packet payload MAY contain headers for other protocols, such as reliability protocols. LCT packet headers have variable size, which is specified by a length field in the third byte of the header. In the LCT packet header, all integer fields are carried in "big-endian" or "network order" format, that is, most significant byte (octet) first. Bits designated as "padding" or "reserved" (r) MUST by set to 0 by senders and ignored by receivers. Unless otherwise noted, numeric constants in this specification are in decimal (base 10). 3.1. LCT packet format The format of LCT packets is depicted in Figure 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V | r | I |S|E|X|A|B| HDR_LEN | Codepoint (CP)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Congestion Control Information (CCI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transport Object Identifier (TOI, if I >= 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOI continued (if I >= 2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOI continued (if I = 3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOI continued (if I = 3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Current Time (SCT, if S = 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Expected Residual Time (ERT, if E = 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header Extensions (if X = 1 ) | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | | Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 - LCT packet format Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.1. [Page 12] ^L INTERNET-DRAFT Expires: January 2002 July 2001 3.2. LCT packet header fields The function each field in LCT packet headers is the following. Fields marked as "1" mean that the corresponding bits MUST be set to "1" by the generating agent. Fields marked as "r" or "0" mean that the corresponding bits MUST be set to "0" by the generating agent. LCT version number (V): 4 bits Indicates the LCT protocol version. The LCT version number for this specification is 0. Reserved (r): 5 bits Reserved for future use. A sender MUST set these bits to zero and a receiver MUST ignore these bits. Transport Object Identifier flag (I): 2 bits I=0 indicates no Transport Object Identifier (TOI) field is present. I=1 indicates that a 32-bit TOI field is present. I=2 indicates that a 64-bit TOI field is present. I=3 indicates that a 128-bit TOI field is present. The TOI field indicates which object within the session this LCT packet pertains to. Sender Current Time present flag (S): 1 bit S = 0 indicates that the Sender Current Time (SCT) field is not present. S = 1 indicates that the SCT field is present. The SCT is inserted by senders to indicate to receivers how long the session has been in progress. Expected Residual Time present flag (E): 1 bit E = 0 indicates that the Expected Residual Time (ERT) field is not present. E = 1 indicates that the ERT field is present. The ERT is inserted by senders to indicate to receivers how much longer the session will continue. Senders MUST NOT set E = 1 when the ERT for the session is more Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.2. [Page 13] ^L INTERNET-DRAFT Expires: January 2002 July 2001 than 2^32-1 time units (approximately 49 days), where time is measured in units of milliseconds. Header extension present flag (X): 1 bit X = 0 indicates no Header Extensions are present. X = 1 indicates that Header Extensions are present. Header Extensions are used in LCT to accommodate OPTIONAL header fields which are not always used or have variable size. Close TOI flag (A): 1 bit Normally, the Close TOI flag is set to 0. The sender MAY set the Close TOI flag to 1 when termination of transmission of LCT packets for the object identified by the TOI is imminent. The Close TOI flag MAY be set to 1 in just the last LCT packet transmitted for the object, or it MAY be set to 1 in the last couple of seconds LCT packets transmitted for the object. Once the sender sets the Close TOI flag to 1 in one packet for a particular object, the sender SHOULD set the Close TOI flag to 1 in all subsequent packets for the object until termination of transmission of LCT packets for the object. A received packet with the Close TOI flag set to 1 indicates to a receiver that the sender will immediately stop sending LCT packets for the object identified by the TOI. When a receiver receives a packet with the Close TOI flag set to 1 then it should assume that no more LCT packets will be sent to the session for this object. Close Session flag (B): 1 bit Normally, the Close Session flag is set to 0. The sender MAY set the Close Session flag to 1 when termination of transmission of LCT packets for the session is imminent. The Close Session flag MAY be set to 1 in just the last LCT packet transmitted for the session, or it MAY be set to 1 in the last couple of seconds LCT packets transmitted for the session. Once the sender sets the Close Session flag to 1 in one packet, the sender SHOULD set the Close Session flag to 1 in all subsequent packets until termination of transmission of LCT packets for the session. A received packet with the Close Session flag set to 1 indicates to a receiver that the sender will immediately stop sending LCT packets for the session. When a receiver receives a packet with the Close Session flag set to 1 then it should assume that no more LCT packets will be sent to the session. Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.2. [Page 14] ^L INTERNET-DRAFT Expires: January 2002 July 2001 LCT packet header length (HDR_LEN): 8 bits Length of the LCT packet header in units of 32-bit words (excluding IP or UDP headers). This field can be used for direct access to the beginning of the LCT packet payload. Codepoint (CP): 8 bits An opaque identifier which is passed to the payload decoder to convey information on the codec being used for the payload. The mapping between the codepoint and the actual codec is defined on a per session basis and communicated out-of-band as part of the session description information. The use of the CP field is similar to the Payload Type (PT) field in RTP headers as described in RFC1889. Congestion Control Information (CCI): 32 bits Used to carry congestion control information, e.g. for the congestion control specified in [9] or other congestion control schemes. This field is opaque for the purpose of this specification. Transport Object Identifier (TOI): 32, 64 or 128 bits (OPTIONAL) This field indicates which object within the session this LCT packet pertains to. For example, a sender might send a number of files in the same session, using TOI=0 for the first file, TOI=1 for the second one, etc. The mapping of TOI field values to objects MUST be done out of band. This field MUST NOT be present if I=0. This field MUST be 32 bits if I=1. This field MUST be 64 bits if I=2. This field MUST be 128 bits if I=3. Sender Current Time (SCT): 32 bits (OPTIONAL) This field represents the current clock at the sender at the time this packet was transmitted, measured in units of 1ms and computed modulo 2^32 units from the start of the session. This field MUST NOT be present if S=0 and MUST be present if S=1. Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.2. [Page 15] ^L INTERNET-DRAFT Expires: January 2002 July 2001 Expected Residual Time (ERT): 32 bits (OPTIONAL) This field represents the sender expected residual transmission time for the current session, measured in units of 1ms. This field MUST NOT be present if E=0 and MUST be present if E=1. 3.3. Header-Extension Fields To allow for additional header fields and to extend the size of some of the predefined fields, the LCT packet header contains an additional header field flag, "X". If "X" is set to 0 then no additional header fields are included within the LCT packet header beyond the predefined fields. When additional headers beyond the predefined fields are used, the value of "X" within the LCT packet header MUST be set to 1. Examples of use of Header Extensions include: o Extended-size version of already existing header fields. o Sender and Receiver authentication information. If present, Header Extensions MUST be processed to ensure that they are recognized before performing any congestion control procedure or otherwise accepting an LCT packet. LCT packets with unrecognised Header Extensions MUST be discarded by the receiving agent, hence the expected use of extensions SHOULD be signaled out-of-band before session startup. There are two formats for Header Extension fields, as depicted below. The first format is used for variable-length extensions, with Header Extension Type (HET) values between 0 and 63. The second format is used for fixed length (one word) extension, using HET values from 64 to 127. Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.3. [Page 16] ^L INTERNET-DRAFT Expires: January 2002 July 2001 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| HET (<=63) | HEL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . Header Extension Content (HEC) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| HET (>=64) | Header Extension Content (HEC) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 - Format of additional headers The explanation of each sub-field is the following. Last Header Extension (L): 1 bit MUST be set to 1 in the last Header Extension field present in an LCT packet header, MUST be set to 0 in all the others. Header Extension Type (HET): 7 bits The type of the Header Extension. This document defines a number of possible types. Additional types may be defined in future version of this specification. HET values from 0 to 63 are used for variable-length Header Extensions. HET values from 64 to 127 are used for fixed-length Header Extensions. Header Extension Length (HEL): 8 bits The length of the whole Header Extension field, expressed in multiples of 32-bit words. This field MUST be present for variable-length extensions (HET between 0 and 63) and MUST NOT be present for fixed-length extensions (HET between 64 and 127). Header Extension Content (HEC): variable length Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.3. [Page 17] ^L INTERNET-DRAFT Expires: January 2002 July 2001 The content of the Header Extension. The format of this sub-field depends on the Header Extension type. For fixed-length Header Extensions, the HEC is 24 bits. For variable-length Header Extensions, the HEC field has variable size, as specified by the HEL field. Note that the length of each Header Extension field MUST be a multiple of 32 bits. Also note that the total size of the LCT packet header, including all Header Extensions and all OPTIONAL header fields, cannot exceed 255 32-bit words. An LCT packet with Header Extensions MUST NOT have space between the end of the last Header Extension and the beginning of the LCT packet payload. All senders and receivers of LCT packets MUST support the EXT_NOP Header Extension. The following Header Extension types are defined: EXT_NOP=0 No-Operation extension. The information present in this extension field MUST be ignored by receivers. EXT_CCI_V=1 Congestion Control Information extension, variable length. This extension field extends the CCI field present in the fixed part of the header. It is used when the congestion control information does not fit in the 32-bit CCI field. When this option is present, the concatenation of the 32-bit CCI field in the fixed part of the header together with the variable length value provided in this option is used as the congestion control information. The interpretation of the data contained in EXT_CCI_V MUST be negotiated out-of-band. The use of EXT_CCI_V and EXT_CCI_F is mutually exclusive. EXT_AUTH=2 Authentication extension Information used to authenticate the sender of the LCT packet. If present, the format of this Header Extension and its processing MUST be communicated out-of-band as part of the session description. It is RECOMMENDED that senders provide some form of authentication on the LCT packets they transmit. If EXT_AUTH is present, whatever authentication checks that can be performed immediately upon reception of the packet MUST be performed before accepting the packet and Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.3. [Page 18] ^L INTERNET-DRAFT Expires: January 2002 July 2001 performing any congestion control-related action on it. Some authentication schemes impose a delay of several seconds between when a packet is received and when the packet is fully authenticated. Any congestion control related action that is appropriate MUST NOT be delayed by any such full authentication delay. EXT_CCI_F=65 Congestion Control Information extension, fixed length. This extension field extends the CCI field present in the fixed part of the header. It is used when the congestion control information does not fit in the 32-bit CCI field. When this option is present, the concatenation of the 32-bit CCI field in the fixed part of the header together with the 24-bit fixed length value provided in this option is used as the congestion control information. The interpretation of the data contained in EXT_CCI_F MUST be negotiated out-of-band. The use of EXT_CCI_V and EXT_CCI_F is mutually exclusive. 4. Procedures 4.1. Sender Operation Before a session starts, an LCT sender MUST make available all applicable information regarding the session. This information could include, but is not limited to: o The number of LCT channels; o The addresses, port numbers and data rates used for each LCT channel; o The format of the payload. For example, the payload could contain other protocol headers such as an FEC header. Then for example the information could include the mapping of codepoints used in the session to FEC codec types and parameters; o The congestion control scheme being used; o The possible Header Extensions that could be used in the session; o The mapping of TOI value(s) to objects for the session; o The authentication scheme being used, and all relevant information which is necessary for sender authentication purposes; Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 4.1. [Page 19] ^L INTERNET-DRAFT Expires: January 2002 July 2001 The session description could be in a form such as SDP as defined in RFC2327, XML metadata, HTTP/Mime headers, etc. It might be carried in a session announcement protocol such as SAP [4], obtained using RCCP session control as described in [8], 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. Within an LCT session, an LCT sender transmits a sequence of LCT packets each containing a payload encoded according to one of the codecs defined in the session description. LCT packets are sent over one or more LCT channels which together constitute a session. Transmission rates MAY be different in different channels. This document does not specify the LCT packet payload, nor the order in which LCT packets are transmitted, nor the organization of a session into multiple channels. Although these issues affect the efficiency of the protocol, they do not affect the correctness nor the inter-operability between senders and receivers. Multiple objects can be carried within the same LCT session. In this case, each object is identified by a unique TOI. Objects MAY be transmitted sequentially, or they MAY be transmitted concurrently. Typically, the sender(s) continues to send LCT packets in a session until the transmission is considered complete. The transmission MAY be considered complete when some time has expired, a certain number of packets have been sent, or some out of band signal (possibly from a higher level protocol) has indicated completion by a sufficient number of receivers. The specification of the processing of the payload carried in LCT packets is beyond the scope of this document. LCT will act as a transport layer and convey payload and associated information (Codepoint and TOI) to the receivers and any complete protocol using LCT will implement congestion control . For the reasons mentioned above, this document does not pose any restriction on LCT packet sizes. However, network efficiency considerations recommend that the sender uses as large as possible payload size, but in such a way that LCT packets do not exceed the network's maximum transmission unit size (MTU), or fragmentation coupled with packet loss might introduce severe inefficiency in the transmission. It is also RECOMMENDED that all LCT packets have the same or very similar sizes, as this can have a severe impact on the effectiveness of congestion control schemes such as the ones described in [9]. A sender of LCT packets MUST implement the sender-side part of one of the congestion control schemes that is in accordance with RFC2357, and the Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 4.1. [Page 20] ^L INTERNET-DRAFT Expires: January 2002 July 2001 corresponding receiver congestion control scheme MUST be communicated out of band and implemented by any receivers participating in the session. 4.2. Receiver Operation Receivers can operate differently depending on the delivery service model. For example, for an on demand service model receivers MAY join a session, obtain the necessary encoding symbols to reproduce the object, and then leave the session. As another example, for a streaming service model a receiver MAY be continuously joined to a set of LCT channels to download all objects in a session. To be able to participate in a session, a receiver MUST first obtain the relevant session description information as listed in Section 4.1. To be able to participate in a session, a receiver MUST implement the congestion control protocol specified in the session description. If a receiver is not able to implement the congestion control protocol used in the session, it MUST NOT join the session. If sender authentication information is present in an LCT packet header, it MUST be used as specified in Section 3.3. If a receiver is unable to implement the authentication mechanism used by the session, it MUST NOT join the session. To be able to be a receiver in a session, the receiver MUST be able to process the LCT packet header. The receiver MUST be able to discard, forward, store or process the LCT packet payload. If a receiver is not able to process a LCT packet header, it MUST either drop from the session, or reduce the receive bandwidth to the minimum value allowed by the congestion control protocol being used. When the session is transmitted on multiple LCT channels, receivers MUST do it according to the specified startup behavior of the congestion control protocol itself. For a layered transmission on multiple channels, this typically means that a receiver will initially join only a minimal set of LCT channels, possibly a single one. This rule has the purpose of preventing receivers from starting at high data rates. Multiple objects can be carried within the same LCT session. In this case, each object is identified by a unique TOI. Note that even if a server stops sending LCT packets for an old object before starting to transmit LCT packets for a new object, both the network and the underlying protocol layers can cause some reordering of packets, especially when sent over different LCT channels, and thus receivers Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 4.2. [Page 21] ^L INTERNET-DRAFT Expires: January 2002 July 2001 MUST NOT assume that the reception of an LCT packet for a new object means that there are no more LCT packets in transit for the previous one, at least for some amount of time. A receiver MAY be concurrently joined to multiple LCT sessions. The receiver MUST perform congestion control on each such LCT session. If the congestion control protocol allows the receiver some flexibility in terms of its actions within a session then the receiver MAY make choices to optimize the packet flow performance across the multiple LCT sessions, as long as the receiver still adheres to the congestion control rules for each LCT session individually. 5. Security Considerations LCT can be subject to denial-of-service attacks by attackers which try to confuse the congestion control mechanism, or send forged packets to the session which would prevent successful reconstruction of large portions of the data stream. The same exact problems are present in TCP, where an attacker can forge packets and either slow down or increase the throughput of the session, or replace parts of the data stream with forged data. If the stream is carrying compressed or otherwise coded data, even a single forged packet could also cause incorrect reconstruction of the rest of the data stream. It is therefore RECOMMENDED that LCT agents implement some form of authentication to protect themselves against such attacks. 6. IANA Considerations No information in this specification is subject to IANA registration. Building blocks components used by LCT may introduce additional IANA considerations. 7. Intellectual Property Issues No specific reliability protocol or congestion control protocol is specified or referenced as mandatory in this document. LCT MAY be used with congestion control protocols and other protocols which are proprietary, or have pending or granted patents. Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 7. [Page 22] ^L INTERNET-DRAFT Expires: January 2002 July 2001 8. Acknowledgments Thanks to Vincent Roca, Bruce Lueckenhoff and Hayder Radha for detailed comments on this document. [1] 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. [2] Cain, B., Speakman, T., and Towsley, D., "Generic Router Assist (GRA) Building Block, Motivation and Architecture", Internet Draft draft-ietf-rmt-gra-arch-00.txt, a work in progress. [3] Gemmell, J., Schooler, E., and Gray, J., "FCast Scalable Multicast File Distribution: Caching and Parameters Optimizations", Technical Report MSR-TR-99-14, Microsoft Research, Redmond, WA, April, 1999. [4] Handley, M., "SAP: Session Announcement Protocol", Internet Draft, IETF MMUSIC Working Group, Nov 1996, a work in progress. [5] Holbrook, H., Cain, B., "Source-Specific Multicast for IP", Internet Draft, SSM Working Group, March 2001, draft-holbrook-ssm-arch-02.txt, a work in progress. [6] Luby, M., Gemmell, Vicisano, L., J., Rizzo, L., Handley, M., Crowcroft, J., "The use of Forward Error Correction in Reliable Multicast", Internet Draft draft-ietf-rmt-info-fec-00.txt, November 2000, a work in progress. [7] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., Crowcroft, J., "RMT BB Forward Error Correction Codes", Internet Draft draft-ietf-rmt-bb-fec-03.txt, July 2001. [8] Luby, M., Hernek, D., Kushi, D., Rasmussen, L., Simu, S., Vainish, R., "Rich Content Control Protocol: A session control protocol instantiation", Digital Fountain document, a work in progress. [9] Luby, M., Vicisano, L., Haken, A., "RMT BB Layered congestion control", draft-ietf-rmt-bb-lcc-00.txt, November 2000, a work in progress. [10] Rizzo, L., "Effective Erasure Codes for Reliable Computer Communication Protocols", ACM SIGCOMM Computer Communication Review, Vol.27, No.2, pp.24-36, Apr 1997. Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 8. [Page 23] ^L INTERNET-DRAFT Expires: January 2002 July 2001 [11] Perrig, A., Canetti, R., Briscoe, B., Tygar, D., Song, D., "TESLA: Multicast Source Authentication Transform", draft-irtf-smug- tesla-00.txt, November, 2000, a work in progress. [12] 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. [13] Speakman, T., Farinacci, D., Crowcroft, J., Gemmell, J., Lin, S., Tweedly, A., Leshchiner, D., Luby, M., Bhaskar, N., Edmonstone, R., Johnson, K., Montgomery, T., Rizzo, L., Sumanasekera, R., Vicisano, L., "PGM Reliable Transport Protocol", draft-speakman-pgm-spec-06.txt, a work in progress. [14] Vicisano, L., Rizzo, L., Crowcroft, J., "TCP-like Congestion Control for Layered Multicast Data Transfer", IEEE Infocom '98, San Francisco, CA, Mar.28-Apr.1 1998. [15] Vicisano, L., "Notes On a Cumulative Layered Organization of Data Packets Across Multiple groups with Different Rates", University College London Computer Science Research Note RN/98/25, Work in Progress (May 1998). 9. Authors' Addresses Michael Luby luby@digitalfountain.com Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA, USA, 94538 Jim Gemmell jgemmell@microsoft.com Microsoft Research 301 Howard St., #830 San Francisco, CA, USA, 94105 Lorenzo Vicisano lorenzo@cisco.com cisco Systems, Inc. 170 West Tasman Dr., San Jose, CA, USA, 95134 Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 9. [Page 24] ^L INTERNET-DRAFT Expires: January 2002 July 2001 Luigi Rizzo luigi@iet.unipi.it ACIRI/ICSI, 1947 Center St, Berkeley, CA, USA, 94704 and Dip. Ing. dell'Informazione, Univ. di Pisa via Diotisalvi 2, 56126 Pisa, Italy Mark Handley mjh@aciri.org ACIRI, 1947 Center St, Berkeley, CA, USA, 94704 Jon Crowcroft J.Crowcroft@cs.ucl.ac.uk Department of Computer Science University College London Gower Street, London WC1E 6BT, UK Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 9. [Page 25] ^L INTERNET-DRAFT Expires: January 2002 July 2001 10. 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." Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 10. [Page 26] ^L INTERNET-DRAFT Expires: January 2002 July 2001 Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 10. [Page 27] --==_Exmh_5195028970 Content-Type: application/postscript ; name="draft-ietf-rmt-bb-lct-01.ps" Content-Description: draft-ietf-rmt-bb-lct-01.ps Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-rmt-bb-lct-01.ps" JSFQUy1BZG9iZS0zLjAKJSVDcmVhdG9yOiBncm9mZiB2ZXJzaW9uIDEuMTYuMQolJUNyZWF0 aW9uRGF0ZTogVGh1IEp1bCAxOSAxNzowODoxNiAyMDAxCiUlRG9jdW1lbnROZWVkZWRSZXNv dXJjZXM6IGZvbnQgQ291cmllci1Cb2xkCiUlKyBmb250IFRpbWVzLUJvbGQKJSUrIGZvbnQg VGltZXMtUm9tYW4KJSUrIGZvbnQgQ291cmllcgolJURvY3VtZW50U3VwcGxpZWRSZXNvdXJj ZXM6IHByb2NzZXQgZ3JvcHMgMS4xNiAxCiUlUGFnZXM6IDIxCiUlUGFnZU9yZGVyOiBBc2Nl bmQKJSVPcmllbnRhdGlvbjogUG9ydHJhaXQKJSVFbmRDb21tZW50cwolJUJlZ2luUHJvbG9n CiUlQmVnaW5SZXNvdXJjZTogcHJvY3NldCBncm9wcyAxLjE2IDEKL3NldHBhY2tpbmcgd2hl cmV7CnBvcApjdXJyZW50cGFja2luZwp0cnVlIHNldHBhY2tpbmcKfWlmCi9ncm9wcyAxMjAg ZGljdCBkdXAgYmVnaW4KL1NDIDMyIGRlZgovQS9zaG93IGxvYWQgZGVmCi9CezAgU0MgMyAt MSByb2xsIHdpZHRoc2hvd31iaW5kIGRlZgovQ3swIGV4Y2ggYXNob3d9YmluZCBkZWYKL0R7 MCBleGNoIDAgU0MgNSAyIHJvbGwgYXdpZHRoc2hvd31iaW5kIGRlZgovRXswIHJtb3ZldG8g c2hvd31iaW5kIGRlZgovRnswIHJtb3ZldG8gMCBTQyAzIC0xIHJvbGwgd2lkdGhzaG93fWJp bmQgZGVmCi9HezAgcm1vdmV0byAwIGV4Y2ggYXNob3d9YmluZCBkZWYKL0h7MCBybW92ZXRv IDAgZXhjaCAwIFNDIDUgMiByb2xsIGF3aWR0aHNob3d9YmluZCBkZWYKL0l7MCBleGNoIHJt b3ZldG8gc2hvd31iaW5kIGRlZgovSnswIGV4Y2ggcm1vdmV0byAwIFNDIDMgLTEgcm9sbCB3 aWR0aHNob3d9YmluZCBkZWYKL0t7MCBleGNoIHJtb3ZldG8gMCBleGNoIGFzaG93fWJpbmQg ZGVmCi9MezAgZXhjaCBybW92ZXRvIDAgZXhjaCAwIFNDIDUgMiByb2xsIGF3aWR0aHNob3d9 YmluZCBkZWYKL017cm1vdmV0byBzaG93fWJpbmQgZGVmCi9Oe3Jtb3ZldG8gMCBTQyAzIC0x IHJvbGwgd2lkdGhzaG93fWJpbmQgZGVmCi9Pe3Jtb3ZldG8gMCBleGNoIGFzaG93fWJpbmQg ZGVmCi9Qe3Jtb3ZldG8gMCBleGNoIDAgU0MgNSAyIHJvbGwgYXdpZHRoc2hvd31iaW5kIGRl ZgovUXttb3ZldG8gc2hvd31iaW5kIGRlZgovUnttb3ZldG8gMCBTQyAzIC0xIHJvbGwgd2lk dGhzaG93fWJpbmQgZGVmCi9Te21vdmV0byAwIGV4Y2ggYXNob3d9YmluZCBkZWYKL1R7bW92 ZXRvIDAgZXhjaCAwIFNDIDUgMiByb2xsIGF3aWR0aHNob3d9YmluZCBkZWYKL1NGewpmaW5k Zm9udCBleGNoCltleGNoIGR1cCAwIGV4Y2ggMCBleGNoIG5lZyAwIDBdbWFrZWZvbnQKZHVw IHNldGZvbnQKW2V4Y2gvc2V0Zm9udCBjdnhdY3Z4IGJpbmQgZGVmCn1iaW5kIGRlZgovTUZ7 CmZpbmRmb250Cls1IDIgcm9sbAowIDMgMSByb2xsCm5lZyAwIDBdbWFrZWZvbnQKZHVwIHNl dGZvbnQKW2V4Y2gvc2V0Zm9udCBjdnhdY3Z4IGJpbmQgZGVmCn1iaW5kIGRlZgovbGV2ZWww IDAgZGVmCi9SRVMgMCBkZWYKL1BMIDAgZGVmCi9MUyAwIGRlZgovTUFOVUFMewpzdGF0dXNk aWN0IGJlZ2luL21hbnVhbGZlZWQgdHJ1ZSBzdG9yZSBlbmQKfWJpbmQgZGVmCi9QTEd7Cmdz YXZlIG5ld3BhdGggY2xpcHBhdGggcGF0aGJib3ggZ3Jlc3RvcmUKZXhjaCBwb3AgYWRkIGV4 Y2ggcG9wCn1iaW5kIGRlZgovQlB7Ci9sZXZlbDAgc2F2ZSBkZWYKMSBzZXRsaW5lY2FwCjEg c2V0bGluZWpvaW4KNzIgUkVTIGRpdiBkdXAgc2NhbGUKTFN7CjkwIHJvdGF0ZQp9ewowIFBM IHRyYW5zbGF0ZQp9aWZlbHNlCjEgLTEgc2NhbGUKfWJpbmQgZGVmCi9FUHsKbGV2ZWwwIHJl c3RvcmUKc2hvd3BhZ2UKfWJpbmQgZGVmCi9EQXsKbmV3cGF0aCBhcmNuIHN0cm9rZQp9Ymlu ZCBkZWYKL1NOewp0cmFuc2Zvcm0KLjI1IHN1YiBleGNoIC4yNSBzdWIgZXhjaApyb3VuZCAu MjUgYWRkIGV4Y2ggcm91bmQgLjI1IGFkZCBleGNoCml0cmFuc2Zvcm0KfWJpbmQgZGVmCi9E THsKU04KbW92ZXRvClNOCmxpbmV0byBzdHJva2UKfWJpbmQgZGVmCi9EQ3sKbmV3cGF0aCAw IDM2MCBhcmMgY2xvc2VwYXRoCn1iaW5kIGRlZgovVE0gbWF0cml4IGRlZgovREV7ClRNIGN1 cnJlbnRtYXRyaXggcG9wCnRyYW5zbGF0ZSBzY2FsZSBuZXdwYXRoIDAgMCAuNSAwIDM2MCBh cmMgY2xvc2VwYXRoClRNIHNldG1hdHJpeAp9YmluZCBkZWYKL1JDL3JjdXJ2ZXRvIGxvYWQg ZGVmCi9STC9ybGluZXRvIGxvYWQgZGVmCi9TVC9zdHJva2UgbG9hZCBkZWYKL01UL21vdmV0 byBsb2FkIGRlZgovQ0wvY2xvc2VwYXRoIGxvYWQgZGVmCi9GTHsKY3VycmVudGdyYXkgZXhj aCBzZXRncmF5IGZpbGwgc2V0Z3JheQp9YmluZCBkZWYKL0JML2ZpbGwgbG9hZCBkZWYKL0xX L3NldGxpbmV3aWR0aCBsb2FkIGRlZgovUkV7CmZpbmRmb250CmR1cCBtYXhsZW5ndGggMSBp bmRleC9Gb250TmFtZSBrbm93biBub3R7MSBhZGR9aWYgZGljdCBiZWdpbgp7CjEgaW5kZXgv RklEIG5le2RlZn17cG9wIHBvcH1pZmVsc2UKfWZvcmFsbAovRW5jb2RpbmcgZXhjaCBkZWYK ZHVwL0ZvbnROYW1lIGV4Y2ggZGVmCmN1cnJlbnRkaWN0IGVuZCBkZWZpbmVmb250IHBvcAp9 YmluZCBkZWYKL0RFRlMgMCBkZWYKL0VCRUdJTnsKbW92ZXRvCkRFRlMgYmVnaW4KfWJpbmQg ZGVmCi9FRU5EL2VuZCBsb2FkIGRlZgovQ05UIDAgZGVmCi9sZXZlbDEgMCBkZWYKL1BCRUdJ TnsKL2xldmVsMSBzYXZlIGRlZgp0cmFuc2xhdGUKZGl2IDMgMSByb2xsIGRpdiBleGNoIHNj YWxlCm5lZyBleGNoIG5lZyBleGNoIHRyYW5zbGF0ZQowIHNldGdyYXkKMCBzZXRsaW5lY2Fw CjEgc2V0bGluZXdpZHRoCjAgc2V0bGluZWpvaW4KMTAgc2V0bWl0ZXJsaW1pdApbXTAgc2V0 ZGFzaAovc2V0c3Ryb2tlYWRqdXN0IHdoZXJlewpwb3AKZmFsc2Ugc2V0c3Ryb2tlYWRqdXN0 Cn1pZgovc2V0b3ZlcnByaW50IHdoZXJlewpwb3AKZmFsc2Ugc2V0b3ZlcnByaW50Cn1pZgpu ZXdwYXRoCi9DTlQgY291bnRkaWN0c3RhY2sgZGVmCnVzZXJkaWN0IGJlZ2luCi9zaG93cGFn ZXt9ZGVmCn1iaW5kIGRlZgovUEVORHsKY2xlYXIKY291bnRkaWN0c3RhY2sgQ05UIHN1Yntl bmR9cmVwZWF0CmxldmVsMSByZXN0b3JlCn1iaW5kIGRlZgplbmQgZGVmCi9zZXRwYWNraW5n IHdoZXJlewpwb3AKc2V0cGFja2luZwp9aWYKJSVFbmRSZXNvdXJjZQolJUluY2x1ZGVSZXNv dXJjZTogZm9udCBDb3VyaWVyLUJvbGQKJSVJbmNsdWRlUmVzb3VyY2U6IGZvbnQgVGltZXMt Qm9sZAolJUluY2x1ZGVSZXNvdXJjZTogZm9udCBUaW1lcy1Sb21hbgolJUluY2x1ZGVSZXNv dXJjZTogZm9udCBDb3VyaWVyCmdyb3BzIGJlZ2luL0RFRlMgMSBkaWN0IGRlZiBERUZTIGJl Z2luL3V7LjAwMSBtdWx9YmluZCBkZWYgZW5kL1JFUyA3MgpkZWYvUEwgNzkyIGRlZi9MUyBm YWxzZSBkZWYvRU5DMFsvYXNjaWljaXJjdW0vYXNjaWl0aWxkZS9TY2Fyb24vWmNhcm9uCi9z Y2Fyb24vemNhcm9uL1lkaWVyZXNpcy90cmFkZW1hcmsvcXVvdGVzaW5nbGUvLm5vdGRlZi8u bm90ZGVmLy5ub3RkZWYKLy5ub3RkZWYvLm5vdGRlZi8ubm90ZGVmLy5ub3RkZWYvLm5vdGRl Zi8ubm90ZGVmLy5ub3RkZWYvLm5vdGRlZi8ubm90ZGVmCi8ubm90ZGVmLy5ub3RkZWYvLm5v dGRlZi8ubm90ZGVmLy5ub3RkZWYvLm5vdGRlZi8ubm90ZGVmLy5ub3RkZWYvLm5vdGRlZgov Lm5vdGRlZi8ubm90ZGVmL3NwYWNlL2V4Y2xhbS9xdW90ZWRibC9udW1iZXJzaWduL2RvbGxh ci9wZXJjZW50Ci9hbXBlcnNhbmQvcXVvdGVyaWdodC9wYXJlbmxlZnQvcGFyZW5yaWdodC9h c3Rlcmlzay9wbHVzL2NvbW1hL2h5cGhlbgovcGVyaW9kL3NsYXNoL3plcm8vb25lL3R3by90 aHJlZS9mb3VyL2ZpdmUvc2l4L3NldmVuL2VpZ2h0L25pbmUvY29sb24KL3NlbWljb2xvbi9s ZXNzL2VxdWFsL2dyZWF0ZXIvcXVlc3Rpb24vYXQvQS9CL0MvRC9FL0YvRy9IL0kvSi9LL0wv TS9OL08KL1AvUS9SL1MvVC9VL1YvVy9YL1kvWi9icmFja2V0bGVmdC9iYWNrc2xhc2gvYnJh Y2tldHJpZ2h0L2NpcmN1bWZsZXgKL3VuZGVyc2NvcmUvcXVvdGVsZWZ0L2EvYi9jL2QvZS9m L2cvaC9pL2ovay9sL20vbi9vL3AvcS9yL3MvdC91L3Yvdy94L3kKL3ovYnJhY2VsZWZ0L2Jh ci9icmFjZXJpZ2h0L3RpbGRlLy5ub3RkZWYvcXVvdGVzaW5nbGJhc2UvZ3VpbGxlbW90bGVm dAovZ3VpbGxlbW90cmlnaHQvYnVsbGV0L2Zsb3Jpbi9mcmFjdGlvbi9wZXJ0aG91c2FuZC9k YWdnZXIvZGFnZ2VyZGJsCi9lbmRhc2gvZW1kYXNoL2ZmL2ZpL2ZsL2ZmaS9mZmwvZG90bGVz c2kvZG90bGVzc2ovZ3JhdmUvaHVuZ2FydW1sYXV0Ci9kb3RhY2NlbnQvYnJldmUvY2Fyb24v cmluZy9vZ29uZWsvcXVvdGVkYmxsZWZ0L3F1b3RlZGJscmlnaHQvb2UvbHNsYXNoCi9xdW90 ZWRibGJhc2UvT0UvTHNsYXNoLy5ub3RkZWYvZXhjbGFtZG93bi9jZW50L3N0ZXJsaW5nL2N1 cnJlbmN5L3llbgovYnJva2VuYmFyL3NlY3Rpb24vZGllcmVzaXMvY29weXJpZ2h0L29yZGZl bWluaW5lL2d1aWxzaW5nbGxlZnQKL2xvZ2ljYWxub3QvbWludXMvcmVnaXN0ZXJlZC9tYWNy b24vZGVncmVlL3BsdXNtaW51cy90d29zdXBlcmlvcgovdGhyZWVzdXBlcmlvci9hY3V0ZS9t dS9wYXJhZ3JhcGgvcGVyaW9kY2VudGVyZWQvY2VkaWxsYS9vbmVzdXBlcmlvcgovb3JkbWFz Y3VsaW5lL2d1aWxzaW5nbHJpZ2h0L29uZXF1YXJ0ZXIvb25laGFsZi90aHJlZXF1YXJ0ZXJz Ci9xdWVzdGlvbmRvd24vQWdyYXZlL0FhY3V0ZS9BY2lyY3VtZmxleC9BdGlsZGUvQWRpZXJl c2lzL0FyaW5nL0FFCi9DY2VkaWxsYS9FZ3JhdmUvRWFjdXRlL0VjaXJjdW1mbGV4L0VkaWVy ZXNpcy9JZ3JhdmUvSWFjdXRlL0ljaXJjdW1mbGV4Ci9JZGllcmVzaXMvRXRoL050aWxkZS9P Z3JhdmUvT2FjdXRlL09jaXJjdW1mbGV4L090aWxkZS9PZGllcmVzaXMKL211bHRpcGx5L09z bGFzaC9VZ3JhdmUvVWFjdXRlL1VjaXJjdW1mbGV4L1VkaWVyZXNpcy9ZYWN1dGUvVGhvcm4K L2dlcm1hbmRibHMvYWdyYXZlL2FhY3V0ZS9hY2lyY3VtZmxleC9hdGlsZGUvYWRpZXJlc2lz L2FyaW5nL2FlL2NjZWRpbGxhCi9lZ3JhdmUvZWFjdXRlL2VjaXJjdW1mbGV4L2VkaWVyZXNp cy9pZ3JhdmUvaWFjdXRlL2ljaXJjdW1mbGV4L2lkaWVyZXNpcwovZXRoL250aWxkZS9vZ3Jh dmUvb2FjdXRlL29jaXJjdW1mbGV4L290aWxkZS9vZGllcmVzaXMvZGl2aWRlL29zbGFzaAov dWdyYXZlL3VhY3V0ZS91Y2lyY3VtZmxleC91ZGllcmVzaXMveWFjdXRlL3Rob3JuL3lkaWVy ZXNpc11kZWYKL0NvdXJpZXJAMCBFTkMwL0NvdXJpZXIgUkUvVGltZXMtUm9tYW5AMCBFTkMw L1RpbWVzLVJvbWFuIFJFCi9UaW1lcy1Cb2xkQDAgRU5DMC9UaW1lcy1Cb2xkIFJFL0NvdXJp ZXItQm9sZEAwIEVOQzAvQ291cmllci1Cb2xkIFJFCiUlRW5kUHJvbG9nCiUlUGFnZTogMSAx CiUlQmVnaW5QYWdlU2V0dXAKQlAKJSVFbmRQYWdlU2V0dXAKL0YwIDEwL0NvdXJpZXItQm9s ZEAwIFNGKEludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UpNzIgODUgUShSTVQgV0cp CjIwOS45OTkgRSAyMDMuOTk5KElOVEVSTkVULURSQUZUIE0uTHVieS9EaWdpdGFsKTcyIDk4 IFIoRm91bnRhaW4pNiBFCjE0OS45OTkoZHJhZnQtaWV0Zi1ybXQtYmItbGN0LTAxLnBzIEou R2VtbWVsbC9NaWNyb3NvZnQpNzIgMTExIFIKKEwuVmljaXNhbm8vQ2lzY28pNDA3Ljk5OSAx MjQgUShMLlJpenpvL0FDSVJJIGFuZCBVbml2LiBQaXNhKTMzNS45OTkgMTM3ClEoTS5IYW5k bGV5L0FDSVJJKTQxMy45OTkgMTUwIFEoSi4gQ3Jvd2Nyb2Z0L1VDTCk0MDcuOTk5IDE2MyBR CigxOSBKdWx5IDIwMDEpNDMxLjk5OSAxNzYgUShFeHBpcmVzOiBKYW51YXJ5IDIwMDIpMzc3 Ljk5OSAxODkgUS9GMSAxNAovVGltZXMtQm9sZEAwIFNGKExheSkyMDUuNDkxIDIxNCBRKGVy KS0uMTQgRShlZCBDb2RpbmcgVCktLjI1MiBFCihyYW5zcG9ydDopLTEuMDM2IEUgMy41KEFt KTE0Ny4zMjEgMjI3IFMoYXNzaSktMy41IEUgLS4xNCh2ZSktLjE0IEcKKGx5IHNjYWxhYmxl IGNvbnRlbnQgZGVsaSkuMTQgRSAtLjE0KHZlKS0uMTQgRyhyeSB0cmFuc3BvcnQpLjE0IEUv RjIgMTEKL1RpbWVzLUJvbGRAMCBTRihTdGF0dXMgb2YgdGhpcyBEb2N1bWVudCk3MiAyNzIg US9GMyAxMS9UaW1lcy1Sb21hbkAwIFNGCihUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0 LURyYWZ0IGFuZCBpcyBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggYWxsXAogcHJvKTcyIDI4 OC42IFEodmlzaW9ucyBvZiBTZWN0aW9uIDEwIG9mKS0uMTY1IEUoUkZDMjAyNi4pNzIgMzAx LjYgUQooSW50ZXJuZXQtRHJhZnRzIGFyZSB3KTcyIDMyNy42IFEKKG9ya2luZyBkb2N1bWVu dHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIFQpLS4xMSBFKGFzayBGKS0uODggRQoo b3JjZSBcKElFVEZcKSwgaXRzIGFyZWFzLCktLjE2NSBFKGFuZCBpdHMgdyk3MiAzNDAuNiBR KG9ya2luZyBncm91cHMuKQotLjExIEUoTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxz byBkaXN0cmliKTUuNSBFKHV0ZSB3KS0uMjIgRQoob3JraW5nIGRvY3VtZW50cyBhcyktLjEx IEUoSW50ZXJuZXQtRHJhZnRzLik3MiAzNTMuNiBRCihJbnRlcm5ldC1EcmFmdHMgYXJlIHYp NzIgMzc5LjYgUQooYWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMgYW5kIE1BKS0u Mjc1IEUgMi43NShZYiktMS4xNTUgRyAyLjc1CihldSktMi43NSBHKHBkYXRlZCwgcmVwbGFj ZWQsIG9yKS0yLjc1IEUKKG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW4pNzIg MzkyLjYgUSAyLjc1KHl0KS0uMTY1IEcgMi43NQooaW1lLiBJdCktMi43NSBGKGlzIGluYXBw cm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UpCjIuNzUgRSht YXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyBhICJ3KTcyIDQwNS42IFEK KG9yayBpbiBwcm9ncmVzcyIuKS0uMTEgRQooVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5l dC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0IGh0dHA6Ly93d3cpNzIKNDMxLjYgUSguaWV0 Zi5vciktLjcxNSBFKGcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dCktLjE5OCBFIDEuNzYgLS44 OAooVG8gdik3MiA0NTcuNiBUKGllKS44OCBFIDIuNzUod3QpLS4yNzUgRyhoZSBsaXN0IElu dGVybmV0LURyYWZ0IFNoYWRvKQotMi43NSBFIDIuNzUod0QpLS4yNzUgRyhpcmVjdG9yaWVz LCBzZWUgaHR0cDovL3d3dyktMi43NSBFKC5pZXRmLm9yKQotLjcxNSBFKGcvc2hhZG8pLS4x OTggRSAtLjcxNSh3LiktLjI3NSBHKGh0bWwuKS43MTUgRQooVGhpcyBkb2N1bWVudCBpcyBh IHByb2R1Y3Qgb2YgdGhlIElFVEYgUk1UIFdHLik3MiA0ODMuNiBRCihDb21tZW50cyBzaG91 bGQgYmUgYWRkcmVzc2VkIHRvIHRoZSk1LjUgRShhdXRob3JzLCBvciB0aGUgV0cnKTcyIDQ5 Ni42ClEgMi43NShzbSktLjYwNSBHKGFpbGluZyBsaXN0IGF0IHJtdEBsYmwuZ28pLTIuNzUg RSAtLjcxNSh2LiktLjE2NSBHIEYyCihBYnN0cmFjdCkyNjcuNTM0IDUyOC42IFEgRjMoVGhp cyBkb2N1bWVudCBkZXNjcmliZXMgTGF5ZXJlZCBDb2RpbmcgVCk5Nwo1NTEuMiBRKHJhbnNw b3J0LCBhIG1hc3NpKS0uMzg1IEUgLS4xNjUodmUpLS4yNzUgRyhseSBzY2FsYWJsZSByZWxp YWJsZSkKLjE2NSBFKGNvbnRlbnQgZGVsaSk5NyA1NjQuMiBRIC0uMTY1KHZlKS0uMjc1IEco cnkgYW5kIHN0cmVhbSBkZWxpKS4xNjUKRSAtLjE2NSh2ZSktLjI3NSBHKHJ5IHRyYW5zcG9y dCwgaGVyZWFmdGVyIHJlZmVycmVkIHRvIGFzIExDVCkuMTY1IEUgNS41CiguTCktLjgxNCBH KENUIGNhbiktNS41IEUoYmUgdXNlZCBmb3IgbXVsdGktcmF0ZSBkZWxpKTk3IDU3Ny4yIFEg LS4xNjUKKHZlKS0uMjc1IEcocnkgdG8gbGFyKS4xNjUgRShnZSBzZXRzIG9mIHJlY2VpKS0u MTk4IEUgLS4xNjUodmUpLS4yNzUgRwoocnMuIEluIExDVCkuMTY1IEUgMi43NSgscyktLjgx NCBHKGNhbGFiaWxpdHkgYW5kKS0yLjc1IEUoY29uZ2VzdGlvbiBjb1wKbnRyb2wgYXJlIHN1 cHBvcnRlZCB0aHJvdWdoIHRoZSB1c2Ugb2YgbGF5ZXJlZCBjb2RpbmcgdGVjaG5pcXVlcy4g Q29kaW5cCmcpOTcgNTkwLjIgUSh0ZWNobmlxdWVzIGNhbiBiZSBjb21iaW5lZCB3aXRoIExD VCB0byBwcm8pOTcgNjAzLjIgUQoodmlkZSBzdXBwb3J0IGZvciByZWxpYWJpbGl0eSktLjE2 NSBFKC4pLS43MTUgRQooQ29uZ2VzdGlvbiBjb250cm9sIGlzIHJlY2VpKTk3IDYyOS4yIFEg LS4xNjUodmUpLS4yNzUgRyAyLjc1KHJkKS4xNjUgRwoocmkpLTIuNzUgRSAtLjE2NSh2ZSkt LjI3NSBHKG4sIGFuZCBpcyBhY2hpZSkuMTY1IEUgLS4xNjUodmUpLS4yNzUgRwoyLjc1KGRi KS4xNjUgRyAyLjc1KHlzKS0yLjc1IEcoZW5kaW5nIHBhY2spLTIuNzUgRShldHMgaW4gdGhl KS0uMTEgRQooc2Vzc2lvbiB0byBtdWx0aXBsZSBgKTk3IDY0Mi4yIFEoYExDVCBjaGFubmVs cycpLS44MTQgRSgnLCBhbmQgaGEpLS44MTQKRSh2aW5nIHJlY2VpKS0uMjIgRSAtLjE2NSh2 ZSktLjI3NSBHKHJzIGpvaW4gYW5kIGxlYSkuMTY1IEUgLjMzIC0uMTY1Cih2ZSBMKS0uMjIg SChDVCkuMTY1IEUKKGNoYW5uZWxzIFwodGh1cyBhZGp1c3RpbmcgdGhlaXIgcmVjZXB0aW9u IHJhdGVcKSBpbiByZWFjdGlvbiB0byBuZXR3KTk3CjY1NS4yIFEob3JrIGNvbmRpdGlvbnMg aW4gYSktLjExIEUobWFubmVyIHRoYXQgaXMgbmV0dyk5NyA2NjguMiBRCihvcmsgZnJpZW5k bHkpLS4xMSBFKC4pLS43MTUgRShMdWJ5L0dlbW1lbGwvVik3MiA3NjkgUQooaWNpc2Fuby9S aXp6by9IYW5kbGUpLS42NiBFKHkvQ3JvKS0uMTY1IEUgMTY2Ljg1Nih3Y3JvZnQgW1ApLS4y NzUgRgooYWdlIDFdKS0uMTY1IEUgRVAKJSVQYWdlOiAyIDIKJSVCZWdpblBhZ2VTZXR1cApC UAolJUVuZFBhZ2VTZXR1cAovRjAgMTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3MiA0 OSBRIDcxLjU4NygtRFJBRlQgRXhwaXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMikyLjc1 IEUoSnVseSAyMDAxKTEyMy43MjYgRS9GMSAxMy9UaW1lcy1Cb2xkQDAgU0YgLTEuMTk2CihU YSkyMzkuMTI2IDg1IFMoYmxlIG9mIENvbnRlbnRzKTEuMTk2IEUvRjIgMTAvVGltZXMtUm9t YW5AMCBTRgooMS4gSW50cm9kdWN0aW9uKTk3IDEyMyBRIEYwIDExKC4uLi4uLi4uLi4uLi4u Li4uLi4uLi4pMy41NiBHIEYyKDMpMTEuNQpFKDEuMS4gUmVsYXRlZCBEb2N1bWVudHMpMTA3 IDEzNSBRIEYwIDExKC4uLi4uLi4uLi4uLi4uLi4uLikxMS45IEcgRjIoNCkKMTEuNSBFKDEu Mi4gRW4pMTA3IDE0NyBRKHZpcm9ubWVudGFsIFJlcXVpcmVtZW50cyBhbmQgQ29uc2lkZXJh dGlvbnMpLS40CkUgRjAgMTEoLi4uLi4uLi4uLikzLjk3IEcgRjIoNSkxMS41IEUoMi4gR2Vu ZXJhbCBBcmNoaXRlY3R1cmUpOTcgMTU5IFEKRjAgMTEoLi4uLi4uLi4uLi4uLi4uLi4uLikx MC4xMiBHIEYyKDYpMTEuNSBFKDIuMS4gRGVsaSkxMDcgMTcxIFEgLS4xNQoodmUpLS4yNSBH KHJ5IHNlcnZpY2UgbW9kZWxzKS4xNSBFIEYwIDExKC4uLi4uLi4uLi4uLi4uLi4uKTcuNDUg RyBGMig3KQoxMS41IEUoMi4yLiBDb25nZXN0aW9uIENvbnRyb2wpMTA3IDE4MyBRIEYwIDEx KC4uLi4uLi4uLi4uLi4uLi4uLikxMS44OApHIEYyKDgpMTEuNSBFKDMuIExDVCBwYWNrKTk3 IDE5NSBRKGV0cyktLjEgRSBGMCAxMQooLi4uLi4uLi4uLi4uLi4uLi4uLi4uLikxLjcyIEcg RjIoOCkxMS41IEUoMy4xLiBMQ1QgcGFjaykxMDcgMjA3IFEKKGV0IGZvcm1hdCktLjEgRSBG MCAxMSguLi4uLi4uLi4uLi4uLi4uLi4uKS4yIEcgRjIoOSkxMS41IEUKKDMuMi4gTENUIHBh Y2spMTA3IDIxOSBRKGV0IGhlYWRlciBcMjE0ZWxkcyktLjEgRSBGMCAxMQooLi4uLi4uLi4u Li4uLi4uLi4pMy41NCBHIEYyKDkpMTEuNSBFKDMuMy4gSGVhZGVyKTEwNyAyMzEgUQooLUV4 dGVuc2lvbiBGaWVsZHMpLS4yIEUgRjAgMTEoLi4uLi4uLi4uLi4uLi4uLi4pNS4zIEcgRjIo MTIpNi41IEUKKDQuIFByb2NlZHVyZXMpOTcgMjQzIFEgRjAgMTEoLi4uLi4uLi4uLi4uLi4u Li4uLi4uLik4LjU3IEcgRjIoMTQpNi41IEUKKDQuMS4gU2VuZGVyIE9wZXJhdGlvbikxMDcg MjU1IFEgRjAgMTEoLi4uLi4uLi4uLi4uLi4uLi4uLik2LjQ5IEcgRjIoMTQpCjYuNSBFKDQu Mi4gUmVjZWkpMTA3IDI2NyBRIC0uMTUodmUpLS4yNSBHIDIuNShyTykuMTUgRyhwZXJhdGlv biktMi41IEUKRjAgMTEoLi4uLi4uLi4uLi4uLi4uLi4uKTEyLjg3IEcgRjIoMTUpNi41IEUo NS4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMpCjk3IDI3OSBRIEYwIDExKC4uLi4uLi4uLi4u Li4uLi4uLikxMi4xNyBHIEYyKDE2KTYuNSBFKDYuIElBTik5NyAyOTEgUQoyLjUoQUMpLS4z NSBHKG9uc2lkZXJhdGlvbnMpLTIuNSBFIEYwIDExKC4uLi4uLi4uLi4uLi4uLi4uLi4pNy4x MSBHIEYyCigxNik2LjUgRSg3LiBJbnRlbGxlY3R1YWwgUHJvcGVydHkgSXNzdWVzKTk3IDMw MyBRIEYwIDExCiguLi4uLi4uLi4uLi4uLi4uLikxMi44OCBHIEYyKDE2KTYuNSBFKDguIEFj a25vKTk3IDMxNSBRKHdsZWRnbWVudHMpLS4yNQpFIEYwIDExKC4uLi4uLi4uLi4uLi4uLi4u Li4uKTUuNzYgRyBGMigxNyk2LjUgRSg5LiBBdXRob3JzJyBBZGRyZXNzZXMpOTcKMzI3IFEg RjAgMTEoLi4uLi4uLi4uLi4uLi4uLi4uLi4pMS4zNSBHIEYyKDE4KTYuNSBFKDEwLiBGdWxs IENvcCk5NyAzMzkKUSh5cmlnaHQgU3RhdGVtZW50KS0uMSBFIEYwIDExKC4uLi4uLi4uLi4u Li4uLi4uLikxLjQyIEcgRjIoMjApNi41IEUgRjAKKEx1YnkvR2VtbWVsbC9WKTcyIDc2OSBR KGljaXNhbm8vUml6em8vSGFuZGxlKS0uNjYgRSh5L0NybyktLjE2NSBFCjE2Ni44NTYod2Ny b2Z0IFtQKS0uMjc1IEYoYWdlIDJdKS0uMTY1IEUgRVAKJSVQYWdlOiAzIDMKJSVCZWdpblBh Z2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTEvVGltZXMtUm9tYW5AMCBTRihJTlRF Uk5FVCk3MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhwaXJlczopLTEuMDEyIEYKKEphbnVhcnkg MjAwMikyLjc1IEUoSnVseSAyMDAxKTEyMy43MjYgRS9GMSAxMS9UaW1lcy1Cb2xkQDAgU0Yo MS4pNzIgODUKUS9GMiAxNC9UaW1lcy1Cb2xkQDAgU0YoSW50cik1LjUgRShvZHVjdGlvbikt LjI1MiBFIEYwCihUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1hc3NpKTcyIDEwMS42IFEg LS4xNjUodmUpLS4yNzUgRwoobHkgc2NhbGFibGUgcmVsaWFibGUgY29udGVudCBkZWxpKS4x NjUgRSAtLjE2NSh2ZSktLjI3NSBHCihyeSBhbmQgc3RyZWFtIGRlbGkpLjE2NSBFIC0uMTY1 KHZlKS0uMjc1IEcocnkpLjE2NSBFCih0cmFuc3BvcnQsIExheWVyZWQgQ29kaW5nIFQpNzIg MTE0LjYgUQoocmFuc3BvcnQgXChMQ1RcKSwgZm9yIG11bHRpLXJhdGUgY29udGVudCBkZWxp KS0uMzg1IEUgLS4xNjUodmUpLS4yNzUgRwoocnkgcHJpbWFyaWx5IGRlc2lnbmVkIHRvKS4x NjUgRShiZSB1c2VkIHdpdGggdGhlIElQIG11bHRpY2FzdCBuZXR3KTcyCjEyNy42IFEob3Jr IHNlcnZpY2UsIGIpLS4xMSBFKHV0IE1BKS0uMjIgRSAyLjc1KFlhKS0xLjE1NSBHCihsc28g YmUgdXNlZCB3aXRoIG90aGVyIGJhc2ljIHVuZGVybHlpbmcpLTIuNzUgRShuZXR3KTcyIDE0 MC42IFEKKG9yayBvciB0cmFuc3BvcnQgc2VydmljZXMgc3VjaCBhcyB1bmljYXN0IFVEUCkt LjExIEUgNS41KC5MKS0xLjIyMSBHCihDVCBzdXBwb3J0cyBib3RoIHJlbGlhYmxlIGFuZCB1 bnJlbGlhYmxlKS01LjUgRShkZWxpKTcyIDE1My42IFEgLS4xNjUKKHZlKS0uMjc1IEcocnkp LjE2NSBFIDIuNzUoLGEpLS43MTUgRwoobmQgc3VwcG9ydHMgY29uZ2VzdGlvbiBjb250cm9s IG1lY2hhbmlzbXMgd2hpY2ggY29uZm9ybSB0byBSRkMyMzU3LikKLTIuNzUgRShMQ1QgaXMg YSBiKTcyIDE3OS42IFEodWlsZGluZyBibG9jayBhcyBkZVwyMTRuZWQgaW4gUkZDMzA0OC4p Ci0uMjIgRShDb21wbGV0ZSBwcm90b2NvbCBpbnN0YW50aWF0aW9ucyBNQSk1LjUgRSAyLjc1 KFliKS0xLjE1NSBHIDIuNzUKKGViKS0yLjc1IEcodWlsdCktMi45NyBFKGJ5IGNvbWJpbmlu ZyB0aGUgTENUIGZyYW1lKTcyIDE5Mi42IFEgLS4xMSh3bykKLS4yNzUgRyhyayB3aXRoIG90 aGVyIGNvbXBvbmVudHMuKS4xMSBFIDIuNzUoQWMpNS41IEcKKG9tcGxldGUgcHJvdG9jb2wg aW5zdGFudGlhdGlvbiB0aGF0KS0yLjc1IEUodXNlcyBMQ1QgTVVTVCBpbmNsdWRlIGEgY29c Cm5nZXN0aW9uIGNvbnRyb2wgcHJvdG9jb2wgdGhhdCBpcyBjb21wYXRpYmxlIHdpdGggTENU IGFuZCB0aGF0KTcyIDIwNS42ClEoY29uZm9ybXMgdG8gUkZDMjM1Ny4pNzIgMjE4LjYgUSAy Ljc1KEFjKTUuNSBHCihvbXBsZXRlIHByb3RvY29sIGluc3RhbnRpYXRpb24gdGhhdCB1c2Vz IExDVCBNQSktMi43NSBFIDIuNzUoWWkpLTEuMTU1CkcobmNsdWRlIGEgc2NhbGFibGUpLTIu NzUgRQoocmVsaWFiaWxpdHkgcHJvdG9jb2wgdGhhdCBpcyBjb21wYXRpYmxlIHdpdGggTENU KTcyIDIzMS42IFEgMi43NSgsaSkKLS44MTQgRyAyLjc1KHRNKS0yLjc1IEcgMi4zMSAtMS4x NTUoQVkgaSktMi43NSBICihuY2x1ZGUgYW4gc2Vzc2lvbiBjb250cm9sIHByb3RvY29sIHRo YXQpMS4xNTUgRShpcyBjb21wYXRpYmxlIHdpdGggTENUKQo3MiAyNDQuNiBRIDIuNzUoLGEp LS44MTQgRyhuZCBpdCBNQSktMi43NSBFIDIuNzUoWWkpLTEuMTU1IEcKKG5jbHVkZSBvdGhl ciBwcm90b2NvbHMgc3VjaCBhcyBzZWN1cml0eSBwcm90b2NvbHMuKS0yLjc1IEUKKExDVCBp cyBwcmVzdW1lZCB0byBiZSB1c2VkIHdpdGggYW4gdW5kZXJseWluZyBuZXR3KTcyIDI3MC42 IFEKKG9yayBvciB0cmFuc3BvcnQgc2VydmljZSB0aGF0IGlzIGEgImJlc3QgZWYpLS4xMSBF KGZvcnQiKS0uMjc1IEUKKHNlcnZpY2UgdGhhdCBkb2VzIG5vdCBndWFyYW50ZWUgcGFjayk3 MiAyODMuNiBRKGV0IHJlY2VwdGlvbiwgcGFjayktLjExCkUoZXQgcmVjZXB0aW9uIG9yZGVy KS0uMTEgRSAyLjc1KCxhKS0uNDQgRyhuZCB3aGljaCBkb2VzIG5vdCBoYSktMi43NSBFCi0u MTY1KHZlKS0uMjIgRyhhbik3MiAyOTYuNiBRIDIuNzUoeXMpLS4xNjUgRyh1cHBvcnQgZm9y IFwyMTVvKS0yLjc1IEUKMi43NSh3byktLjI3NSBHIDIuNzUocmMpLTIuNzUgRyhvbmdlc3Rp b24gY29udHJvbC4pLTIuNzUgRSAtLjE2NShGbyk1LjUKRyAyLjc1KHJlKS4xNjUgRyh4YW1w bGUsIHRoZSBBbiktMi45MTUgRQooeS1Tb3VyY2UgTXVsdGljYXN0IFwoQVNNXCkgbW9kZWwp LS4xNjUgRQoob2YgSVAgbXVsdGljYXN0IGFzIGRlXDIxNG5lZCBpbiBSRkMxMTEyIGlzIHN1 Y2ggYSAiYmVzdCBlZik3MiAzMDkuNiBRCihmb3J0IiBuZXR3KS0uMjc1IEUob3JrIHNlcnZp Y2UuKS0uMTEgRShXaGlsZSB0aGUgYmFzaWMpNS41IEUKKHNlcnZpY2UgcHJvKTcyIDMyMi42 IFEodmlkZWQgYnkgUkZDMTExMiBpcyBsYXIpLS4xNjUgRQooZ2VseSBzY2FsYWJsZSwgcHJv KS0uMTk4IEUodmlkaW5nIGNvbmdlc3Rpb24gY29udHJvbCBvciByZWxpYWJpbGl0eSkKLS4x NjUgRShzaG91bGQgYmUgZG9uZSBjYXJlZnVsbHkgdG8gYSk3MiAzMzUuNiBRIC0uMjIodm8p LS4yMiBHKGlkIHNlKQouMjIgRSAtLjE2NSh2ZSktLjI3NSBHCihyZSBzY2FsYWJpbGl0eSBs aW1pdGF0aW9ucywgZXNwZWNpYWxseSBpbiBwcmVzZW5jZSBvZikuMTY1IEUKKGhldGVyb2dl bmVvdXMgc2V0cyBvZiByZWNlaSk3MiAzNDguNiBRIC0uMTY1KHZlKS0uMjc1IEcocnMuKS4x NjUgRQooU2NhbGFiaWxpdHkgcmVmZXJzIHRvIHRoZSBiZWhhKTcyIDM3NC42IFEKKHZpb3Ig b2YgdGhlIHByb3RvY29sIGluIHJlbGF0aW9uIHRvIHRoZSBudW1iZXIgb2YgcmVjZWkpLS4y MiBFIC0uMTY1Cih2ZSktLjI3NSBHKHJzIGFuZCkuMTY1IEUobmV0dyk3MiAzODcuNiBRCihv cmsgcGF0aHMsIHRoZWlyIGhldGVyb2dlbmVpdHkpLS4xMSBFIDIuNzUoLGEpLS43MTUgRwoo bmQgdGhlIGFiaWxpdHkgdG8gYWNjb21tb2RhdGUgZHluYW1pY2FsbHkgdiktMi43NSBFKGFy aWFibGUgc2V0cyBvZikKLS4yNzUgRShyZWNlaSk3MiA0MDAuNiBRIC0uMTY1KHZlKS0uMjc1 IEcgMi43NShycy4gU2NhbGFiaWxpdHkpLjE2NSBGKGxcCmltaXRhdGlvbnMgY2FuIGNvbWUg ZnJvbSBtZW1vcnkgb3IgcHJvY2Vzc2luZyByZXF1aXJlbWVudHMsIG9yIGZyb20gdGhlKQoy Ljc1IEUoYW1vdW50IG9mIHBhY2spNzIgNDEzLjYgUShldCB0cmFmKS0uMTEgRQooXDIxNGMg Z2VuZXJhdGVkIGJ5IHRoZSBwcm90b2NvbC4pLS4yNzUgRQooSW4gdHVybiwgc3VjaCBsaW1p dGF0aW9ucyBtYXkgYmUgYSk1LjUgRQooY29uc2VxdWVuY2Ugb2YgdGhlIGZlYXR1cmVzIHRo YXQgYSBjb21wbGV0ZSByZWxpYWJsZSBjb250ZW50IGRlbGkpNzIKNDI2LjYgUSAtLjE2NSh2 ZSktLjI3NSBHKHJ5IG9yIHN0cmVhbSBkZWxpKS4xNjUgRSAtLjE2NSh2ZSktLjI3NSBHCihy eSBwcm90b2NvbCkuMTY1IEUoaXMgZSk3MiA0MzkuNiBRKHhwZWN0ZWQgdG8gcHJvKS0uMTY1 IEUodmlkZS4pLS4xNjUgRQooQ29uZ2VzdGlvbiBjb250cm9sIHJlZmVycyB0byB0aGUgYWJp bGl0eSBvZiB0aGUgcHJvdG9jb2wgdG8gYWRhcHQgaXRzIFwKdGhyb3VnaHB1dCB0byB0aGUg YSk3MiA0NjUuNiBRIC0uMjc1KHZhKS0uMjIgRyhpbGFibGUpLjI3NSBFCihiYW5kd2lkdGgg b24gdGhlIHBhdGggdG8gdGhlIHJlY2VpKTcyIDQ3OC42IFEgLS4xNjUodmUpLS4yNzUgRwoo cnMsIGFuZCB0byBzaGFyZSBiYW5kd2lkdGggZikuMTY1IEUoYWlybHkgd2l0aCBjb21wZXRp bmcgXDIxNW8pLS4xMSBFCih3cyBzdWNoKS0uMjc1IEUoYXMgVENQKTcyIDQ5MS42IFEgMi43 NSguSSktMS4yMjEgRyAyLjc1KHRpKS0yLjc1IEcgMi43NQooc1IpLTIuNzUgRyhFUSktMi43 NSBFCihVSVJFRCB0aGF0IHByb3RvY29scyBpbXBsZW1lbnQgc29tZSBmb3JtIG9mIGNvbmdl c3Rpb24gY29udHJvbCBvbiBlYWNoKQotLjExIEUoc2Vzc2lvbiBzbyB0aGF0IHRoZSk3MiA1 MDQuNiBRIDIuNzUoeW4pLS4xNjUgRyhvdCBjb21wZXRlIHVuZikKLTIuNzUgRShhaXJseSB3 aXRoIGUpLS4xMSBFKHhpc3RpbmcgYW5kIGFkYXB0aSktLjE2NSBFIC4zMyAtLjE2NSh2ZSBw KQotLjI3NSBIKHJvdG9jb2xzIHN1Y2ggYXMgVENQKS4xNjUgRSguKS0xLjIyMSBFIC0uMTY1 KEZvKTcyIDUzMC42IFMgMi43NQoocm0pLjE2NSBHKHVsdGktcmF0ZSBwcm90b2NvbHMsIHRo ZSBzZW5kZXIgdHlwaWNhbGx5IHNlbmRzIHBhY2spLTIuNzUgRQooZXRzIGF0IGEgY29uc3Rh bnQgYWdncmUpLS4xMSBFIC0uMDU1KGdhKS0uMTY1IEcodGUgcmF0ZSB0bykuMDU1IEUKKG11 bHRpcGxlIGNoYW5uZWxzLCBiKTcyIDU0My42IFEodXQgaW5kaSktLjIyIEUodmlkdWFsIHJl Y2VpKS0uMjc1IEUKLS4xNjUodmUpLS4yNzUgRyhycyBhZGp1c3Qgd2hpY2ggcG9ydGlvbiBv ZiB0aGVzZSBwYWNrKS4xNjUgRShldHMgdGhlKQotLjExIEUgMi43NSh5YSktLjE2NSBHKHR0 ZW1wdCB0byktMi43NSBFKHJlY2VpKTcyIDU1Ni42IFEgLjMzIC0uMTY1Cih2ZSBiKS0uMjc1 IEggMi43NSh5YSkuMTY1IEcoZGp1c3Rpbmcgd2hpY2ggc2V0IG9mIGNoYW5uZWxzIHRoZSkt Mi43NSBFCjIuNzUoeWEpLS4xNjUgRyhyZSBqb2luZWQgdG8gYXQgZWFjaCBwb2ludCBpbiB0 aW1lIGRlcGVuZGluZyBvbiktMi43NSBFCih0aGUgYSk3MiA1NjkuNiBRIC0uMjc1KHZhKS0u MjIgRyhpbGFibGUgYmFuZHdpZHRoIGJldHdlZW4gdGhlIHJlY2VpKQouMjc1IEUgLS4xNjUo dmUpLS4yNzUgRyAyLjc1KHJhKS4xNjUgRyhuZCB0aGUgc2VuZGVyKS0yLjc1IEUgMi43NSgs YikKLS40NCBHKHV0IGluZGVwZW5kZW50IG9mIGFsbCBvdGhlciktMi45NyBFKHJlY2VpKTcy IDU4Mi42IFEgLS4xNjUodmUpCi0uMjc1IEcgMi43NShycy4gVGh1cywpLjE2NSBGKGZvciBt dWx0aS1yYXRlIHByb3RvY29scywgdGhlIHBhY2spMi43NSBFCihldCByZWNlcHRpb24gcmF0 ZSBvZiBlYWNoIHJlY2VpKS0uMTEgRSAtLjE2NSh2ZSktLjI3NSBHIDIuNzUocm0pLjE2NSBH CihheSB2KS0yLjc1IEUoYXJ5KS0uMjc1IEUoZHluYW1pY2FsbHkgYWNjb3JkaW5nIHRvIHRo ZSBhKTcyIDU5NS42IFEKLS4yNzUodmEpLS4yMiBHKGlsYWJsZSBiYW5kd2lkdGggYmV0d2Vl biBlYWNoIHJlY2VpKS4yNzUgRSAtLjE2NSh2ZSkKLS4yNzUgRyAyLjc1KHJhKS4xNjUgRyhu ZCB0aGUgc2VuZGVyKS0yLjc1IEUoLCktLjQ0IEUKKGluZGVwZW5kZW50IG9mIHRoZSBvdGhl ciByZWNlaSk3MiA2MDguNiBRIC0uMTY1KHZlKS0uMjc1IEcgMi43NShycy4gRikKLjE2NSBG KG9yIHNpbmdsZS1yYXRlIHByb3RvY29scywgdGhlIHNlbmRlciB0eXBpY2FsbHkgc2VuZHMg cGFjayktLjE2NSBFCihldHMgdG8pLS4xMSBFKG9uZSBjaGFubmVsIGF0IHYpNzIgNjIxLjYg UShhcmlhYmxlIHJhdGVzIG8pLS4yNzUgRSAtLjE2NQoodmUpLS4xNjUgRyAyLjc1KHJ0KS4x NjUgRyhpbWUgZGVwZW5kaW5nIG9uIGZlZWRiYWNrIGZyb20gcmVjZWkpLTIuNzUgRQotLjE2 NSh2ZSktLjI3NSBHKHJzLCBhbmQgYWxsIHJlY2VpKS4xNjUgRSAtLjE2NSh2ZSktLjI3NSBH KHJzKS4xNjUgRQooYXR0ZW1wdCB0byByZWNlaSk3MiA2MzQuNiBRIC4zMyAtLjE2NSh2ZSBh KS0uMjc1IEgobGwgcGFjaykuMTY1IEUKKGV0cyB0cmFuc21pdHRlZCBieSB0aGUgc2VuZGVy IGF0IGFsbCBwb2ludHMgaW4gdGltZS4pLS4xMSBFCihUaHVzLCBmb3Igc2luZ2xlLXJhdGUp OC4yNSBFKHByb3RvY29scywgdGhlIHBhY2spNzIgNjQ3LjYgUQooZXQgcmVjZXB0aW9uIHJh dGUgb2YgYWxsIHJlY2VpKS0uMTEgRSAtLjE2NSh2ZSktLjI3NSBHKHJzIG1heSB2KS4xNjUg RQooYXJ5IGR5bmFtaWNhbGx5IG8pLS4yNzUgRSAtLjE2NSh2ZSktLjE2NSBHIDIuNzUocnQp LjE2NSBHKGltZSBpbiBlKQotMi43NSBFKHhhY3RseSB0aGUpLS4xNjUgRShzYW1lIHcpNzIg NjYwLjYgUQooYXkgZGVwZW5kZW50IG9uIHRoZSBmZWVkYmFjayBvZiBvdGhlciByZWNlaSkt LjExIEUgLS4xNjUodmUpLS4yNzUgRwoocnMgdG8gdGhlIHNlbmRlcikuMTY1IEUgNS41KC5H KS0uNjA1IEcoZW5lcmFsbHkpLTUuNSBFIDIuNzUoLGFtKS0uNzE1IEcKKHVsdGktcmF0ZSkt Mi43NSBFKHByb3RvY29sIGlzIHByZWZlcmFibGUgdG8gYSBzaW5nbGUtcmF0ZSBwcm90b2Nv bCBpbiBcCmEgaGV0ZXJvZ2VuZW91cyByZWNlaSk3MiA2NzMuNiBRIC0uMTY1KHZlKS0uMjc1 IEcgMi43NShyZSkuMTY1IEcgLS40NAoobnYpLTIuNzUgRyhpcm9ubWVudCwgYikuNDQgRSh1 dCBvbmx5KS0uMjIgRShpZiBpdCBjYW4gYmUgYWNoaWUpNzIgNjg2LjYKUSAtLjE2NSh2ZSkt LjI3NSBHIDIuNzUoZHcpLjE2NSBHKGl0aG91dCBzYWNyaVwyMTRjaW5nIHNjYWxhYmlsaXR5 KS0yLjc1CkUoLiktLjcxNSBFKExheWVyZWQgY29kaW5nIHJlZmVycyB0byB0aGUgYWJpbGl0 eSB0byBwcm9kdWNlIGEgY29kZWQgc3RyXAplYW0gdGhhdCBjYW4gYmUgc3BsaXQgaW50byBt dWx0aXBsZSk3MiA3MTIuNiBRCihsYXllcnMgdGhhdCBjYW4gYmUgc2VudCB0byBkaWYpNzIg NzI1LjYgUQooZmVyZW50IGNoYW5uZWxzLiBUaGUgY29kZWQgc3RyZWFtIGNhbiBiZSBnZW5l cmF0ZWQgZWl0aGVyIGZyb20gYSktLjI3NQpFKEx1YnkvR2VtbWVsbC9WKTcyIDc2OSBRKGlj aXNhbm8vUml6em8vSGFuZGxlKS0uNjYgRSh5L0NybyktLjE2NSBFCjExNy4zNTYod2Nyb2Z0 IFNlY3Rpb24pLS4yNzUgRiAyLjc1KDEuIFtQKTIuNzUgRihhZ2UgM10pLS4xNjUgRSBFUAol JVBhZ2U6IDQgNAolJUJlZ2luUGFnZVNldHVwCkJQCiUlRW5kUGFnZVNldHVwCi9GMCAxMS9U aW1lcy1Sb21hbkAwIFNGKElOVEVSTkVUKTcyIDQ5IFEgNzEuNTg3KC1EUkFGVCBFeHBpcmVz OiktMS4wMTIgRgooSmFudWFyeSAyMDAyKTIuNzUgRShKdWx5IDIwMDEpMTIzLjcyNiBFPDhj Nzg+NzIgODUgUShlZCBwaWVjZSBvZiBjb250ZVwKbnQsIG9yIGZyb20gYW4gb25nb2luZyBk YXRhIHN0cmVhbSwgYW5kIGhhcyB0aGUgcHJvcGVydHkgdGhhdCB0aGUgcXVhbGlcCnR5KS0u MTY1IEUgLS4xNjUoZXgpNzIgOTggUyhwZXJpZW5jZWQgYnkgYSByZWNlaSkuMTY1IEUgLS4x NjUodmUpLS4yNzUgRwoyLjc1KHJcKCkuMTY1IEcoaW4gdGVybXMgb2YgcXVhbGl0eSBvZiBw bGF5b3V0LCBvciBvKS0yLjc1IEUgLS4xNjUodmUpCi0uMTY1IEcocmFsbCB0cmFuc2ZlciBz cGVlZFwpIGlzIHByb3BvcnRpb25hbCkuMTY1IEUodG8gaG8pNzIgMTExIFEgMi43NQood20p LS4yNzUgRyhhbiktMi43NSBFIDIuNzUoeW8pLS4xNjUgRyAyLjc1KGZ0KS0yLjc1IEcKKGhl IGxheWVycyB0aGUgcmVjZWkpLTIuNzUgRSAtLjE2NSh2ZSktLjI3NSBHIDIuNzUocmkpLjE2 NSBHIDIuNzUoc2opCi0yLjc1IEcob2luZWQgdG8uKS0yLjc1IEUoTENUIE1BKTUuNSBFIDIu NzUoWWIpLTEuMTU1IEcgMi43NShlYyktMi43NSBHCihvbWJpbmVkIHdpdGggYSByZWxpYWJp bGl0eSktMi43NSBFKHByb3RvY29sIHN1Y2ggYXMgdGhlIGdlbmVyYWwgY2xhc3MgXApvZiBw cm90b2NvbHMgZGVzY3JpYmVkIGluIFs3XS4gTENUIE1VU1QgYmUgY29tYmluZWQgd2l0aCBh KTcyIDEyNCBRKGNvblwKZ2VzdGlvbiBjb250cm9sIHByb3RvY29sIHRoYXQgaXMgY29tcGxp YW50IHdpdGggUkZDMjM1NywgYW5kIHRoaXMgTUEpNzIKMTM3IFEgMi43NShZYiktMS4xNTUg RyAyLjc1KGVlKS0yLjc1IEcoaXRoZXIgc2luZ2xlLXJhdGUpLTIuNzUgRQoob3IgbXVsdGkt cmF0ZSBjb25nZXN0aW9uIGNvbnRyb2wgbyk3MiAxNTAgUSAtLjE2NSh2ZSktLjE2NSBHIDIu NzUocnQpCi4xNjUgRyhoZSBlbnRpcmUgc2Vzc2lvbi4pLTIuNzUgRShJdCBpcyBtb3N0IGNv bXBlbGxpbmcgdG8gdXNlIExDVCBpbikKNS41IEUoY29uanVuY3Rpb24gd2l0aCBhIGxheWVy ZWQgY29uZ2VzdGlvbiBjb250cm9sIHByb3RvY29sIHN1Y2ggYXMgdGhcCmUgY2xhc3Mgb2Yg cHJvdG9jb2xzIGRlc2NyaWJlZCBpbik3MiAxNjMgUShbOV0sIGFuZCBzcGVjaVwyMTRlZCBp biBbOV0sXAogd2hpY2ggYXJlIG11bHRpLXJhdGUgY29uZ2VzdGlvbiBjb250cm9sIHByb3Rv Y29scy4pNzIgMTc2IFEKKFRoZSBjb25jZXB0IG9mIGxheWVyZWQgY29kaW5nIHcpNzIgMjAy IFEKKGFzIFwyMTRyc3QgaW50cm9kdWNlZCB3aXRoIHJlZmVyZW5jZSB0byBhdWRpbyBhbmQg dmlkZW8gc3RyZWFtcy4pLS4xMSBFCi0uMTY1KEZvKTcyIDIxNSBTIDIuNzUocmUpLjE2NSBH KHhhbXBsZSwgdGhlIGluZm9ybWF0aW9uIGFzc29jaWF0ZWQgd2l0XApoIGEgVFYgYnJvYWRj YXN0IGNhbiBiZSBwYXJ0aXRpb25lZCBpbnRvIHRocmVlIGxheWVycywpLTIuOTE1IEUKKGNv cnJlc3BvbmRpbmcgdG8gYmxhY2sgYW5kIHdoaXRlLCBjb2xvcik3MiAyMjggUSAyLjc1KCxh KS0uNDQgRwoobmQgSERUViBxdWFsaXR5KS0yLjc1IEUgMi43NSguUiktLjcxNSBHKGVjZWkp LTIuNzUgRSAtLjE2NSh2ZSktLjI3NSBHCihycyBjYW4gZSkuMTY1IEUoeHBlcmllbmNlIGRp ZiktLjE2NSBFKGZlcmVudCktLjI3NSBFKHF1YWxpdHkgd2l0aG91dCB0XApoZSBuZWVkIGZv ciB0aGUgc2VuZGVyIHRvIHJlcGxpY2F0ZSBpbmZvcm1hdGlvbiBpbiB0aGUgZGlmKTcyIDI0 MSBRCihmZXJlbnQgbGF5ZXJzLiktLjI3NSBFCihUaGUgY29uY2VwdCBvZiBsYXllcmVkIGNv ZGluZyBjYW4gYmUgbmF0dXJhbGx5IGUpNzIgMjY3IFEKKHh0ZW5kZWQgdG8gcmVsaWFibGUg Y29udGVudCBkZWxpKS0uMTY1IEUgLS4xNjUodmUpLS4yNzUgRyhyeSBwcm90b2NvbHMpCi4x NjUgRSh3aGVuIEYpNzIgMjgwIFEob3J3KS0uMTY1IEUoYXJkIEVycm9yIENvcnJlY3Rpb24g XChGRUNcKSB0ZWNobmlxXAp1ZXMgYXJlIHVzZWQgZm9yIGNvZGluZyB0aGUgZGF0YSBzdHJl YW0gWzEyXSBbMTBdKS0uMTEgRShbM10gWzE0XSBbMTVdIFwKWzFdLiBCeSB1c2luZyBGRUMs IHRoZSBkYXRhIHN0cmVhbSBpcyB0cmFuc2Zvcm1lZCBpbiBzdWNoIGEgdyk3MiAyOTMgUQoo YXkgdGhhdCByZWNvbnN0cnVjdGlvbiktLjExIEUob2YgYSBkYXRhIG9iamVjdCBkb2VzIG5v dCBkZXBlbmQgb24gdGhlIFwKcmVjZXB0aW9uIG9mIHNwZWNpXDIxNGMgZGF0YSBwYWNrKTcy IDMwNiBRKGV0cywgYiktLjExIEUKKHV0IG9ubHkgb24gdGhlIG51bWJlciktLjIyIEUob2Yg ZGlmKTcyIDMxOSBRKGZlcmVudCBwYWNrKS0uMjc1IEUKKGV0cyByZWNlaSktLjExIEUgLS4x NjUodmUpLS4yNzUgRyAyLjc1KGQuIEFzKS4xNjUgRiAyLjc1KGFyKTIuNzUgRwooZXN1bHQs IGJ5IGluY3JlYXNpbmcgdGhlIG51bWJlciBvZiBsYXllcnMgYSByZWNlaSktMi43NSBFIC0u MTY1KHZlKQotLjI3NSBHIDIuNzUocmkpLjE2NSBHKHMpLTIuNzUgRShyZWNlaSk3MiAzMzIg USh2aW5nIGZyb20sIHRoZSByZWNlaSkKLS4yNzUgRSAtLjE2NSh2ZSktLjI3NSBHIDIuNzUo cmMpLjE2NSBHCihhbiByZWR1Y2UgdGhlIHRyYW5zZmVyIHRpbWUgYWNjb3JkaW5nbHkpLTIu NzUgRSA1LjUoLk0pLS43MTUgRwoob3JlIGRldGFpbHMgb24gdGhlIHVzZSBvZiktNS41IEUo RkVDIGZvciByZWxpYWJsZSBjb250ZW50IGRlbGkpNzIgMzQ1IFEKLS4xNjUodmUpLS4yNzUg RyhyeSBjYW4gYmUgZm91bmQgaW4gWzZdLikuMTY1IEUKKFJlbGlhYmxlIHByb3RvY29scyBh aW0gYXQgZ2kpNS41IEUodmluZyBndWFyYW50ZWVzKS0uMjc1IEUKKG9uIHRoZSByZWxpYWJs ZSBkZWxpKTcyIDM1OCBRIC0uMTY1KHZlKS0uMjc1IEcKKHJ5IG9mIGRhdGEgZnJvbSB0aGUg c2VuZGVyIHRvIHRoZSBpbnRlbmRlZCByZWNpcGllbnRzLikuMTY1IEUKKEd1YXJhbnRlZXMg dik1LjUgRShhcnkgZnJvbSktLjI3NSBFKHNpbXBsZSBwYWNrKTcyIDM3MSBRKGV0IGRhdGEg aW50ZSkKLS4xMSBFKGdyaXR5IHRvIHJlbGlhYmxlIGRlbGkpLS4xNjUgRSAtLjE2NSh2ZSkt LjI3NSBHCihyeSBvZiBhIHByZWNpc2UgY29wKS4xNjUgRSAyLjc1KHlvKS0uMTEgRyAyLjc1 KGZhZCktMi43NSBHCihhdGEgb2JqZWN0IHRvIGFsbCBpbnRlbmRlZCktMi43NSBFIDIuNzUo cmVjaXBpZW50cy4gU2UpNzIgMzg0IFIgLS4xNjUKKHZlKS0uMjc1IEcocmFsIHJlbGlhYmxl IGNvbnRlbnQgZGVsaSkuMTY1IEUgLS4xNjUodmUpLS4yNzUgRwoocnkgcHJvdG9jb2xzIGhh KS4xNjUgRSAuMzMgLS4xNjUodmUgYiktLjIyIEgoZWVuIGIpLjE2NSBFCih1aWx0IG9uIHRv cCBvZiBJUCBtdWx0aWNhc3QsIGIpLS4yMiBFKHV0KS0uMjIgRShzY2FsYWJpbGl0eSB3KTcy IDM5NyBRCihhcyBub3QgYSBkZXNpZ24gZ29hbCBmb3IgbWFuKS0uMTEgRSAyLjc1KHlvKS0u MTY1IEcgMi43NShmdCktMi43NSBHCjIuNzUoaGVtLiBJbiktMi43NSBGKHNvbWUgY2FzZXMs IHNjYWxhYmlsaXR5IGlzIGFjaGllKTIuNzUgRSAtLjE2NSh2ZSkKLS4yNzUgRyAyLjc1KGRi KS4xNjUgRyh5KS0yLjc1IEUKKGludHJvZHVjaW5nIGNoYW5nZXMgdG8gcm91dGVycyBvciBv dGhlciBpbmZyYXN0cnVjdHVyZSBcKHNlZSBmb3IgZSk3Mgo0MTAgUSh4YW1wbGUgWzEzXSBc KSwgYW4gYXBwcm9hY2ggd2hpY2gpLS4xNjUgRQooaGFzIGFuIGltcGFjdCBvbiBuZWFyIHRl cm0gZGVwbG8pNzIgNDIzIFEoeW1lbnQgYWNyb3NzIHRoZSBJbnRlcm5ldC4pCi0uMTEgRSAt MS4xIC0uODgoVHcgbyk3MiA0NDkgVChvZiB0aGUgaykzLjYzIEUgLjMzIC0uMTY1KGV5IGQp LS4xMSBIKGlmKQouMTY1IEUoXDIxNGN1bHRpZXMgaW4gc2NhbGluZyByZWxpYWJsZSBjb250 ZW50IGRlbGkpLS4yNzUgRSAtLjE2NSh2ZSkKLS4yNzUgRyhyeSB1c2luZyBJUCBtdWx0aWNh c3QgYXJlIGRlYWxpbmcgd2l0aCkuMTY1IEUKKHRoZSBhbW91bnQgb2YgZGF0YSB0aGF0IFwy MTVvKTcyIDQ2MiBRKHdzIGZyb20gcmVjZWkpLS4yNzUgRSAtLjE2NSh2ZSkKLS4yNzUgRyhy cyBiYWNrIHRvIHRoZSBzZW5kZXIpLjE2NSBFIDIuNzUoLGEpLS40NCBHCihuZCB0aGUgYXNz b2NpYXRlZCByZXNwb25zZSktMi43NSBFCihcKGdlbmVyYWxseSBkYXRhIHJldHJhbnNtaXNz aW9uc1wpIGZyb20gdGhlIHNlbmRlcik3MiA0NzUgUSA1LjUoLlApCi0uNjA1IEcocm90b2Nv bHMgdGhhdCBhKS01LjUgRSAtLjIyKHZvKS0uMjIgRyhpZCBhbikuMjIgRSAyLjc1KHlzKS0u MTY1CkcodWNoIGZlZWRiYWNrLCBhbmQpLTIuNzUgRQoobWluaW1pemUgdGhlIGFtb3VudCBv ZiByZXRyYW5zbWlzc2lvbnMsIGNhbiBiZSBtYXNzaSk3MiA0ODggUSAtLjE2NSh2ZSkKLS4y NzUgRyhseSBzY2FsYWJsZS4pLjE2NSBFKExDVCByZWxpZXMgb24gdGhlKTUuNSBFIC0uMjIo YXYpNzIgNTAxIFMKKGFpbGFiaWxpdHkgb2YgRkVDIGNvZGVzIG9yIGEgbGF5ZXJlZCBjb2Rl YyB0byBhY2hpZSktLjA1NSBFIC4zMyAtLjE2NQoodmUgciktLjI3NSBIKGVsaWFiaWxpdHkg d2l0aCBsaXR0bGUgb3Igbm8gZmVlZGJhY2suKS4xNjUgRQooSW4gdGhpcyBkb2N1bWVudCB3 ZSBwcmVzZW50IHRoZSBhcmNoaXRlY3R1cmUgYW5kIGFic3RyYWN0IExDVCBwYWNrKTcyCjUy NyBRKGV0IHN0cnVjdHVyZSwgYW5kIGlsbHVzdHJhdGUgaXRzKS0uMTEgRQooc3VwcG9ydCBm b3IgbXVsdGktcmF0ZSBsYXllcmVkIGNvbmdlc3Rpb24gY29udHJvbC4pNzIgNTQwIFEoVGhl IGspNzIKNTY2IFEgLjMzIC0uMTY1KGV5IHcpLS4xMSBIKG9yZHMgIk1VU1QiLCAiTVVTVCBO TykuMDU1IEUoVCIsICJSRVEpLS40NCBFCihVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOTykt LjExIEUoVCIsKS0uNDQgRSgiU0hPVUxEIiwgIlNIT1VMRCBOTyk3Mgo1NzkgUShUIiwgIlJF Q09NTUVOREVEIiwgIk1BKS0uNDQgRShZIiwgYW5kICJPUFRJT04pLTEuMTU1IEUKKEFMIiBp biB0aGlzKS0uMzg1IEUKKGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNj cmliZWQgaW4gUkZDMjExOS4pNzIgNTkyIFEvRjEgMTEKL1RpbWVzLUJvbGRAMCBTRigxLjEu KTcyIDYzMSBRL0YyIDEzL1RpbWVzLUJvbGRAMCBTRihSZWxhdGVkIERvY3VtZW50cykKNS41 IEUgRjAgMi43NShBbSk3MiA2NDcuNiBTCihvcmUgaW4tZGVwdGggZGVzY3JpcHRpb24gb2Yg dGhlIHVzZSBvZiBGRUMgaW4gUmVsaWFibGUgTXVsdGljYXN0IFQpCi0yLjc1IEUocmFuc3Bv cnQgXChSTVRcKSBwcm90b2NvbHMpLS4zODUgRShpcyBnaSk3MiA2NjAuNiBRIC0uMTY1KHZl KQotLjI3NSBHIDIuNzUobmkpLjE2NSBHIDIuNzUoblspLTIuNzUgRwooNl0uIFNvbWUgb2Yg dGhlIEZFQyBjb2RlY3MgdGhhdCBNQSktMi43NSBFIDIuNzUoWWIpLTEuMTU1IEcgMi43NShl dSkKLTIuNzUgRyhzZWQgYnkgTENUIGZvciByZWxpYWJsZSBjb250ZW50IGRlbGkpLTIuNzUg RSAtLjE2NSh2ZSktLjI3NSBHCihyeSkuMTY1IEUoYXJlIHNwZWNpXDIxNGVkIGluIFs3XS4g TENUIHJlc2Vydik3MiA2NzMuNiBRCihlcyBvcGFxdWUgaGVhZGVyIFwyMTRlbGRzIHRoYXQg Y2FuIGJlIHVzZWQgdG8gdHJhbnNwb3J0IGluZm9ybWF0aW9uKQotLjE2NSBFKHJlbGF0ZWQg dG8gdGhlIHBheWxvYWQgZW5jb2RpbmcuKTcyIDY4Ni42IFEoSW1wbGVtZW50b3JzIG9mIExD VFwKIE1VU1QgYWxzbyBpbXBsZW1lbnQgY29uZ2VzdGlvbiBjb250cm9sIGluIGFjY29yZGFu Y2UgdG8gUkZDMjM1NywpNzIKNzEyLjYgUSh3aGVyZSB0aGUgY29uZ2VzdGlvbiBjb250cm9s IGlzIG8pNzIgNzI1LjYgUSAtLjE2NSh2ZSktLjE2NSBHCjIuNzUocnQpLjE2NSBHKGhlIGVu dGlyZSBzZXNzaW9uLiktMi43NSBFCihTb21lIHBvc3NpYmxlIHNjaGVtZXMgYXJlIHNwZWNp XDIxNGVkIGluKTUuNSBFKEx1YnkvR2VtbWVsbC9WKTcyIDc2OSBRCihpY2lzYW5vL1Jpenpv L0hhbmRsZSktLjY2IEUoeS9Dcm8pLS4xNjUgRSAxMDkuMTA2KHdjcm9mdCBTZWN0aW9uKS0u Mjc1CkYgMi43NSgxLjEuIFtQKTIuNzUgRihhZ2UgNF0pLS4xNjUgRSBFUAolJVBhZ2U6IDUg NQolJUJlZ2luUGFnZVNldHVwCkJQCiUlRW5kUGFnZVNldHVwCi9GMCAxMS9UaW1lcy1Sb21h bkAwIFNGKElOVEVSTkVUKTcyIDQ5IFEgNzEuNTg3KC1EUkFGVCBFeHBpcmVzOiktMS4wMTIg RgooSmFudWFyeSAyMDAyKTIuNzUgRShKdWx5IDIwMDEpMTIzLjcyNiBFKFs5XS4gTENUIHJl c2Vydik3MiA4NSBRKGVzIG9wYVwKcXVlIGhlYWRlciBcMjE0ZWxkcyB0aGF0IGNhbiBiZSB1 c2VkIGJ5IHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgc2NoZW1lIHRcCm8pLS4xNjUgRSh0cmFu c3BvcnQgaW5mb3JtYXRpb24gcmVsYXRlZCB0byBjb25nZXN0aW9uIGNvbnRyb2wuKTcyIDk4 IFEoXApJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IExDVCBpbXBsZW1lbnRvcnMgdXNlIHNvbWUg YXV0aGVudGljYXRpb24gc2NoZW1lIFwKdG8gcHJvdGVjdCB0aGUpNzIgMTI0IFEocHJvdG9j b2wgZnJvbSBhdHRhY2tzLiBBbiBlKTcyIDEzNyBRCih4YW1wbGUgb2YgYSBwb3NzaWJseSBz dWl0YWJsZSBzY2hlbWUgaXMgZGVzY3JpYmVkIGluIFsxMV0uKS0uMTY1IEUvRjEKMTEvVGlt ZXMtQm9sZEAwIFNGKDEuMi4pNzIgMTYzIFEvRjIgMTMvVGltZXMtQm9sZEAwIFNGKEVuKTUu NSBFKHZpciktLjUyCkUob25tZW50YWwgUmVxdWlyKS0uMjM0IEUoZW1lbnRzIGFuZCBDb25z aWRlcmF0aW9ucyktLjIzNCBFIEYwCihMQ1QgaXMgaW50ZW5kZWQgZm9yIGNvbmdlc3Rpb24g Y29udHJvbGxlZCwgbXVsdGktcmF0ZSBkZWxpKTcyIDE3OS42IFEKLS4xNjUodmUpLS4yNzUg RyhyeSBvZiBvYmplY3RzIGFuZCBzdHJlYW1zIFwoYm90aCkuMTY1IEUKKHJlbGlhYmxlIGNv bnRlbnQgZGVsaSk3MiAxOTIuNiBRIC0uMTY1KHZlKS0uMjc1IEcKKHJ5IGFuZCBzdHJlYW1p bmcgb2YgbXVsdGltZWRpYSBpbmZvcm1hdGlvblwpLikuMTY1IEUKKExDVCBpcyBtb3N0IGFw cGxpY2FibGUgZm9yIGRlbGkpNzIgMjE4LjYgUSAtLjE2NSh2ZSktLjI3NSBHCihyeSBvZiBv YmplY3RzIG9yIHN0cmVhbXMgb2Ygc3Vic3RhbnRpYWwgbGVuZ3RoLCBpLmUuLCBvYmplY3Rz IG9yKS4xNjUgRQooc3RyZWFtcyB0aGF0IHJhbmdlIGluIGxlbmd0aCBmcm9tIGh1bmRyZWRz IG9mIGtpbG9ieXRlcyB0byBtYW4pNzIgMjMxLjYKUSAyLjc1KHlnKS0uMTY1IEcoaWcpLTIu NzUgRShhYnl0ZXMsIGFuZCB3aG9zZSB0cmFuc2ZlciktLjA1NSBFCih0aW1lIGlzIGluIHRo ZSBvcmRlciBvZiB0ZW5zIG9mIHNlY29uZHMgb3IgbW9yZS4pNzIgMjQ0LjYgUQooTENUIGlz IGRpcmVjdGx5IGFwcGxpY2FibGUgdG8gYWxsIG11bHRpY2FzdCBlbmFibGVkIG5ldHcpNzIg MjcwLjYgUQoob3JrcywgaW5jbHVkaW5nIGFzeW1tZXRyaWMgbmV0dyktLjExIEUob3Jrcywp LS4xMSBFKHdpcmVsZXNzIG5ldHcpNzIKMjgzLjYgUShvcmtzLCBhbmQgc2F0ZWxsaXRlIG5l dHcpLS4xMSBFIDIuNzUob3Jrcy4gVGh1cywpLS4xMSBGCih0aGUgaW5oZXJlbnQgcmEpMi43 NSBFIDIuNzUod3MpLS4xNjUgRyhjYWxhYmlsaXR5IG9mIExDVCBpcyB1bmxpbWl0ZWQuKQot Mi43NSBFKEhvKTcyIDI5Ni42IFEod2UpLS4yNzUgRSAtLjE2NSh2ZSktLjI3NSBHIC44OCAt LjQ0KHIsIHcpLjE2NSBICihoZW4gb3RoZXIgc3BlY2lcMjE0YyBhcHBsaWNhdGlvbnMgYXJl IGIpLjQ0IEUodWlsdCBvbiB0b3Agb2YgTENUKS0uMjIgRQoyLjc1KCx0KS0uODE0IEcoaGVu IHRoZXNlIGFwcGxpY2F0aW9ucyBieSktMi43NSBFKHRoZWlyIHYpNzIgMzA5LjYgUQooZXJ5 IG5hdHVyZSBtYXkgbGltaXQgc2NhbGFiaWxpdHkpLS4xNjUgRSA1LjUoLkYpLS43MTUgRyhv ciBlKS01LjY2NSBFCih4YW1wbGUsIGlmIGFuIGFwcGxpY2F0aW9uIHJlcXVpcmVzIHJlY2Vp KS0uMTY1IEUgLS4xNjUodmUpLS4yNzUgRwoocnMgdG8pLjE2NSBFKHJldHJpZSk3MiAzMjIu NiBRIC4zMyAtLjE2NSh2ZSBvKS0uMjc1IEgodXQgb2YgYmFuZCBpbmZvclwKbWF0aW9uIGlu IG9yZGVyIHRvIGpvaW4gYSBzZXNzaW9uLCBvciBhbiBhcHBsaWNhdGlvbiBhbGxvKS4xNjUg RQood3MgcmVjZWkpLS4yNzUgRSAtLjE2NSh2ZSktLjI3NSBHKHJzIHRvKS4xNjUgRQooc2Vu ZCByZXF1ZXN0cyBiYWNrIHRvIHRoZSBzZW5kZXIgaW4gb3JkZXIgdG8gZSk3MiAzMzUuNiBR Cih4dGVuZCBhbiBvbmdvaW5nIHNlc3Npb24sIHRoZW4gdGhlIHNjYWxhYmlsaXR5IG9mIHRo ZSktLjE2NSBFCihhcHBsaWNhdGlvbiBpcyBsaW1pdGVkIGJ5IHRoZSBhYmlsaXR5IHRvIHNl bmQsIHJlY2VpKTcyIDM0OC42IFEgLS4xNjUKKHZlKS0uMjc1IEcgMi43NSgsYSkuMTY1IEco bmQgcHJvY2VzcyB0aGlzIGFkZGl0aW9uYWwgZGF0YS4pLTIuNzUgRQooTENUIHJlcXVpcmVz IHRoYXQgdGhlIHVuZGVybHlpbmcgbmV0dyk3MiAzNzQuNiBRCihvcmsgb3IgdHJhbnNwb3J0 IGxheWVyIGNhbiBkZWxpKS0uMTEgRSAtLjE2NSh2ZSktLjI3NSBHIDIuNzUocmEpLjE2NSBH CihuZCBkZW11bHRpcGxlKS0yLjc1IEUgMi43NSh4TCktLjE2NSBHKENUKS0yLjc1IEUocGFj ayk3MiAzODcuNiBRCihldHMgZm9yIGEgZ2kpLS4xMSBFIC0uMTY1KHZlKS0uMjc1IEcgMi43 NShuTCkuMTY1IEcKKENUIHNlc3Npb24sIGFuZCBzdXBwbHkgcGFjayktMi43NSBFCihldCBs ZW5ndGggaW5mb3JtYXRpb24gdG8gdGhlIExDVCByZWNlaSktLjExIEUgLS4xNjUodmUpLS4y NzUgRyAxLjIxCi0uNjA1KHIuIEkpLjE2NSBIIDIuNzUobkkpLjYwNSBHKFApLTIuNzUgRShu ZXR3KTcyIDQwMC42IFEKKG9ya3MsIHRoaXMgaXMgb2Z0ZW4gYWNoaWUpLS4xMSBFIC0uMTY1 KHZlKS0uMjc1IEcgMi43NShkYikuMTY1IEcgMi43NQooeXUpLTIuNzUgRyhzaW5nIFVEUCkt Mi43NSBFIDIuNzUoLG8pLTEuMjIxIEcgMi43NShyYSktMi43NSBHIC4zMyAtLjE2NQoobnkg cCktMi43NSBIKHJvdG9jb2wgdGhhdCBjYW4gcHJvKS4xNjUgRSh2aWRlIGFuIGVxdWkpLS4x NjUgRSAtLjI3NSh2YSkKLS4yNzUgRyhsZW50KS4yNzUgRShzZXJ2aWNlLCBhcyB0aGUgdW5k ZXJseWluZyB0cmFuc3BvcnQgcHJvdG9jb2wuKTcyCjQxMy42IFEoSW4gdGhpcyBkb2N1bWVu dCwgd2UgcmVmZXIgdG8gdGhlIG9yaWdpbmFsIG11bHRpY2FzdCBzZXJ2aWNlIG1vXApkZWwg ZGVcMjE0bmVkIGluIFJGQzExMTIgYXMgQW4pNzIgNDM5LjYgUSh5LSktLjE2NSBFCihTb3Vy Y2UgTXVsdGljYXN0LCBvciBBU00gZm9yIHNob3J0Lik3MiA0NTIuNiBRIDEuNzYgLS44OChX ZSByKTUuNSBICihlZmVyIHRvIHRoZSBtdWx0aWNhc3Qgc2VydmljZSBtb2RlbCBkZVwyMTRu ZWQgaW4gWzVdIGFzKS44OCBFCihTb3VyY2UtU3BlY2lcMjE0YyBNdWx0aWNhc3QsIG9yIFNT TSBmb3Igc2hvcnQuKTcyIDQ2NS42IFEKKExDVCBkb2VzIG5vdCByZXF1aXJlIHJlKTUuNSBF IC0uMTY1KHZlKS0uMjc1IEcocnNlIG11bHRpY2FzdCkuMTY1IEUKKGNvbm5lY3RpKTcyIDQ3 OC42IFEodml0eSktLjI3NSBFIDIuNzUoLGkpLS43MTUgRyguZS4gTENUIHJlY2VpKS0yLjc1 IEUKLS4xNjUodmUpLS4yNzUgRyhycyBkbyBub3Qgc2VuZCBtdWx0aWNhc3QgdHJhZikuMTY1 IEUgMi43NShcMjE0Yy4gQXMpCi0uMjc1IEYoc3VjaCwgTENUIHcpMi43NSBFKG9ya3Mgd2l0 aCBib3RoKS0uMTEgRShBU00gYW5kIFNTTS4pNzIgNDkxLjYgUQooVGhlIGRlXDIxNG5pdGlv biBvZiBhbiBMQ1QgY2hhbm5lbCB1c2VkIHRocm91Z2hvdXQgdGhpcyBkb2N1bWVudCBpcyBz bFwKaWdodGx5IGRpZik3MiA1MTcuNiBRKGZlcmVudCB3aXRoIEFTTSktLjI3NSBFKGFuZCB3 aXRoIFNTTS4pNzIgNTMwLjYgUQooV2hlbiB1c2luZyBBU00sIGEgc2VuZGVyIFMgc2VuZHMg TENUIHBhY2spNS41IEUKKGV0cyB0byBhIG11bHRpY2FzdCBncm91cCBHLCBhbmQgdGhlKS0u MTEgRShMQ1QgY2hhbm5lbCBhZGRyZXNzIGNvbnNpc3RcCnMgb2YgdGhlIHBhaXIgXChTLEdc KSwgd2hlcmUgUyBpcyB0aGUgSVAgYWRkcmVzcyBvZiB0aGUgc2VuZGVyIGFuZCBHIGlzXAog YSk3MiA1NDMuNiBRKG11bHRpY2FzdCBncm91cCBhZGRyZXNzLik3MiA1NTYuNiBRCihXaGVu IHVzaW5nIFNTTSwgYSBzZW5kZXIgUyBzZW5kcyBMQ1QgcGFjayk1LjUgRShldHMgdG8gYW4g U1NNIGNoYW5uZWwpCi0uMTEgRShcKFMsR1wpLCBhbmQgdGhlIExDVCBjaGFubmVsIGFkZHJl c3MgY29pbmNpZGVzIHdpdGggdGhlIFNTTSBjaGFuXApuZWwgYWRkcmVzcy4pNzIgNTY5LjYg UShTU00gaXMgbW9yZSBhdHRyYWN0aSk3MiA1OTUuNiBRIC4zMyAtLjE2NSh2ZSB0KQotLjI3 NSBIIDIuNzUob2QpLjE2NSBHKGVwbG8pLTIuNzUgRSh5bWVudCBvZiBMQ1QgdGhhbiBBU00g Zm9yIHNlKS0uMTEgRQotLjE2NSh2ZSktLjI3NSBHKHJhbCByZWFzb25zLikuMTY1IEUoRmly c3QsIGEgc2VuZGVyIG1heSk1LjUgRQooYWxsb2NhdGUgYW5kIHVzZSBzZSk3MiA2MDguNiBR IC0uMTY1KHZlKS0uMjc1IEcKKHJhbCBMQ1QgY2hhbm5lbHMgaW4gYSBzZXNzaW9uLCBzZXNz aW9ucyBtYXkgY29tZSBhbmQgZ28gZHluYW1pY2FsbHkpCi4xNjUgRSAyLjc1KC5BKS0uNzE1 IEcKKHNlbmRlciBjYW4gbG9jYWxseSBhbGxvY2F0ZSB1bmlxdWUgU1NNIGNoYW5uZWwgYWRk cmVzc2VzLCBhbmQgdGhpcyBtYWspCjcyIDYyMS42IFEoZXMgYWxsb2NhdGlvbiBvZiBMQ1Qp LS4xMSBFKGNoYW5uZWwgYWRkcmVzc2VzIGVhc3kgd2l0aCBTU00uKQo3MiA2MzQuNiBRIDEu NzYgLS44OChUbyBhKTUuNSBICihsbG9jYXRlIExDVCBjaGFubmVsIGFkZHJlc3NlcyB1c2lu ZyBBU00sIHRoZSBzZW5kZXIpLjg4IEUobXVzdCB1bmlxdWVsXAp5IGNob3NlIHRoZSBBU00g bXVsdGljYXN0IGdyb3VwIGFkZHJlc3MgYWNyb3NzIHRoZSBzY29wZSBvZiB0aGUgZ3JvdXAs IFwKYW5kIHRoaXMpNzIgNjQ3LjYgUShtYWspNzIgNjYwLjYgUQooZXMgYWxsb2NhdGlvbiBv ZiBMQ1QgY2hhbm5lbCBhZGRyZXNzZXMgbW9yZSBkaWYpLS4xMSBFCihcMjE0Y3VsdCB3aXRo IEFTTS4pLS4yNzUgRShJbiBnZW5lcmFsIFNTTSBwZXJmb3JtcyB3ZWxsIGUpNzIgNjg2LjYg UQotLjE2NSh2ZSktLjI3NSBHIDIuNzUobmkpLjE2NSBHIDIuNzUobnApLTIuNzUgRyhyZXNl bmNlIG9mIHYpLTIuNzUgRQooZXJ5IGxhciktLjE2NSBFKGdlIGFuZCBkeW5hbWljYWxseSBj aGFuZ2luZyByZWNlaSktLjE5OCBFIC0uMTY1KHZlKQotLjI3NSBHKHIpLjE2NSBFIDIuNzUo c2V0cy4gQ2hhbmdlcyk3MiA2OTkuNiBSKGluIHRoZSBtdWx0aWNhc3QgdHJlZSB0b1wKcG9s b2d5IHdpdGggU1NNIGFyZSBsaWdodCB3ZWlnaHQgb3BlcmF0aW9ucyBcKGEgbmUpMi43NSBF IDIuNzUod2IpLS4yNzUKRyhyYW5jaCktMi43NSBFKGZyb20gdGhlIHJlY2VpKTcyIDcxMi42 IFEgLS4xNjUodmUpLS4yNzUgRyAyLjc1KHJ0KS4xNjUKRyAtMi4zMSAtLjI3NShvdyBhKS0y Ljc1IEgocmRzIFMgZ3JvKS4yNzUgRSh3cyB3aGVuIGEgcmVjZWkpLS4yNzUgRQotLjE2NSh2 ZSktLjI3NSBHIDIuNzUocmopLjE2NSBHCihvaW5zLCBhbmQgdGhlIGJyYW5jaCBpcyBkZWxl dGVkIHdoZW4gdGhlKS0yLjc1IEUocmVjZWkpNzIgNzI1LjYgUSAtLjE2NQoodmUpLS4yNzUg RyAyLjc1KHJsKS4xNjUgRyhlYSktMi43NSBFIC0uMTY1KHZlKS0uMjIgRwooc1wpLCB3aGVy ZWFzIHdpdGggQVNNIGNoYW5nZXMgY2FuIGJlIGhlYSkuMTY1IEUodmllciB3ZWlnaHQgXChp biktLjIyIEUKLS4yMih2byktLjQ0IEcobHZpbmcgdHJhbnNpdGlvbnMgZnJvbSBhKS4yMiBF KEx1YnkvR2VtbWVsbC9WKTcyIDc2OSBRCihpY2lzYW5vL1JpenpvL0hhbmRsZSktLjY2IEUo eS9Dcm8pLS4xNjUgRSAxMDkuMTA2KHdjcm9mdCBTZWN0aW9uKS0uMjc1CkYgMi43NSgxLjIu IFtQKTIuNzUgRihhZ2UgNV0pLS4xNjUgRSBFUAolJVBhZ2U6IDYgNgolJUJlZ2luUGFnZVNl dHVwCkJQCiUlRW5kUGFnZVNldHVwCi9GMCAxMS9UaW1lcy1Sb21hbkAwIFNGKElOVEVSTkVU KTcyIDQ5IFEgNzEuNTg3KC1EUkFGVCBFeHBpcmVzOiktMS4wMTIgRgooSmFudWFyeSAyMDAy KTIuNzUgRShKdWx5IDIwMDEpMTIzLjcyNiBFCihcKCosR1wpLXRyZWUgcm9vdGVkIGF0IGFu IFJQIHRvIHRoZSB0cmVlIHJvb3RlZCBhdCBTXCkuKTcyIDg1IFEKKFRoaXMgZWYpNS41IEUo XDIxNGNpZW5jKS0uMjc1IEUgMi43NSh5aSktLjE2NSBHIDIuNzUoc2kpLTIuNzUgRwoobXBv cnRhbnQgd2hlbiBhIGNvbmdlc3Rpb24pLTIuNzUgRQooY29udHJvbCBwcm90b2NvbCBpcyB1 c2VkIHdpdGggTENUIHRoYXQgcmVsaWVzIHVwb24gam9pbmluZyBhbmQgbGVhKTcyCjk4IFEo dmluZyBjaGFubmVscyB0byBuaW1ibHkpLS4yMiBFCihpbmNyZWFzZSBhbmQgZGVjcmVhc2Ug cmVjZXB0aW9uIHJhdGUuKTcyIDExMSBRCihMQ1QgY2hhbm5lbHMgYW5kIFNTTSBjaGFubmVs cyBjb2luY2lkZSwgYW5kIHRodXMgdGhlIHJlY2VpKTcyIDEzNyBRCi0uMTY1KHZlKS0uMjc1 IEcgMi43NShydykuMTY1IEcoaWxsIG9ubHkgcmVjZWkpLTIuNzUgRSAuMzMgLS4xNjUodmUg cCkKLS4yNzUgSChhY2spLjE2NSBFKGV0cyBzZW50IHRvKS0uMTEgRSh0aGUgcmVxdWVzdGVk IExDVCBjaGFubmVsLik3MiAxNTAKUSAtLjQ0KFdpKTUuNSBHKHRoIEFTTSwgdGhlIHJlY2Vp KS40NCBFIC0uMTY1KHZlKS0uMjc1IEcgMi43NShyaikuMTY1IEcKKG9pbnMgYW4gTENUIGNo YW5uZWwgYnkgam9pbmluZyBhIG11bHRpY2FzdCktMi43NSBFCihncm91cCBHLCBhbmQgYWxs IHBhY2spNzIgMTYzIFEoZXRzIHNlbnQgdG8gRywgcmUpLS4xMSBFIC0uMDU1KGdhKS0uMTY1 CkcocmRsZXNzIG9mIHRoZSBzZW5kZXIpLjA1NSBFIDIuNzUoLG0pLS40NCBHKGF5IGJlIHJl Y2VpKS0yLjc1IEUgLS4xNjUKKHZlKS0uMjc1IEcgMi43NShkYikuMTY1IEcgMi43NSh5dCkt Mi43NSBHKGhlIHJlY2VpKS0yLjc1IEUgLS4xNjUodmUpCi0uMjc1IEcgMy45NiAtLjYwNShy LiBJKS4xNjUgSChuKS42MDUgRShlaXRoZXIgY2FzZSwgcmVjZWkpNzIgMTc2IFEKLS4xNjUo dmUpLS4yNzUgRyhycyBzaG91bGQgdXNlIG1lY2hhbmlzbXMgdG8gXDIxNGx0ZXIgb3V0IHBh Y2spLjE2NSBFCihldHMgZnJvbSB1bncpLS4xMSBFKGFudGVkIHNvdXJjZXMuKS0uMTEgRShU aHVzLCk1LjUgRQooU1NNIGhhcyBjb21wZWxsaW5nIHNlY3VyaXR5IGFkdik3MiAxODkgUShh bnRhZ2VzIG8pLS4yNzUgRSAtLjE2NSh2ZSkKLS4xNjUgRyAyLjc1KHJBKS4xNjUgRyhTTSBm b3IgcHJlKS0yLjc1IEUgLS4xNjUodmUpLS4yNzUgRwoobnRpb24gb2YgZGVuaWFsIG9mIHNl cnZpY2UgYXR0YWNrcy4pLjE2NSBFKExDVCBhbHNvIHJlcXVpcmVzIHJlY2VpKTcyCjIxNSBR IC0uMTY1KHZlKS0uMjc1IEcocnMgdG8gb2J0YWluIFNlc3Npb24gRGVzY3JpcHRpb24gSW5m b3JtYXRpb24gYmVmXApvcmUgam9pbmluZyBhIHNlc3Npb24sIGFzKS4xNjUgRShkZXNjcmli ZWQgaW4gU2VjdGlvbiA0LjEuKTcyIDIyOCBRCihUaGUgc2Vzc2lvbiBkZXNjcmlwdGlvbiBj b3VsZCBiZSBpbiBhIGZvcm0gc3VjaCBhcyBTRFAgYXMgZGVcMjE0bmVkIGluKQo1LjUgRShS RkMyMzI3LCBvciBYTUwgbWV0YWRhdGEsIG9yIEhUVFAvTWltZSBoZWFkZXJzIGFzIGRlXDIx NG5lZCBpbiBSRlwKQzIwNjgsIGFuZCBkaXN0cmliKTcyIDI0MSBRKHV0ZWQpLS4yMiBFCih3 aXRoIFNBUCBbNF0sIHVzaW5nIFJDQ1AgWzhdLCBIVFRQKTcyIDI1NCBRIDIuNzUoLG8pLTEu MjIxIEcgMi43NShyaSkKLTIuNzUgRyAyLjc1KG5vKS0yLjc1IEcodGhlciB3KS0yLjc1IEUo YXlzLiktLjExIEUoVGhlIHBhcnRpY3VsYXIgbGF5ZXJcCmVkIGVuY29kZXIgYW5kIGNvbmdl c3Rpb24gY29udHJvbCBwcm90b2NvbHMgdXNlZCB3aXRoIExDVCBoYSk3MiAyODAgUQouMzMg LS4xNjUodmUgYSktLjIyIEggMi43NShuaSkuMTY1IEcobXBhY3QpLTIuNzUgRQoob24gdGhl IHBlcmZvcm1hbmNlIGFuZCBhcHBsaWNhYmlsaXR5IG9mIExDVCk3MiAyOTMgUSA1LjUoLkYp LS44MTQgRwoob3IgZSktNS42NjUgRSh4YW1wbGUsIHNvbWUgbGF5ZXJlZCBlbmNvZGVycyB1 c2VkIGZvciB2aWRlbyktLjE2NSBFCihhbmQgYXVkaW8gc3RyZWFtcyBjYW4gcHJvZHVjZSBh IHYpNzIgMzA2IFEKKGVyeSBsaW1pdGVkIG51bWJlciBvZiBzdWJzdHJlYW1zLCB0aHVzIHBy byktLjE2NSBFKHZpZGluZyBhIHYpLS4xNjUgRQooZXJ5IGNvYXJzZSktLjE2NSBFKGNvbnRy b2wgaW4gdGhlIHJlY2VwdGlvbiByYXRlIG9mIHBhY2spNzIgMzE5IFEKKGV0cyBieSByZWNl aSktLjExIEUgLS4xNjUodmUpLS4yNzUgRyhycyBpbiBhIHNlc3Npb24uKS4xNjUgRQooV2hl biBMQ1QgaXMgdXNlZCBmb3IgcmVsaWFibGUpNS41IEUoZGF0YSB0cmFuc2Zlcik3MiAzMzIg USAyLjc1KCxzKS0uNDQKRyhvbWUgRkVDIGNvZGVjcyBhcmUgaW5oZXJlbnRseSBsaW1pdGVk IGluIHRoZSBzaXplIG9mIHRoZSBvYmplY3QgdGhlKQotMi43NSBFIDIuNzUoeWMpLS4xNjUg RyhhbiBlbmNvZGUsKS0yLjc1IEUoYW5kIGZvciBvYmplY3RzIGxhcik3MiAzNDUgUQooZ2Vy IHRoYW4gdGhpcyBzaXplIHRoZSByZWNlcHRpb24gbyktLjE5OCBFIC0uMTY1KHZlKS0uMTY1 IEcKKHJoZWFkIG9uIHRoZSByZWNlaSkuMTY1IEUgLS4xNjUodmUpLS4yNzUgRyhycyBjYW4g Z3JvKS4xNjUgRSAyLjc1KHdzKQotLjI3NSBHKHVic3RhbnRpYWxseSktMi43NSBFKC4pLS43 MTUgRShBcyBhbm90aGVyIGUpNzIgMzcxIFEKKHhhbXBsZSwgc29tZSBuZXR3KS0uMTY1IEUK KG9ya3MgYXJlIG5vdCBhbWVuYWJsZSB0byBzb21lIGNvbmdlc3Rpb24gY29udHJvbCBwcm90 b2NvbHMgdGhhdCktLjExIEUKKGNvdWxkIGJlIHVzZWQgd2l0aCBMQ1QpNzIgMzg0IFEgNS41 KC5JKS0uODE0IEcgMi43NShucCktNS41IEcKKGFydGljdWxhciktMi43NSBFIDIuNzUoLGYp LS40NCBHKG9yIGEgc2F0ZWxsaXRlIG9yIHdpcmVsZXNzIG5ldHcpLTIuNzUKRShvcmssIHRo ZXJlIG1heSBiZSBubyktLjExIEUobWVjaGFuaXNtIGZvciByZWNlaSk3MiAzOTcgUSAtLjE2 NSh2ZSkKLS4yNzUgRyhycyB0byBlZikuMTY1IEUoZmVjdGkpLS4yNzUgRSAtLjE2NSh2ZSkt LjI3NSBHCihseSByZWR1Y2UgdGhlaXIgcmVjZXB0aW9uIHJhdGUgc2luY2UgdGhlcmUgbWF5 IGJlIGEgXDIxNHgpLjE2NSBFKGVkKQotLjE2NSBFKHRyYW5zbWlzc2lvbiByYXRlIGFsbG9j YXRlZCB0byB0aGUgc2Vzc2lvbi4pNzIgNDEwIFEvRjEgMTEKL1RpbWVzLUJvbGRAMCBTRigy Lik3MiA0NDkgUS9GMiAxNC9UaW1lcy1Cb2xkQDAgU0YoR2VuZXJhbCBBcik1LjUgRQooY2hp dGVjdHVyKS0uMjUyIEUoZSktLjI1MiBFIEYwKEFuIExDVCBzZXNzaW9uIGNvbXByaXNlcyBh bGwgTENUIHBhY2spNzIKNDY1LjYgUShldHMgc2VudCB0byBvbmUgb3IgbW9yZSBMQ1QgY2hh bm5lbHMgZnJvbSBhIHNpbmdsZSktLjExIEUKKHNlbmRlcik3MiA0NzguNiBRIDIuNzUoLGEp LS40NCBHKG5kIHBlcnRhaW5pbmcgdG8gdGhlIHRyYW5zbWlzc2lvbiBvZiBcCm9uZSBvciBt b3JlIG9iamVjdHMgdGhhdCBjYW4gYmUgb2YgaW50ZXJlc3QgZm9yIHRoZSktMi43NSBFKHJl Y2VpKTcyCjQ5MS42IFEgLS4xNjUodmUpLS4yNzUgRyhycy4pLjE2NSBFIC0uMTY1KEZvKTcy IDUxNy42IFMgMi43NShyZSkuMTY1IEcKKHhhbXBsZSwgYW4gTENUIHNlc3Npb24gY291bGQg YmUgdXNlZCB0byBkZWxpKS0yLjkxNSBFIC0uMTY1KHZlKS0uMjc1IEcKMi43NShyYVQpLjE2 NSBHIDIuNzUoVmMpLTIuNzUgRyhoYW5uZWwgdXNpbmcgdGhyZWUgY2hhbm5lbHMuKS0yLjc1 IEUKKFJlY2VpKTcyIDUzMC42IFEodmluZyB0aGUgXDIxNHJzdCBjaGFubmVsIGNvdWxkIGFs bG8pLS4yNzUgRSAyLjc1KHdiKQotLjI3NSBHKGxhY2sgYW5kIHdoaXRlIHJlY2VwdGlvbiwg cmVjZWkpLTIuNzUgRSh2aW5nIHRoZSBcMjE0cnN0IHR3KQotLjI3NSBFIDIuNzUob2MpLS4x MSBHKGhhbm5lbHMpLTIuNzUgRSAtLjExKHdvKTcyIDU0My42IFMKKHVsZCBwZXJtaXQgY29s b3IgcmVjZXB0aW9uLCB3aGVyZWFzIHJlY2VpKS4xMSBFCih2aW5nIHRoZSBzZXQgb2YgdGhy ZWUgY2hhbm5lbHMgZGVsaSktLjI3NSBFIC0uMTY1KHZlKS0uMjc1IEcKKHJzIEhEVFYgcXVh bGl0eSkuMTY1IEUgMi43NShpbWFnZXMuIE9iamVjdHMpNzIgNTU2LjYgUihpbiB0aGlzIGUp Mi43NSBFCih4YW1wbGUgY291bGQgY29ycmVzcG9uZCB0byBpbmRpKS0uMTY1IEUodmlkdWFs IHByb2dyYW1zIFwobW8pLS4yNzUgRQoodmllcywgbmUpLS4xNjUgRSh3cywpLS4yNzUgRShj b21tZXJjaWFsXCkgYmVpbmcgdHJhbnNtaXR0ZWQuKTcyIDU2OS42IFEKKEFzIGFub3RoZXIg ZSk3MiA1OTUuNiBRCih4YW1wbGUsIGEgcmVsaWFibGUgTENUIHNlc3Npb24gY291bGQgYmUg dXNlZCB0byByZWxpYWJseSBkZWxpKS0uMTY1IEUKLS4xNjUodmUpLS4yNzUgRyAyLjc1KHJo KS4xNjUgRyhvdXJseS11cGRhdGVkKS0yLjc1IEUKKHdlYXRoZXIgbWFwcyBcKG9iamVjdHNc KSB1c2luZyB0ZW4gTENUIGNoYW5uZWxzIGF0IGRpZik3MiA2MDguNiBRCihmZXJlbnQgcmF0 ZXMsIHVzaW5nIEZFQyBjb2RpbmcuKS0uMjc1IEUgMi43NShBcik1LjUgRyhlY2VpKS0yLjc1 IEUKLS4xNjUodmUpLS4yNzUgRyhyKS4xNjUgRShNQSk3MiA2MjEuNiBRIDIuNzUoWWopLTEu MTU1IEcKKG9pbiBhbmQgY29uY3VycmVudGx5IHJlY2VpKS0yLjc1IEUgLjMzIC0uMTY1KHZl IEwpLS4yNzUgSChDVCBwYWNrKS4xNjUKRShldHMgZnJvbSBzdWJzZXRzIG9mIHRoZXNlIGNo YW5uZWxzLCB1bnRpbCBpdCBoYXMpLS4xMSBFKGVub3VnaCBwYWNrKTcyCjYzNC42IFEoZXRz IGluIHRvdGFsIHRvIHJlY28pLS4xMSBFIC0uMTY1KHZlKS0uMTY1IEcgMi43NShydCkuMTY1 IEcKKGhlIG9iamVjdCwgdGhlbiBsZWEpLTIuNzUgRSAuMzMgLS4xNjUodmUgdCktLjIyIEgK KGhlIHNlc3Npb24gXChvciByZW1haW4gdGhlcmUgbGlzdGVuaW5nIHRvKS4xNjUgRQooY29u dHJvbCBpbmZvcm1hdGlvbiBvbmx5XCkgdW50aWwgaXQgaXMgdGltZSB0byByZWNlaSk3MiA2 NDcuNiBRIC4zMwotLjE2NSh2ZSB0KS0uMjc1IEgoaGUgbmUpLjE2NSBFKHh0IG9iamVjdC4p LS4xNjUgRQooSW4gdGhpcyBjYXNlLCB0aGUgcXVhbGl0eSBtZXRyaWMpNS41IEUoaXMgdGhl IHRpbWUgcmVxdWlyZWQgdG8gcmVjZWkpNzIKNjYwLjYgUSAuMzMgLS4xNjUodmUgZSktLjI3 NSBIKGFjaCBvYmplY3QuKS4xNjUgRQooQmVmb3JlIGpvaW5pbmcgYSBzZXNzaW9uLCB0aGUg cmVjZWkpNzIgNjg2LjYgUSAtLjE2NSh2ZSktLjI3NSBHCihycyBNVVNUIG9idGFpbiBhIHNl c3Npb24gZGVzY3JpcHRpb24sIHdoaWNoIE1VU1QgaW5jbHVkZSkuMTY1IEUKKHRoZSByZWxl KTcyIDY5OS42IFEgLS4yNzUodmEpLS4yNzUgRwoobnQgc2Vzc2lvbiBwYXJhbWV0ZXJzIG5l ZWRlZCBieSBhIHJlY2VpKS4yNzUgRSAtLjE2NSh2ZSktLjI3NSBHIDIuNzUKKHJ0KS4xNjUg RyAyLjc1KG9wKS0yLjc1IEcoYXJ0aWNpcGF0ZSBpbiB0aGUgc2Vzc2lvbi4pLTIuNzUgRQoo VGhlIHNlc3Npb24pNS41IEUoZGVzY3JpcHRpb24gaXMgZGV0ZXJtaW5lZCBhbmQgYWdyZWVk IHVwb24gYnkgdGhlIHNlblwKZGVycywgYW5kIHR5cGljYWxseSBjb21tdW5pY2F0ZWQgdG8g dGhlKTcyIDcxMi42IFEocmVjZWkpNzIgNzI1LjYgUQotLjE2NSh2ZSktLjI3NSBHCihycyBv dXQgb2YgYmFuZC4gSW4gc29tZSBjYXNlcywgcGFydCBvZiB0aGUgc2Vzc2lvbiBkZXNjcmlw dGlvbiBNQSkuMTY1CkUgMi43NShZYiktMS4xNTUgRyAyLjc1KGVpKS0yLjc1IEcobmNsdWRl ZCBpbiB0aGUgTENUKS0yLjc1IEUKKEx1YnkvR2VtbWVsbC9WKTcyIDc2OSBRKGljaXNhbm8v Uml6em8vSGFuZGxlKS0uNjYgRSh5L0NybyktLjE2NSBFCjExNy4zNTYod2Nyb2Z0IFNlY3Rp b24pLS4yNzUgRiAyLjc1KDIuIFtQKTIuNzUgRihhZ2UgNl0pLS4xNjUgRSBFUAolJVBhZ2U6 IDcgNwolJUJlZ2luUGFnZVNldHVwCkJQCiUlRW5kUGFnZVNldHVwCi9GMCAxMS9UaW1lcy1S b21hbkAwIFNGKElOVEVSTkVUKTcyIDQ5IFEgNzEuNTg3KC1EUkFGVCBFeHBpcmVzOiktMS4w MTIgRgooSmFudWFyeSAyMDAyKTIuNzUgRShKdWx5IDIwMDEpMTIzLjcyNiBFKHBhY2spNzIg ODUgUShldC4pLS4xMSBFCihBbiBlbmNvZGVyIE1BKTcyIDExMSBRIDIuNzUoWWIpLTEuMTU1 IEcgMi43NShldSktMi43NSBHCihzZWQgdG8gZ2VuZXJhdGUgdGhlIGRhdGEgdGhhdCBpcyBw bGFjZWQgaW4gdGhlIExDVCBwYWNrKS0yLjc1IEUKKGV0IHBheWxvYWQgaW4gb3JkZXIpLS4x MSBFKHRvIHBybyk3MiAxMjQgUSh2aWRlIHJlbGlhYmlsaXR5KS0uMTY1IEUgNS41CiguQSkt LjcxNSBHKHN1aXRhYmxlIGRlY29kZXIgaXMgdXNlZCB0byByZXByb2R1Y2UgdGhlIG9yaWdp bmFsIGluZm9ybWF0XAppb24gZnJvbSB0aGUpLTIuNzUgRSAyLjc1KHBheWxvYWQuIFRoZXJl KTcyIDEzNyBSKE1BKTIuNzUgRSAyLjc1KFliKQotMS4xNTUgRyAyLjc1KGVhciktMi43NSBH KGVsaWFiaWxpdHkgcGFjayktMi43NSBFKGV0IGhlYWRlciB0aGF0IGZvbGxvKQotLjExIEUo d3MgdGhlIExDVCBwYWNrKS0uMjc1IEUoZXQgaGVhZGVyIGlmIHN1Y2ggYW4pLS4xMSBFCihl bmNvZGVyIGFuZCBkZWNvZGVyIGlzIHVzZWQuKTcyIDE1MCBRKFRoZSByZWxpYWJpbGl0eSBw YWNrKTUuNSBFCihldCBoZWFkZXIgaGVscHMgdG8gZGVzY3JpYmUgdGhlIGVuY29kaW5nIGRh dGEpLS4xMSBFCihjYXJyaWVkIGluIHRoZSBwYXlsb2FkIG9mIHRoZSBwYWNrKTcyIDE2MyBR IDIuNzUoZXQuIFRoZSktLjExIEYKKGZvcm1hdCBvZiB0aGUgcmVsaWFiaWxpdHkgcGFjayky Ljc1IEUoZXQgaGVhZGVyIGRlcGVuZHMgb24gdGhlKS0uMTEgRQooY29kaW5nIHVzZWQsIGFu ZCB0aGlzIGlzIG5lKTcyIDE3NiBRKGdvdGlhdGVkIG91dC1vZi1iYW5kLiktLjE2NSBFCihB cyBhbiBlKTUuNSBFKHhhbXBsZSwgb25lIG9mIHRoZSBGRUMgcGFjayktLjE2NSBFKGV0IGhl YWRlcnMpLS4xMSBFCihkZXNjcmliZWQgaW4gWzddIGNvdWxkIGJlIHVzZWQuKTcyIDE4OSBR IC0uMTY1KEZvKTcyIDIxNSBTIDIuNzUockwpLjE2NQpHKENUKS0yLjc1IEUgMi43NSgsdykt LjgxNCBHCihoZW4gbGF5ZXJlZCBjb25nZXN0aW9uIGNvbnRyb2wgaXMgdXNlZCwgY29uZ2Vz dGlvbiBjb250cm9sIGlzIGFjaGllKQotMi43NSBFIC0uMTY1KHZlKS0uMjc1IEcgMi43NShk YikuMTY1IEcgMi43NSh5cyktMi43NSBHKGVuZGluZyktMi43NSBFCihMQ1QgcGFjayk3MiAy MjggUShldHMgYXNzb2NpYXRlZCB3aXRoIGEgZ2kpLS4xMSBFIC0uMTY1KHZlKS0uMjc1IEcg Mi43NQoobnMpLjE2NSBHKGVzc2lvbiB0byBzZSktMi43NSBFIC0uMTY1KHZlKS0uMjc1IEco cmFsIExDVCBjaGFubmVscy4pLjE2NQpFKEluZGkpNS41IEUodmlkdWFsIHJlY2VpKS0uMjc1 IEUgLS4xNjUodmUpLS4yNzUgRyhycykuMTY1IEUKKGR5bmFtaWNhbGx5IGpvaW4gb25lIG9y IG1vcmUgb2YgdGhlc2UgY2hhbm5lbHMsIGFjY29yZGluZyB0byB0aGUgbmV0dykKNzIgMjQx IFEob3JrIGNvbmdlc3Rpb24gYXMgc2VlbiBieSktLjExIEUodGhlIHJlY2VpKTcyIDI1NCBR IC0uMTY1KHZlKQotLjI3NSBHIDMuOTYgLS42MDUoci4gTCkuMTY1IEgoQ1QgcGFjaykuNjA1 IEUKKGV0IGhlYWRlcnMgaW5jbHVkZSBhbiBvcGFxdWUgXDIxNGVsZCB3aGljaCBNVVNUIGJl IHVzZWQgdG8gY29uKS0uMTEgRQotLjE2NSh2ZXkpLS40NCBHKGNvbmdlc3Rpb24gY29udHJv bCBpbmZvcm1hdGlvbiB0byB0aGUgcmVjZWkpNzIgMjY3IFEKLS4xNjUodmUpLS4yNzUgRyAy Ljc1KHJzLiBUaGUpLjE2NSBGCihhY3R1YWwgY29uZ2VzdGlvbiBjb250cm9sIHNjaGVtZSB0 byB1c2Ugd2l0aCkyLjc1IEUoTENUIGlzIG5lKTcyIDI4MCBRCihnb3RpYXRlZCBvdXQtb2Yt YmFuZC4pLS4xNjUgRShTb21lIGUpNS41IEUKKHhhbXBsZXMgb2YgY29uZ2VzdGlvbiBjb250 cm9sIHByb3RvY29scyB0aGF0IE1BKS0uMTY1IEUgMi43NShZYiktMS4xNTUKRyhlKS0yLjc1 IEUoc3VpdGFibGUgZm9yIGNvbnRlbnQgZGVsaSk3MiAyOTMgUSAtLjE2NSh2ZSktLjI3NSBH CihyeSBhcmUgZGVzY3JpYmVkIGluIFs5XS4gT3RoZXIgY29uZ2VzdGlvbiBjb250cm9scyBN QSkuMTY1IEUgMi43NShZYikKLTEuMTU1IEcgMi43NShlcyktMi43NSBHKHVpdGFibGUpLTIu NzUgRQood2hlbiBMQ1QgaXMgdXNlZCBmb3IgYSBzdHJlYW1pbmcgYXBwbGljYXRpb24uKTcy IDMwNiBRKExDVCBjYW4gYmUgdXNlZFwKIHdpdGggb3RoZXIgY29uZ2VzdGlvbiBjb250cm9s IHByb3RvY29scyBzdWNoIGFzIHRoZSBvbmUgZGVzY3JpYmVkIGluIFtcCjE0XSwgb3IpNzIg MzMyIFEocm91dGVyKTcyIDM0NSBRCigtYXNzaXN0ZWQgc2NoZW1lcyB3aGVyZSB0aGUgc2Vs ZWN0aW9uIG9mIHdoaWNoIHBhY2spLS4yMiBFKGV0cyB0byBmb3J3KQotLjExIEUoYXJkIGlz IHBlcmZvcm1lZCBieSByb3V0ZXJzLiktLjExIEUKKFRoaXMgbGF0dGVyIGFwcHJvYWNoIHBv dGVudGlhbGx5IGFsbG8pNzIgMzU4IFEKKHdzIGZvciBcMjE0bmVyIGdyYWluIGNvbmdlc3Rp b24gY29udHJvbCBhbmQgYSBmKS0uMjc1IEUKKGFzdGVyIHJlYWN0aW9uIHRvKS0uMTEgRShu ZXR3KTcyIDM3MSBRKG9yayBjb25nZXN0aW9uLCBiKS0uMTEgRQoodXQgcmVxdWlyZXMgY2hh bmdlcyB0byB0aGUgcm91dGVyIGluZnJhc3RydWN0dXJlLiktLjIyIEUKKFNlZSBbMl0gZm9y IGEgcHJlbGltaW5hcnkpNS41IEUoZGVzaWduIGRlc2NyaXB0aW9uLik3MiAzODQgUSAxLjc2 IC0uODgKKFdlIGQpNS41IEggMi43NShvbikuODggRwoob3QgZGlzY3VzcyB0aGlzIGFwcHJv YWNoIGZ1cnRoZXIgaW4gdGhpcyBkb2N1bWVudC4pLTIuNzUgRS9GMSAxMQovVGltZXMtQm9s ZEAwIFNGKDIuMS4pNzIgNDIzIFEvRjIgMTMvVGltZXMtQm9sZEAwIFNGKERlbGkpNS41IEUg LS4xMyh2ZSkKLS4xMyBHKHJ5IHNlcikuMTMgRSh2aWNlIG1vZGVscyktLjEzIEUgRjAoTENU IGNhbiBzdXBwb3J0IHNlKTcyIDQzOS42IFEKLS4xNjUodmUpLS4yNzUgRyhyYWwgZGlmKS4x NjUgRShmZXJlbnQgZGVsaSktLjI3NSBFIC0uMTY1KHZlKS0uMjc1IEcKKHJ5IHNlcnZpY2Ug bW9kZWxzLiBUKS4xNjUgRSAuMjIgLS4xMSh3byBlKS0uODggSAooeGFtcGxlcyBhcmUgYnJp ZVwyMTV5IGRlc2NyaWJlZCktLjA1NSBFKGhlcmUuKTcyIDQ1Mi42IFEgRjEoUHVzaCBzZXIp NzIKNDkxLjYgUSh2aWNlIG1vZGVsLiktLjExIEUgRjAoT25lIHcpNzIgNTA4LjIgUQooYXkg YSBwdXNoIHNlcnZpY2UgbW9kZWwgY2FuIGJlIHVzZWQgZm9yIHJlbGlhYmxlIGNvbnRlbnQg ZGVsaSktLjExIEUKLS4xNjUodmUpLS4yNzUgRyhyeSBpcyB0byBkZWxpKS4xNjUgRSAtLjE2 NSh2ZSktLjI3NSBHIDIuNzUocmFzKS4xNjUgRwooZXJpZXMgb2YpLTIuNzUgRSAyLjc1KG9i amVjdHMuIEYpNzIgNTIxLjIgUihvciBlKS0uMTY1IEUKKHhhbXBsZSwgYSByZWNlaSktLjE2 NSBFIC0uMTY1KHZlKS0uMjc1IEcgMi43NShyYykuMTY1IEcKKG91bGQgam9pbiB0aGUgc2Vz c2lvbiBhbmQgZHluYW1pY2FsbHkgYWRhcHQgdGhlIG51bWJlciBvZiBMQ1QpLTIuNzUgRQoo Y2hhbm5lbHMgdGhlIHJlY2VpKTcyIDUzNC4yIFEgLS4xNjUodmUpLS4yNzUgRyAyLjc1KHJp KS4xNjUgRyAyLjc1KHNqKQotMi43NSBHKG9pbmVkIHRvIHVudGlsIGVub3VnaCBwYWNrKS0y Ljc1IEUoZXRzIGhhKS0uMTEgRSAuMzMgLS4xNjUodmUgYikKLS4yMiBIKGVlbiByZWNlaSku MTY1IEUgLS4xNjUodmUpLS4yNzUgRyAyLjc1KGR0KS4xNjUgRyAyLjc1KG9yKS0yLjc1IEcK KGVjb25zdHJ1Y3QgYW4pLTIuNzUgRQoob2JqZWN0LiBBZnRlciByZWNvbnN0cnVjdGluZyB0 aGUgb2JqZWN0IHRoZSByZWNlaSk3MiA1NDcuMiBRIC0uMTY1KHZlKQotLjI3NSBHIDIuNzUo cm0pLjE2NSBHKGF5IHN0YXkgaW4gdGhlIHNlc3Npb24gYW5kIHcpLTIuNzUgRShhaXQgZm9y IHRoZSkKLS4xMSBFKHRyYW5zbWlzc2lvbiBvZiB0aGUgbmUpNzIgNTYwLjIgUSh4dCBvYmpl Y3QuKS0uMTY1IEUKKFRoZSBwdXNoIG1vZGVsIGlzIHBhcnRpY3VsYXJseSBhdHRyYWN0aSk3 MiA1ODYuMiBRIC4zMyAtLjE2NSh2ZSBpKS0uMjc1CkggMi43NShucykuMTY1IEcoYXRlbGxp dGUgbmV0dyktMi43NSBFKG9ya3MgYW5kIHdpcmVsZXNzIG5ldHcpLS4xMSBFCjIuNzUob3Jr cy4gSW4pLS4xMSBGKHRoZXNlKTIuNzUgRQooY2FzZXMsIGEgc2Vzc2lvbiBtYXkgY29uc2lz dCBvZiBvbmUgXDIxNHgpNzIgNTk5LjIgUQooZWQgcmF0ZSBMQ1QgY2hhbm5lbC4pLS4xNjUg RSBGMShPbi1kZW1hbmQgY29udGVudCBkZWxpKTcyIDYzOC4yIFEgLS4xMQoodmUpLS4xMSBH KHJ5IG1vZGVsLikuMTEgRSBGMCAtLjE2NShGbyk3MiA2NTQuOCBTIDIuNzUocmEpLjE2NSBH IDIuNzUKKG5vKS0yLjc1IEcobi1kZW1hbmQgY29udGVudCBkZWxpKS0yLjc1IEUgLS4xNjUo dmUpLS4yNzUgRwoocnkgc2VydmljZSBtb2RlbCwgc2VuZGVycyB0eXBpY2FsbHkgdHJhbnNt aXQgZm9yIHNvbWUgZ2kpLjE2NSBFIC0uMTY1Cih2ZSktLjI3NSBHIDIuNzUobnQpLjE2NSBH KGltZSktMi43NSBFCihwZXJpb2Qgc2VsZWN0ZWQgdG8gYmUgbG9uZyBlbm91Z2ggdG8gYWxs byk3MiA2NjcuOCBRIDIuNzUod2EpLS4yNzUgRwoobGwgdGhlIGludGVuZGVkIHJlY2VpKS0y Ljc1IEUgLS4xNjUodmUpLS4yNzUgRwoocnMgdG8gam9pbiB0aGUgc2Vzc2lvbiBhbmQpLjE2 NSBFKHJlY28pNzIgNjgwLjggUSAtLjE2NSh2ZSktLjE2NSBHIDIuNzUKKHJ0KS4xNjUgRyho ZSBvYmplY3QuKS0yLjc1IEUgLS4xNjUoRm8pNS41IEcgMi43NShyZSkuMTY1IEcKKHhhbXBs ZSBhIHBvcHVsYXIgc29mdHcpLTIuOTE1IEUKKGFyZSB1cGRhdGUgbWlnaHQgYmUgdHJhbnNt aXR0ZWQgdXNpbmcgTENUIGZvciktLjExIEUoc2UpNzIgNjkzLjggUQotLjE2NSh2ZSktLjI3 NSBHKHJhbCBkYXlzLCBlKS4xNjUgRSAtLjE2NSh2ZSktLjI3NSBHIDIuNzUobnQpLjE2NSBH Cihob3VnaCBhIHJlY2VpKS0yLjc1IEUgLS4xNjUodmUpLS4yNzUgRyAyLjc1KHJtKS4xNjUg RwooYXkgYmUgYWJsZSB0byBjb21wbGV0ZSB0aGUgZG8pLTIuNzUgRSh3bmxvYWQgaW4gb25l IGhvdXIgdG90YWwgb2YpLS4yNzUKRShjb25uZWN0aW9uIHRpbWUsIHBlcmhhcHMgc3ByZWFk IG8pNzIgNzA2LjggUSAtLjE2NSh2ZSktLjE2NSBHIDIuNzUocnMpCi4xNjUgRyAtMi4zNjUg LS4yNzUoZXYgZSktMi43NSBIKHJhbCBpbnRlcnYpLjI3NSBFKGFscyBvZiB0aW1lLiktLjI3 NSBFCihMdWJ5L0dlbW1lbGwvVik3MiA3NjkgUShpY2lzYW5vL1JpenpvL0hhbmRsZSktLjY2 IEUoeS9Dcm8pLS4xNjUgRQoxMDkuMTA2KHdjcm9mdCBTZWN0aW9uKS0uMjc1IEYgMi43NSgy LjEuIFtQKTIuNzUgRihhZ2UgN10pLS4xNjUgRSBFUAolJVBhZ2U6IDggOAolJUJlZ2luUGFn ZVNldHVwCkJQCiUlRW5kUGFnZVNldHVwCi9GMCAxMS9UaW1lcy1Sb21hbkAwIFNGKElOVEVS TkVUKTcyIDQ5IFEgNzEuNTg3KC1EUkFGVCBFeHBpcmVzOiktMS4wMTIgRgooSmFudWFyeSAy MDAyKTIuNzUgRShKdWx5IDIwMDEpMTIzLjcyNiBFKEluIHRoaXMgY2FzZSB0aGUgcmVjZWkp NzIgODUgUQotLjE2NSh2ZSktLjI3NSBHCihycyBqb2luIHRoZSBzZXNzaW9uLCBhbmQgZHlu YW1pY2FsbHkgYWRhcHQgdGhlIG51bWJlciBvZiBMQ1QgY2hhbm5lbHMpCi4xNjUgRSh0aGUp NzIgOTggUSAyLjc1KHlzKS0uMTY1IEcKKHVic2NyaWJlIHRvIFwoYW5kIHRoZSByZWNlcHRp b24gcXVhbGl0eVwpIGFjY29yZGluZyB0byB0aGUgYSktMi43NSBFCi0uMjc1KHZhKS0uMjIg RyhpbGFibGUgYmFuZHdpZHRoLiBSZWNlaSkuMjc1IEUgLS4xNjUodmUpLS4yNzUgRyhycyB0 aGVuKQouMTY1IEUoZHJvcCBmcm9tIHRoZSBzZXNzaW9uIHdoZW4gdGhlKTcyIDExMSBRIDIu NzUoeWgpLS4xNjUgRyAtMi40NzUKLS4yMihhdiBlKS0yLjc1IEgocmVjZWkpMi45NyBFIC0u MTY1KHZlKS0uMjc1IEcgMi43NShkZSkuMTY1IEcKKG5vdWdoIHBhY2spLTIuNzUgRShldHMg dG8gcmVjbyktLjExIEUgLS4xNjUodmUpLS4xNjUgRyAyLjc1KHJ0KS4xNjUgRwooaGUgb2Jq ZWN0LiktMi43NSBFKEFzIGFuIGUpNzIgMTM3IFEKKHhhbXBsZSwgYXNzdW1lIHRoYXQgYW4g b2JqZWN0IGlzIDUwIE1CLiktLjE2NSBFCihUaGUgc2VuZGVyIGNvdWxkIHNldCB0aGUgZGF0 YSByYXRlIG9uIHRoZSBsbyk1LjUgRSh3ZXN0KS0uMjc1IEUKKExDVCBjaGFubmVsIHRvIDUw IDFLQiBwYWNrKTcyIDE1MCBRKGV0cyBwZXIgc2Vjb25kLCBzbyB0aGF0IHJlY2VpKS0uMTEK RSAtLjE2NSh2ZSktLjI3NSBHKHJzIHVzaW5nIGp1c3QgdGhpcyBMQ1QgY2hhbm5lbCBjb3Vs ZCkuMTY1IEUoY29tcGxldGVcCiByZWNlcHRpb24gb2YgdGhlIG9iamVjdCBpbiAxLDAwMCBz ZWNvbmRzIGluIGFic2VuY2Ugb2YgbG9zcywgYW5kIHcpNzIKMTYzIFEob3VsZCBiZSBhYmxl IHRvKS0uMTEgRShjb21wbGV0ZSByZWNlcHRpb24gZSk3MiAxNzYgUSAtLjE2NSh2ZSkKLS4y NzUgRyAyLjc1KG5pKS4xNjUgRyAyLjc1KG5wKS0yLjc1IEcKKHJlc2VuY2Ugb2Ygc29tZSBz dWJzdGFudGlhbCBhbW91bnQgb2YgbG9zc2VzIHdpdGggdGhlIHVzZSBvZiBjb2RpbmcpCi0y Ljc1IEUoZm9yIHJlbGlhYmlsaXR5KTcyIDE4OSBRIDUuNSguRiktLjcxNSBHKHVydGhlcm1v cmUsIHRoZSBzZW5kZXIgXApjb3VsZCB1c2UgYSBudW1iZXIgb2YgTENUIGNoYW5uZWxzIHN1 Y2ggdGhhdCB0aGUpLTUuNSBFKGFnZ3JlKTcyIDIwMiBRCi0uMDU1KGdhKS0uMTY1IEcKKHRl IGRhdGEgcmF0ZSB3aGVuIHVzaW5nIGFsbCBMQ1QgY2hhbm5lbHMgaXMgMSwwMDAgMUtCIHBh Y2spLjA1NSBFCihldHMgcGVyIHNlY29uZCwgc28gdGhhdCBhKS0uMTEgRShyZWNlaSk3MiAy MTUgUSAtLjE2NSh2ZSktLjI3NSBHIDIuNzUKKHJjKS4xNjUgRyhvdWxkIGJlIGFibGUgdG8g Y29tcGxldGUgcmVjZXB0aW9uIG9mIHRoZSBvYmplY3QgaW4gYXMgbGl0dGxcCmUgNTAgc2Vj b25kcyBcKGFzc3VtaW5nIG5vIGxvc3MpLTIuNzUgRQooYW5kIHRoYXQgdGhlIGNvbmdlc3Rp b24gY29udHJvbCBtZWNoYW5pc20gaW1tZWRpYXRlbHkgY29uKTcyIDIyOCBRCi0uMTY1KHZl KS0uNDQgRyAtLjE5OChyZykuMTY1IEcoZXMgdG8gdGhlIHVzZSBvZiBhbGwgTENUKS4xOTgg RQooY2hhbm5lbHNcKS4pNzIgMjQxIFEvRjEgMTEvVGltZXMtQm9sZEAwIFNGKE90aGVyIHNl cik3MiAyODAgUQoodmljZSBtb2RlbHMuKS0uMTEgRSBGMChUaGVyZSBhcmUgbWFuKTcyIDMw OS42IFEgMi43NSh5byktLjE2NSBHCih0aGVyIGRlbGkpLTIuNzUgRSAtLjE2NSh2ZSktLjI3 NSBHCihyeSBzZXJ2aWNlIG1vZGVscyB0aGF0IExDVCBjYW4gYmUgdXNlZCBmb3IgdGhhdCBh cmUgbm90IGNvKS4xNjUgRSAtLjE2NQoodmUpLS4xNjUgRyhyZWQpLjE2NSBFKGFibyk3MiAz MjIuNiBRIC0uMTY1KHZlKS0uMTY1IEcgNS41KC5BKS4xNjUgRwoyLjc1KHNlKS01LjUgRyh4 YW1wbGVzLCBhIGxpKS0yLjkxNSBFIC4zMyAtLjE2NSh2ZSBzKS0uMjc1IEgKKHRyZWFtaW5n IG9yIGFuIG9uLWRlbWFuZCBhcmNoaSkuMTY1IEUgLS4yNzUodmEpLS4yNzUgRyAyLjc1KGxj KS4yNzUgRwoob250ZW50IHN0cmVhbWluZyBzZXJ2aWNlIG1vZGVsLiktMi43NSBFKFRoZSBk ZXNjcmlwdGlvbiBvZiB0aGUgbWFuKTcyCjMzNS42IFEgMi43NSh5cCktLjE2NSBHKG90ZW50 aWFsIGFwcGxpY2F0aW9ucywgdGhlIGFwcHJvcHJpYXRlIGRlbGkpCi0yLjc1IEUgLS4xNjUo dmUpLS4yNzUgRyhyeSBzZXJ2aWNlIG1vZGVsLCBhbmQpLjE2NSBFKHRoZSBhZGRpdGlvbmFs IG1lXApjaGFuaXNtcyB0byBzdXBwb3J0IHN1Y2ggZnVuY3Rpb25hbGl0aWVzIHdoZW4gY29t YmluZWQgd2l0aCBMQ1QgaXMgYmUpNzIKMzQ4LjYgUSh5b25kKS0uMTY1IEUodGhlIHNjb3Bl IG9mIHRoaXMgZG9jdW1lbnQuKTcyIDM2MS42IFEKKFRoaXMgZG9jdW1lbnQgb25seSBhdHRl bXB0cyB0byBkZXNjcmliZSB0aGUgbWluaW1hbCBjb21tb24pNS41IEUKKHNjYWxhYmxlIGVs ZW1lbnRzIHRvIHRoZXNlIGRpKTcyIDM3NC42IFEgLS4xNjUodmUpLS4yNzUgRwoocnNlIGFw cGxpY2F0aW9ucyB1c2luZyBMQ1QgYXMgdGhlIGRlbGkpLjE2NSBFIC0uMTY1KHZlKS0uMjc1 IEcKKHJ5IHRyYW5zcG9ydC4pLjE2NSBFIEYxKDIuMi4pNzIgNDEzLjYgUS9GMiAxMy9UaW1l cy1Cb2xkQDAgU0YKKENvbmdlc3Rpb24gQ29udHIpNS41IEUob2wpLS4yMzQgRSBGMChUaGUg c3BlY2lcMjE0YyBjb25nZXN0aW9uIGNvbnRyb2xcCiBwcm90b2NvbCB0byBiZSB1c2VkIGZv ciBMQ1Qgc2Vzc2lvbnMgZGVwZW5kcyBvbiB0aGUgdHlwZSBvZik3MiA0MzAuMiBRCihjb250 ZW50IHRvIGJlIGRlbGkpNzIgNDQzLjIgUSAtLjE2NSh2ZSktLjI3NSBHCihyZWQuIFdoaWxl IHRoZSBnZW5lcmFsIGJlaGEpLjE2NSBFCih2aW9yIG9mIHRoZSBjb25nZXN0aW9uIGNvbnRy b2wgcHJvdG9jb2wgaXMgdG8gcmVkdWNlKS0uMjIgRSh0aGUgdGhyb3VnXApocHV0IGluIHBy ZXNlbmNlIG9mIGNvbmdlc3Rpb24gYW5kIGdyYWR1YWxseSBpbmNyZWFzZSBpdCBpbiB0aGUg YWJzZW5jZVwKIG9mIGNvbmdlc3Rpb24sKTcyIDQ1Ni4yIFEodGhlIGFjdHVhbCBkeW5hbWlj IGJlaGEpNzIgNDY5LjIgUQoodmlvciBcKGUuZy4gcmVzcG9uc2UgdG8gc2luZ2xlIGxvc3Nl c1wpIGNhbiB2KS0uMjIgRShhcnkpLS4yNzUgRSguKQotLjcxNSBFCihTb21lIHBvc3NpYmxl IGNvbmdlc3Rpb24gY29udHJvbCBwcm90b2NvbHMgZm9yIHJlbGlhYmxlIGNvbnRlbnQgZGVs aSk3Mgo0OTUuMiBRIC0uMTY1KHZlKS0uMjc1IEcocnkgdXNpbmcgTENUIGFyZSBkZXNjcmli ZWQpLjE2NSBFKGluIFs5XS4gRGlmKQo3MiA1MDguMiBRKGZlcmVudCBkZWxpKS0uMjc1IEUg LS4xNjUodmUpLS4yNzUgRwoocnkgc2VydmljZSBtb2RlbHMgbWlnaHQgcmVxdWlyZSBhIGRp ZikuMTY1IEUKKGZlcmVudCBjb25nZXN0aW9uIGNvbnRyb2wgcHJvdG9jb2xzLiktLjI3NSBF IEYxKDMuKTcyIDU0Ny4yIFEvRjMgMTQKL1RpbWVzLUJvbGRAMCBTRihMQ1QgcGFjayk1LjUg RShldHMpLS4xNCBFIEYwKFRoZSB0eXBlIG9mIHBhY2spNzIgNTYzLjgKUShldCB1c2VkIGJ5 IExDVCBzZXNzaW9ucyBpcyAiTENUIFApLS4xMSBFKGFjayktLjE2NSBFIDIuNzUoZXQiLiBM Q1QpCi0uMTEgRihwYWNrKTIuNzUgRShldHMgYXJlIHNlbnQgYnkgc2VuZGVycyB0byktLjEx IEUoTENUIGNoYW5uZWxzLik3Mgo1NzYuOCBRKFNvbWUgaW5zdGFuY2VzIG9mIExDVCBzZXNz aW9ucyBNQSk3MiA2MDIuOCBRIDIuNzUoWXIpLTEuMTU1IEcKKGVxdWlyZSB0aGUgZ2VuZXJh dGlvbiBvZiBmZWVkYmFjayBmcm9tIHRoZSByZWNlaSktMi43NSBFIC0uMTY1KHZlKS0uMjc1 CkcocnMgdG8pLjE2NSBFKHRoZSBzZW5kZXIpNzIgNjE1LjggUSA1LjUoLkgpLS42MDUgRyAt LjI3NShvdyktNS41IEcKLTIuMzY1IC0uMjc1KGV2IGUpLjI3NSBIIC44OCAtLjQ0KHIsIHQp LjI3NSBICihoZSBtZWNoYW5pc20gZm9yIGRvaW5nIHRoaXMgaXMgb3V0c2lkZSB0aGUgc2Nv cGUgb2YgTENUKS40NCBFKC4pLS44MTQgRQooVGhlIExDVCBwYWNrKTcyIDY0MS44IFEoZXQg Zm9ybWF0IGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGlzIGludGVuZFwKZWQgdG8gYmUg dXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoIHRoZSktLjExIEUoVURQIHRyYW5zcG9ydCBwcm90 b2NvbCBhcyBcCmRlXDIxNG5lZCBpbiBSRkM3Njggb3Igb3RoZXIgdHJhbnNwb3J0IHByb3Rv Y29scyB0aGF0IHNhdGlzZnkgdGhlKTcyCjY1NC44IFEKKHJlcXVpcmVtZW50cyBzdGF0ZWQg aW4gU2VjdGlvbiAxLjIsIHNwZWNpXDIxNGNhbGx5IGFib3V0IGRlbXVsdGlwbGUpNzIKNjY3 LjggUSh4aW5nIGFuZCBkZWxpKS0uMTY1IEUgLS4xNjUodmUpLS4yNzUgRyhyeSBvZiBwYWNr KS4xNjUgRQooZXQgc2l6ZSktLjExIEUoaW5mb3JtYXRpb24uKTcyIDY4MC44IFEoTENUIHBh Y2spNzIgNzA2LjggUQooZXRzIGNvbnNpc3Qgb2YgYW4gTENUIHBhY2spLS4xMSBFKGV0IGhl YWRlciBhbmQgYW4gT1BUSU9OKS0uMTEgRQooQUwgTENUIHBhY2spLS4zODUgRShldCBwYXls b2FkLCBhcyBzaG8pLS4xMSBFKHduKS0uMjc1IEUoaW4gRmlndXJlIDEuKQo3MiA3MTkuOCBR KFdoZW4gcHJlc2VudCwgdGhlIExDVCBwYWNrKTUuNSBFCihldCBwYXlsb2FkIGltbWVkaWF0 ZWx5IGZvbGxvKS0uMTEgRSh3cyB0aGUgTENUIHBhY2spLS4yNzUgRShldCBoZWFkZXIpCi0u MTEgRSguKS0uNjA1IEUoTHVieS9HZW1tZWxsL1YpNzIgNzY5IFEoaWNpc2Fuby9SaXp6by9I YW5kbGUpLS42NiBFCih5L0NybyktLjE2NSBFIDExNy4zNTYod2Nyb2Z0IFNlY3Rpb24pLS4y NzUgRiAyLjc1KDMuIFtQKTIuNzUgRihhZ2UgOF0pCi0uMTY1IEUgRVAKJSVQYWdlOiA5IDkK JSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTEvVGltZXMtUm9tYW5A MCBTRihJTlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhwaXJlczopLTEuMDEyIEYK KEphbnVhcnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEyMy43MjYgRShUaGUgTENUIHBhY2sp NzIgODUgUQooZXQgcGF5bG9hZCBNQSktLjExIEUgMi43NShZYyktMS4xNTUgRwoob250YWlu IGhlYWRlcnMgZm9yIG90aGVyIHByb3RvY29scywgc3VjaCBhcyByZWxpYWJpbGl0eSBwcm90 b2NvbHMuKQotMi43NSBFKExDVCBwYWNrKTcyIDExMSBRKGV0IGhlYWRlcnMgaGEpLS4xMSBF IC4zMyAtLjE2NSh2ZSB2KS0uMjIgSChhclwKaWFibGUgc2l6ZSwgd2hpY2ggaXMgc3BlY2lc MjE0ZWQgYnkgYSBsZW5ndGggXDIxNGVsZCBpbiB0aGUgdGhpcmQgYnl0ZSBcCm9mIHRoZSkt LjExIEUoaGVhZGVyKTcyIDEyNCBRIDUuNSguSSktLjYwNSBHIDIuNzUobnQpLTUuNSBHKGhl IExDVCBwYWNrKQotMi43NSBFKGV0IGhlYWRlciktLjExIEUgMi43NSgsYSktLjQ0IEcobGwg aW50ZSktMi43NSBFCihnZXIgXDIxNGVsZHMgYXJlIGNhcnJpZWQgaW4gImJpZy1lbmRpYW4i IG9yICJuZXR3KS0uMTY1IEUob3JrIG9yZGVyIikKLS4xMSBFKGZvcm1hdCwgdGhhdCBpcywg bW9zdCBzaWduaVwyMTRjYW50IGJ5dGUgXChvY3RldFwpIFwyMTRyc3QuKTcyCjEzNyBRKEJp dHMgZGVzaWduYXRlZCBhcyAicGFkZGluZyIgb3IgInJlc2Vydik1LjUgRShlZCIgXChyXCkp LS4xNjUgRQooTVVTVCBieSBzZXQgdG8gMCBieSBzZW5kZXJzIGFuZCBpZ25vcmVkIGJ5IHJl Y2VpKTcyIDE1MCBRIC0uMTY1KHZlKQotLjI3NSBHIDIuNzUocnMuIFVubGVzcykuMTY1IEYo b3RoZXJ3aXNlIG5vdGVkLCBudW1lcmljKTIuNzUgRQooY29uc3RhbnRzIGluIHRoaXMgc3Bl Y2lcMjE0Y2F0aW9uIGFyZSBpbiBkZWNpbWFsIFwoYmFzZSAxMFwpLik3MiAxNjMgUQovRjEg MTEvVGltZXMtQm9sZEAwIFNGKDMuMS4pNzIgMjAyIFEvRjIgMTMvVGltZXMtQm9sZEAwIFNG KExDVCBwYWNrKTUuNQpFKGV0IGYpLS4xMyBFKG9ybWF0KS0uMzI1IEUgRjAoVGhlIGZvcm1h dCBvZiBMQ1QgcGFjayk3MiAyMTguNiBRCihldHMgaXMgZGVwaWN0ZWQgaW4gRmlndXJlIDEu KS0uMTEgRS9GMyA4L0NvdXJpZXJAMCBTRiA5MS4yKDAxMjMpODEuNgoyNTcuNiBTIDQuOCgw MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMSk4MS42IDI3MC42IFMKKCstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rKTc2LjgKMjgzLjYgUSAtMTQuNCAxNC40KHxWfCByIHwpNzYuOCAyOTYuNiBUIDQuOChJ fCktOS42IEcgOS42CihTfEV8WHxBfEJ8IEhEUl9MRU4pLTQuOCBGIDQuOCh8QykyNCBHKG9k ZXBvaW50IFwoQ1BcKXwpLTQuOCBFCigrLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyk3Ni44CjMwOS42IFEgNjIuNCh8 Qyk3Ni44IDMyMi42IFMob25nZXN0aW9uIENvbnRyb2wgSW5mb3JtYXRpb24gXChDQ0lcKSkt NjIuNApFKHwpNjcuMiBFCigrLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyk3Ni44CjMzNS42IFEgMzguNCh8VCk3Ni44 IDM0OC42IFMKKHJhbnNwb3J0IE9iamVjdCBJZGVudGlmaWVyIFwoVE9JLCBpZiBJID49IDFc KSktMzguNCBFKHwpNTIuOCBFCigrLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyk3Ni44CjM2MS42IFEgNzYuOCh8VCk3 Ni44IDM3NC42IFMoT0kgY29udGludWVkKS03Ni44IEUoXChpZiBJID49IDJcKSk5LjYgRSh8 KQoxMDAuOCBFCigrLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKyk3Ni44CjM4Ny42IFEgNzYuOCh8VCk3Ni44IDQwMC42 IFMoT0kgY29udGludWVkKS03Ni44IEUoXChpZiBJID0gM1wpKTkuNiBFKHwpCjEwNS42IEUK KCstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rKTc2LjgKNDEzLjYgUSA3Ni44KHxUKTc2LjggNDI2LjYgUyhPSSBjb250 aW51ZWQpLTc2LjggRShcKGlmIEkgPSAzXCkpOS42IEUofCkKMTA1LjYgRQooKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSspNzYuOAo0MzkuNiBRIDcyKHxTKTc2LjggNDUyLjYgUyhlbmRlciBDdXJyZW50IFRpbWUg XChTQ1QsIGlmIFMgPSAxXCkpLTcyIEUofCkKNjIuNCBFCigrLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyk3Ni44CjQ2 NS42IFEgNjcuMih8RSk3Ni44IDQ3OC42IFMoeHBlY3RlZCBSZXNpZHVhbCBUaW1lIFwoRVJU LCBpZiBFID0gMVwpKQotNjcuMiBFKHwpNTIuOCBFCigrLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyk3Ni44CjQ5MS42 IFEgNzYuOCh8SCk3Ni44IDUwNC42IFMoZWFkZXIgRXh0ZW5zaW9ucyBcKGlmIFggPSAxIFwp KS03Ni44IEUofCkKODYuNCBFIDMwMi40KHx8KTc2LjggNTE3LjYgUwooKz0rPSs9Kz0rPSs9 Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSsp NzYuOAo1MzAuNiBRIDMwMi40KHx8KTc2LjggNTQzLjYgUyAxMjQuOCh8UCk3Ni44IDU1Ni42 IFMgMTM5LjIoYXlsb2FkIHwpCi0xMjQuOCBGIDMwMi40KHx8KTc2LjggNTY5LjYgUwooKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSspNzYuOAo1ODIuNiBRL0Y0IDEwL1RpbWVzLVJvbWFuQDAgU0YoRmlndXJlIDEg LSBMQ1QgcGFjayk3MiA2MjEuNiBRKGV0IGZvcm1hdCkKLS4xIEUgRjEoMy4yLik3MiA2NjAu NiBRIEYyKExDVCBwYWNrKTUuNSBFKGV0IGhlYWRlciBcMjE0ZWxkcyktLjEzIEUgRjAKKFRo ZSBmdW5jdGlvbiBlYWNoIFwyMTRlbGQgaW4gTENUIHBhY2spNzIgNjc3LjIgUQooZXQgaGVh ZGVycyBpcyB0aGUgZm9sbG8pLS4xMSBFIDIuNzUod2luZy4gRmllbGRzKS0uMjc1IEYobWFy aykyLjc1IEUKKGVkIGFzICIxIiBtZWFuIHRoYXQpLS4xMSBFCih0aGUgY29ycmVzcG9uZGlu ZyBiaXRzIE1VU1QgYmUgc2V0IHRvICIxIiBieSB0aGUgZ2VuZXJhdGluZyBhZ2VudC4pNzIK NjkwLjIgUShGaWVsZHMgbWFyayk1LjUgRShlZCBhcyAiciIgb3IgIjAiKS0uMTEgRShtZWFu IHRoYXQgdGhlIGNvcnJlc3BcCm9uZGluZyBiaXRzIE1VU1QgYmUgc2V0IHRvICIwIiBieSB0 aGUgZ2VuZXJhdGluZyBhZ2VudC4pNzIgNzAzLjIgUQooTHVieS9HZW1tZWxsL1YpNzIgNzY5 IFEoaWNpc2Fuby9SaXp6by9IYW5kbGUpLS42NiBFKHkvQ3JvKS0uMTY1IEUKMTA5LjEwNih3 Y3JvZnQgU2VjdGlvbiktLjI3NSBGIDIuNzUoMy4yLiBbUCkyLjc1IEYoYWdlIDldKS0uMTY1 IEUgRVAKJSVQYWdlOiAxMCAxMAolJUJlZ2luUGFnZVNldHVwCkJQCiUlRW5kUGFnZVNldHVw Ci9GMCAxMS9UaW1lcy1Sb21hbkAwIFNGKElOVEVSTkVUKTcyIDQ5IFEgNzEuNTg3KC1EUkFG VCBFeHBpcmVzOiktMS4wMTIgRgooSmFudWFyeSAyMDAyKTIuNzUgRShKdWx5IDIwMDEpMTIz LjcyNiBFKExDVCB2KTgzIDg1IFEKKGVyc2lvbiBudW1iZXIgXChWXCk6IDQgYml0cyktLjE2 NSBFKEluZGljYXRlcyB0aGUgTENUIHByb3RvY29sIHYpMTA1CjEwMS42IFEgMi43NShlcnNp b24uIFRoZSktLjE2NSBGKExDVCB2KTIuNzUgRQooZXJzaW9uIG51bWJlciBmb3IgdGhpcyBz cGVjaVwyMTRjYXRpb24gaXMgMC4pLS4xNjUgRShSZXNlcnYpODMgMTMxLjIgUQooZWQgXChy XCk6IDUgYml0cyktLjE2NSBFKFJlc2VydikxMDUgMTQ3LjggUQooZWQgZm9yIGZ1dHVyZSB1 c2UuIEEgc2VuZGVyIE1VU1Qgc2V0IHRoZXNlIGJpdHMgdG8gemVybyBhbmQgYSByZWNlaSkK LS4xNjUgRSAtLjE2NSh2ZSktLjI3NSBHIDIuNzUock0pLjE2NSBHKFVTVCktMi43NSBFKGln bm9yZSB0aGVzZSBiaXRzLikKMTA1IDE2MC44IFEgLS4zODUoVHIpODMgMTkwLjQgUwooYW5z cG9ydCBPYmplY3QgSWRlbnRpXDIxNGVyIFwyMTVhZyBcKElcKTogMiBiaXRzKS4zODUgRQoo ST0wIGluZGljYXRlcyBubyBUKTEwNSAyMDcgUShyYW5zcG9ydCBPYmplY3QgSWRlbnRpXDIx NGVyIFwoVCktLjM4NSBFCihPSVwpIFwyMTRlbGQgaXMgcHJlc2VudC4pLS4xOTggRShJPTEg aW5kaWNhdGVzIHRoYXQgYSAzMi1iaXQgVCkxMDUgMjIwClEoT0kgXDIxNGVsZCBpcyBwcmVz ZW50LiktLjE5OCBFKEk9MiBpbmRpY2F0ZXMgdGhhdCBhIDY0LWJpdCBUKTEwNSAyMzMgUQoo T0kgXDIxNGVsZCBpcyBwcmVzZW50LiktLjE5OCBFKEk9MyBpbmRpY2F0ZXMgdGhhdCBhIDEy OC1iaXQgVCkxMDUgMjQ2IFEKKE9JIFwyMTRlbGQgaXMgcHJlc2VudC4pLS4xOTggRShUaGUg VCkxMDUgMjU5IFEKKE9JIFwyMTRlbGQgaW5kaWNhdGVzIHdoaWNoIG9iamVjdCB3aXRoaW4g dGhlIHNlc3Npb24gdGhpcyBMQ1QgcGFjaykKLS4xOTggRShldCBwZXJ0YWlucyB0by4pLS4x MSBFKFNlbmRlciBDdXJyZW50IFQpODMgMjg4LjYgUQooaW1lIHByZXNlbnQgXDIxNWFnIFwo U1wpOiAxIGJpdCktLjM4NSBFIDIuNzUoUz0waSkxMDUgMzA1LjIgUwoobmRpY2F0ZXMgdGhh dCB0aGUgU2VuZGVyIEN1cnJlbnQgVCktMi43NSBFCihpbWUgXChTQ1RcKSBcMjE0ZWxkIGlz IG5vdCBwcmVzZW50LiktLjM4NSBFIDIuNzUoUz0xaSkxMDUgMzE4LjIgUwoobmRpY2F0ZXMg dGhhdCB0aGUgU0NUIFwyMTRlbGQgaXMgcHJlc2VudC4pLTIuNzUgRQooVGhlIFNDVCBpcyBp bnNlcnRlZCBieSBzZW5kZXJzIHRvIGluZGljYXRlIHRvIHJlY2VpKTEwNSAzMzEuMiBRIC0u MTY1Cih2ZSktLjI3NSBHKHJzIGhvKS4xNjUgRSAyLjc1KHdsKS0uMjc1IEcob25nIHRoZSBz ZXNzaW9uIGhhcyBiZWVuIGluKQotMi43NSBFKHByb2dyZXNzLikxMDUgMzQ0LjIgUShFeHBl Y3RlZCBSZXNpZHVhbCBUKTgzIDM3My44IFEKKGltZSBwcmVzZW50IFwyMTVhZyBcKEVcKTog MSBiaXQpLS4zODUgRSAyLjc1KEU9MGkpMTA1IDM5MC40IFMKKG5kaWNhdGVzIHRoYXQgdGhl IEV4cGVjdGVkIFJlc2lkdWFsIFQpLTIuNzUgRShpbWUgXChFUiktLjM4NSBFCihUXCkgXDIx NGVsZCBpcyBub3QgcHJlc2VudC4pLS42NiBFIDIuNzUoRT0xaSkxMDUgNDAzLjQgUwoobmRp Y2F0ZXMgdGhhdCB0aGUgRVIpLTIuNzUgRSAyLjc1PDU0OGM+LS42NiBHKGVsZCBpcyBwcmVz ZW50LiktMi43NSBFCihUaGUgRVIpMTA1IDQxNi40IFEgMi43NShUaSktLjY2IEcgMi43NShz aSktMi43NSBHCihuc2VydGVkIGJ5IHNlbmRlcnMgdG8gaW5kaWNhdGUgdG8gcmVjZWkpLTIu NzUgRSAtLjE2NSh2ZSktLjI3NSBHKHJzIGhvKQouMTY1IEUgMi43NSh3bSktLjI3NSBHKHVj aCBsb25nZXIgdGhlIHNlc3Npb24gd2lsbCktMi43NSBFKGNvbnRpbnVlLikxMDUKNDI5LjQg UShTZW5kZXJzIE1VU1QgTk8pMTA1IDQ0Mi40IFEgMi43NShUcyktLjQ0IEcoZXQgRSA9IDEg d2hlbiB0aGUgRVIpCi0yLjc1IEUgMi43NShUZiktLjY2IEcob3IgdGhlIHNlc3Npb24gaXMg bW9yZSB0aGFuIDJeMzItMSB0aW1lKS0yLjc1IEUoXAp1bml0cyBcKGFwcHJveGltYXRlbHkg NDkgZGF5c1wpLCB3aGVyZSB0aW1lIGlzIG1lYXN1cmVkIGluIHVuaXRzIG9mIG1pbFwKbGlz ZWNvbmRzLikxMDUgNDU1LjQgUShIZWFkZXIgZSk4MyA0ODUgUQooeHRlbnNpb24gcHJlc2Vu dCBcMjE1YWcgXChYXCk6IDEgYml0KS0uMTY1IEUgMi43NShYPTBpKTEwNSA1MDEuNiBTCihu ZGljYXRlcyBubyBIZWFkZXIgRXh0ZW5zaW9ucyBhcmUgcHJlc2VudC4pLTIuNzUgRSAyLjc1 KFg9MWkpMTA1IDUxNC42ClMobmRpY2F0ZXMgdGhhdCBIZWFkZXIgRXh0ZW5zaW9ucyBhcmUg cHJlc2VudC4pLTIuNzUgRQooSGVhZGVyIEV4dGVuc2lvbnMgYXJlIHVzZWQgaW4gTENUIHRv IGFjY29tbW9kYXRlIE9QVElPTikxMDUgNTI3LjYgUQooQUwgaGVhZGVyIFwyMTRlbGRzIHdo aWNoIGFyZSktLjM4NSBFKG5vdCBhbCkxMDUgNTQwLjYgUSAtLjExKHdhKS0uMTEgRwooeXMg dXNlZCBvciBoYSkuMTEgRSAuMzMgLS4xNjUodmUgdiktLjIyIEgoYXJpYWJsZSBzaXplLikt LjExIEUoQ2xvc2UgVCkKODMgNTcwLjIgUShPSSBcMjE1YWcgXChBXCk6IDEgYml0KS0uMTk4 IEUoTm9ybWFsbHkpMTA1IDU4Ni44IFEgMi43NSgsdCkKLS43MTUgRyhoZSBDbG9zZSBUKS0y Ljc1IEUoT0kgXDIxNWFnIGlzIHNldCB0byAwLiktLjE5OCBFKFRoZSBzZW5kZXIgTUEpCjUu NSBFIDIuNzUoWXMpLTEuMTU1IEcoZXQgdGhlIENsb3NlIFQpLTIuNzUgRShPSSBcMjE1YWcg dG8gMSktLjE5OCBFCih3aGVuIHRlcm1pbmF0aW9uIG9mIHRyYW5zbWlzc2lvbiBvZiBMQ1Qg cGFjaykxMDUgNTk5LjggUQooZXRzIGZvciB0aGUgb2JqZWN0IGlkZW50aVwyMTRlZCBieSB0 aGUgVCktLjExIEUoT0kgaXMpLS4xOTggRSAyLjc1CihpbW1pbmVudC4gVGhlKTEwNSA2MTIu OCBSKENsb3NlIFQpMi43NSBFKE9JIFwyMTVhZyBNQSktLjE5OCBFIDIuNzUoWWIpCi0xLjE1 NSBHIDIuNzUoZXMpLTIuNzUgRyhldCB0byAxIGluIGp1c3QgdGhlIGxhc3QgTENUIHBhY2sp LTIuNzUgRQooZXQgdHJhbnNtaXR0ZWQgZm9yKS0uMTEgRSh0aGUgb2JqZWN0LCBvciBpdCBN QSkxMDUgNjI1LjggUSAyLjc1KFliKQotMS4xNTUgRyAyLjc1KGVzKS0yLjc1IEcoZXQgdG8g MSBpbiB0aGUgbGFzdCBjb3VwbGUgb2Ygc2Vjb25kcyBMQ1QgcGFjaykKLTIuNzUgRShldHMg dHJhbnNtaXR0ZWQgZm9yKS0uMTEgRSh0aGUgb2JqZWN0LikxMDUgNjM4LjggUQooT25jZSB0 aGUgc2VuZGVyIHNldHMgdGhlIENsb3NlIFQpNS41IEUoT0kgXDIxNWFnIHRvIDEgaW4gb25l IHBhY2spLS4xOTgKRShldCBmb3IgYSBwYXJ0aWN1bGFyKS0uMTEgRShvYmplY3QsIHRoZSBz ZW5kZXIgU0hPVUxEIHNldCB0aGUgQ2xvc2UgVCkKMTA1IDY1MS44IFEoT0kgXDIxNWFnIHRv IDEgaW4gYWxsIHN1YnNlcXVlbnQgcGFjayktLjE5OCBFKGV0cyBmb3IgdGhlKQotLjExIEUo b2JqZWN0IHVudGlsIHRlcm1pbmF0aW9uIG9mIHRyYW5zbWlzc2lvbiBvZiBMQ1QgcGFjaykx MDUgNjY0LjggUQooZXRzIGZvciB0aGUgb2JqZWN0LiktLjExIEUgMi43NShBcik1LjUgRyhl Y2VpKS0yLjc1IEUgLS4xNjUodmUpLS4yNzUgRwoyLjc1KGRwKS4xNjUgRyhhY2spLTIuNzUg RShldCktLjExIEUod2l0aCB0aGUgQ2xvc2UgVCkxMDUgNjc3LjggUQooT0kgXDIxNWFnIHNl dCB0byAxIGluZGljYXRlcyB0byBhIHJlY2VpKS0uMTk4IEUgLS4xNjUodmUpLS4yNzUgRyAy Ljc1CihydCkuMTY1IEcoaGF0IHRoZSBzZW5kZXIgd2lsbCBpbW1lZGlhdGVseSktMi43NSBF CihzdG9wIHNlbmRpbmcgTENUIHBhY2spMTA1IDY5MC44IFEKKGV0cyBmb3IgdGhlIG9iamVj dCBpZGVudGlcMjE0ZWQgYnkgdGhlIFQpLS4xMSBFIDIuNzUoT0kuIFdoZW4pLS4xOTggRgoy Ljc1KGFyKTIuNzUgRyhlY2VpKS0yLjc1IEUgLS4xNjUodmUpLS4yNzUgRyAyLjc1KHJyKS4x NjUgRyhlY2VpKS0yLjc1IEUKLS4xNjUodmUpLS4yNzUgRyAyLjc1KHNhKS4xNjUgRyhwYWNr KTEwNSA3MDMuOCBRKGV0IHdpdGggdGhlIENsb3NlIFQpCi0uMTEgRShPSSBcMjE1YWcgc2V0 IHRvIDEgdGhlbiBpdCBzaG91bGQgYXNzdW1lIHRoYXQgbm8gbW9yZSBMQ1QgcGFjaykKLS4x OTggRShldHMpLS4xMSBFKHdpbGwgYmUgc2VudCB0byB0aGUgc2Vzc2lvbiBmb3IgdGhpcyBv YmplY3QuKTEwNQo3MTYuOCBRKEx1YnkvR2VtbWVsbC9WKTcyIDc2OSBRKGljaXNhbm8vUml6 em8vSGFuZGxlKS0uNjYgRSh5L0NybyktLjE2NQpFIDEwMy42MDYod2Nyb2Z0IFNlY3Rpb24p LS4yNzUgRiAyLjc1KDMuMi4gW1ApMi43NSBGKGFnZSAxMF0pLS4xNjUgRSBFUAolJVBhZ2U6 IDExIDExCiUlQmVnaW5QYWdlU2V0dXAKQlAKJSVFbmRQYWdlU2V0dXAKL0YwIDExL1RpbWVz LVJvbWFuQDAgU0YoSU5URVJORVQpNzIgNDkgUSA3MS41ODcoLURSQUZUIEV4cGlyZXM6KS0x LjAxMiBGCihKYW51YXJ5IDIwMDIpMi43NSBFKEp1bHkgMjAwMSkxMjMuNzI2IEUKKENsb3Nl IFNlc3Npb24gXDIxNWFnIFwoQlwpOiAxIGJpdCk4MyA4NSBRKE5vcm1hbGx5KTEwNSAxMDEu NiBRIDIuNzUoLHQpCi0uNzE1IEcoaGUgQ2xvc2UgU2Vzc2lvbiBcMjE1YWcgaXMgc2V0IHRv IDAuKS0yLjc1IEUoVGhlIHNlbmRlciBNQSk1LjUgRQoyLjc1KFlzKS0xLjE1NSBHKGV0IHRo ZSBDbG9zZSBTZXNzaW9uIFwyMTVhZyB0byktMi43NSBFIDIuNzUoMXcpMTA1CjExNC42IFMo aGVuIHRlcm1pbmF0aW9uIG9mIHRyYW5zbWlzc2lvbiBvZiBMQ1QgcGFjayktMi43NSBFCihl dHMgZm9yIHRoZSBzZXNzaW9uIGlzIGltbWluZW50LiktLjExIEUoVGhlKTUuNSBFCihDbG9z ZSBTZXNzaW9uIFwyMTVhZyBNQSkxMDUgMTI3LjYgUSAyLjc1KFliKS0xLjE1NSBHIDIuNzUo ZXMpLTIuNzUgRwooZXQgdG8gMSBpbiBqdXN0IHRoZSBsYXN0IExDVCBwYWNrKS0yLjc1IEUK KGV0IHRyYW5zbWl0dGVkIGZvciB0aGUgc2Vzc2lvbiwpLS4xMSBFKG9yIGl0IE1BKTEwNSAx NDAuNiBRIDIuNzUoWWIpCi0xLjE1NSBHIDIuNzUoZXMpLTIuNzUgRyhldCB0byAxIGluIHRo ZSBsYXN0IGNvdXBsZSBvZiBzZWNvbmRzIExDVCBwYWNrKQotMi43NSBFKGV0cyB0cmFuc21p dHRlZCBmb3IgdGhlKS0uMTEgRSAyLjc1KHNlc3Npb24uIE9uY2UpMTA1IDE1My42IFIKKHRo ZSBzZW5kZXIgc2V0cyB0aGUgQ2xvc2UgU2Vzc2lvbiBcMjE1YWcgdG8gMSBpbiBvbmUgcGFj aykyLjc1IEUKKGV0LCB0aGUgc2VuZGVyKS0uMTEgRQooU0hPVUxEIHNldCB0aGUgQ2xvc2Ug U2Vzc2lvbiBcMjE1YWcgdG8gMSBpbiBhbGwgc3Vic2VxdWVudCBwYWNrKTEwNQoxNjYuNiBR KGV0cyB1bnRpbCB0ZXJtaW5hdGlvbiBvZiktLjExIEUodHJhbnNtaXNzaW9uIG9mIExDVCBw YWNrKTEwNQoxNzkuNiBRKGV0cyBmb3IgdGhlIHNlc3Npb24uKS0uMTEgRSAyLjc1KEFyKTUu NSBHKGVjZWkpLTIuNzUgRSAtLjE2NSh2ZSkKLS4yNzUgRyAyLjc1KGRwKS4xNjUgRyhhY2sp LTIuNzUgRShldCB3aXRoIHRoZSBDbG9zZSBTZXNzaW9uKS0uMTEgRQooXDIxNWFnIHNldCB0 byAxIGluZGljYXRlcyB0byBhIHJlY2VpKTEwNSAxOTIuNiBRIC0uMTY1KHZlKS0uMjc1IEcg Mi43NQoocnQpLjE2NSBHKGhhdCB0aGUgc2VuZGVyIHdpbGwgaW1tZWRpYXRlbHkgc3RvcCBz ZW5kaW5nIExDVCktMi43NSBFCihwYWNrKTEwNSAyMDUuNiBRKGV0cyBmb3IgdGhlIHNlc3Np b24uKS0uMTEgRShXaGVuIGEgcmVjZWkpNS41IEUgLS4xNjUKKHZlKS0uMjc1IEcgMi43NShy cikuMTY1IEcoZWNlaSktMi43NSBFIC0uMTY1KHZlKS0uMjc1IEcgMi43NShzYXApLjE2NSBH CihhY2spLTIuNzUgRShldCB3aXRoIHRoZSBDbG9zZSBTZXNzaW9uIFwyMTVhZyBzZXQpLS4x MSBFCih0byAxIHRoZW4gaXQgc2hvdWxkIGFzc3VtZSB0aGF0IG5vIG1vcmUgTENUIHBhY2sp MTA1IDIxOC42IFEKKGV0cyB3aWxsIGJlIHNlbnQgdG8gdGhlIHNlc3Npb24uKS0uMTEgRShM Q1QgcGFjayk4MyAyNDguMiBRCihldCBoZWFkZXIgbGVuZ3RoIFwoSERSX0xFTlwpOiA4IGJp dHMpLS4xMSBFKExlbmd0aCBvZiB0aGUgTENUIHBhY2spMTA1CjI2NC44IFEoZXQgaGVhZGVy IGluIHVuaXRzIG9mIDMyLWJpdCB3KS0uMTEgRShvcmRzIFwoZSktLjExIEUKKHhjbHVkaW5n IElQIG9yIFVEUCBoZWFkZXJzXCkuKS0uMTY1IEUKKFRoaXMgXDIxNGVsZCBjYW4gYmUgdXNl ZCBmb3IgZGlyZWN0IGFjY2VzcyB0byB0aGUgYmUpMTA1IDI3Ny44IFEKKGdpbm5pbmcgb2Yg dGhlIExDVCBwYWNrKS0uMTY1IEUoZXQgcGF5bG9hZC4pLS4xMSBFCihDb2RlcG9pbnQgXChD UFwpOiA4IGJpdHMpODMgMzA3LjQgUQooQW4gb3BhcXVlIGlkZW50aVwyMTRlciB3aGljaCBp cyBwYXNzZWQgdG8gdGhlIHBheWxvYWQgZGVjb2RlciB0byBjb24pCjEwNSAzMjQgUSAuMzMg LS4xNjUodmV5IGkpLS40NCBIKG5mb3JtYXRpb24gb24gdGhlKS4xNjUgRShjb2RlYyBiZWlu ZyB1XApzZWQgZm9yIHRoZSBwYXlsb2FkLiBUaGUgbWFwcGluZyBiZXR3ZWVuIHRoZSBjb2Rl cG9pbnQgYW5kIHRoZSBhY3R1YWwpCjEwNSAzMzcgUShjb2RlYyBpcyBkZVwyMTRuZWQgb24g YSBwZXIgc2Vzc2lvbiBiYXNpcyBhbmQgY29tbXVuaWNhdGVkIG91XAp0LW9mLWJhbmQgYXMg cGFydCBvZiB0aGUpMTA1IDM1MCBRKHNlc3Npb24gZGVzY3JpcHRpb24gaW5mb3JtYXRpb24u KTEwNQozNjMgUShUaGUgdXNlIG9mIHRoZSBDUCBcMjE0ZWxkIGlzIHNpbWlsYXIgdG8gdGhl IFApNS41IEUoYXlsb2FkIFQpLS4xNjUKRSh5cGUpLS44OCBFKFwoUFRcKSBcMjE0ZWxkIGlu IFIpMTA1IDM3NiBRCihUUCBoZWFkZXJzIGFzIGRlc2NyaWJlZCBpbiBSRkMxODg5LiktLjY2 IEUKKENvbmdlc3Rpb24gQ29udHJvbCBJbmZvcm1hdGlvbiBcKENDSVwpOiAzMiBiaXRzKTgz IDQwNS42IFEoVXNlZCB0byBjYXJcCnJ5IGNvbmdlc3Rpb24gY29udHJvbCBpbmZvcm1hdGlv biwgZS5nLiBmb3IgdGhlIGNvbmdlc3Rpb24gY29udHJvbCBzcGVjXAppXDIxNGVkIGluKTEw NSA0MjIuMiBRKFs5XSBvciBvdGhlciBjb25nZXN0aW9uIGNvbnRyb2wgc2NoZW1lcy4pMTA1 CjQzNS4yIFEoVGhpcyBcMjE0ZWxkIGlzIG9wYXF1ZSBmb3IgdGhlIHB1cnBvc2Ugb2YgdGhp cyk1LjUgRQooc3BlY2lcMjE0Y2F0aW9uLikxMDUgNDQ4LjIgUSAtLjM4NShUcik4MyA0Nzcu OCBTCihhbnNwb3J0IE9iamVjdCBJZGVudGlcMjE0ZXIgXChUKS4zODUgRQooT0lcKTogMzIs IDY0IG9yIDEyOCBiaXRzIFwoT1BUSU9OKS0uMTk4IEUoQUxcKSktLjM4NSBFCihUaGlzIFwy MTRlbGQgaW5kaWNhdGVzIHdoaWNoIG9iamVjdCB3aXRoaW4gdGhlIHNlc3Npb24gdGhpcyBM Q1QgcGFjaykKMTA1IDQ5NC40IFEoZXQgcGVydGFpbnMgdG8uKS0uMTEgRSAtLjE2NShGbyk1 LjUgRyhyKS4xNjUgRSAtLjE2NShleCkxMDUKNTA3LjQgUyhhbXBsZSwgYSBzZW5kZXIgbWln aHQgc2VuZCBhIG51bWJlciBvZiBcMjE0bGVzIGluIHRoZSBzYW1lIHNlc3NcCmlvbiwgdXNp bmcgVCkuMTY1IEUoT0k9MCBmb3IgdGhlKS0uMTk4IEUoXDIxNHJzdCBcMjE0bGUsIFQpMTA1 IDUyMC40IFEKKE9JPTEgZm9yIHRoZSBzZWNvbmQgb25lLCBldGMuKS0uMTk4IEUoVGhlIG1h cHBpbmcgb2YgVCk1LjUgRQooT0kgXDIxNGVsZCB2KS0uMTk4IEUoYWx1ZXMgdG8gb2JqZWN0 cyktLjI3NSBFCihNVVNUIGJlIGRvbmUgb3V0IG9mIGJhbmQuKTEwNSA1MzMuNCBRKFRoaXMg XDIxNGVsZCBNVVNUIE5PKTEwNSA1NDYuNCBRCjIuNzUoVGIpLS40NCBHIDIuNzUoZXApLTIu NzUgRyhyZXNlbnQgaWYgST0wLiktMi43NSBFCihUaGlzIFwyMTRlbGQgTVVTVCBiZSAzMiBi aXRzIGlmIEk9MS4pMTA1IDU1OS40IFEKKFRoaXMgXDIxNGVsZCBNVVNUIGJlIDY0IGJpdHMg aWYgST0yLikxMDUgNTcyLjQgUQooVGhpcyBcMjE0ZWxkIE1VU1QgYmUgMTI4IGJpdHMgaWYg ST0zLikxMDUgNTg1LjQgUShTZW5kZXIgQ3VycmVudCBUKTgzCjYxNSBRKGltZSBcKFNDVFwp OiAzMiBiaXRzIFwoT1BUSU9OKS0uMzg1IEUoQUxcKSktLjM4NSBFKFRoaXMgXDIxNGVsZCBy XAplcHJlc2VudHMgdGhlIGN1cnJlbnQgY2xvY2sgYXQgdGhlIHNlbmRlciBhdCB0aGUgdGlt ZSB0aGlzIHBhY2spMTA1CjYzMS42IFEoZXQgdyktLjExIEUoYXMgdHJhbnNtaXR0ZWQsKS0u MTEgRShtZWFzdXJlZCBpbiB1bml0cyBvZiAxbXMgYW5kXAogY29tcHV0ZWQgbW9kdWxvIDJe MzIgdW5pdHMgZnJvbSB0aGUgc3RhcnQgb2YgdGhlIHNlc3Npb24uKTEwNSA2NDQuNiBRCihU aGlzIFwyMTRlbGQgTVVTVCBOTykxMDUgNjU3LjYgUSAyLjc1KFRiKS0uNDQgRyAyLjc1KGVw KS0yLjc1IEcKKHJlc2VudCBpZiBTPTAgYW5kIE1VU1QgYmUgcHJlc2VudCBpZiBTPTEuKS0y Ljc1IEUoRXhwZWN0ZWQgUmVzaWR1YWwgVCkKODMgNjg3LjIgUShpbWUgXChFUiktLjM4NSBF KFRcKTogMzIgYml0cyBcKE9QVElPTiktLjY2IEUoQUxcKSktLjM4NSBFCihUaGlzIFwyMTRl bGQgcmVwcmVzZW50cyB0aGUgc2VuZGVyIGUpMTA1IDcwMy44IFEKKHhwZWN0ZWQgcmVzaWR1 YWwgdHJhbnNtaXNzaW9uIHRpbWUgZm9yIHRoZSBjdXJyZW50KS0uMTY1IEUKKHNlc3Npb24s IG1lYXN1cmVkIGluIHVuaXRzIG9mIDFtcy4pMTA1IDcxNi44IFEoTHVieS9HZW1tZWxsL1Yp NzIgNzY5IFEKKGljaXNhbm8vUml6em8vSGFuZGxlKS0uNjYgRSh5L0NybyktLjE2NSBFIDEw My42MDYod2Nyb2Z0IFNlY3Rpb24pLS4yNzUKRiAyLjc1KDMuMi4gW1ApMi43NSBGKGFnZSAx MV0pLS4xNjUgRSBFUAolJVBhZ2U6IDEyIDEyCiUlQmVnaW5QYWdlU2V0dXAKQlAKJSVFbmRQ YWdlU2V0dXAKL0YwIDExL1RpbWVzLVJvbWFuQDAgU0YoSU5URVJORVQpNzIgNDkgUSA3MS41 ODcoLURSQUZUIEV4cGlyZXM6KS0xLjAxMiBGCihKYW51YXJ5IDIwMDIpMi43NSBFKEp1bHkg MjAwMSkxMjMuNzI2IEUoVGhpcyBcMjE0ZWxkIE1VU1QgTk8pMTA1IDg1IFEKMi43NShUYikt LjQ0IEcgMi43NShlcCktMi43NSBHCihyZXNlbnQgaWYgRT0wIGFuZCBNVVNUIGJlIHByZXNl bnQgaWYgRT0xLiktMi43NSBFL0YxIDExL1RpbWVzLUJvbGRAMCBTRgooMy4zLik3MiAxMjQg US9GMiAxMy9UaW1lcy1Cb2xkQDAgU0YoSGVhZGVyKTUuNSBFKC1FeHRlbnNpb24gRmllbGRz KQotLjQ4MSBFIEYwIDEuNzYgLS44OChUbyBhKTcyIDE0MC42IFQobGxvKS44OCBFIDIuNzUo d2YpLS4yNzUgRwoob3IgYWRkaXRpb25hbCBoZWFkZXIgXDIxNGVsZHMgYW5kIHRvIGUpLTIu NzUgRQooeHRlbmQgdGhlIHNpemUgb2Ygc29tZSBvZiB0aGUgcHJlZGVcMjE0bmVkIFwyMTRl bGRzLCB0aGUpLS4xNjUgRQooTENUIHBhY2spNzIgMTUzLjYgUShldCBoZWFkZXIgY29udGFp bnMgYW4gYWRkaXRpb25hbCBoZWFkZXIgXDIxNGVsZCBcClwyMTVhZywgIlgiLiBJZiAiWCIg aXMgc2V0IHRvIDAgdGhlbiBubyktLjExIEUKKGFkZGl0aW9uYWwgaGVhZGVyIFwyMTRlbGRz IGFyZSBpbmNsdWRlZCB3aXRoaW4gdGhlIExDVCBwYWNrKTcyIDE2Ni42IFEKKGV0IGhlYWRl ciBiZSktLjExIEUoeW9uZCB0aGUgcHJlZGVcMjE0bmVkIFwyMTRlbGRzLiktLjE2NSBFCihX aGVuIGFkZGl0aW9uYWwgaGVhZGVycyBiZSk3MiAxNzkuNiBRCih5b25kIHRoZSBwcmVkZVwy MTRuZWQgXDIxNGVsZHMgYXJlIHVzZWQsIHRoZSB2KS0uMTY1IEUKKGFsdWUgb2YgIlgiIHdp dGhpbiB0aGUgTENUKS0uMjc1IEUocGFjayk3MiAxOTIuNiBRCihldCBoZWFkZXIgTVVTVCBi ZSBzZXQgdG8gMS4pLS4xMSBFCihFeGFtcGxlcyBvZiB1c2Ugb2YgSGVhZGVyIEV4dGVuc2lv bnMgaW5jbHVkZTopNzIgMjE4LjYgUSAxMShvRSk3Ny41CjIzNS4yIFMoeHRlbmRlZC1zaXpl IHYpLTExIEUoZXJzaW9uIG9mIGFscmVhZHkgZSktLjE2NSBFCih4aXN0aW5nIGhlYWRlciBc MjE0ZWxkcy4pLS4xNjUgRSAxMShvUyk3Ny41IDI1MS44IFMoZW5kZXIgYW5kIFJlY2VpKS0x MQpFIC0uMTY1KHZlKS0uMjc1IEcgMi43NShyYSkuMTY1IEcodXRoZW50aWNhdGlvbiBpbmZv cm1hdGlvbi4pLTIuNzUgRQooSWYgcHJlc2VudCwgSGVhZGVyIEV4dGVuc2lvbnMgTVVTVCBi ZSBwcm9jZXNzZWQgdG8gZW5zdXJlIHRoYXQgdGhlKTcyCjI4MS40IFEgMi43NSh5YSktLjE2 NSBHKHJlIHJlY29nbml6ZWQgYmVmb3JlKS0yLjc1IEUocGVyZm9ybWluZyBhbik3MgoyOTQu NCBRIDIuNzUoeWMpLS4xNjUgRwoob25nZXN0aW9uIGNvbnRyb2wgcHJvY2VkdXJlIG9yIG90 aGVyd2lzZSBhY2NlcHRpbmcgYW4gTENUIHBhY2spLTIuNzUgRQooZXQuIExDVCBwYWNrKS0u MTEgRShldHMpLS4xMSBFCih3aXRoIHVucmVjb2duaXNlZCBIZWFkZXIgRXh0ZW5zaW9ucyBN VVNUIGJlIGRpc2NhcmRlZCBieSB0aGUgcmVjZWkpNzIKMzA3LjQgUSh2aW5nIGFnZW50LCBo ZW5jZSB0aGUpLS4yNzUgRSAtLjE2NShleCk3MiAzMjAuNCBTCihwZWN0ZWQgdXNlIG9mIGUp LjE2NSBFCih4dGVuc2lvbnMgU0hPVUxEIGJlIHNpZ25hbGVkIG91dC1vZi1iYW5kIGJlZm9y ZSBzZXNzaW9uIHN0YXJ0dXAuKS0uMTY1CkUoVGhlcmUgYXJlIHR3KTcyIDM0Ni40IFEgMi43 NShvZiktLjExIEcKKG9ybWF0cyBmb3IgSGVhZGVyIEV4dGVuc2lvbiBcMjE0ZWxkcywgYXMg ZGVwaWN0ZWQgYmVsbyktMi43NSBFIDEuNDMKLS43MTUody4gVCktLjI3NSBIKGhlIFwyMTRy c3QgZm9ybWF0IGlzIHVzZWQgZm9yKS43MTUgRSAtLjI3NSh2YSk3MgozNTkuNCBTKHJpYWJs ZS1sZW5ndGggZSkuMjc1IEUoeHRlbnNpb25zLCB3aXRoIEhlYWRlciBFeHRlbnNpb24gVCkt LjE2NQpFKHlwZSBcKEhFVFwpIHYpLS44OCBFKGFsdWVzIGJldHdlZW4gMCBhbmQgNjMuIFRo ZSktLjI3NSBFCihzZWNvbmQgZm9ybWF0IGlzIHVzZWQgZm9yIFwyMTR4KTcyIDM3Mi40IFEo ZWQgbGVuZ3RoIFwob25lIHcpLS4xNjUgRQoob3JkXCkgZSktLjExIEUoeHRlbnNpb24sIHVz aW5nIEhFVCB2KS0uMTY1IEUoYWx1ZXMgZnJvbSA2NCB0byAxMjcuKQotLjI3NSBFL0YzIDgv Q291cmllckAwIFNGIDkxLjIoMDEyMyk4MS42IDQxMS40IFMgNC44CigwMTIzNDU2Nzg5MDEy MzQ1Njc4OTAxMjM0NTY3ODkwMSk4MS42IDQyNC40IFMKKCstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rKTc2LjgKNDM3 LjQgUSh8THwgSEVUIFwoPD02M1wpKTc2LjggNDUwLjQgUSAzMy42KHxIKTkuNiBHIDE5LjIo RUwgfCktMzMuNiBGKHwpCjE0OC44IEUgMTQ0KCstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKyArKTc2LjggNDYzLjQgUiAzMDIuNCguLikKNzYuOCA0NzYuNCBTIDY3LjIoLkgp NzYuOCA0ODkuNCBTKGVhZGVyIEV4dGVuc2lvbiBDb250ZW50IFwoSEVDXCkpLTY3LjIKRSgu KTkxLjIgRQooKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSspNzYuOAo1MDIuNCBRIDkxLjIoMDEyMyk4MS42IDUyOC40 IFMgNC44KDAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxKTgxLjYKNTQxLjQgUwoo Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSspNzYuOAo1NTQuNCBRKHxMfCBIRVQgXCg+PTY0XCkpNzYuOCA1NjcuNCBR IDMzLjYofEgpOS42IEcKKGVhZGVyIEV4dGVuc2lvbiBDb250ZW50IFwoSEVDXCkpLTMzLjYg RSh8KTQ4IEUKKCstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rKTc2LjgKNTgwLjQgUS9GNCAxMC9UaW1lcy1Sb21hbkAw IFNGKEZpZ3VyZSA1IC0gRik3MiA2MTkuNCBRCihvcm1hdCBvZiBhZGRpdGlvbmFsIGhlYWRl cnMpLS4xNSBFIEYwKFRoZSBlKTcyIDY0OSBRCih4cGxhbmF0aW9uIG9mIGVhY2ggc3ViLVwy MTRlbGQgaXMgdGhlIGZvbGxvKS0uMTY1IEUod2luZy4pLS4yNzUgRQooTGFzdCBIZWFkZXIg RXh0ZW5zaW9uIFwoTFwpOiAxIGJpdCk4MyA2NzguNiBRKE1VU1QgYmUgc2V0IHRvIDEgaW4g dGhlIFwKbGFzdCBIZWFkZXIgRXh0ZW5zaW9uIFwyMTRlbGQgcHJlc2VudCBpbiBhbiBMQ1Qg cGFjaykxMDUgNjk1LjIgUQooZXQgaGVhZGVyKS0uMTEgRSgsKS0uNDQgRShNVVNUIGJlIHNl dCB0byAwIGluIGFsbCB0aGUgb3RoZXJzLikxMDUgNzA4LjIKUShMdWJ5L0dlbW1lbGwvVik3 MiA3NjkgUShpY2lzYW5vL1JpenpvL0hhbmRsZSktLjY2IEUoeS9Dcm8pLS4xNjUgRQoxMDMu NjA2KHdjcm9mdCBTZWN0aW9uKS0uMjc1IEYgMi43NSgzLjMuIFtQKTIuNzUgRihhZ2UgMTJd KS0uMTY1IEUgRVAKJSVQYWdlOiAxMyAxMwolJUJlZ2luUGFnZVNldHVwCkJQCiUlRW5kUGFn ZVNldHVwCi9GMCAxMS9UaW1lcy1Sb21hbkAwIFNGKElOVEVSTkVUKTcyIDQ5IFEgNzEuNTg3 KC1EUkFGVCBFeHBpcmVzOiktMS4wMTIgRgooSmFudWFyeSAyMDAyKTIuNzUgRShKdWx5IDIw MDEpMTIzLjcyNiBFKEhlYWRlciBFeHRlbnNpb24gVCk4MyA4NSBRCih5cGUgXChIRVRcKTog NyBiaXRzKS0uODggRShUaGUgdHlwZSBvZiB0aGUgSGVhZGVyIEV4dGVuc2lvbi4gVGhpcyBk b2N1XAptZW50IGRlXDIxNG5lcyBhIG51bWJlciBvZiBwb3NzaWJsZSB0eXBlcy4pMTA1IDEw MS42IFEKKEFkZGl0aW9uYWwgdHlwZXMgbWF5IGJlIGRlXDIxNG5lZCBpbiBmdXR1cmUgdikx MDUgMTE0LjYgUQooZXJzaW9uIG9mIHRoaXMgc3BlY2lcMjE0Y2F0aW9uLiBIRVQgdiktLjE2 NSBFKGFsdWVzIGZyb20gMCktLjI3NSBFCih0byA2MyBhcmUgdXNlZCBmb3IgdikxMDUgMTI3 LjYgUQooYXJpYWJsZS1sZW5ndGggSGVhZGVyIEV4dGVuc2lvbnMuIEhFVCB2KS0uMjc1IEUK KGFsdWVzIGZyb20gNjQgdG8gMTI3IGFyZSB1c2VkKS0uMjc1IEUoZm9yIFwyMTR4KTEwNSAx NDAuNiBRCihlZC1sZW5ndGggSGVhZGVyIEV4dGVuc2lvbnMuKS0uMTY1IEUKKEhlYWRlciBF eHRlbnNpb24gTGVuZ3RoIFwoSEVMXCk6IDggYml0cyk4MyAxNzAuMiBRCihUaGUgbGVuZ3Ro IG9mIHRoZSB3aG9sZSBIZWFkZXIgRXh0ZW5zaW9uIFwyMTRlbGQsIGUpMTA1IDE4Ni44IFEK KHhwcmVzc2VkIGluIG11bHRpcGxlcyBvZiAzMi1iaXQgdyktLjE2NSBFKG9yZHMuKS0uMTEg RQooVGhpcyBcMjE0ZWxkIE1VU1QgYmUgcHJlc2VudCBmb3IgdikxMDUgMTk5LjggUShhcmlh YmxlLWxlbmd0aCBlKS0uMjc1IEUKKHh0ZW5zaW9ucyBcKEhFVCBiZXR3ZWVuIDAgYW5kIDYz XCkgYW5kKS0uMTY1IEUoTVVTVCBOTykxMDUgMjEyLjggUSAyLjc1CihUYiktLjQ0IEcgMi43 NShlcCktMi43NSBHKHJlc2VudCBmb3IgXDIxNHgpLTIuNzUgRShlZC1sZW5ndGggZSktLjE2 NSBFCih4dGVuc2lvbnMgXChIRVQgYmV0d2VlbiA2NCBhbmQgMTI3XCkuKS0uMTY1IEUKKEhl YWRlciBFeHRlbnNpb24gQ29udGVudCBcKEhFQ1wpOiB2KTg1Ljc1IDI0Mi40IFEoYXJpYWJs ZSBsZW5ndGgpLS4yNzUKRShUaGUgY29udGVudCBvZiB0aGUgSGVhZGVyIEV4dGVuc2lvbi4g VGhlIGZvcm1hdCBvZiB0aGlzIHN1Yi1cMjE0ZWxkIGRcCmVwZW5kcyBvbiB0aGUgSGVhZGVy KTEwNSAyNTkgUShFeHRlbnNpb24gdHlwZS4pMTA1IDI3MiBRIC0uMTY1KEZvKTUuNSBHCjIu NzU8NzI4Yz4uMTY1IEcgLS4xNjUoeGUpLTIuNzUgRwooZC1sZW5ndGggSGVhZGVyIEV4dGVu c2lvbnMsIHRoZSBIRUMgaXMgMjQgYml0cy4pLjE2NSBFIC0uMTY1KEZvKTUuNSBHCjIuNzUo cnYpLjE2NSBHKGFyaWFibGUtKS0zLjAyNSBFCihsZW5ndGggSGVhZGVyIEV4dGVuc2lvbnMs IHRoZSBIRUMgXDIxNGVsZCBoYXMgdikxMDUgMjg1IFEKKGFyaWFibGUgc2l6ZSwgYXMgc3Bl Y2lcMjE0ZWQgYnkgdGhlIEhFTCBcMjE0ZWxkLiktLjI3NSBFKE5vdGUgdGhhdCB0aGVcCiBs ZW5ndGggb2YgZWFjaCBIZWFkZXIgRXh0ZW5zaW9uIFwyMTRlbGQgTVVTVCBiZSBhIG11bHRp cGxlIG9mIDMyIGJpdHMuKQoxMDUgMjk4IFEoQWxzbyk1LjUgRShub3RlIHRoYXQgdGhlIHRv dGFsIHNpemUgb2YgdGhlIExDVCBwYWNrKTEwNSAzMTEgUQooZXQgaGVhZGVyKS0uMTEgRSAy Ljc1KCxpKS0uNDQgRyhuY2x1ZGluZyBhbGwgSGVhZGVyIEV4dGVuc2lvbnMgYW5kIGFsbCkK LTIuNzUgRShPUFRJT04pMTA1IDMyNCBRKEFMIGhlYWRlciBcMjE0ZWxkcywgY2Fubm90IGUp LS4zODUgRQooeGNlZWQgMjU1IDMyLWJpdCB3KS0uMTY1IEUob3Jkcy4pLS4xMSBFKEFuIExD VCBwYWNrKTcyIDM1My42IFEKKGV0IHdpdGggSGVhZGVyIEV4dGVuc2lvbnMgTVVTVCBOTykt LjExIEUgMi43NShUaCktLjQ0IEcgLTIuNDc1IC0uMjIKKGF2IGUpLTIuNzUgSChzcGFjZSBi ZXR3ZWVuIHRoZSBlbmQgb2YgdGhlIGxhc3QpMi45NyBFCihIZWFkZXIgRXh0ZW5zaW9uIGFu ZCB0aGUgYmUpNzIgMzY2LjYgUShnaW5uaW5nIG9mIHRoZSBMQ1QgcGFjayktLjE2NSBFCihl dCBwYXlsb2FkLiktLjExIEUoQWxsIHNlbmRlcnMgYW5kIHJlY2VpKTcyIDM5Mi42IFEgLS4x NjUodmUpLS4yNzUgRwoocnMgb2YgTENUIHBhY2spLjE2NSBFKGV0cyBNVVNUIHN1cHBvcnQg dGhlIEVYVF9OT1AgSGVhZGVyIEV4dGVuc2lvbi4pCi0uMTEgRShUaGUgZm9sbG8pNzIgNDE4 LjYgUSh3aW5nIEhlYWRlciBFeHRlbnNpb24gdHlwZXMgYXJlIGRlXDIxNG5lZDopCi0uMjc1 IEUgMTMuNjYyKEVYVF9OT1A9MCBOby1PcGVyYXRpb24pNzIgNDQ4LjIgUiAtLjE2NShleCky Ljc1IEcKKHRlbnNpb24uKS4xNjUgRShUaGUgaW5mb3JtYXRpb24gcHJlc2VudCBpbiB0aGlz IGUpMTQ5IDQ2MS4yIFEKKHh0ZW5zaW9uIFwyMTRlbGQgTVVTVCBiZSBpZ25vcmVkIGJ5IHJl Y2VpKS0uMTY1IEUgLS4xNjUodmUpLS4yNzUgRyhycy4pCi4xNjUgRSAzLjg4MyhFWFRfQ0NJ X1Y9MSBDb25nZXN0aW9uKTcyIDQ5MC44IFIoQ29udHJvbCBJbmZvcm1hdGlvbiBlKQoyLjc1 IEUoeHRlbnNpb24sIHYpLS4xNjUgRShhcmlhYmxlIGxlbmd0aC4pLS4yNzUgRShUaGlzIGUp MTQ5IDUwMy44IFEKKHh0ZW5zaW9uIFwyMTRlbGQgZSktLjE2NSBFKHh0ZW5kcyB0aGUgQ0NJ IFwyMTRlbGQgcHJlc2VudCBpbiB0aGUgXDIxNHgpCi0uMTY1IEUoZWQgcGFydCBvZiB0aGUg aGVhZGVyKS0uMTY1IEUoLiktLjYwNSBFKEl0IGlzIHVzZWQgd2hlbiB0aGUgY29uXApnZXN0 aW9uIGNvbnRyb2wgaW5mb3JtYXRpb24gZG9lcyBub3QgXDIxNHQgaW4gdGhlIDMyLWJpdCBD Q0kpMTQ5IDUxNi44IFEKKFwyMTRlbGQuIFdoZW4gdGhpcyBvcHRpb24gaXMgcHJlc2VudCwg dGhlIGNvbmNhdGVuYXRpb24gb2YgdGhlIDMyLWJpdCBcCkNDSSBcMjE0ZWxkIGluKTE0OSA1 MjkuOCBRKHRoZSBcMjE0eCkxNDkgNTQyLjggUQooZWQgcGFydCBvZiB0aGUgaGVhZGVyIHRv Z2V0aGVyIHdpdGggdGhlIHYpLS4xNjUgRShhcmlhYmxlIGxlbmd0aCB2KQotLjI3NSBFKGFs dWUgcHJvKS0uMjc1IEUodmlkZWQgaW4pLS4xNjUgRQoodGhpcyBvcHRpb24gaXMgdXNlZCBh cyB0aGUgY29uZ2VzdGlvbiBjb250cm9sIGluZm9ybWF0aW9uLikxNDkgNTU1LjggUQooVGhl IGludGVycHJldGF0aW9uIG9mKTUuNSBFKHRoZSBkYXRhIGNvbnRhaW5lZCBpbiBFWFRfQ0NJ X1YgTVVTVCBiZSBuZSkKMTQ5IDU2OC44IFEoZ290aWF0ZWQgb3V0LW9mLWJhbmQuKS0uMTY1 IEUoVGhlIHVzZSk1LjUgRQoob2YgRVhUX0NDSV9WIGFuZCBFWFRfQ0NJX0YgaXMgbXV0dWFs bHkgZSkxNDkgNTgxLjggUSh4Y2x1c2kpLS4xNjUgRQotLjE2NSh2ZSktLjI3NSBHKC4pLjE2 NSBFKEVYVF9BKTcyIDYxMS40IFEgNS43MihVVEg9MiBBdXRoZW50aWNhdGlvbikKLS42MDUg RiAtLjE2NShleCkyLjc1IEcodGVuc2lvbikuMTY1IEUKKEluZm9ybWF0aW9uIHVzZWQgdG8g YXV0aGVudGljYXRlIHRoZSBzZW5kZXIgb2YgdGhlIExDVCBwYWNrKTE0OSA2MjQuNCBRCjIu NzUoZXQuIElmKS0uMTEgRihwcmVzZW50LCB0aGUpMi43NSBFKGZvcm1hdCBvZiB0aGlzIEhl YWRlciBFeHRlbnNpb24gXAphbmQgaXRzIHByb2Nlc3NpbmcgTVVTVCBiZSBjb21tdW5pY2F0 ZWQpMTQ5IDYzNy40IFEKKG91dC1vZi1iYW5kIGFzIHBhcnQgb2YgdGhlIHNlc3Npb24gZGVz Y3JpcHRpb24uKTE0OSA2NTAuNCBRCihJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IHNlbmRlcnMg cHJvKTE0OSA2NjMuNCBRCih2aWRlIHNvbWUgZm9ybSBvZiBhdXRoZW50aWNhdGlvbiBvbiB0 aGUpLS4xNjUgRShMQ1QgcGFjaykxNDkgNjc2LjQgUQooZXRzIHRoZSktLjExIEUgMi43NSh5 dCktLjE2NSBHIDIuNzUocmFuc21pdC4gSWYpLTIuNzUgRihFWFRfQSkyLjc1IEUKKFVUSCBp cyBwcmVzZW50LCB3aGF0ZSktLjYwNSBFIC0uMTY1KHZlKS0uMjc1IEcgMi43NShyYSkuMTY1 IEcKKHV0aGVudGljYXRpb24pLTIuNzUgRQooY2hlY2tzIHRoYXQgY2FuIGJlIHBlcmZvcm1l ZCBpbW1lZGlhdGVseSB1cG9uIHJlY2VwdGlvbiBvZiB0aGUgcGFjaykxNDkKNjg5LjQgUShl dCBNVVNUKS0uMTEgRShiZSBwZXJmb3JtZWQgYmVmb3JlIGFjY2VwdGluZyB0aGUgcGFjaykx NDkgNzAyLjQKUShldCBhbmQgcGVyZm9ybWluZyBhbiktLjExIEUgMi43NSh5YyktLjE2NSBH KG9uZ2VzdGlvbiktMi43NSBFCihjb250cm9sLXJlbGF0ZWQgYWN0aW9uIG9uIGl0LikxNDkg NzE1LjQgUShMdWJ5L0dlbW1lbGwvVik3MiA3NjkgUQooaWNpc2Fuby9SaXp6by9IYW5kbGUp LS42NiBFKHkvQ3JvKS0uMTY1IEUgMTAzLjYwNih3Y3JvZnQgU2VjdGlvbiktLjI3NQpGIDIu NzUoMy4zLiBbUCkyLjc1IEYoYWdlIDEzXSktLjE2NSBFIEVQCiUlUGFnZTogMTQgMTQKJSVC ZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTEvVGltZXMtUm9tYW5AMCBT RihJTlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhwaXJlczopLTEuMDEyIEYKKEph bnVhcnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEyMy43MjYgRQooU29tZSBhdXRoZW50aWNh dGlvbiBzY2hlbWVzIGltcG9zZSBhIGRlbGF5IG9mIHNlKTE0OSA4NSBRIC0uMTY1KHZlKQot LjI3NSBHKHJhbCBzZWNvbmRzIGJldHdlZW4gd2hlbikuMTY1IEUgMi43NShhcCkxNDkgOTgg UyhhY2spLTIuNzUgRQooZXQgaXMgcmVjZWkpLS4xMSBFIC0uMTY1KHZlKS0uMjc1IEcgMi43 NShkYSkuMTY1IEcobmQgd2hlbiB0aGUgcGFjaykKLTIuNzUgRShldCBpcyBmdWxseSBhdXRo ZW50aWNhdGVkLiktLjExIEUoQW4pNS41IEUgMi43NSh5YyktLjE2NSBHCihvbmdlc3Rpb24p LTIuNzUgRShjb250cm9sIHJlbGF0ZWQgYWN0aW9uIHRoYXQgaXMgYXBwcm9wcmlhdGUgTVVT VCBOTykKMTQ5IDExMSBRIDIuNzUoVGIpLS40NCBHIDIuNzUoZWQpLTIuNzUgRyhlbGF5ZWQg YnkgYW4pLTIuNzUgRSAyLjc1KHlzKQotLjE2NSBHKHVjaCktMi43NSBFKGZ1bGwgYXV0aGVu dGljYXRpb24gZGVsYXkpMTQ5IDEyNCBRKC4pLS43MTUgRQooRVhUX0NDSV9GPTY1KTcyIDE1 My42IFEoQ29uZ2VzdGlvbiBDb250cm9sIEluZm9ybWF0aW9uIGUpMTQ5IDE2Ni42IFEKKHh0 ZW5zaW9uLCBcMjE0eCktLjE2NSBFKGVkIGxlbmd0aC4pLS4xNjUgRShUaGlzIGUpMTQ5IDE3 OS42IFEKKHh0ZW5zaW9uIFwyMTRlbGQgZSktLjE2NSBFKHh0ZW5kcyB0aGUgQ0NJIFwyMTRl bGQgcHJlc2VudCBpbiB0aGUgXDIxNHgpCi0uMTY1IEUoZWQgcGFydCBvZiB0aGUgaGVhZGVy KS0uMTY1IEUoLiktLjYwNSBFKEl0IGlzIHVzZWQgd2hlbiB0aGUgY29uXApnZXN0aW9uIGNv bnRyb2wgaW5mb3JtYXRpb24gZG9lcyBub3QgXDIxNHQgaW4gdGhlIDMyLWJpdCBDQ0kpMTQ5 IDE5Mi42IFEKKFwyMTRlbGQuIFdoZW4gdGhpcyBvcHRpb24gaXMgcHJlc2VudCwgdGhlIGNv bmNhdGVuYXRpb24gb2YgdGhlIDMyLWJpdCBcCkNDSSBcMjE0ZWxkIGluKTE0OSAyMDUuNiBR KHRoZSBcMjE0eCkxNDkgMjE4LjYgUQooZWQgcGFydCBvZiB0aGUgaGVhZGVyIHRvZ2V0aGVy IHdpdGggdGhlIDI0LWJpdCBcMjE0eCktLjE2NSBFCihlZCBsZW5ndGggdiktLjE2NSBFKGFs dWUgcHJvKS0uMjc1IEUodmlkZWQpLS4xNjUgRQooaW4gdGhpcyBvcHRpb24gaXMgdXNlZCBh cyB0aGUgY29uZ2VzdGlvbiBjb250cm9sIGluZm9ybWF0aW9uLikxNDkgMjMxLjYKUShUaGUg aW50ZXJwcmV0YXRpb24pNS41IEUKKG9mIHRoZSBkYXRhIGNvbnRhaW5lZCBpbiBFWFRfQ0NJ X0YgTVVTVCBiZSBuZSkxNDkgMjQ0LjYgUQooZ290aWF0ZWQgb3V0LW9mLWJhbmQuKS0uMTY1 IEUoVGhlKTUuNSBFCih1c2Ugb2YgRVhUX0NDSV9WIGFuZCBFWFRfQ0NJX0YgaXMgbXV0dWFs bHkgZSkxNDkgMjU3LjYgUSh4Y2x1c2kpLS4xNjUgRQotLjE2NSh2ZSktLjI3NSBHKC4pLjE2 NSBFL0YxIDExL1RpbWVzLUJvbGRAMCBTRig0Lik3MiAyOTYuNiBRL0YyIDE0Ci9UaW1lcy1C b2xkQDAgU0YoUHIpNS41IEUob2NlZHVyKS0uMjUyIEUoZXMpLS4yNTIgRSBGMSg0LjEuKTcy IDMzNS42IFEKL0YzIDEzL1RpbWVzLUJvbGRAMCBTRihTZW5kZXIgT3BlcmF0aW9uKTUuNSBF IEYwCihCZWZvcmUgYSBzZXNzaW9uIHN0YXJ0cywgYW4gTENUIHNlbmRlciBNVVNUIG1hayk3 MiAzNTIuMiBRIDIuNzUoZWEpLS4xMQpHIC0uMjc1KHZhKS0yLjk3IEcoaWxhYmxlIGFsbCBh cHBsaWNhYmxlIGluZm9ybWF0aW9uIHJlKS4yNzUgRSAtLjA1NShnYSkKLS4xNjUgRyhyZGlu ZykuMDU1IEUodGhlIHNlc3Npb24uKTcyIDM2NS4yIFEKKFRoaXMgaW5mb3JtYXRpb24gY291 bGQgaW5jbHVkZSwgYik1LjUgRSh1dCBpcyBub3QgbGltaXRlZCB0bzopLS4yMiBFIDExCihv VCk3Ny41IDM4MS44IFMoaGUgbnVtYmVyIG9mIExDVCBjaGFubmVsczspLTExIEUgMTEob1Qp NzcuNSAzOTguNCBTCihoZSBhZGRyZXNzZXMsIHBvcnQgbnVtYmVycyBhbmQgZGF0YSByYXRl cyB1c2VkIGZvciBlYWNoIExDVCBjaGFubmVsOykKLTExIEUgMTEob1QpNzcuNSA0MTUgUyho ZSBmb3JtYXQgb2YgdGhlIHBheWxvYWQuIEYpLTExIEUob3IgZSktLjE2NSBFCih4YW1wbGUs IHRoZSBwYXlsb2FkIGNvdWxkIGNvbnRhaW4gb3RoZXIgcHJvdG9jb2wgaGVhZGVycyktLjE2 NSBFCihzdWNoIGFzIGFuIEZFQyBoZWFkZXIpOTQgNDI4IFEgNS41KC5UKS0uNjA1IEcoaGVu IGZvciBlKS01LjUgRQooeGFtcGxlIHRoZSBpbmZvcm1hdGlvbiBjb3VsZCBpbmNsdWRlIHRo ZSBtYXBwaW5nIG9mKS0uMTY1IEUKKGNvZGVwb2ludHMgdXNlZCBpbiB0aGUgc2Vzc2lvbiB0 byBGRUMgY29kZWMgdHlwZXMgYW5kIHBhcmFtZXRlcnM7KTk0CjQ0MSBRIDExKG9UKTc3LjUg NDU3LjYgUyhoZSBjb25nZXN0aW9uIGNvbnRyb2wgc2NoZW1lIGJlaW5nIHVzZWQ7KS0xMSBF CjExKG9UKTc3LjUgNDc0LjIgUwooaGUgcG9zc2libGUgSGVhZGVyIEV4dGVuc2lvbnMgdGhh dCBjb3VsZCBiZSB1c2VkIGluIHRoZSBzZXNzaW9uOyktMTEgRQoxMShvVCk3Ny41IDQ5MC44 IFMoaGUgbWFwcGluZyBvZiBUKS0xMSBFKE9JIHYpLS4xOTggRQooYWx1ZVwoc1wpIHRvIG9i amVjdHMgZm9yIHRoZSBzZXNzaW9uOyktLjI3NSBFIDExKG9UKTc3LjUgNTA3LjQgUwooaGUg YXV0aGVudGljYXRpb24gc2NoZW1lIGJlaW5nIHVzZWQsIGFuZCBhbGwgcmVsZSktMTEgRSAt LjI3NSh2YSktLjI3NQpHKG50IGluZm9ybWF0aW9uIHdoaWNoIGlzIG5lY2Vzc2FyeSBmb3Ip LjI3NSBFCihzZW5kZXIgYXV0aGVudGljYXRpb24gcHVycG9zZXM7KTk0IDUyMC40IFEoVGhl IHNlc3Npb24gZGVzY3JpcHRpb24gY291XApsZCBiZSBpbiBhIGZvcm0gc3VjaCBhcyBTRFAg YXMgZGVcMjE0bmVkIGluIFJGQzIzMjcsIFhNTCBtZXRhZGF0YSwpNzIKNTUwIFEoSFRUUC9N aW1lIGhlYWRlcnMsIGV0Yy4gSXQgbWlnaHQgYmUgY2FycmllZCBpbiBhIHNlc3Npb24gYW5u b3VuY2VcCm1lbnQgcHJvdG9jb2wgc3VjaCBhcyBTQVApNzIgNTYzIFEoWzRdLCBvYnRhaW5l ZCB1c2luZyBSQ0NQIHNlc3Npb24gY29uXAp0cm9sIGFzIGRlc2NyaWJlZCBpbiBbOF0sIGxv Y2F0ZWQgb24gYSBXKTcyIDU3NiBRKGViIHBhZ2Ugd2l0aCktLjg4IEUKKHNjaGVkdWxpbmcg aW5mb3JtYXRpb24sIG9yIGNvbik3MiA1ODkgUSAtLjE2NSh2ZXkpLS40NCBHCihlZCB2aWEg RS1tYWlsIG9yIG90aGVyIG91dCBvZiBiYW5kIG1ldGhvZHMuKS4xNjUgRShEaXNjdXNzaW9u IG9mKTUuNSBFCihzZXNzaW9uIGRlc2NyaXB0aW9uIGZvcm1hdCwgYW5kIGRpc3RyaWIpNzIg NjAyIFEKKHV0aW9uIG9mIHNlc3Npb24gZGVzY3JpcHRpb25zIGlzIGJlKS0uMjIgRSh5b25k IHRoZSBzY29wZSBvZiB0aGlzKS0uMTY1CkUoZG9jdW1lbnQuKTcyIDYxNSBRIC0uNDQoV2kp NzIgNjQxIFMKKHRoaW4gYW4gTENUIHNlc3Npb24sIGFuIExDVCBzZW5kZXIgdHJhbnNtaXRz IGEgc2VxdWVuY2Ugb2YgTENUIHBhY2spLjQ0CkUoZXRzIGVhY2ggY29udGFpbmluZyBhKS0u MTEgRShwYXlsb2FkIGVuY29kZWQgYWNjb3JkaW5nIHRvIG9uZSBvZiB0aGUgXApjb2RlY3Mg ZGVcMjE0bmVkIGluIHRoZSBzZXNzaW9uIGRlc2NyaXB0aW9uLik3MiA2NTQgUShMQ1QgcGFj ayk1LjUgRQooZXRzKS0uMTEgRShhcmUgc2VudCBvKTcyIDY2NyBRIC0uMTY1KHZlKS0uMTY1 IEcgMi43NShybykuMTY1IEcKKG5lIG9yIG1vcmUgTENUIGNoYW5uZWxzIHdoaWNoIHRvZ2V0 aGVyIGNvbnN0aXR1dGUgYSBzZXNzaW9uLiktMi43NSBFCi0uMzg1KFRyKTUuNSBHKGFuc21p c3Npb24gcmF0ZXMpLjM4NSBFKE1BKTcyIDY4MCBRIDIuNzUoWWIpLTEuMTU1IEcgMi43NQoo ZWQpLTIuNzUgRyhpZiktMi43NSBFKGZlcmVudCBpbiBkaWYpLS4yNzUgRQooZmVyZW50IGNo YW5uZWxzLiBUaGlzIGRvY3VtZW50IGRvZXMgbm90IHNwZWNpZnkgdGhlIExDVCBwYWNrKS0u Mjc1IEUKKGV0IHBheWxvYWQsKS0uMTEgRShub3IgdGhlIG9yZGVyIGluIHdoaWNoIExDVCBw YWNrKTcyIDY5MyBRCihldHMgYXJlIHRyYW5zbWl0dGVkLCBub3IgdGhlIG9yKS0uMTEgRSAt LjA1NShnYSktLjE5OCBHCihuaXphdGlvbiBvZiBhIHNlc3Npb24gaW50bykuMDU1IEUKKG11 bHRpcGxlIGNoYW5uZWxzLiBBbHRob3VnaCB0aGVzZSBpc3N1ZXMgYWYpNzIgNzA2IFEoZmVj dCB0aGUgZWYpLS4yNzUKRShcMjE0Y2llbmMpLS4yNzUgRSAyLjc1KHlvKS0uMTY1IEcgMi43 NShmdCktMi43NSBHKGhlIHByb3RvY29sLCB0aGUpCi0yLjc1IEUgMi43NSh5ZCktLjE2NSBH IDIuNzUob24pLTIuNzUgRyhvdCBhZiktMi43NSBFKGZlY3QpLS4yNzUgRQoodGhlIGNvcnJl Y3RuZXNzIG5vciB0aGUgaW50ZXIpNzIgNzE5IFEKKC1vcGVyYWJpbGl0eSBiZXR3ZWVuIHNl bmRlcnMgYW5kIHJlY2VpKS0uMjIgRSAtLjE2NSh2ZSktLjI3NSBHKHJzLikuMTY1CkUoTHVi eS9HZW1tZWxsL1YpNzIgNzY5IFEoaWNpc2Fuby9SaXp6by9IYW5kbGUpLS42NiBFKHkvQ3Jv KS0uMTY1IEUKMTAzLjYwNih3Y3JvZnQgU2VjdGlvbiktLjI3NSBGIDIuNzUoNC4xLiBbUCky Ljc1IEYoYWdlIDE0XSktLjE2NSBFIEVQCiUlUGFnZTogMTUgMTUKJSVCZWdpblBhZ2VTZXR1 cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3 MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhwaXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMiky Ljc1IEUoSnVseSAyMDAxKTEyMy43MjYgRQooTXVsdGlwbGUgb2JqZWN0cyBjYW4gYmUgY2Fy cmllZCB3aXRoaW4gdGhlIHNhbWUgTENUIHNlc3Npb24uKTcyIDg1IFEKKEluIHRoaXMgY2Fz ZSwgZWFjaCBvYmplY3QgaXMpNS41IEUoaWRlbnRpXDIxNGVkIGJ5IGEgdW5pcXVlIFQpNzIg OTggUQoyLjc1KE9JLiBPYmplY3RzKS0uMTk4IEYoTUEpMi43NSBFIDIuNzUoWWIpLTEuMTU1 IEcgMi43NShldCktMi43NSBHCihyYW5zbWl0dGVkIHNlcXVlbnRpYWxseSktMi43NSBFIDIu NzUoLG8pLS43MTUgRyAyLjc1KHJ0KS0yLjc1IEcoaGUpCi0yLjc1IEUgMi43NSh5TSktLjE2 NSBHIDIuMzEgLTEuMTU1KEFZIGIpLTIuNzUgSChlKTEuMTU1IEUKKHRyYW5zbWl0dGVkIGNv bmN1cnJlbnRseSk3MiAxMTEgUSguKS0uNzE1IEUgLS44OChUeSk3MiAxMzcgUyhwaWNhbGx5 KQouODggRSAyLjc1KCx0KS0uNzE1IEcoaGUgc2VuZGVyXChzXCkgY29udGludWVzIHRvIHNl bmQgTENUIHBhY2spLTIuNzUgRQooZXRzIGluIGEgc2Vzc2lvbiB1bnRpbCB0aGUgdHJhbnNt aXNzaW9uIGlzKS0uMTEgRShjb25zaWRlcmVkIGNvbXBsZXRlLikKNzIgMTUwIFEoVGhlIHRy YW5zbWlzc2lvbiBNQSk1LjUgRSAyLjc1KFliKS0xLjE1NSBHIDIuNzUoZWMpLTIuNzUgRwoo b25zaWRlcmVkIGNvbXBsZXRlIHdoZW4gc29tZSB0aW1lIGhhcyktMi43NSBFIC0uMTY1KGV4 KTcyIDE2MyBTCihwaXJlZCwgYSBjZXJ0YWluIG51bWJlciBvZiBwYWNrKS4xNjUgRShldHMg aGEpLS4xMSBFIC4zMyAtLjE2NSh2ZSBiKQotLjIyIEgoZWVuIHNlbnQsIG9yIHNvbWUgb3V0 IG9mIGJhbmQgc2lnbmFsIFwocG9zc2libHkgZnJvbSBhKS4xNjUgRQooaGlnaGVyIGxlKTcy IDE3NiBRIC0uMTY1KHZlKS0uMjc1IEcgMi43NShscCkuMTY1IEcKKHJvdG9jb2xcKSBoYXMg aW5kaWNhdGVkIGNvbXBsZXRpb24gYnkgYSBzdWYpLTIuNzUgRQooXDIxNGNpZW50IG51bWJl ciBvZiByZWNlaSktLjI3NSBFIC0uMTY1KHZlKS0uMjc1IEcocnMuKS4xNjUgRShUaGUgc3Bl Y1wKaVwyMTRjYXRpb24gb2YgdGhlIHByb2Nlc3Npbmcgb2YgdGhlIHBheWxvYWQgY2Fycmll ZCBpbiBMQ1QgcGFjayk3MiAyMDIKUShldHMgaXMgYmUpLS4xMSBFKHlvbmQgdGhlIHNjb3Bl IG9mKS0uMTY1IEUodGhpcyBkb2N1bWVudC4pNzIgMjE1IFEKKExDVCB3aWxsIGFjdCBhcyBh IHRyYW5zcG9ydCBsYXllciBhbmQgY29uKTUuNSBFIC4zMyAtLjE2NSh2ZXkgcCktLjQ0IEgK KGF5bG9hZCBhbmQgYXNzb2NpYXRlZCBpbmZvcm1hdGlvbikuMTY1IEUoXChDb2RlcG9pbnQg YW5kIFQpNzIgMjI4IFEKKE9JXCkgdG8gdGhlIHJlY2VpKS0uMTk4IEUgLS4xNjUodmUpLS4y NzUgRyhycyBhbmQgYW4pLjE2NSBFIDIuNzUoeWMpCi0uMTY1IEcob21wbGV0ZSBwcm90b2Nv bCB1c2luZyBMQ1Qgd2lsbCBpbXBsZW1lbnQpLTIuNzUgRQooY29uZ2VzdGlvbiBjb250cm9s IC4pNzIgMjQxIFEgLS4xNjUoRm8pNzIgMjY3IFMgMi43NShydCkuMTY1IEcKKGhlIHJlYXNv bnMgbWVudGlvbmVkIGFibyktMi43NSBFIC0uMTY1KHZlKS0uMTY1IEcgMi43NSgsdCkuMTY1 IEcKKGhpcyBkb2N1bWVudCBkb2VzIG5vdCBwb3NlIGFuKS0yLjc1IEUgMi43NSh5ciktLjE2 NSBHCihlc3RyaWN0aW9uIG9uIExDVCBwYWNrKS0yLjc1IEUoZXQpLS4xMSBFKHNpemVzLiBI byk3MiAyODAgUSh3ZSktLjI3NSBFCi0uMTY1KHZlKS0uMjc1IEcgLjg4IC0uNDQociwgbiku MTY1IEgoZXR3KS40NCBFKG9yayBlZiktLjExIEUoXDIxNGNpZW5jKQotLjI3NSBFIDIuNzUo eWMpLS4xNjUgRwoob25zaWRlcmF0aW9ucyByZWNvbW1lbmQgdGhhdCB0aGUgc2VuZGVyIHVz ZXMgYXMgbGFyKS0yLjc1IEUoZ2UgYXMpLS4xOTgKRShwb3NzaWJsZSBwYXlsb2FkIHNpemUs IGIpNzIgMjkzIFEodXQgaW4gc3VjaCBhIHcpLS4yMiBFCihheSB0aGF0IExDVCBwYWNrKS0u MTEgRShldHMgZG8gbm90IGUpLS4xMSBFKHhjZWVkIHRoZSBuZXR3KS0uMTY1IEUKKG9yaycp LS4xMSBFIDIuNzUoc20pLS42MDUgRyhheGltdW0pLTIuNzUgRQoodHJhbnNtaXNzaW9uIHVu aXQgc2l6ZSBcKE1UVVwpLCBvciBmcmFnbWVudGF0aW9uIGNvdXBsZWQgd2l0aCBwYWNrKTcy CjMwNiBRKGV0IGxvc3MgbWlnaHQgaW50cm9kdWNlIHNlKS0uMTEgRSAtLjE2NSh2ZSktLjI3 NSBHKHJlKS4xNjUgRShpbmVmKQo3MiAzMTkgUShcMjE0Y2llbmMpLS4yNzUgRSAyLjc1KHlp KS0uMTY1IEcgMi43NShudCktMi43NSBHCihoZSB0cmFuc21pc3Npb24uKS0yLjc1IEUoSXQg aXMgYWxzbyBSRUNPTU1FTkRFRCB0aGF0IGFsbCBMQ1QgcGFjayk3MgozNDUgUShldHMgaGEp LS4xMSBFIC4zMyAtLjE2NSh2ZSB0KS0uMjIgSChoZSBzYW1lIG9yIHYpLjE2NSBFCihlcnkg c2ltaWxhciBzaXplcywgYXMgdGhpcyBjYW4pLS4xNjUgRShoYSk3MiAzNTggUSAuMzMgLS4x NjUodmUgYSBzKQotLjIyIEggLTIuMzY1IC0uMjc1KGV2IGUpLjE2NSBIKHJlIGltcGFjdCBv biB0aGUgZWYpLjI3NSBFKGZlY3RpKS0uMjc1IEUKLS4xNjUodmUpLS4yNzUgRyhuZXNzIG9m IGNvbmdlc3Rpb24gY29udHJvbCBzY2hlbWVzIHN1Y2ggYXMgdGhlIG9uZXMpCi4xNjUgRShk ZXNjcmliZWQgaW4gWzldLik3MiAzNzEgUSAyLjc1KEFzKTUuNSBHKGVuZGVyIG9mIExDVCBw YWNrKS0yLjc1CkUoZXRzIE1VU1QgaW1wbGVtZW50IHRoZSBzZW5kZXIpLS4xMSBFKC1zaWRl IHBhcnQgb2Ygb25lIG9mIHRoZSktLjIyIEUoXApjb25nZXN0aW9uIGNvbnRyb2wgc2NoZW1l cyB0aGF0IGlzIGluIGFjY29yZGFuY2Ugd2l0aCBSRkMyMzU3LCBhbmQgdGhlIFwKY29ycmVz cG9uZGluZyByZWNlaSk3MiAzODQgUSAtLjE2NSh2ZSktLjI3NSBHKHIpLjE2NSBFKGNvbmdl c3Rpb24gY29udHJcCm9sIHNjaGVtZSBNVVNUIGJlIGNvbW11bmljYXRlZCBvdXQgb2YgYmFu ZCBhbmQgaW1wbGVtZW50ZWQgYnkgYW4pNzIgMzk3ClEoeSktLjE2NSBFKHJlY2VpKTcyIDQx MCBRIC0uMTY1KHZlKS0uMjc1IEcKKHJzIHBhcnRpY2lwYXRpbmcgaW4gdGhlIHNlc3Npb24u KS4xNjUgRS9GMSAxMS9UaW1lcy1Cb2xkQDAgU0YoNC4yLik3Mgo0NDkgUS9GMiAxMy9UaW1l cy1Cb2xkQDAgU0YoUmVjZWkpNS41IEUgLS4xMyh2ZSktLjEzIEcgMy4yNShyTykuMTMgRwoo cGVyYXRpb24pLTMuMjUgRSBGMChSZWNlaSk3MiA0NjUuNiBRIC0uMTY1KHZlKS0uMjc1IEcK KHJzIGNhbiBvcGVyYXRlIGRpZikuMTY1IEUoZmVyZW50bHkgZGVwZW5kaW5nIG9uIHRoZSBk ZWxpKS0uMjc1IEUgLS4xNjUKKHZlKS0uMjc1IEcocnkgc2VydmljZSBtb2RlbC4pLjE2NSBF IC0uMTY1KEZvKTUuNSBHIDIuNzUocmUpLjE2NSBHCih4YW1wbGUsIGZvciBhbiktMi45MTUg RShvbiBkZW1hbmQgc2VydmljZSBtb2RlbCByZWNlaSk3MiA0NzguNiBRIC0uMTY1Cih2ZSkt LjI3NSBHKHJzIE1BKS4xNjUgRSAyLjc1KFlqKS0xLjE1NSBHCihvaW4gYSBzZXNzaW9uLCBv YnRhaW4gdGhlIG5lY2Vzc2FyeSBlbmNvZGluZyBzeW1ib2xzKS0yLjc1IEUKKHRvIHJlcHJv ZHVjZSB0aGUgb2JqZWN0LCBhbmQgdGhlbiBsZWEpNzIgNDkxLjYgUSAuMzMgLS4xNjUodmUg dCktLjIyIEgKKGhlIHNlc3Npb24uKS4xNjUgRShBcyBhbm90aGVyIGUpNS41IEUoeGFtcGxl LCBmb3IgYSBzdHJlYW1pbmcgc2VydmljZSkKLS4xNjUgRShtb2RlbCBhIHJlY2VpKTcyIDUw NC42IFEgLS4xNjUodmUpLS4yNzUgRyAyLjc1KHJNKS4xNjUgRyAyLjMxCi0xLjE1NShBWSBi KS0yLjc1IEggMi43NShlYykxLjE1NSBHCihvbnRpbnVvdXNseSBqb2luZWQgdG8gYSBzZXQg b2YgTENUIGNoYW5uZWxzIHRvIGRvKS0yLjc1IEUKKHdubG9hZCBhbGwgb2JqZWN0cyBpbikt LjI3NSBFIDIuNzUoYXMpNzIgNTE3LjYgUyhlc3Npb24uKS0yLjc1IEUgMS43NgotLjg4KFRv IGIpNzIgNTQzLjYgVCAyLjc1KGVhKS44OCBHCihibGUgdG8gcGFydGljaXBhdGUgaW4gYSBz ZXNzaW9uLCBhIHJlY2VpKS0yLjc1IEUgLS4xNjUodmUpLS4yNzUgRyAyLjc1CihyTSkuMTY1 IEcoVVNUIFwyMTRyc3Qgb2J0YWluIHRoZSByZWxlKS0yLjc1IEUgLS4yNzUodmEpLS4yNzUg RwoobnQgc2Vzc2lvbiBkZXNjcmlwdGlvbikuMjc1IEUoaW5mb3JtYXRpb24gYXMgbGlzdGVk IGluIFNlY3Rpb24gNC4xLik3Mgo1NTYuNiBRIDEuNzYgLS44OChUbyBiKTcyIDU4Ni4yIFQg Mi43NShlYSkuODggRwooYmxlIHRvIHBhcnRpY2lwYXRlIGluIGEgc2Vzc2lvbiwgYSByZWNl aSktMi43NSBFIC0uMTY1KHZlKS0uMjc1IEcgMi43NQoock0pLjE2NSBHKFVTVCBpbXBsZW1l bnQgdGhlIGNvbmdlc3Rpb24gY29udHJvbCBwcm90b2NvbCktMi43NSBFCihzcGVjaVwyMTRl ZCBpbiB0aGUgc2Vzc2lvbiBkZXNjcmlwdGlvbi4gSWYgYSByZWNlaSk3MiA1OTkuMiBRIC0u MTY1KHZlKQotLjI3NSBHIDIuNzUocmkpLjE2NSBHIDIuNzUoc24pLTIuNzUgRwoob3QgYWJs ZSB0byBpbXBsZW1lbnQgdGhlIGNvbmdlc3Rpb24gY29udHJvbCktMi43NSBFCihwcm90b2Nv bCB1c2VkIGluIHRoZSBzZXNzaW9uLCBpdCBNVVNUIE5PKTcyIDYxMi4yIFEgMi43NShUaikt LjQ0IEcKKG9pbiB0aGUgc2Vzc2lvbi4pLTIuNzUgRQooSWYgc2VuZGVyIGF1dGhlbnRpY2F0 aW9uIGluZm9ybWF0aW9uIGlzIHByZXNlbnQgaW4gYW4gTENUIHBhY2spNzIgNjM4LjIKUShl dCBoZWFkZXIpLS4xMSBFIDIuNzUoLGkpLS40NCBHIDIuNzUodE0pLTIuNzUgRyhVU1QgYmUg dXNlZCBhcyktMi43NSBFCihzcGVjaVwyMTRlZCBpbiBTZWN0aW9uIDMuMy4gSWYgYSByZWNl aSk3MiA2NTEuMiBRIC0uMTY1KHZlKS0uMjc1IEcgMi43NQoocmkpLjE2NSBHIDIuNzUoc3Up LTIuNzUgRwoobmFibGUgdG8gaW1wbGVtZW50IHRoZSBhdXRoZW50aWNhdGlvbiBtZWNoYW5p c20gdXNlZCktMi43NSBFCihieSB0aGUgc2Vzc2lvbiwgaXQgTVVTVCBOTyk3MiA2NjQuMiBR IDIuNzUoVGopLS40NCBHKG9pbiB0aGUgc2Vzc2lvbi4pCi0yLjc1IEUgMS43NiAtLjg4KFRv IGIpNzIgNjkwLjIgVCAyLjc1KGVhKS44OCBHKGJsZSB0byBiZSBhIHJlY2VpKS0yLjc1CkUg LS4xNjUodmUpLS4yNzUgRyAyLjc1KHJpKS4xNjUgRyAyLjc1KG5hcyktMi43NSBHKGVzc2lv biwgdGhlIHJlY2VpKQotMi43NSBFIC0uMTY1KHZlKS0uMjc1IEcgMi43NShyTSkuMTY1IEcK KFVTVCBiZSBhYmxlIHRvIHByb2Nlc3MgdGhlIExDVCBwYWNrKS0yLjc1IEUoZXQpLS4xMSBF KGhlYWRlcik3MiA3MDMuMiBRCjUuNSguVCktLjYwNSBHKGhlIHJlY2VpKS01LjUgRSAtLjE2 NSh2ZSktLjI3NSBHIDIuNzUock0pLjE2NSBHCihVU1QgYmUgYWJsZSB0byBkaXNjYXJkLCBm b3J3KS0yLjc1IEUKKGFyZCwgc3RvcmUgb3IgcHJvY2VzcyB0aGUgTENUIHBhY2spLS4xMSBF KGV0IHBheWxvYWQuKS0uMTEgRQooSWYgYSByZWNlaSk3MiA3MTYuMiBRIC0uMTY1KHZlKS0u Mjc1IEcgMi43NShyaSkuMTY1IEcgMi43NShzbiktMi43NSBHCihvdCBhYmxlIHRvIHByb2Nl c3MgYSBMQ1QgcGFjayktMi43NSBFKGV0IGhlYWRlciktLjExIEUgMi43NSgsaSktLjQ0IEcK Mi43NSh0TSktMi43NSBHKFVTVCBlaXRoZXIgZHJvcCBmcm9tIHRoZSBzZXNzaW9uLCBvcikt Mi43NSBFCihMdWJ5L0dlbW1lbGwvVik3MiA3NjkgUShpY2lzYW5vL1JpenpvL0hhbmRsZSkt LjY2IEUoeS9Dcm8pLS4xNjUgRQoxMDMuNjA2KHdjcm9mdCBTZWN0aW9uKS0uMjc1IEYgMi43 NSg0LjIuIFtQKTIuNzUgRihhZ2UgMTVdKS0uMTY1IEUgRVAKJSVQYWdlOiAxNiAxNgolJUJl Z2luUGFnZVNldHVwCkJQCiUlRW5kUGFnZVNldHVwCi9GMCAxMS9UaW1lcy1Sb21hbkAwIFNG KElOVEVSTkVUKTcyIDQ5IFEgNzEuNTg3KC1EUkFGVCBFeHBpcmVzOiktMS4wMTIgRgooSmFu dWFyeSAyMDAyKTIuNzUgRShKdWx5IDIwMDEpMTIzLjcyNiBFKHJlZHVjZSB0aGUgcmVjZWkp NzIgODUgUSAuMzMKLS4xNjUodmUgYiktLjI3NSBIKGFuZHdpZHRoIHRvIHRoZSBtaW5pbXVt IHYpLjE2NSBFKGFsdWUgYWxsbyktLjI3NSBFCih3ZWQgYnkgdGhlIGNvbmdlc3Rpb24gY29u dHJvbCBwcm90b2NvbCktLjI3NSBFKGJlaW5nIHVzZWQuKTcyIDk4IFEKKFdoZW4gdGhlIHNl c3Npb24gaXMgdHJhbnNtaXR0ZWQgb24gbXVsdGlwbGUgTENUIGNoYW5uZWxzLCByZWNlaSk3 MiAxMjQKUSAtLjE2NSh2ZSktLjI3NSBHKHJzIE1VU1QgZG8gaXQgYWNjb3JkaW5nIHRvIHRo ZSkuMTY1IEUKKHNwZWNpXDIxNGVkIHN0YXJ0dXAgYmVoYSk3MiAxMzcgUQoodmlvciBvZiB0 aGUgY29uZ2VzdGlvbiBjb250cm9sIHByb3RvY29sIGl0c2VsZi4gRiktLjIyIEUKKG9yIGEg bGF5ZXJlZCB0cmFuc21pc3Npb24gb24pLS4xNjUgRQoobXVsdGlwbGUgY2hhbm5lbHMsIHRo aXMgdHlwaWNhbGx5IG1lYW5zIHRoYXQgYSByZWNlaSk3MiAxNTAgUSAtLjE2NSh2ZSkKLS4y NzUgRyAyLjc1KHJ3KS4xNjUgRyhpbGwgaW5pdGlhbGx5IGpvaW4gb25seSBhIG1pbmltYWwg c2V0IG9mKS0yLjc1IEUKKExDVCBjaGFubmVscywgcG9zc2libHkgYSBzaW5nbGUgb25lLik3 MiAxNjMgUQooVGhpcyBydWxlIGhhcyB0aGUgcHVycG9zZSBvZiBwcmUpNS41IEUgLS4xNjUo dmUpLS4yNzUgRyhudGluZyByZWNlaSkKLjE2NSBFIC0uMTY1KHZlKS0uMjc1IEcocnMgZnJv bSkuMTY1IEUoc3RhcnRpbmcgYXQgaGlnaCBkYXRhIHJhdGVzLik3MgoxNzYgUShNdWx0aXBs ZSBvYmplY3RzIGNhbiBiZSBjYXJyaWVkIHdpdGhpbiB0aGUgc2FtZSBMQ1Qgc2Vzc2lvbi4p NzIKMjAyIFEoSW4gdGhpcyBjYXNlLCBlYWNoIG9iamVjdCBpcyk1LjUgRShpZGVudGlcMjE0 ZWQgYnkgYSB1bmlxdWUgVCk3MgoyMTUgUSAyLjc1KE9JLiBOb3RlKS0uMTk4IEYodGhhdCBl KTIuNzUgRSAtLjE2NSh2ZSktLjI3NSBHIDIuNzUobmkpLjE2NQpHIDIuNzUoZmFzKS0yLjc1 IEcoZXJ2KS0yLjc1IEUoZXIgc3RvcHMgc2VuZGluZyBMQ1QgcGFjayktLjE2NSBFCihldHMg Zm9yIGFuIG9sZCBvYmplY3QpLS4xMSBFKGJlZm9yZSBzdGFydGluZyB0byB0cmFuc21pdCBM Q1QgcGFjayk3MgoyMjggUShldHMgZm9yIGEgbmUpLS4xMSBFIDIuNzUod28pLS4yNzUgRyhi amVjdCwgYm90aCB0aGUgbmV0dyktMi43NSBFCihvcmsgYW5kIHRoZSB1bmRlcmx5aW5nKS0u MTEgRQoocHJvdG9jb2wgbGF5ZXJzIGNhbiBjYXVzZSBzb21lIHJlb3JkZXJpbmcgb2YgcGFj ayk3MiAyNDEgUQooZXRzLCBlc3BlY2lhbGx5IHdoZW4gc2VudCBvKS0uMTEgRSAtLjE2NSh2 ZSktLjE2NSBHIDIuNzUocmQpLjE2NSBHKGlmKQotMi43NSBFKGZlcmVudCBMQ1QpLS4yNzUg RShjaGFubmVscywgYW5kIHRodXMgcmVjZWkpNzIgMjU0IFEgLS4xNjUodmUpCi0uMjc1IEco cnMgTVVTVCBOTykuMTY1IEUgMi43NShUYSktLjQ0IEcKKHNzdW1lIHRoYXQgdGhlIHJlY2Vw dGlvbiBvZiBhbiBMQ1QgcGFjayktMi43NSBFKGV0IGZvciBhIG5lKS0uMTEgRSh3KQotLjI3 NSBFKG9iamVjdCBtZWFucyB0aGF0IHRoZXJlIGFyZSBubyBtb3JlIExDVCBwYWNrKTcyIDI2 NyBRCihldHMgaW4gdHJhbnNpdCBmb3IgdGhlIHByZSktLjExIEUodmlvdXMgb25lLCBhdCBs ZWFzdCBmb3Igc29tZSktLjI3NSBFCihhbW91bnQgb2YgdGltZS4pNzIgMjgwIFEgMi43NShB cik3MiAzMDYgUyhlY2VpKS0yLjc1IEUgLS4xNjUodmUpLS4yNzUgRwoyLjc1KHJNKS4xNjUg RyAyLjMxIC0xLjE1NShBWSBiKS0yLjc1IEggMi43NShlYykxLjE1NSBHCihvbmN1cnJlbnRs eSBqb2luZWQgdG8gbXVsdGlwbGUgTENUIHNlc3Npb25zLiktMi43NSBFKFRoZSByZWNlaSk1 LjUgRQotLjE2NSh2ZSktLjI3NSBHIDIuNzUock0pLjE2NSBHKFVTVCBwZXJmb3JtKS0yLjc1 IEUKKGNvbmdlc3Rpb24gY29udHJvbCBvbiBlYWNoIHN1Y2ggTENUIHNlc3Npb24uKTcyIDMx OSBRCihJZiB0aGUgY29uZ2VzdGlvbiBjb250cm9sIHByb3RvY29sIGFsbG8pNS41IEUod3Mg dGhlKS0uMjc1IEUocmVjZWkpNzIKMzMyIFEgLS4xNjUodmUpLS4yNzUgRyAyLjc1KHJzKS4x NjUgRyhvbWUgXDIxNWUpLTIuNzUgRQooeGliaWxpdHkgaW4gdGVybXMgb2YgaXRzIGFjdGlv bnMgd2l0aGluIGEgc2Vzc2lvbiB0aGVuIHRoZSByZWNlaSktLjE2NQpFIC0uMTY1KHZlKS0u Mjc1IEcgMi43NShyTSkuMTY1IEcgMi4zMSAtMS4xNTUoQVkgbSktMi43NSBIKGFrKTEuMTU1 IEUoZSkKLS4xMSBFKGNob2ljZXMgdG8gb3B0aW1pemUgdGhlIHBhY2spNzIgMzQ1IFEoZXQg XDIxNW8pLS4xMSBFIDIuNzUod3ApCi0uMjc1IEcoZXJmb3JtYW5jZSBhY3Jvc3MgdGhlIG11 bHRpcGxlIExDVCBzZXNzaW9ucywgYXMgbG9uZyBhcyB0aGUpCi0yLjc1IEUocmVjZWkpNzIg MzU4IFEgLS4xNjUodmUpLS4yNzUgRyAyLjc1KHJzKS4xNjUgRwoodGlsbCBhZGhlcmVzIHRv IHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgcnVsZXMgZm9yIGVhY2ggTENUIHNlc3Npb24gaW5k aSkKLTIuNzUgRSh2aWR1YWxseSktLjI3NSBFKC4pLS43MTUgRS9GMSAxMS9UaW1lcy1Cb2xk QDAgU0YoNS4pNzIgMzk3IFEvRjIKMTQvVGltZXMtQm9sZEAwIFNGKFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zKTUuNSBFIEYwCihMQ1QgY2FuIGJlIHN1YmplY3QgdG8gZGVuaWFsLW9mLXNl cnZpY2UgYXR0YWNrcyBieSBhdHRhY2spNzIgNDEzLjYgUQooZXJzIHdoaWNoIHRyeSB0byBj b25mdXNlIHRoZSBjb25nZXN0aW9uKS0uMTEgRQooY29udHJvbCBtZWNoYW5pc20sIG9yIHNl bmQgZm9yKTcyIDQyNi42IFEoZ2VkIHBhY2spLS4xOTggRQooZXRzIHRvIHRoZSBzZXNzaW9u IHdoaWNoIHcpLS4xMSBFKG91bGQgcHJlKS0uMTEgRSAtLjE2NSh2ZSktLjI3NSBHCihudCBz dWNjZXNzZnVsKS4xNjUgRShyZWNvbnN0cnVjdGlvbiBvZiBsYXIpNzIgNDM5LjYgUQooZ2Ug cG9ydGlvbnMgb2YgdGhlIGRhdGEgc3RyZWFtLiktLjE5OCBFKFRoZSBzYW1lIGUpNzIgNDY1 LjYgUQooeGFjdCBwcm9ibGVtcyBhcmUgcHJlc2VudCBpbiBUQ1ApLS4xNjUgRSAyLjc1KCx3 KS0xLjIyMSBHCihoZXJlIGFuIGF0dGFjayktMi43NSBFKGVyIGNhbiBmb3IpLS4xMSBFKGdl IHBhY2spLS4xOTggRQooZXRzIGFuZCBlaXRoZXIgc2xvKS0uMTEgRSh3KS0uMjc1IEUoZG8p NzIgNDc4LjYgUSh3biBvciBpbmNyZWFzZSB0aGUgdFwKaHJvdWdocHV0IG9mIHRoZSBzZXNz aW9uLCBvciByZXBsYWNlIHBhcnRzIG9mIHRoZSBkYXRhIHN0cmVhbSB3aXRoIGZvcikKLS4y NzUgRShnZWQpLS4xOTggRQooZGF0YS4gSWYgdGhlIHN0cmVhbSBpcyBjYXJyeWluZyBjb21w cmVzc2VkIG9yIG90aGVyd2lzZSBjb2RlZCBkYXRhLCBlKQo3MiA0OTEuNiBRIC0uMTY1KHZl KS0uMjc1IEcgMi43NShuYXMpLjE2NSBHKGluZ2xlIGZvciktMi43NSBFKGdlZCBwYWNrKQot LjE5OCBFKGV0KS0uMTEgRShjb3VsZCBhbHNvIGNhdXNlIGluY29ycmVjdCByZWNvbnN0cnVj dGlvbiBvZiB0aGUgcmVzdFwKIG9mIHRoZSBkYXRhIHN0cmVhbS4pNzIgNTA0LjYgUShJdCBp cyB0aGVyZWZvcmUgUkVDT01NRU5ERUQgdGhhdCBMQ1QgYWdcCmVudHMgaW1wbGVtZW50IHNv bWUgZm9ybSBvZiBhdXRoZW50aWNhdGlvbiB0byk3MiA1MzAuNiBRCihwcm90ZWN0IHRoZW1z ZWx2KTcyIDU0My42IFEoZXMgYWcpLS4xNjUgRShhaW5zdCBzdWNoIGF0dGFja3MuKS0uMDU1 IEUKRjEoNi4pNzIgNTgyLjYgUSBGMihJQU4pNS41IEUgMy41KEFDKS0uMjggRyhvbnNpZGVy YXRpb25zKS0zLjUgRSBGMAooTm8gaW5mb3JtYXRpb24gaW4gdGhpcyBzcGVjaVwyMTRjYXRp b24gaXMgc3ViamVjdCB0byBJQU4pNzIgNTk5LjIgUQoyLjc1KEFyKS0uMzg1IEcgLS4xNjUo ZWcpLTIuNzUgRyhpc3RyYXRpb24uKS4xNjUgRQooQnVpbGRpbmcgYmxvY2tzIGNvbXBvbmVu dHMgdXNlZCBieSBMQ1QgbWF5IGludHJvZHVjZSBhZGRpdGlvbmFsIElBTik3Mgo2MjUuMiBR IDIuNzUoQWMpLS4zODUgRyhvbnNpZGVyYXRpb25zLiktMi43NSBFIEYxKDcuKTcyIDY2NC4y IFEgRjIKKEludGVsbGVjdHVhbCBQcik1LjUgRShvcGVydHkgSXNzdWVzKS0uMjUyIEUgRjAo Tm8gc3BlY2lcMjE0YyByZWxpYWJpbGlcCnR5IHByb3RvY29sIG9yIGNvbmdlc3Rpb24gY29u dHJvbCBwcm90b2NvbCBpcyBzcGVjaVwyMTRlZCBvciByZWZlcmVuY2VkXAogYXMpNzIgNjkz LjggUShtYW5kYXRvcnkgaW4gdGhpcyBkb2N1bWVudC4pNzIgNzA2LjggUShMdWJ5L0dlbW1l bGwvVik3Mgo3NjkgUShpY2lzYW5vL1JpenpvL0hhbmRsZSktLjY2IEUoeS9Dcm8pLS4xNjUg RSAxMTEuODU2KHdjcm9mdCBTZWN0aW9uKQotLjI3NSBGIDIuNzUoNy4gW1ApMi43NSBGKGFn ZSAxNl0pLS4xNjUgRSBFUAolJVBhZ2U6IDE3IDE3CiUlQmVnaW5QYWdlU2V0dXAKQlAKJSVF bmRQYWdlU2V0dXAKL0YwIDExL1RpbWVzLVJvbWFuQDAgU0YoSU5URVJORVQpNzIgNDkgUSA3 MS41ODcoLURSQUZUIEV4cGlyZXM6KS0xLjAxMiBGCihKYW51YXJ5IDIwMDIpMi43NSBFKEp1 bHkgMjAwMSkxMjMuNzI2IEUoTENUIE1BKTcyIDg1IFEgMi43NShZYiktMS4xNTUgRwoyLjc1 KGV1KS0yLjc1IEcoc2VkIHdpdGggY29uZ2VzdGlvbiBjb250cm9sIHByb3RvY29scyBhbmQg b3RoZXIgcHJvdG9jb1wKbHMgd2hpY2ggYXJlIHByb3ByaWV0YXJ5KS0yLjc1IEUoLCktLjcx NSBFKG9yIGhhKTcyIDk4IFEgLjMzIC0uMTY1KHZlIHApCi0uMjIgSChlbmRpbmcgb3IgZ3Jh bnRlZCBwYXRlbnRzLikuMTY1IEUvRjEgMTEvVGltZXMtQm9sZEAwIFNGKDguKTcyIDEzNwpR L0YyIDE0L1RpbWVzLUJvbGRAMCBTRihBY2tubyk1LjUgRSh3bGVkZ21lbnRzKS0uMTQgRSBG MChUaGFua3MgdG8gVik3MgoxNTMuNiBRKGluY2VudCBSb2NhLCBCcnVjZSBMdWVjayktLjY2 IEUoZW5ob2YpLS4xMSBFIDIuNzUoZmEpLS4yNzUgRwoobmQgSGF5ZGVyIFJhZGhhIGZvciBk ZXRhaWxlZCBjb21tZW50cyBvbiB0aGlzKS0yLjc1IEUoZG9jdW1lbnQuKTcyCjE2Ni42IFEo WzFdIEJ5ZXJzLCBKLlcpNzIgMjIyLjIgUSguLCBMdWJ5KS0xLjAxMiBFIDIuNzUoLE0pLS43 MTUgRwooLiwgTWl0emVubWFjaGVyKS0yLjc1IEUgMi43NSgsTSktLjQ0IEcoLiwgYW5kIFJl KS0yLjc1IEUKKGdlLCBBLiwgIkEgRGlnaXRhbCBGKS0uMTY1IEUob3VudGFpbiBBcHByb2Fj aCB0byktLjE2NSBFCihSZWxpYWJsZSBEaXN0cmliKTcyIDIzNS4yIFEodXRpb24gb2YgQnVs ayBEYXRhIiwgUHJvY2VlZGluZ3MgQSktLjIyIEUKKENNIFNJR0NPTU0gJzk4LCBWKS0uNDQg RShhbmNvdXYpLTEuMjIxIEUoZXIpLS4xNjUgRSAyLjc1KCxDKS0uNDQgRwooYW5hZGEsIFNl cHQpLTIuNzUgRSgxOTk4Lik3MiAyNDguMiBRKFsyXSBDYWluLCBCLiwgU3BlYWttYW4sIFQp NzIgMjc0LjIKUSguLCBhbmQgVCktLjgxNCBFIC0uMjc1KG93KS0uODggRyhzbGUpLjI3NSBF IDEuNDMgLS43MTUoeSwgRCktLjE2NSBICiguLCAiR2VuZXJpYyBSb3V0ZXIgQXNzaXN0IFwo R1JBXCkgQnVpbGRpbmcgQmxvY2ssKS43MTUgRShNb3RpKTcyIDI4Ny4yClEgLS4yNzUodmEp LS4yNzUgRyh0aW9uIGFuZCBBcmNoaXRlY3R1cmUiLCBJbnRlcm5ldCBEcmFmdCBkcmFmdC1p ZXRmLXJtXAp0LWdyYS1hcmNoLTAwLnR4dCwgYSB3KS4yNzUgRShvcmsgaW4gcHJvZ3Jlc3Mu KS0uMTEgRQooWzNdIEdlbW1lbGwsIEouLCBTY2hvb2xlcik3MiAzMTMuMiBRIDIuNzUoLEUp LS40NCBHKC4sIGFuZCBHcmF5KS0yLjc1IEUKMi43NSgsSiktLjcxNSBHKC4sICJGQ2FzdCBT Y2FsYWJsZSBNdWx0aWNhc3QgRmlsZSBEaXN0cmliKS0yLjc1IEUKKHV0aW9uOiBDYWNoaW5n KS0uMjIgRShhbmQgUCk3MiAzMjYuMiBRKGFyYW1ldGVycyBPcHRpbWl6YXRpb25zIiwgVCkK LS4xNjUgRShlY2huaWNhbCBSZXBvcnQgTVNSLVRSLTk5LTE0LCBNaWNyb3NvZnQgUmVzZWFy Y2gsKS0uNzcgRQooUmVkbW9uZCwgVyk3MiAzMzkuMiBRKEEsIEFwcmlsLCAxOTk5LiktMS4z MiBFKFs0XSBIYW5kbGUpNzIgMzY1LjIgUQoxLjQzIC0uNzE1KHksIE0pLS4xNjUgSAooLiwg IlNBUDogU2Vzc2lvbiBBbm5vdW5jZW1lbnQgUHJvdG9jb2wiLCBJbnRlcm5ldCBEcmFmdCwg SUVURiBNTVVTSUMpCi43MTUgRSAtLjg4KFdvKTcyIDM3OC4yIFMocmtpbmcgR3JvdXAsIE5v KS44OCBFIDIuNzUodjEpLS4xNjUgRwooOTk2LCBhIHcpLTIuNzUgRShvcmsgaW4gcHJvZ3Jl c3MuKS0uMTEgRShbNV0gSG9sYnJvb2ssIEguLCBDYWluLCBCLiwgIlwKU291cmNlLVNwZWNp XDIxNGMgTXVsdGljYXN0IGZvciBJUCIsIEludGVybmV0IERyYWZ0LCBTU00gVyk3MiA0MDQu MiBRCihvcmtpbmcpLS44OCBFKEdyb3VwLCBNYXJjaCAyMDAxLCBkcmFmdC1ob2xicm9vay1z c20tYXJjaC0wMi50eHQsIGEgdyk3Mgo0MTcuMiBRKG9yayBpbiBwcm9ncmVzcy4pLS4xMSBF KFs2XSBMdWJ5KTcyIDQ0My4yIFEgMi43NSgsTSktLjcxNSBHCiguLCBHZW1tZWxsLCBWKS0y Ljc1IEUoaWNpc2FubywgTC4sIEouLCBSaXp6bywgTC4sIEhhbmRsZSktLjY2IEUgMS40Mwot LjcxNSh5LCBNKS0uMTY1IEgoLiwgQ3JvKS43MTUgRSh3Y3JvZnQsIEouLCAiVGhlIHVzZSBv ZiktLjI3NSBFIC0uMTY1CihGbyk3MiA0NTYuMiBTKHJ3KS4xNjUgRShhcmQgRXJyb3IgQ29y cmVjdGlvbiBpbiBSZWxpYWJsZSBNdWx0aWNhc3QiLCBJXApudGVybmV0IERyYWZ0IGRyYWZ0 LWlldGYtcm10LWluZm8tZmVjLTAwLnR4dCwpLS4xMSBFKE5vKTcyIDQ2OS4yIFEgLS4xNjUK KHZlKS0uMTY1IEcobWJlciAyMDAwLCBhIHcpLjE2NSBFKG9yayBpbiBwcm9ncmVzcy4pLS4x MSBFKFs3XSBMdWJ5KTcyCjQ5NS4yIFEgMi43NSgsTSktLjcxNSBHKC4sIFYpLTIuNzUgRQoo aWNpc2FubywgTC4sIEdlbW1lbGwsIEouLCBSaXp6bywgTC4sIEhhbmRsZSktLjY2IEUgMS40 MyAtLjcxNSh5LCBNKQotLjE2NSBIKC4sIENybykuNzE1IEUod2Nyb2Z0LCBKLiwgIlJNVCBC QiktLjI3NSBFIC0uMTY1KEZvKTcyIDUwOC4yIFMKKHJ3KS4xNjUgRShhcmQgRXJyb3IgQ29y cmVjdGlvbiBDb2RlcyIsIEludGVybmV0IERyYWZ0IGRyYWZ0LWlldGYtcm10LWJcCmItZmVj LTAzLnR4dCwgSnVseSAyMDAxLiktLjExIEUoWzhdIEx1YnkpNzIgNTM0LjIgUSAyLjc1KCxN KS0uNzE1IEcKKC4sIEhlcm5laywgRC4sIEspLTIuNzUgRSh1c2hpLCBELiwgUmFzbXVzc2Vu LCBMLiwgU2ltdSwgUy4sIFYpLS4xNjUgRQooYWluaXNoLCBSLiwgIlJpY2ggQ29udGVudCBD b250cm9sKS0xLjIyMSBFCihQcm90b2NvbDogQSBzZXNzaW9uIGNvbnRyb2wgcHJvdG9jb2wg aW5zdGFudGlhdGlvbiIsIERpZ2l0YWwgRik3MiA1NDcuMgpRKG91bnRhaW4gZG9jdW1lbnQs IGEgdyktLjE2NSBFKG9yayBpbiktLjExIEUocHJvZ3Jlc3MuKTcyIDU2MC4yIFEKKFs5XSBM dWJ5KTcyIDU4Ni4yIFEgMi43NSgsTSktLjcxNSBHKC4sIFYpLTIuNzUgRShpY2lzYW5vLCBM LiwgSGFrKS0uNjYKRShlbiwgQS4sICJSTVQgQkIgTGF5ZXJlZCBjb25nZXN0aW9uIGNvbnRy b2wiLCBkcmFmdC1pZXRmLXJtdC1iYi0pLS4xMSBFCihsY2MtMDAudHh0LCBObyk3MiA1OTku MiBRIC0uMTY1KHZlKS0uMTY1IEcobWJlciAyMDAwLCBhIHcpLjE2NSBFCihvcmsgaW4gcHJv Z3Jlc3MuKS0uMTEgRShbMTBdIFJpenpvLCBMLiwgIkVmKTcyIDYyNS4yIFEoZmVjdGkpLS4y NzUgRQouMzMgLS4xNjUodmUgRSktLjI3NSBICihyYXN1cmUgQ29kZXMgZm9yIFJlbGlhYmxl IENvbXB1dGVyIENvbW11bmljYXRpb24gUHJvdG9jb2xzIiwpLjE2NSBFCi0uNDQoQUMpNzIg NjM4LjIgUyAyLjc1KE1TKS40NCBHKElHQ09NTSBDb21wdXRlciBDb21tdW5pY2F0aW9uIFJl KS0yLjc1CkUodmllKS0uMjc1IEUgMS40MyAtLjcxNSh3LCBWKS0uMjc1IEgob2wuMjcsIE5v LjIsIHBwLjI0LTM2LCBBcHIgMTk5Ny4pCi0uNzA0IEUoWzExXSBQZXJyaWcsIEEuLCBDYW5l dHRpLCBSLiwgQnJpc2NvZSwgQi4sIFQpNzIgNjY0LjIgUSh5ZyktLjg4CkUoYXIpLS4wNTUg RSAyLjc1KCxEKS0uNDQgRyguLCBTb25nLCBELiwgIlRFU0xBOiBNdWx0aWNhc3QgU291cmNl KS0yLjc1CkUoQXV0aGVudGljYXRpb24gVCk3MiA2NzcuMiBRCihyYW5zZm9ybSIsIGRyYWZ0 LWlydGYtc211Zy10ZXNsYS0wMC50eHQsIE5vKS0uMzg1IEUgLS4xNjUodmUpLS4xNjUgRwoo bWJlcikuMTY1IEUgMi43NSgsMiktLjQ0IEcoMDAwLCBhIHcpLTIuNzUgRShvcmsgaW4gcHJv Z3Jlc3MuKS0uMTEgRQooWzEyXSBSaXp6bywgTCwgYW5kIFYpNzIgNzAzLjIgUQooaWNpc2Fu bywgTC4sICJSZWxpYWJsZSBNdWx0aWNhc3QgRGF0YSBEaXN0cmliKS0uNjYgRQoodXRpb24g cHJvdG9jb2wgYmFzZWQgb24gc29mdHcpLS4yMiBFKGFyZSktLjExIEUKKEZFQyB0ZWNobmlx dWVzIiwgUHJvY2VlZGluZ3Mgb2YgdGhlIEYpNzIgNzE2LjIgUShvdXJ0aCBJRUVFUyBXKS0u MTY1IEUKKG9ya3Nob3Agb24gdGhlIEFyY2hpdGVjdHVyZSBhbmQpLS44OCBFKEx1YnkvR2Vt bWVsbC9WKTcyIDc2OSBRCihpY2lzYW5vL1JpenpvL0hhbmRsZSktLjY2IEUoeS9Dcm8pLS4x NjUgRSAxMTEuODU2KHdjcm9mdCBTZWN0aW9uKS0uMjc1CkYgMi43NSg4LiBbUCkyLjc1IEYo YWdlIDE3XSktLjE2NSBFIEVQCiUlUGFnZTogMTggMTgKJSVCZWdpblBhZ2VTZXR1cApCUAol JUVuZFBhZ2VTZXR1cAovRjAgMTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3MiA0OSBR IDcxLjU4NygtRFJBRlQgRXhwaXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMikyLjc1IEUo SnVseSAyMDAxKTEyMy43MjYgRShJbXBsZW1lbnRhdGlvbiBvZiBIaWdoIFBlcmZvcm1cCmFu Y2UgQ29tbXVuaWNhdGlvbiBTeXN0ZW1zLCBIUENTJzk3LCBDaGFsa2lkaWtpLCBHcmVlY2Us KTcyIDg1IFEKKEp1bmUgMTk5Ny4pNzIgOTggUShbMTNdIFNwZWFrbWFuLCBUKTcyIDEyNCBR KC4sIEYpLS44MTQgRQooYXJpbmFjY2ksIEQuLCBDcm8pLS4xNjUgRSh3Y3JvZnQsIEouLCBH ZW1tZWxsLCBKLiwgTGluLCBTLiwgVCktLjI3NSBFCih3ZWVkbHkpLS44OCBFIDIuNzUoLEEp LS43MTUgRyguLCBMZXNoY2hpbmVyKS0yLjc1IEUoLCktLjQ0IEUoRC4sIEx1YnkpCjcyIDEz NyBRIDIuNzUoLE0pLS43MTUgRyguLCBCaGFza2FyKS0yLjc1IEUgMi43NSgsTiktLjQ0IEcK KC4sIEVkbW9uc3RvbmUsIFIuLCBKb2huc29uLCBLLiwgTW9udGdvbWVyeSktMi43NSBFIDIu NzUoLFQpLS43MTUgRwooLiwgUml6em8sIEwuLCktMy41NjQgRShTdW1hbmFzZWspNzIgMTUw IFEoZXJhLCBSLiwgViktLjExIEUKKGljaXNhbm8sIEwuLCAiUEdNIFJlbGlhYmxlIFQpLS42 NiBFCihyYW5zcG9ydCBQcm90b2NvbCIsIGRyYWZ0LXNwZWFrbWFuLXBnbS0pLS4zODUgRShz cGVjLTA2LnR4dCwgYSB3KTcyIDE2MwpRKG9yayBpbiBwcm9ncmVzcy4pLS4xMSBFKFsxNF0g Vik3MiAxODkgUShpY2lzYW5vLCBMLiwgUml6em8sIEwuLCBDcm8pCi0uNjYgRSh3Y3JvZnQs IEouLCAiVENQLWxpayktLjI3NSBFIDIuNzUoZUMpLS4xMSBHCihvbmdlc3Rpb24gQ29udHJv bCBmb3IgTGF5ZXJlZCBNdWx0aWNhc3QpLTIuNzUgRShEYXRhIFQpNzIgMjAyIFEKKHJhbnNm ZXIiLCBJRUVFIEluZm9jb20gJzk4LCBTYW4gRnJhbmNpc2NvLCBDQSwgTWFyKS0uMzg1IEUo LjI4LUFwcikKLS42MDUgRSguMSAxOTk4LiktLjYwNSBFKFsxNV0gVik3MiAyMjggUQooaWNp c2FubywgTC4sICJOb3RlcyBPbiBhIEN1bXVsYXRpKS0uNjYgRSAuMzMgLS4xNjUodmUgTCkt LjI3NSBICihheWVyZWQgT3IpLjE2NSBFIC0uMDU1KGdhKS0uMTk4IEcobml6YXRpb24gb2Yg RGF0YSBQKS4wNTUgRShhY2spLS4xNjUgRQooZXRzIEFjcm9zcyBNdWx0aXBsZSktLjExIEUo Z3JvdXBzIHdpdGggRGlmKTcyIDI0MSBRKGZlcmVudCBSYXRlcyIsIFVuaSkKLS4yNzUgRSAt LjE2NSh2ZSktLjI3NSBHKHJzaXR5IENvbGxlKS4xNjUgRQooZ2UgTG9uZG9uIENvbXB1dGVy IFNjaWVuY2UgUmVzZWFyY2ggTm90ZSktLjE2NSBFKFJOLzk4LzI1LCBXKTcyIDI1NCBRCihv cmsgaW4gUHJvZ3Jlc3MgXChNYXkgMTk5OFwpLiktLjg4IEUvRjEgMTEvVGltZXMtQm9sZEAw IFNGKDkuKTcyIDMwNiBRCi9GMiAxNC9UaW1lcy1Cb2xkQDAgU0YgLS43KEF1KTUuNSBHKHRo b3JzJyBBZGRyKS43IEUoZXNzZXMpLS4yNTIgRSBGMAooTWljaGFlbCBMdWJ5KTgwLjI1IDMy Mi42IFEobHVieUBkaWdpdGFsZm91bnRhaW4uY29tKTgwLjI1IDMzNS42IFEKKERpZ2l0YWwg Rik4MC4yNSAzNDguNiBRKG91bnRhaW4pLS4xNjUgRSgzOTE0MSBDaSk4MC4yNSAzNjEuNiBR Cih2aWMgQ2VudGVyIERyaSktLjI3NSBFIC0uMTY1KHZlKS0uMjc1IEcoU3VpdGUgMzAwKTgw LjI1IDM3NC42IFEKKEZyZW1vbnQsIENBLCBVU0EsIDk0NTM4KTgwLjI1IDM4Ny42IFEoSmlt IEdlbW1lbGwpODAuMjUgNDEzLjYgUQooamdlbW1lbGxAbWljcm9zb2Z0LmNvbSk4MC4yNSA0 MjYuNiBRKE1pY3Jvc29mdCBSZXNlYXJjaCk4MC4yNSA0MzkuNiBRCigzMDEgSG8pODAuMjUg NDUyLjYgUSAtLjExKHdhKS0uMjc1IEcocmQgU3QuLCAjODMwKS4xMSBFCihTYW4gRnJhbmNp c2NvLCBDQSwgVVNBLCA5NDEwNSk4MC4yNSA0NjUuNiBRKExvcmVuem8gVik4MC4yNSA0OTEu NiBRCihpY2lzYW5vKS0uNjYgRShsb3JlbnpvQGNpc2NvLmNvbSk4MC4yNSA1MDQuNiBRKGNp c2NvIFN5c3RlbXMsIEluYy4pCjgwLjI1IDUxNy42IFEoMTcwIFcpODAuMjUgNTMwLjYgUShl c3QgVCktLjg4IEUoYXNtYW4gRHIpLS44OCBFKC4sKS0uNjA1CkUoU2FuIEpvc2UsIENBLCBV U0EsIDk1MTM0KTgwLjI1IDU0My42IFEoTHVpZ2kgUml6em8pODAuMjUgNTY5LjYgUQoobHVp Z2lAaWV0LnVuaXBpLml0KTgwLjI1IDU4Mi42IFEgLS40NChBQyk4MC4yNSA1OTUuNiBTKElS SS9JQ1NJLCkuNDQgRQooMTk0NyBDZW50ZXIgU3QsIEJlcmspODAuMjUgNjA4LjYgUShlbGUp LS4xMSBFIDEuNDMgLS43MTUoeSwgQyktLjE2NSBICihBLCBVU0EsIDk0NzA0KS43MTUgRShh bmQpODAuMjUgNjIxLjYgUShEaXAuIEluZy4gZGVsbCdJbmZvcm1hemlvbmUsKQo4MC4yNSA2 MzQuNiBRKFVuaSk4MC4yNSA2NDcuNiBRIDEuNDMgLS43MTUodi4gZCktLjI3NSBIIDIuNzUo aVApLjcxNSBHCihpc2EpLTIuNzUgRSh2aWEgRGlvdGlzYWx2aSAyLCA1NjEyNiBQaXNhLCBJ dGFseSk4MC4yNSA2NjAuNiBRCihNYXJrIEhhbmRsZSk4MC4yNSA2ODYuNiBRKHkpLS4xNjUg RShtamhAYWNpcmkub3IpODAuMjUgNjk5LjYgUShnKS0uMTk4CkUgLS40NChBQyk4MC4yNSA3 MTIuNiBTKElSSSwpLjQ0IEUoMTk0NyBDZW50ZXIgU3QsKTgwLjI1IDcyNS42IFEKKEx1Ynkv R2VtbWVsbC9WKTcyIDc2OSBRKGljaXNhbm8vUml6em8vSGFuZGxlKS0uNjYgRSh5L0Nybykt LjE2NSBFCjExMS44NTYod2Nyb2Z0IFNlY3Rpb24pLS4yNzUgRiAyLjc1KDkuIFtQKTIuNzUg RihhZ2UgMThdKS0uMTY1IEUgRVAKJSVQYWdlOiAxOSAxOQolJUJlZ2luUGFnZVNldHVwCkJQ CiUlRW5kUGFnZVNldHVwCi9GMCAxMS9UaW1lcy1Sb21hbkAwIFNGKElOVEVSTkVUKTcyIDQ5 IFEgNzEuNTg3KC1EUkFGVCBFeHBpcmVzOiktMS4wMTIgRgooSmFudWFyeSAyMDAyKTIuNzUg RShKdWx5IDIwMDEpMTIzLjcyNiBFKEJlcmspODAuMjUgODUgUShlbGUpLS4xMSBFIDEuNDMK LS43MTUoeSwgQyktLjE2NSBIKEEsIFVTQSwgOTQ3MDQpLjcxNSBFKEpvbiBDcm8pODAuMjUg MTExIFEod2Nyb2Z0KS0uMjc1CkUoSi5Dcm8pODAuMjUgMTI0IFEod2Nyb2Z0QGNzLnVjbC5h Yy51ayktLjI3NSBFCihEZXBhcnRtZW50IG9mIENvbXB1dGVyIFNjaWVuY2UpODAuMjUgMTM3 IFEoVW5pKTgwLjI1IDE1MCBRIC0uMTY1KHZlKQotLjI3NSBHKHJzaXR5IENvbGxlKS4xNjUg RShnZSBMb25kb24pLS4xNjUgRShHbyk4MC4yNSAxNjMgUSh3ZXIgU3RyZWV0LCkKLS4yNzUg RShMb25kb24gV0MxRSA2QlQpODAuMjUgMTc2IFEgMi43NSgsVSktLjgxNCBHKEspLTIuNzUg RQooTHVieS9HZW1tZWxsL1YpNzIgNzY5IFEoaWNpc2Fuby9SaXp6by9IYW5kbGUpLS42NiBF KHkvQ3JvKS0uMTY1IEUKMTExLjg1Nih3Y3JvZnQgU2VjdGlvbiktLjI3NSBGIDIuNzUoOS4g W1ApMi43NSBGKGFnZSAxOV0pLS4xNjUgRSBFUAolJVBhZ2U6IDIwIDIwCiUlQmVnaW5QYWdl U2V0dXAKQlAKJSVFbmRQYWdlU2V0dXAKL0YwIDExL1RpbWVzLVJvbWFuQDAgU0YoSU5URVJO RVQpNzIgNDkgUSA3MS41ODcoLURSQUZUIEV4cGlyZXM6KS0xLjAxMiBGCihKYW51YXJ5IDIw MDIpMi43NSBFKEp1bHkgMjAwMSkxMjMuNzI2IEUvRjEgMTEvVGltZXMtQm9sZEAwIFNGKDEw Lik3MiA4NQpRL0YyIDE0L1RpbWVzLUJvbGRAMCBTRihGdWxsIENvcHlyaWdodCBTdGF0ZW1l bnQpNS41IEUgRjAoQ29wKTcyIDEwMS42IFEKKHlyaWdodCBcKENcKSBUaGUgSW50ZXJuZXQg U29jaWV0eSBcKDIwMDBcKS4pLS4xMSBFKEFsbCBSaWdodHMgUmVzZXJ2KQo1LjUgRShlZC4p LS4xNjUgRShUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xhdGlvbnMgb2YgaXQgbWF5IGJlIGNv cGllZCBhblwKZCBmdXJuaXNoZWQgdG8gb3RoZXJzLCBhbmQgZGVyaSk3MiAxMTguMiBRIC0u Mjc1KHZhKS0uMjc1IEcodGkpLjI3NSBFCi4zMyAtLjE2NSh2ZSB3KS0uMjc1IEgob3Jrcyku MDU1IEUodGhhdCBjb21tZW50IG9uIG9yIG90aGVyd2lzZSBlKTcyCjEzMS4yIFEKKHhwbGFp biBpdCBvciBhc3Npc3QgaW4gaXRzIGltcGxlbWVudGF0aW9uIG1heSBiZSBwcmVwYXJlZCwg Y29waWVkLCkKLS4xNjUgRShwdWJsaXNoZWQgYW5kIGRpc3RyaWIpNzIgMTQ0LjIgUQoodXRl ZCwgaW4gd2hvbGUgb3IgaW4gcGFydCwgd2l0aG91dCByZXN0cmljdGlvbiBvZiBhbiktLjIy IEUgMi43NSh5aykKLS4xNjUgRyhpbmQsIHBybyktMi43NSBFKHZpZGVkIHRoYXQgdGhlKS0u MTY1IEUoYWJvKTcyIDE1Ny4yIFEgLjMzIC0uMTY1Cih2ZSBjKS0uMTY1IEgob3ApLjE2NSBF KHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGFyYWdyYXBoIGFyZSBpbmNsdWRlZCBvXApuIGFs bCBzdWNoIGNvcGllcyBhbmQgZGVyaSktLjExIEUgLS4yNzUodmEpLS4yNzUgRyh0aSkuMjc1 IEUgLjMzIC0uMTY1Cih2ZSB3KS0uMjc1IEgob3Jrcy4pLjA1NSBFKEhvKTcyIDE3MC4yIFEo d2UpLS4yNzUgRSAtLjE2NSh2ZSktLjI3NSBHIC44OAotLjQ0KHIsIHQpLjE2NSBIKGhpcyBk b2N1bWVudCBpdHNlbGYgbWF5IG5vdCBiZSBtb2RpXDIxNGVkIGluIGFuKS40NCBFCjIuNzUo eXcpLS4xNjUgRyhheSktMi44NiBFIDIuNzUoLHMpLS43MTUgRyh1Y2ggYXMgYnkgcmVtbykt Mi43NSBFCih2aW5nIHRoZSktLjE2NSBFKGNvcCk3MiAxODMuMiBRKHlyaWdodCBub3RpY2Ug b3IgcmVmZXJlbmNlcyB0byB0aGUgSW50XAplcm5ldCBTb2NpZXR5IG9yIG90aGVyIEludGVy bmV0IG9yKS0uMTEgRSAtLjA1NShnYSktLjE5OCBHKG5pemF0aW9ucywgZSkKLjA1NSBFKHhj ZXB0IGFzKS0uMTY1IEUobmVlZGVkIGZvciB0aGUgcHVycG9zZSBvZiBkZSk3MiAxOTYuMiBR IC0uMTY1Cih2ZSktLjI3NSBHKGxvcGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hpY2gg Y2FzZSB0aGUgcHJvY2VkdXJlcyBmb3IpCi4xNjUgRShjb3ApNzIgMjA5LjIgUQooeXJpZ2h0 cyBkZVwyMTRuZWQgaW4gdGhlIEludGVybmV0IGxhbmd1YWdlcyBvdGhlciB0aGFuIEVuZ2xp c2guKS0uMTEgRQooVGhlIGxpbWl0ZWQgcGVybWlzc2lvbnMgZ3JhbnRlZCBhYm8pNzIgMjI1 LjggUSAuMzMgLS4xNjUodmUgYSktLjE2NSBICihyZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90 IGJlIHJlKS4xNjUgRSAtLjIyKHZvKS0uMjc1IEcgLS4xMShrZSkuMjIgRwoyLjc1KGRiKS4x MSBHIDIuNzUoeXQpLTIuNzUgRyhoZSBJbnRlcm5ldCktMi43NSBFCihTb2NpZXR5IG9yIGl0 cyBzdWNjZXNzb3JzIG9yIGFzc2lnbnMuKTcyIDIzOC44IFEKKFRoaXMgZG9jdW1lbnQgYW5k IHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGlzIHBybyk3MiAyNTUuNCBRCih2 aWRlZCBvbiBhbiAiQVMgSVMiIGJhc2lzIGFuZCBUSEUpLS4xNjUgRQooSU5URVJORVQgU09D SUVUWSBBTkQgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HIFQpNzIgMjY4LjQgUQooQVNLIEZP UkNFIERJU0NMQUlNUyktMS4wMjMgRShBTEwgVyk3MiAyODEuNCBRCihBUlJBTlRJRVMsIEVY UFJFU1MgT1IgSU1QTElFRCwgSU5DTFVESU5HIEIpLTEuMzIgRShVVCBOTyktLjExIEUgMi43 NQooVEwpLS40NCBHKElNSVRFRCBUKS0yLjc1IEUgMi43NShPQSktLjE5OCBHKE5ZKS0yLjc1 IEUgLTEuMzIoV0EpNzIgMjk0LjQKUyhSUkFOVFkgVEhBKTEuMzIgRSAyLjc1KFRUKS0xLjIy MSBHKEhFIFVTRSBPRiBUSEUgSU5GT1JNQSktMi43NSBFCihUSU9OIEhFUkVJTiBXSUxMIE5P KS0xLjIyMSBFIDIuNzUoVEkpLS40NCBHKE5GUklOR0UpLTIuNzUgRQooQU5ZIFJJR0hUUyBP UiBBTlkgSU1QTElFRCBXKTcyIDMwNy40IFEoQVJSQU5USUVTIE9GIE1FUkNIQU5UKS0xLjMy IEUKKEFCSUxJVFkgT1IgRklUTkVTUyktMS4wMjMgRShGT1IgQSBQKTcyIDMyMC40IFEoQVIp LTEuMDEyIEUKKFRJQ1VMQVIgUFVSUE9TRS4iKS0uNjYgRShMdWJ5L0dlbW1lbGwvVik3MiA3 NjkgUShpY2lzYW5vL1JpenpvL0hhbmRsZSkKLS42NiBFKHkvQ3JvKS0uMTY1IEUgMTA2LjM1 Nih3Y3JvZnQgU2VjdGlvbiktLjI3NSBGIDIuNzUoMTAuIFtQKTIuNzUgRgooYWdlIDIwXSkt LjE2NSBFIEVQCiUlUGFnZTogMjEgMjEKJSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VT ZXR1cAovRjAgMTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3MiA0OSBRIDcxLjU4Nygt RFJBRlQgRXhwaXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMikyLjc1IEUoSnVseSAyMDAx KTEyMy43MjYgRShMdWJ5L0dlbW1lbGwvVik3MiA3NjkgUQooaWNpc2Fuby9SaXp6by9IYW5k bGUpLS42NiBFKHkvQ3JvKS0uMTY1IEUgMTA2LjM1Nih3Y3JvZnQgU2VjdGlvbiktLjI3NQpG IDIuNzUoMTAuIFtQKTIuNzUgRihhZ2UgMjFdKS0uMTY1IEUgRVAKJSVUcmFpbGVyCmVuZAol JUVPRgo= --==_Exmh_5195028970-- >From owner-rmt@listserv.lbl.gov Thu Jul 19 17:12:19 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6K0CGO28854; Thu, 19 Jul 2001 17:12:16 -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.11.2/8.11.2) with ESMTP id f6K0CER28850 for ; Thu, 19 Jul 2001 17:12:14 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6K0CD721890 for ; Thu, 19 Jul 2001 17:12:13 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6K0CCA21876 for ; Thu, 19 Jul 2001 17:12:12 -0700 (PDT) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6K0C4X18278; Thu, 19 Jul 2001 17:12:04 -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 RAA01812; Thu, 19 Jul 2001 17:11:45 -0700 (PDT) Message-Id: <200107200011.RAA01812@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI] To: internet-drafts@ietf.org cc: adamson@itd.nrl.navy.mil, jgemmell@MICROSOFT.com, luigi@iet.unipi.it, mjh@aciri.org, J.Crowcroft@cs.ucl.ac.uk, lorenzo@cisco.com, rmt@lbl.gov Subject: draft-ietf-rmt-bb-fec-03.txt Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_5297534880" Date: Thu, 19 Jul 2001 17:11:45 -0700 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk This is a multipart MIME message. --==_Exmh_5297534880 Content-Type: text/plain; charset=us-ascii Please post this draft on the IETF Internet Drafts archive. This is an update of an existing WG draft (RMT). Thank you, Lorenzo Vicisano --==_Exmh_5297534880 Content-Type: text/plain ; name="draft-ietf-rmt-bb-fec-03.txt"; charset=us-ascii Content-Description: draft-ietf-rmt-bb-fec-03.txt Content-Disposition: attachment; filename="draft-ietf-rmt-bb-fec-03.txt" Internet Engineering Task Force RMT WG INTERNET-DRAFT M.Luby/Digital Fountain draft-ietf-rmt-bb-fec-03.txt L.Vicisano/Cisco J.Gemmell/Microsoft L.Rizzo/ACIRI and Univ. Pisa M.Handley/ACIRI J. Crowcroft/UCL 19 July 2001 Expires: January 2002 RMT BB Forward Error Correction Codes 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". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This document is a product of the IETF RMT WG. Comments should be addressed to the authors, or the WG's mailing list at rmt@isi.edu. Abstract This memo describes the abstract packet formats and IANA registration procedures for use of Forward Error Correction (FEC) codes within the context of reliable IP multicast transport. This memo should be read in conjunction with and uses the terminology of the companion memo [1], which describes the use of Forward Error Correction (FEC) codes within the context of reliable IP multicast transport and Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft [Page 1] ^L INTERNET-DRAFT Expires: January 2002 July 2001 provides an introduction to some commonly used FEC codes. 1. FEC Abstract Packet Fields and Out-of-Band Information This section specifies the information that protocol packets must carry to implement the various forms of FEC-based reliability. A session is defined to be all the information associated with a transmission of data about a particular object by a single sender. There are three classes of packets that may contain FEC information within a session: data packets, session-control packets and feedback packets. They generally contain different kinds of FEC information. Note that some protocols do not use feedback packets. Data packets may sometime serve as session-control packets as well; both data and session-control packets generally travel downstream (from the sender towards receivers) and are addressed to a multicast IP address (sometime they might be addressed to the unicast address of a specific receiver). In the following, for simplicity we will refer to both data and session control packets as downstream-traveling packets, or simply downstream packets. As a general rule, feedback packets travel upstream (from receivers to the sender) and are addressed to the unicast address of the sender. Sometimes, however, they might be addressed to a multicast IP address or to the unicast address of a receiver or also the the unicast address of some different node (an intermediate node that provides recovery services or a neighboring router). The FEC-related information that can be present in downstream packets can be classified as follows: 1) FEC Encoding Identifier Identifies the FEC encoding being used and has the purpose of allowing receivers to select the appropriate FEC decoder. As a general rule, the "FEC Encoding Identifier" MUST be the same for a given session, i.e., for all transmission of data related to a particular object, but MAY vary across different transmissions of data about different objects in different sessions, even if transmitted using the same set of multicast groups and/or using a single upper-layer session. 2) FEC payload ID Identifies the symbol(s) in the payload of the packet. The content of this piece of information depends on the encoder being used Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1. [Page 2] ^L INTERNET-DRAFT Expires: January 2002 July 2001 (e.g. in Block FEC codes this may be the combination of block index and encoding symbol identifier; in ideal expandable FEC codes this may be just a flat encoding symbol identifier). 3) FEC Object Transmission Information This is information regarding the encoding of a specific object needed by the FEC decoder (e.g. for Block FEC codes this may be the combination of block length and object length). This might also include general parameters of the FEC encoder. Note that, in strict terms, the "FEC Encoding Identifier" belongs to this class of information, however, for practical purposes, we will consider it separately. All the classes of information above, except 2), can either be transmitted within the transport session (using protocol packet-header fields) or out of band. The information described in 2) MUST be transmitted in data-packet header fields, as it provides a description of the data contained in the packet. In the following we will specify the content of 1), 2) and 3) regardless of whether these pieces of information are transmitted in protocol packets or out of band. This document neither specifies out-of-band methods to transport the information nor does it specify the way out-of-band information is associated with packet payloads. This last task is devolved to an upper- layer protocol. Within the context of FEC repair schemes, feedback packets are (optionally) used to request FEC retransmission. The FEC-related information present in feedback packets usually contains an FEC Block Identifier, that defines the block that is being repaired, and the number of Repair Symbols requested. Although this is the most common case, variants are possible in which the receivers provide more specific information about the Repair Symbols requested (e.g. an index range or a list of symbols accepted). It is also possible to include multiple of these request in a single feedback packet. This document does not provide any detail about the format of FEC information in feedback packets. 1.1. FEC Encoding Identifier This is a numeric index that identifies a specific FEC scheme OR a class of encoding schemes that share the same format of "FEC Payload ID" and "FEC Object Transmission Information". Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1.1. [Page 3] ^L INTERNET-DRAFT Expires: January 2002 July 2001 The FEC Encoding Identifier identifies a specific FEC scheme when the encoding scheme is formally and fully specified, in a way that independent implementors can implement both encoder and decoder from the specification. Companion documents of this specification may specify such FEC schemes and associate them with "FEC Encoding Identifier" values. These documents MUST also specify a correspondent format for the "FEC Payload ID" and "FEC Object Transmission Information". Currently FEC Encoding Identifiers in the range 0-127 are reserved for this class of encoding schemes (fully-specified schemes). It is possible that a FEC scheme cannot be completely specified or that such a specification is simply not available or also that a party exists that owns the encoding scheme and it is not willing to disclose its algorithm. We refer to these encoding schemes as "Under-Specified" schemes. Under-specified schemes can still be identified as follows: o A format of the fields "FEC Payload ID" and "FEC Object Transmission Information" MUST be defined for the encoding scheme. o A value of "FEC Encoding Identifier" MUST be reserved and associated to the format definitions above. An already reserved "FEC Encoding Identifier" MUST be reused if it is associated to the same format of "FEC Payload ID" and "FEC Object Transmission Information" as the ones needed for the new under-specified FEC scheme. o A value of "FEC Encoding Name" must be reserved (see below). An Under-specified FEC scheme is completely identified by the tuple (FEC Encoding Identifier, FEC Encoding Name). The tuple MUST identify a single scheme that has at least one implementation. The party that owns this tuple MUST be able to provide information on how to obtain the under-specified FEC scheme identified by the tuple (e.g. a pointer to a publicly available reference-implementation or the name and contacts of a company that sells it, either separately or embedded in another product). "FEC Encoding Names" are numeric identifiers scoped by a FEC Encoding Identifier. The FEC Encoding Name MUST be part of the "FEC Object Transmission Information" and must be communicated to receivers together with the FEC Encoding Identifier. Different FEC schemes that share the same FEC Encoding Identifier -- but have different FEC Encoding Names -- also share the same format of FEC Payload ID and FEC Object Transmission Information. Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1.1. [Page 4] ^L INTERNET-DRAFT Expires: January 2002 July 2001 This specification reserves the range 0-127 of FEC Encoding Identifiers for fully-specified encoding schemes and the range 128-255 for under- specified encoding schemes. 1.2. FEC Payload ID and FEC Object Transmission Information A document that specifies an encoding scheme and reserves a value of FEC Encoding Identifier MUST define a packet-field format for FEC Payload ID and FEC Object Transmission Information according to the need of the encoding scheme. This also applies to documents that reserves values of FEC Encoding Identifiers for under-specified encoding schemes. In this case the FEC Object Transmission Information must also include a field to contain the "FEC Encoding Name". A packet field definition of FEC Object Transmission Information MUST be provided despite the fact that a protocol instantiation may decide to communicate this information out of band. All packet field definitions (FEC Payload ID and FEC Object Transmission Information) MUST be fully specified at the level of bit-fields and they must have a length that is a multiple of a 4-byte word (this is to facilitate the alignment of packet fields in protocol instantiations). Note that the specification of FEC Payload ID MUST allow an implementation-independent identification of the packet payload even in the case of Under-Specified encoding schemes. 2. Preassigned FEC Encoding Identifiers This section specifies the FEC Encoding Identifier and the relative packets field for a number of known schemes that follow under the class of under-specified FEC schemes. Others may be specified in companion documents. 2.1. Small Block, Large Block and Expandable FEC Codes This section reserves a FEC Encoding Identifier for the families of codes described in [1], and specifies the relative packet fields. Under-specified FEC schemes that belong to this class MUST use this identifier and packet field definitions. The FEC Encoding Identifier for under specified codes assigned to Small Block, Large Block, and Expandable FEC Codes is 128. Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.1. [Page 5] ^L INTERNET-DRAFT Expires: January 2002 July 2001 The FEC Payload ID is composed of an encoding symbol identifier and an encoding block number structured as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | encoding block number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | encoding symbol ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In addition, a one bit FEC Encoding Flag MAY be included, and this flag indicates whether the encoding symbol(s) in the payload of the packet are source symbol(s) or redundant symbol(s). The FEC Object Transmission Information has the following structure: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Encoding Name | Object Length (MSB) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Object Length (LSB) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that this structure limits the range of possible FEC Encoding Names to 0-:-65536, despite the fact that the FEC Object Transmission Information can also be transmitted out of band. The Object Length, composed of a Most Significant Bytes portion (MSB) and a Least Significant Bytes portion (LSB), is expressed in bytes. 2.2. Small Block Systematic FEC Codes The following definitions apply to systematic codes of small length (total block length < 2^16). The FEC Encoding Identifier for under specified codes assigned to Small Block Systematic FEC Codes is 129. Although these codes can generally be accommodated by the FEC Encoding Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.2. [Page 6] ^L INTERNET-DRAFT Expires: January 2002 July 2001 Identifier described in Section 2.1, a specific Encoding-ID is defined for systematic codes to allow better flexibility and to retain header compactness. The small source block length and small exapansion factor that often characterize systematic codes may require that the data source changes frequently the source block length. To allow the dynamic variation of the source block length and to communicate it to the receivers with low overhead, the block length is included in the FEC Payload ID. The FEC Payload ID is composed of the encoding block number, the encoding symbol identifier and the block length: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | encoding block number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source block length | encoding symbol ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The FEC Object Transmission Information, when used, has the following structure: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Encoding Name | Number of redundant symbols | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When variable block-length is used, the number of redundant symbols is to be interpreted as a maximum value (upper bound). This field is provided as an indication to allow receives to preallocate a decoder suitable for all the object blocks. Note that this structure limits the range of possible FEC Encoding Names to 0-:-65536, despite the FEC Object Transmission Information can also be transmitted out of band. 3. IANA Considerations Values of FEC Encoding Identifiers and FEC Encoding Names are subject to IANA registration. FEC Encoding Identifiers and FEC Encoding Names are hierarchical: FEC Encoding Identifiers (at the top level) scope ranges Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 3. [Page 7] ^L INTERNET-DRAFT Expires: January 2002 July 2001 of FEC Encoding Names. Not all FEC Encoding Identifiers have a corresponding FEC Encoding Name scope (see below). A FEC Encoding Identifier is a numeric non-negative index. Value from 0 to 127 are reserved for FEC encoders that are fully specified, as described in section 3.1. The assignment of a FEC Encoding Identifier in this range can only be granted if the requestor can provide such a specification published as an IETF RFC. Values greater than 127 can be assigned to under-specified encoding schemes. Note: this specification already assigns the values 128 and 129. In any case values of FEC Encoding Identifiers can only be assigned if the required FEC packet fields corresponding to it (see section 1.2) are specified in a RFC. Each FEC Encoding Identifier assigned to an under-specified encoding scheme scopes an independent range of FEC Encoding Names (i.e. the same value of FEC Encoding Name can be reused for different FEC Encoding Identifiers). An FEC Encoding Name is a numeric non-negative index. The document that reserves a FEC Encoding Identifier MAY also specify a range for the subordinate FEC Encoding Names. Under the scope of a FEC Encoding Identifier, FEC Encoding Names are assigned on a First Come First Served base to requestors that are able to provide point of contact information and a pointer to publicly accessible documentation describing the FEC scheme and ways to obtain it (e.g. a pointer to a publicly available reference-implementation or the name and contacts of a company that sells it, either separately or embedded in another product). The requestor is responsible for keeping this information up to date. 4. Acknowledgments Brian Adamson contributed to this document by shaping Section 2.2 and providing general feedback. We also wish to thank Vincent Roca for his comments. 5. References [1] Luby, M., Vicisano, Gemmell, J., L., Rizzo, L., Handley, M., Crowcroft, J., "The use of Forward Error Correction in Reliable Multicast", Internet draft draft-ietf-rmt-info-fec-00.txt, November 2000. Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 5. [Page 8] ^L INTERNET-DRAFT Expires: January 2002 July 2001 6. Authors' Addresses Michael Luby luby@digitalfountain.com Digital Fountain, Inc. 39141 Civic Center Drive Suite 300 Fremont, CA 94538 Lorenzo Vicisano lorenzo@cisco.com cisco Systems, Inc. 170 West Tasman Dr., San Jose, CA, USA, 95134 Jim Gemmell jgemmell@microsoft.com Microsoft Research 301 Howard St., #830 San Francisco, CA, USA, 94105 Luigi Rizzo luigi@iet.unipi.it ACIRI, 1947 Center St., Berkeley CA 94704 and Dip. di Ing. dell'Informazione Universita` di Pisa via Diotisalvi 2, 56126 Pisa, Italy Mark Handley mjh@aciri.org ACIRI 1947 Center St. Berkeley CA, USA, 94704 Jon Crowcroft J.Crowcroft@cs.ucl.ac.uk Department of Computer Science University College London Gower Street, London WC1E 6BT, UK Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 6. [Page 9] ^L INTERNET-DRAFT Expires: January 2002 July 2001 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." Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 7. [Page 10] ^L INTERNET-DRAFT Expires: January 2002 July 2001 Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 7. [Page 11] --==_Exmh_5297534880 Content-Type: application/postscript ; name="draft-ietf-rmt-bb-fec-03.ps" Content-Description: draft-ietf-rmt-bb-fec-03.ps Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-rmt-bb-fec-03.ps" JSFQUy1BZG9iZS0zLjAKJSVDcmVhdG9yOiBncm9mZiB2ZXJzaW9uIDEuMTYuMQolJUNyZWF0 aW9uRGF0ZTogVGh1IEp1bCAxOSAxNzowODoxNCAyMDAxCiUlRG9jdW1lbnROZWVkZWRSZXNv dXJjZXM6IGZvbnQgQ291cmllci1Cb2xkCiUlKyBmb250IFRpbWVzLUJvbGQKJSUrIGZvbnQg VGltZXMtUm9tYW4KJSUrIGZvbnQgQ291cmllcgolJURvY3VtZW50U3VwcGxpZWRSZXNvdXJj ZXM6IHByb2NzZXQgZ3JvcHMgMS4xNiAxCiUlUGFnZXM6IDkKJSVQYWdlT3JkZXI6IEFzY2Vu ZAolJU9yaWVudGF0aW9uOiBQb3J0cmFpdAolJUVuZENvbW1lbnRzCiUlQmVnaW5Qcm9sb2cK JSVCZWdpblJlc291cmNlOiBwcm9jc2V0IGdyb3BzIDEuMTYgMQovc2V0cGFja2luZyB3aGVy ZXsKcG9wCmN1cnJlbnRwYWNraW5nCnRydWUgc2V0cGFja2luZwp9aWYKL2dyb3BzIDEyMCBk aWN0IGR1cCBiZWdpbgovU0MgMzIgZGVmCi9BL3Nob3cgbG9hZCBkZWYKL0J7MCBTQyAzIC0x IHJvbGwgd2lkdGhzaG93fWJpbmQgZGVmCi9DezAgZXhjaCBhc2hvd31iaW5kIGRlZgovRHsw IGV4Y2ggMCBTQyA1IDIgcm9sbCBhd2lkdGhzaG93fWJpbmQgZGVmCi9FezAgcm1vdmV0byBz aG93fWJpbmQgZGVmCi9GezAgcm1vdmV0byAwIFNDIDMgLTEgcm9sbCB3aWR0aHNob3d9Ymlu ZCBkZWYKL0d7MCBybW92ZXRvIDAgZXhjaCBhc2hvd31iaW5kIGRlZgovSHswIHJtb3ZldG8g MCBleGNoIDAgU0MgNSAyIHJvbGwgYXdpZHRoc2hvd31iaW5kIGRlZgovSXswIGV4Y2ggcm1v dmV0byBzaG93fWJpbmQgZGVmCi9KezAgZXhjaCBybW92ZXRvIDAgU0MgMyAtMSByb2xsIHdp ZHRoc2hvd31iaW5kIGRlZgovS3swIGV4Y2ggcm1vdmV0byAwIGV4Y2ggYXNob3d9YmluZCBk ZWYKL0x7MCBleGNoIHJtb3ZldG8gMCBleGNoIDAgU0MgNSAyIHJvbGwgYXdpZHRoc2hvd31i aW5kIGRlZgovTXtybW92ZXRvIHNob3d9YmluZCBkZWYKL057cm1vdmV0byAwIFNDIDMgLTEg cm9sbCB3aWR0aHNob3d9YmluZCBkZWYKL097cm1vdmV0byAwIGV4Y2ggYXNob3d9YmluZCBk ZWYKL1B7cm1vdmV0byAwIGV4Y2ggMCBTQyA1IDIgcm9sbCBhd2lkdGhzaG93fWJpbmQgZGVm Ci9Re21vdmV0byBzaG93fWJpbmQgZGVmCi9Se21vdmV0byAwIFNDIDMgLTEgcm9sbCB3aWR0 aHNob3d9YmluZCBkZWYKL1N7bW92ZXRvIDAgZXhjaCBhc2hvd31iaW5kIGRlZgovVHttb3Zl dG8gMCBleGNoIDAgU0MgNSAyIHJvbGwgYXdpZHRoc2hvd31iaW5kIGRlZgovU0Z7CmZpbmRm b250IGV4Y2gKW2V4Y2ggZHVwIDAgZXhjaCAwIGV4Y2ggbmVnIDAgMF1tYWtlZm9udApkdXAg c2V0Zm9udApbZXhjaC9zZXRmb250IGN2eF1jdnggYmluZCBkZWYKfWJpbmQgZGVmCi9NRnsK ZmluZGZvbnQKWzUgMiByb2xsCjAgMyAxIHJvbGwKbmVnIDAgMF1tYWtlZm9udApkdXAgc2V0 Zm9udApbZXhjaC9zZXRmb250IGN2eF1jdnggYmluZCBkZWYKfWJpbmQgZGVmCi9sZXZlbDAg MCBkZWYKL1JFUyAwIGRlZgovUEwgMCBkZWYKL0xTIDAgZGVmCi9NQU5VQUx7CnN0YXR1c2Rp Y3QgYmVnaW4vbWFudWFsZmVlZCB0cnVlIHN0b3JlIGVuZAp9YmluZCBkZWYKL1BMR3sKZ3Nh dmUgbmV3cGF0aCBjbGlwcGF0aCBwYXRoYmJveCBncmVzdG9yZQpleGNoIHBvcCBhZGQgZXhj aCBwb3AKfWJpbmQgZGVmCi9CUHsKL2xldmVsMCBzYXZlIGRlZgoxIHNldGxpbmVjYXAKMSBz ZXRsaW5lam9pbgo3MiBSRVMgZGl2IGR1cCBzY2FsZQpMU3sKOTAgcm90YXRlCn17CjAgUEwg dHJhbnNsYXRlCn1pZmVsc2UKMSAtMSBzY2FsZQp9YmluZCBkZWYKL0VQewpsZXZlbDAgcmVz dG9yZQpzaG93cGFnZQp9YmluZCBkZWYKL0RBewpuZXdwYXRoIGFyY24gc3Ryb2tlCn1iaW5k IGRlZgovU057CnRyYW5zZm9ybQouMjUgc3ViIGV4Y2ggLjI1IHN1YiBleGNoCnJvdW5kIC4y NSBhZGQgZXhjaCByb3VuZCAuMjUgYWRkIGV4Y2gKaXRyYW5zZm9ybQp9YmluZCBkZWYKL0RM ewpTTgptb3ZldG8KU04KbGluZXRvIHN0cm9rZQp9YmluZCBkZWYKL0RDewpuZXdwYXRoIDAg MzYwIGFyYyBjbG9zZXBhdGgKfWJpbmQgZGVmCi9UTSBtYXRyaXggZGVmCi9ERXsKVE0gY3Vy cmVudG1hdHJpeCBwb3AKdHJhbnNsYXRlIHNjYWxlIG5ld3BhdGggMCAwIC41IDAgMzYwIGFy YyBjbG9zZXBhdGgKVE0gc2V0bWF0cml4Cn1iaW5kIGRlZgovUkMvcmN1cnZldG8gbG9hZCBk ZWYKL1JML3JsaW5ldG8gbG9hZCBkZWYKL1NUL3N0cm9rZSBsb2FkIGRlZgovTVQvbW92ZXRv IGxvYWQgZGVmCi9DTC9jbG9zZXBhdGggbG9hZCBkZWYKL0ZMewpjdXJyZW50Z3JheSBleGNo IHNldGdyYXkgZmlsbCBzZXRncmF5Cn1iaW5kIGRlZgovQkwvZmlsbCBsb2FkIGRlZgovTFcv c2V0bGluZXdpZHRoIGxvYWQgZGVmCi9SRXsKZmluZGZvbnQKZHVwIG1heGxlbmd0aCAxIGlu ZGV4L0ZvbnROYW1lIGtub3duIG5vdHsxIGFkZH1pZiBkaWN0IGJlZ2luCnsKMSBpbmRleC9G SUQgbmV7ZGVmfXtwb3AgcG9wfWlmZWxzZQp9Zm9yYWxsCi9FbmNvZGluZyBleGNoIGRlZgpk dXAvRm9udE5hbWUgZXhjaCBkZWYKY3VycmVudGRpY3QgZW5kIGRlZmluZWZvbnQgcG9wCn1i aW5kIGRlZgovREVGUyAwIGRlZgovRUJFR0lOewptb3ZldG8KREVGUyBiZWdpbgp9YmluZCBk ZWYKL0VFTkQvZW5kIGxvYWQgZGVmCi9DTlQgMCBkZWYKL2xldmVsMSAwIGRlZgovUEJFR0lO ewovbGV2ZWwxIHNhdmUgZGVmCnRyYW5zbGF0ZQpkaXYgMyAxIHJvbGwgZGl2IGV4Y2ggc2Nh bGUKbmVnIGV4Y2ggbmVnIGV4Y2ggdHJhbnNsYXRlCjAgc2V0Z3JheQowIHNldGxpbmVjYXAK MSBzZXRsaW5ld2lkdGgKMCBzZXRsaW5lam9pbgoxMCBzZXRtaXRlcmxpbWl0CltdMCBzZXRk YXNoCi9zZXRzdHJva2VhZGp1c3Qgd2hlcmV7CnBvcApmYWxzZSBzZXRzdHJva2VhZGp1c3QK fWlmCi9zZXRvdmVycHJpbnQgd2hlcmV7CnBvcApmYWxzZSBzZXRvdmVycHJpbnQKfWlmCm5l d3BhdGgKL0NOVCBjb3VudGRpY3RzdGFjayBkZWYKdXNlcmRpY3QgYmVnaW4KL3Nob3dwYWdl e31kZWYKfWJpbmQgZGVmCi9QRU5EewpjbGVhcgpjb3VudGRpY3RzdGFjayBDTlQgc3Vie2Vu ZH1yZXBlYXQKbGV2ZWwxIHJlc3RvcmUKfWJpbmQgZGVmCmVuZCBkZWYKL3NldHBhY2tpbmcg d2hlcmV7CnBvcApzZXRwYWNraW5nCn1pZgolJUVuZFJlc291cmNlCiUlSW5jbHVkZVJlc291 cmNlOiBmb250IENvdXJpZXItQm9sZAolJUluY2x1ZGVSZXNvdXJjZTogZm9udCBUaW1lcy1C b2xkCiUlSW5jbHVkZVJlc291cmNlOiBmb250IFRpbWVzLVJvbWFuCiUlSW5jbHVkZVJlc291 cmNlOiBmb250IENvdXJpZXIKZ3JvcHMgYmVnaW4vREVGUyAxIGRpY3QgZGVmIERFRlMgYmVn aW4vdXsuMDAxIG11bH1iaW5kIGRlZiBlbmQvUkVTIDcyCmRlZi9QTCA3OTIgZGVmL0xTIGZh bHNlIGRlZi9FTkMwWy9hc2NpaWNpcmN1bS9hc2NpaXRpbGRlL1NjYXJvbi9aY2Fyb24KL3Nj YXJvbi96Y2Fyb24vWWRpZXJlc2lzL3RyYWRlbWFyay9xdW90ZXNpbmdsZS8ubm90ZGVmLy5u b3RkZWYvLm5vdGRlZgovLm5vdGRlZi8ubm90ZGVmLy5ub3RkZWYvLm5vdGRlZi8ubm90ZGVm Ly5ub3RkZWYvLm5vdGRlZi8ubm90ZGVmLy5ub3RkZWYKLy5ub3RkZWYvLm5vdGRlZi8ubm90 ZGVmLy5ub3RkZWYvLm5vdGRlZi8ubm90ZGVmLy5ub3RkZWYvLm5vdGRlZi8ubm90ZGVmCi8u bm90ZGVmLy5ub3RkZWYvc3BhY2UvZXhjbGFtL3F1b3RlZGJsL251bWJlcnNpZ24vZG9sbGFy L3BlcmNlbnQKL2FtcGVyc2FuZC9xdW90ZXJpZ2h0L3BhcmVubGVmdC9wYXJlbnJpZ2h0L2Fz dGVyaXNrL3BsdXMvY29tbWEvaHlwaGVuCi9wZXJpb2Qvc2xhc2gvemVyby9vbmUvdHdvL3Ro cmVlL2ZvdXIvZml2ZS9zaXgvc2V2ZW4vZWlnaHQvbmluZS9jb2xvbgovc2VtaWNvbG9uL2xl c3MvZXF1YWwvZ3JlYXRlci9xdWVzdGlvbi9hdC9BL0IvQy9EL0UvRi9HL0gvSS9KL0svTC9N L04vTwovUC9RL1IvUy9UL1UvVi9XL1gvWS9aL2JyYWNrZXRsZWZ0L2JhY2tzbGFzaC9icmFj a2V0cmlnaHQvY2lyY3VtZmxleAovdW5kZXJzY29yZS9xdW90ZWxlZnQvYS9iL2MvZC9lL2Yv Zy9oL2kvai9rL2wvbS9uL28vcC9xL3Ivcy90L3Uvdi93L3gveQovei9icmFjZWxlZnQvYmFy L2JyYWNlcmlnaHQvdGlsZGUvLm5vdGRlZi9xdW90ZXNpbmdsYmFzZS9ndWlsbGVtb3RsZWZ0 Ci9ndWlsbGVtb3RyaWdodC9idWxsZXQvZmxvcmluL2ZyYWN0aW9uL3BlcnRob3VzYW5kL2Rh Z2dlci9kYWdnZXJkYmwKL2VuZGFzaC9lbWRhc2gvZmYvZmkvZmwvZmZpL2ZmbC9kb3RsZXNz aS9kb3RsZXNzai9ncmF2ZS9odW5nYXJ1bWxhdXQKL2RvdGFjY2VudC9icmV2ZS9jYXJvbi9y aW5nL29nb25lay9xdW90ZWRibGxlZnQvcXVvdGVkYmxyaWdodC9vZS9sc2xhc2gKL3F1b3Rl ZGJsYmFzZS9PRS9Mc2xhc2gvLm5vdGRlZi9leGNsYW1kb3duL2NlbnQvc3RlcmxpbmcvY3Vy cmVuY3kveWVuCi9icm9rZW5iYXIvc2VjdGlvbi9kaWVyZXNpcy9jb3B5cmlnaHQvb3JkZmVt aW5pbmUvZ3VpbHNpbmdsbGVmdAovbG9naWNhbG5vdC9taW51cy9yZWdpc3RlcmVkL21hY3Jv bi9kZWdyZWUvcGx1c21pbnVzL3R3b3N1cGVyaW9yCi90aHJlZXN1cGVyaW9yL2FjdXRlL211 L3BhcmFncmFwaC9wZXJpb2RjZW50ZXJlZC9jZWRpbGxhL29uZXN1cGVyaW9yCi9vcmRtYXNj dWxpbmUvZ3VpbHNpbmdscmlnaHQvb25lcXVhcnRlci9vbmVoYWxmL3RocmVlcXVhcnRlcnMK L3F1ZXN0aW9uZG93bi9BZ3JhdmUvQWFjdXRlL0FjaXJjdW1mbGV4L0F0aWxkZS9BZGllcmVz aXMvQXJpbmcvQUUKL0NjZWRpbGxhL0VncmF2ZS9FYWN1dGUvRWNpcmN1bWZsZXgvRWRpZXJl c2lzL0lncmF2ZS9JYWN1dGUvSWNpcmN1bWZsZXgKL0lkaWVyZXNpcy9FdGgvTnRpbGRlL09n cmF2ZS9PYWN1dGUvT2NpcmN1bWZsZXgvT3RpbGRlL09kaWVyZXNpcwovbXVsdGlwbHkvT3Ns YXNoL1VncmF2ZS9VYWN1dGUvVWNpcmN1bWZsZXgvVWRpZXJlc2lzL1lhY3V0ZS9UaG9ybgov Z2VybWFuZGJscy9hZ3JhdmUvYWFjdXRlL2FjaXJjdW1mbGV4L2F0aWxkZS9hZGllcmVzaXMv YXJpbmcvYWUvY2NlZGlsbGEKL2VncmF2ZS9lYWN1dGUvZWNpcmN1bWZsZXgvZWRpZXJlc2lz L2lncmF2ZS9pYWN1dGUvaWNpcmN1bWZsZXgvaWRpZXJlc2lzCi9ldGgvbnRpbGRlL29ncmF2 ZS9vYWN1dGUvb2NpcmN1bWZsZXgvb3RpbGRlL29kaWVyZXNpcy9kaXZpZGUvb3NsYXNoCi91 Z3JhdmUvdWFjdXRlL3VjaXJjdW1mbGV4L3VkaWVyZXNpcy95YWN1dGUvdGhvcm4veWRpZXJl c2lzXWRlZgovQ291cmllckAwIEVOQzAvQ291cmllciBSRS9UaW1lcy1Sb21hbkAwIEVOQzAv VGltZXMtUm9tYW4gUkUKL1RpbWVzLUJvbGRAMCBFTkMwL1RpbWVzLUJvbGQgUkUvQ291cmll ci1Cb2xkQDAgRU5DMC9Db3VyaWVyLUJvbGQgUkUKJSVFbmRQcm9sb2cKJSVQYWdlOiAxIDEK JSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTAvQ291cmllci1Cb2xk QDAgU0YoSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSk3MiA4NSBRKFJNVCBXRykK MjA5Ljk5OSBFIDIwMy45OTkoSU5URVJORVQtRFJBRlQgTS5MdWJ5L0RpZ2l0YWwpNzIgOTgg UihGb3VudGFpbik2IEUKMTY3Ljk5OShkcmFmdC1pZXRmLXJtdC1iYi1mZWMtMDMucHMgTC5W aWNpc2Fuby9DaXNjbyk3MiAxMTEgUgooSi5HZW1tZWxsL01pY3Jvc29mdCkzODkuOTk5IDEy NCBRKEwuUml6em8vQUNJUkkgYW5kIFVuaXYuIFBpc2EpMzM1Ljk5OQoxMzcgUShNLkhhbmRs ZXkvQUNJUkkpNDEzLjk5OSAxNTAgUShKLiBDcm93Y3JvZnQvVUNMKTQwNy45OTkgMTYzIFEK KDE5IEp1bHkgMjAwMSk0MzEuOTk5IDE3NiBRKEV4cGlyZXM6IEphbnVhcnkgMjAwMikzNzcu OTk5IDE4OSBRL0YxIDE0Ci9UaW1lcy1Cb2xkQDAgU0YoUk1UIEJCIEYpMTU5LjE0NCAyMTQg UShvcndhcmQgRXJyKS0uMzUgRShvciBDb3JyKS0uMjUyCkUoZWN0aW9uIENvZGVzKS0uMjUy IEUvRjIgMTEvVGltZXMtUm9tYW5AMCBTRihUaGlzIGRvY3VtZW50IGlzIGFuIEludGVyXApu ZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCBhbGwgcHJvKTcyIDIz MyBRCih2aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YpLS4xNjUgRShSRkMyMDI2Lik3MiAyNDYg UQooSW50ZXJuZXQtRHJhZnRzIGFyZSB3KTcyIDI3MiBRCihvcmtpbmcgZG9jdW1lbnRzIG9m IHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZyBUKS0uMTEgRShhc2sgRiktLjg4IEUKKG9yY2Ug XChJRVRGXCksIGl0cyBhcmVhcywpLS4xNjUgRShhbmQgaXRzIHcpNzIgMjg1IFEob3JraW5n IGdyb3Vwcy4pCi0uMTEgRShOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3Ry aWIpNS41IEUodXRlIHcpLS4yMiBFCihvcmtpbmcgZG9jdW1lbnRzIGFzKS0uMTEgRShJbnRl cm5ldC1EcmFmdHMuKTcyIDI5OCBRCihJbnRlcm5ldC1EcmFmdHMgYXJlIHYpNzIgMzI0IFEK KGFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwg cmVwbGFjZWQsIG9yKS0uMjc1CkUob2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBh bik3MiAzMzcgUSAyLjc1KHl0KS0uMTY1IEcgMi43NQooaW1lLiBJdCktMi43NSBGKGlzIGlu YXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UpCjIuNzUg RShtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyBhICJ3KTcyIDM1MCBR CihvcmsgaW4gcHJvZ3Jlc3MiLiktLjExIEUKKFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJu ZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCBodHRwOi8vd3d3KTcyCjM3NiBRKC5pZXRm Lm9yKS0uNzE1IEUoZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0KS0uMTk4IEUgMS43NiAtLjg4 KFRvIHYpCjcyIDQwMiBUKGllKS44OCBFIDIuNzUod3QpLS4yNzUgRyhoZSBsaXN0IEludGVy bmV0LURyYWZ0IFNoYWRvKS0yLjc1IEUKMi43NSh3RCktLjI3NSBHKGlyZWN0b3JpZXMsIHNl ZSBodHRwOi8vd3d3KS0yLjc1IEUoLmlldGYub3IpLS43MTUgRQooZy9zaGFkbyktLjE5OCBF IC0uNzE1KHcuKS0uMjc1IEcoaHRtbC4pLjcxNSBFCihUaGlzIGRvY3VtZW50IGlzIGEgcHJv ZHVjdCBvZiB0aGUgSUVURiBSTVQgV0cuKTcyIDQyOCBRCihDb21tZW50cyBzaG91bGQgYmUg YWRkcmVzc2VkIHRvIHRoZSk1LjUgRShhdXRob3JzLCBvciB0aGUgV0cnKTcyIDQ0MSBRCjIu NzUoc20pLS42MDUgRyhhaWxpbmcgbGlzdCBhdCBybXRAaXNpLmVkdS4pLTIuNzUgRS9GMyAx MS9UaW1lcy1Cb2xkQDAKU0YoQWJzdHJhY3QpMjY3LjUzNCA0NzMgUSBGMihUaGlzIG1lbW8g ZGVzY3JpYmVzIHRoZSBhYnN0cmFjdCBwYWNrKTk3CjQ5NS42IFEoZXQgZm9ybWF0cyBhbmQg SUFOKS0uMTEgRSAyLjc1KEFyKS0uMzg1IEcgLS4xNjUoZWcpLTIuNzUgRwooaXN0cmF0aW9u IHByb2NlZHVyZXMpLjE2NSBFKGZvciB1c2Ugb2YgRik5NyA1MDguNiBRKG9ydyktLjE2NSBF CihhcmQgRXJyb3IgQ29ycmVjdGlvbiBcKEZFQ1wpIGNvZGVzIHdpdGhpbiB0aGUgY29udGUp LS4xMSBFCih4dCBvZiByZWxpYWJsZSBJUCktLjE2NSBFKG11bHRpY2FzdCB0cmFuc3BvcnQu KTk3IDUyMS42IFEKKFRoaXMgbWVtbyBzaG91bGQgYmUgcmVhZCBpbiBjb25qdW5jdGlvbiB3 aXRoIGFuZCB1c2VzIHRoZSk1LjUgRQoodGVybWlub2xvZ3kgb2YgdGhlIGNvbXBhbmlvbiBt ZW1vIFsxXSwgd2hpY2ggZGVzY3JpYmVzIHRoZSB1c2Ugb2YgRik5Nwo1MzQuNiBRKG9ydykt LjE2NSBFKGFyZCBFcnJvciktLjExIEUKKENvcnJlY3Rpb24gXChGRUNcKSBjb2RlcyB3aXRo aW4gdGhlIGNvbnRlKTk3IDU0Ny42IFEKKHh0IG9mIHJlbGlhYmxlIElQIG11bHRpY2FzdCB0 cmFuc3BvcnQgYW5kKS0uMTY1IEUocHJvKTk3IDU2MC42IFEKKHZpZGVzIGFuIGludHJvZHVj dGlvbiB0byBzb21lIGNvbW1vbmx5IHVzZWQgRkVDIGNvZGVzLiktLjE2NSBFIEYzKDEuKTcy CjU5OS42IFEgRjEoRkVDIEFic3RyYWN0IFApNS41IEUoYWNrKS0uMTQgRQooZXQgRmllbGRz IGFuZCBPdXQtb2YtQmFuZCBJbmYpLS4xNCBFKG9ybWF0aW9uKS0uMzUgRSBGMgooVGhpcyBz ZWN0aW9uIHNwZWNpXDIxNGVzIHRoZSBpbmZvcm1hdGlvbiB0aGF0IHByb3RvY29sIHBhY2sp NzIgNjE2LjIgUQooZXRzIG11c3QgY2FycnkgdG8gaW1wbGVtZW50IHRoZSB2KS0uMTEgRShh cmlvdXMpLS4yNzUgRQooZm9ybXMgb2YgRkVDLWJhc2VkIHJlbGlhYmlsaXR5KTcyIDYyOS4y IFEgNS41KC5BKS0uNzE1IEcKKHNlc3Npb24gaXMgZGVcMjE0bmVkIHRvIGJlIGFsbCB0aGUg aW5mb3JtYXRpb24gYXNzb2NpYXRlZCB3aXRoIGEpLTIuNzUKRSh0cmFuc21pc3Npb24gb2Yg ZGF0YSBhYm91dCBhIHBhcnRpY3VsYXIgb2JqZWN0IGJ5IGEgc2luZ2xlIHNlbmRlcik3Mgo2 NDIuMiBRIDUuNSguVCktLjYwNSBHKGhlcmUgYXJlIHRocmVlIGNsYXNzZXMgb2YpLTUuNSBF KHBhY2spNzIgNjU1LjIgUQooZXRzIHRoYXQgbWF5IGNvbnRhaW4gRkVDIGluZm9ybWF0aW9u IHdpdGhpbiBhIHNlc3Npb246IGRhdGEgcGFjayktLjExIEUKKGV0cywgc2Vzc2lvbi1jb250 cm9sIHBhY2spLS4xMSBFKGV0cyktLjExIEUoYW5kIGZlZWRiYWNrIHBhY2spNzIgNjY4LjIK USAyLjc1KGV0cy4gVGhlKS0uMTEgRiAyLjc1KHlnKS0uMTY1IEcoZW5lcmFsbHkgY29udGFp biBkaWYpLTIuNzUgRQooZmVyZW50IGtpbmRzIG9mIEZFQyBpbmZvcm1hdGlvbi4pLS4yNzUg RShOb3RlIHRoYXQpNS41IEUKKHNvbWUgcHJvdG9jb2xzIGRvIG5vdCB1c2UgZmVlZGJhY2sg cGFjayk3MiA2ODEuMiBRKGV0cy4pLS4xMSBFCihEYXRhIHBhY2spNzIgNzA3LjIgUShldHMg bWF5IHNvbWV0aW1lIHNlcnYpLS4xMSBFIDIuNzUoZWEpLS4xNjUgRyAyLjc1CihzcyktMi43 NSBHKGVzc2lvbi1jb250cm9sIHBhY2spLTIuNzUgRQooZXRzIGFzIHdlbGw7IGJvdGggZGF0 YSBhbmQgc2Vzc2lvbi0pLS4xMSBFKGNvbnRyb2wgcGFjayk3MiA3MjAuMiBRCihldHMgZ2Vu ZXJhbGx5IHRyYSktLjExIEUgLS4xNjUodmUpLS4yMiBHIDIuNzUobGQpLjE2NSBHIC0uMjc1 KG93KS0yLjc1CkcobnN0cmVhbSBcKGZyb20gdGhlIHNlbmRlciB0bykuMjc1IEUgLS4xMSh3 YSktLjI3NSBHKHJkcyByZWNlaSkuMTEgRQotLjE2NSh2ZSktLjI3NSBHKHJzXCkgYW5kIGFy ZSkuMTY1IEUoTHVieS9WKTcyIDc2OSBRCihpY2lzYW5vL0dlbW1lbGwvUml6em8vSGFuZGxl KS0uNjYgRSh5L0NybyktLjE2NSBFIDExNy4zNTYKKHdjcm9mdCBTZWN0aW9uKS0uMjc1IEYg Mi43NSgxLiBbUCkyLjc1IEYoYWdlIDFdKS0uMTY1IEUgRVAKJSVQYWdlOiAyIDIKJSVCZWdp blBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTEvVGltZXMtUm9tYW5AMCBTRihJ TlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhwaXJlczopLTEuMDEyIEYKKEphbnVh cnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEyMy43MjYgRQooYWRkcmVzc2VkIHRvIGEgbXVs dGljYXN0IElQIGFkZHJlc3MgXChzb21ldGltZSB0aGUpNzIgODUgUSAyLjc1KHltKQotLjE2 NSBHKGlnaHQgYmUgYWRkcmVzc2VkIHRvIHRoZSB1bmljYXN0IGFkZHJlc3Mgb2YgYSktMi43 NSBFCihzcGVjaVwyMTRjIHJlY2VpKTcyIDk4IFEgLS4xNjUodmUpLS4yNzUgRyhyXCkuIElu IHRoZSBmb2xsbykuMTY1IEUKKHdpbmcsIGZvciBzaW1wbGljaXR5IHdlIHdpbGwgcmVmZXIg dG8gYm90aCBkYXRhIGFuZCBzZXNzaW9uIGNvbnRyb2wpCi0uMjc1IEUocGFjayk3MiAxMTEg UShldHMgYXMgZG8pLS4xMSBFKHduc3RyZWFtLXRyYSktLjI3NSBFIC0uMTY1KHZlKQotLjIy IEcobGluZyBwYWNrKS4xNjUgRShldHMsIG9yIHNpbXBseSBkbyktLjExIEUod25zdHJlYW0g cGFjayktLjI3NSBFCihldHMuKS0uMTEgRShBcyBhIGdlbmVyYWwgcnVsZSwgZmVlZGJhY2sg cGFjayk3MiAxMzcgUShldHMgdHJhKS0uMTEgRQotLjE2NSh2ZSktLjIyIEcgMi43NShsdSku MTY1IEcocHN0cmVhbSBcKGZyb20gcmVjZWkpLTIuNzUgRSAtLjE2NSh2ZSkKLS4yNzUgRyhy cyB0byB0aGUgc2VuZGVyXCkgYW5kIGFyZSkuMTY1IEUKKGFkZHJlc3NlZCB0byB0aGUgdW5p Y2FzdCBhZGRyZXNzIG9mIHRoZSBzZW5kZXIpNzIgMTUwIFEgMi43NSguUyktLjYwNSBHCihv bWV0aW1lcywgaG8pLTIuNzUgRSh3ZSktLjI3NSBFIC0uMTY1KHZlKS0uMjc1IEcgLjg4IC0u NDQociwgdCkuMTY1IEgKKGhlKS40NCBFIDIuNzUoeW0pLS4xNjUgRyhpZ2h0IGJlIGFkZHJl c3NlZCB0byBhKS0yLjc1IEUKKG11bHRpY2FzdCBJUCBhZGRyZXNzIG9yIHRvIHRoZSB1bmlj YXN0IGFkZHJlc3Mgb2YgYSByZWNlaSk3MiAxNjMgUQotLjE2NSh2ZSktLjI3NSBHIDIuNzUo cm8pLjE2NSBHIDIuNzUocmEpLTIuNzUgRwoobHNvIHRoZSB0aGUgdW5pY2FzdCBhZGRyZXNz IG9mIHNvbWUpLTIuNzUgRShkaWYpNzIgMTc2IFEKKGZlcmVudCBub2RlIFwoYW4gaW50ZXJt ZWRpYXRlIG5vZGUgdGhhdCBwcm8pLS4yNzUgRSh2aWRlcyByZWNvKS0uMTY1IEUKLS4xNjUo dmUpLS4xNjUgRyhyeSBzZXJ2aWNlcyBvciBhIG5laWdoYm9yaW5nIHJvdXRlclwpLikuMTY1 IEUKKFRoZSBGRUMtcmVsYXRlZCBpbmZvcm1hdGlvbiB0aGF0IGNhbiBiZSBwcmVzZW50IGlu IGRvKTcyIDIwMiBRCih3bnN0cmVhbSBwYWNrKS0uMjc1IEUoZXRzIGNhbiBiZSBjbGFzc2lc MjE0ZWQgYXMpLS4xMSBFKGZvbGxvKTcyIDIxNSBRCih3czopLS4yNzUgRSA3LjMzNygxXCkg RkVDKTc0Ljc1IDI0NC42IFIoRW5jb2RpbmcgSWRlbnRpXDIxNGVyKTIuNzUgRQooSWRlbnRp XDIxNGVzIHRoZSBGRUMgZW5jb2RpbmcgYmVpbmcgdXNlZCBhbmQgaGFzIHRoZSBwdXJwb3Nl IG9mIGFsbG8pCjEwNSAyNjEuMiBRKHdpbmcgcmVjZWkpLS4yNzUgRSAtLjE2NSh2ZSktLjI3 NSBHKHJzIHRvIHNlbGVjdCkuMTY1IEUKKHRoZSBhcHByb3ByaWF0ZSBGRUMgZGVjb2Rlcikx MDUgMjc0LjIgUSAyLjc1KC5BKS0uNjA1IEcgMi43NShzYWcpLTIuNzUKRyhlbmVyYWwgcnVs ZSwgdGhlICJGRUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVyIiBNVVNUIGJlKS0yLjc1IEUKKHRo ZSBzYW1lIGZvciBhIGdpKTEwNSAyODcuMiBRIC0uMTY1KHZlKS0uMjc1IEcgMi43NShucyku MTY1IEcoZXNzaW9uLCBcCmkuZS4sIGZvciBhbGwgdHJhbnNtaXNzaW9uIG9mIGRhdGEgcmVs YXRlZCB0byBhIHBhcnRpY3VsYXIgb2JqZWN0LCktMi43NQpFIC0uMjIoYnUpMTA1IDMwMC4y IFMgMi43NSh0TSkuMjIgRyAyLjMxIC0xLjE1NShBWSB2KS0yLjc1IEgKKGFyeSBhY3Jvc3Mg ZGlmKS44OCBFKGZlcmVudCB0cmFuc21pc3Npb25zIG9mIGRhdGEgYWJvdXQgZGlmKS0uMjc1 IEUKKGZlcmVudCBvYmplY3RzIGluIGRpZiktLjI3NSBFKGZlcmVudCktLjI3NSBFKHNlc3Np b25zLCBlKTEwNSAzMTMuMiBRCi0uMTY1KHZlKS0uMjc1IEcgMi43NShuaSkuMTY1IEcgMi43 NShmdCktMi43NSBHKHJhbnNtaXR0ZWQgdXNpbmcgdGhlIHNhXAptZSBzZXQgb2YgbXVsdGlj YXN0IGdyb3VwcyBhbmQvb3IgdXNpbmcgYSBzaW5nbGUpLTIuNzUgRSh1cHBlcikxMDUgMzI2 LjIKUSgtbGF5ZXIgc2Vzc2lvbi4pLS4yMiBFIDcuMzM3KDJcKSBGRUMpNzQuNzUgMzQyLjgg UihwYXlsb2FkIElEKTIuNzUgRQooSWRlbnRpXDIxNGVzIHRoZSBzeW1ib2xcKHNcKSBpbiB0 aGUgcGF5bG9hZCBvZiB0aGUgcGFjaykxMDUgMzU5LjQgUQooZXQuIFRoZSBjb250ZW50IG9m IHRoaXMgcGllY2Ugb2YpLS4xMSBFKGluZm9ybWF0aW9uIGRlcGVuZHMgb24gdGhlIGVuY1wK b2RlciBiZWluZyB1c2VkIFwoZS5nLiBpbiBCbG9jayBGRUMgY29kZXMgdGhpcyBtYXkgYmUg dGhlKTEwNSAzNzIuNCBRCihjb21iaW5hdGlvbiBvZiBibG9jayBpbmRlKTEwNSAzODUuNCBR IDIuNzUoeGEpLS4xNjUgRwoobmQgZW5jb2Rpbmcgc3ltYm9sIGlkZW50aVwyMTRlcjsgaW4g aWRlYWwgZSktMi43NSBFKHhwYW5kYWJsZSBGRUMpLS4xNjUKRShjb2RlcyB0aGlzIG1heSBi ZSBqdXN0IGEgXDIxNWF0IGVuY29kaW5nIHN5bWJvbCBpZGVudGlcMjE0ZXJcKS4pMTA1CjM5 OC40IFEgNy4zMzcoM1wpIEZFQyk3NC43NSA0MTUgUihPYmplY3QgVCkyLjc1IEUKKHJhbnNt aXNzaW9uIEluZm9ybWF0aW9uKS0uMzg1IEUoVGhpcyBpcyBpbmZvcm1hdGlvbiByZSkxMDUg NDMxLjYgUQotLjA1NShnYSktLjE2NSBHCihyZGluZyB0aGUgZW5jb2Rpbmcgb2YgYSBzcGVj aVwyMTRjIG9iamVjdCBuZWVkZWQgYnkgdGhlIEZFQyBkZWNvZGVyKQouMDU1IEUoXChlLmcu IGZvciBCbG9jayBGRUMgY29kZXMgdGhpcyBtYXkgYmUgdGhlIGNvbWJpbmF0aW9uIG9mIGJs b2NrIFwKbGVuZ3RoIGFuZCBvYmplY3QgbGVuZ3RoXCkuKTEwNSA0NDQuNiBRCihUaGlzIG1p Z2h0IGFsc28gaW5jbHVkZSBnZW5lcmFsIHBhcmFtZXRlcnMgb2YgdGhlIEZFQyBlbmNvZGVy KTEwNSA0NTcuNgpRIDIuNzUoLk4pLS42MDUgRyhvdGUgdGhhdCwgaW4gc3RyaWN0IHRlcm1z LCktMi43NSBFKHRoZSAiRkVDIEVuY29kaW5nIFwKSWRlbnRpXDIxNGVyIiBiZWxvbmdzIHRv IHRoaXMgY2xhc3Mgb2YgaW5mb3JtYXRpb24sIGhvKTEwNSA0NzAuNiBRKHdlKQotLjI3NSBF IC0uMTY1KHZlKS0uMjc1IEcgLjg4IC0uNDQociwgZikuMTY1IEgob3IgcHJhY3RpY2FsKS40 NCBFCihwdXJwb3Nlcywgd2Ugd2lsbCBjb25zaWRlciBpdCBzZXBhcmF0ZWx5KTEwNSA0ODMu NiBRKC4pLS43MTUgRQooQWxsIHRoZSBjbGFzc2VzIG9mIGluZm9ybWF0aW9uIGFibyk5NyA1 MTMuMiBRIC0uMTY1KHZlKS0uMTY1IEcgMi43NSgsZSkKLjE2NSBHKHhjZXB0IDJcKSwgY2Fu IGVpdGhlciBiZSB0cmFuc21pdHRlZCB3aXRoaW4gdGhlKS0yLjkxNSBFCih0cmFuc3BvcnQg c2Vzc2lvbiBcKHVzaW5nIHByb3RvY29sIHBhY2spNzIgNTI2LjIgUQooZXQtaGVhZGVyIFwy MTRlbGRzXCkgb3Igb3V0IG9mIGJhbmQuIFRoZSBpbmZvcm1hdGlvbiBkZXNjcmliZWQpLS4x MSBFCihpbiAyXCkgTVVTVCBiZSB0cmFuc21pdHRlZCBpbiBkYXRhLXBhY2spNzIgNTM5LjIg UQooZXQgaGVhZGVyIFwyMTRlbGRzLCBhcyBpdCBwcm8pLS4xMSBFKHZpZGVzIGEgZGVzY3Jp cHRpb24gb2YgdGhlIGRhdGEpCi0uMTY1IEUoY29udGFpbmVkIGluIHRoZSBwYWNrKTcyIDU1 Mi4yIFEoZXQuIEluIHRoZSBmb2xsbyktLjExIEUKKHdpbmcgd2Ugd2lsbCBzcGVjaWZ5IHRo ZSBjb250ZW50IG9mIDFcKSwgMlwpIGFuZCAzXCkgcmUpLS4yNzUgRSAtLjA1NQooZ2EpLS4x NjUgRyhyZGxlc3Mgb2YpLjA1NSBFCih3aGV0aGVyIHRoZXNlIHBpZWNlcyBvZiBpbmZvcm1h dGlvbiBhcmUgdHJhbnNtaXR0ZWQgaW4gcHJvdG9jb2wgcGFjayk3Mgo1NjUuMiBRKGV0cyBv ciBvdXQgb2YgYmFuZC4gVGhpcyktLjExIEUoZG9jdW1lbnQgbmVpdGhlciBzcGVjaVwyMTRl cyBvdVwKdC1vZi1iYW5kIG1ldGhvZHMgdG8gdHJhbnNwb3J0IHRoZSBpbmZvcm1hdGlvbiBu b3IgZG9lcyBpdCBzcGVjaWZ5KTcyCjU3OC4yIFEodGhlIHcpNzIgNTkxLjIgUQooYXkgb3V0 LW9mLWJhbmQgaW5mb3JtYXRpb24gaXMgYXNzb2NpYXRlZCB3aXRoIHBhY2spLS4xMSBFCihl dCBwYXlsb2Fkcy4gVGhpcyBsYXN0IHRhc2sgaXMgZGUpLS4xMSBFIC0uMjIodm8pLS4yNzUg RyhsdikuMjIgRQooZWQgdG8pLS4xNjUgRShhbiB1cHBlcik3MiA2MDQuMiBRKC1sYXllciBw cm90b2NvbC4pLS4yMiBFIC0uNDQoV2kpNzIKNjMwLjIgUyh0aGluIHRoZSBjb250ZSkuNDQg RSh4dCBvZiBGRUMgcmVwYWlyIHNjaGVtZXMsIGZlZWRiYWNrIHBhY2spCi0uMTY1IEUoZXRz IGFyZSBcKG9wdGlvbmFsbHlcKSB1c2VkIHRvIHJlcXVlc3QgRkVDKS0uMTEgRSAyLjc1Cihy ZXRyYW5zbWlzc2lvbi4gVGhlKTcyIDY0My4yIFIKKEZFQy1yZWxhdGVkIGluZm9ybWF0aW9u IHByZXNlbnQgaW4gZmVlZGJhY2sgcGFjaykyLjc1IEUKKGV0cyB1c3VhbGx5IGNvbnRhaW5z IGFuKS0uMTEgRShGRUMgQmxvY2sgSWRlbnRpXDIxNGVyKTcyIDY1Ni4yIFEgMi43NQooLHQp LS40NCBHKGhhdCBkZVwyMTRuZXMgdGhlIGJsb2NrIHRoYXQgaXMgYmVpbmcgcmVwYWlyZWQs IGFuZCB0aGUgbnVtYlwKZXIgb2YgUmVwYWlyKS0yLjc1IEUKKFN5bWJvbHMgcmVxdWVzdGVk LiBBbHRob3VnaCB0aGlzIGlzIHRoZSBtb3N0IGNvbW1vbiBjYXNlLCB2KTcyIDY2OS4yIFEK KGFyaWFudHMgYXJlIHBvc3NpYmxlIGluIHdoaWNoIHRoZSktLjI3NSBFKHJlY2VpKTcyIDY4 Mi4yIFEgLS4xNjUodmUpCi0uMjc1IEcocnMgcHJvKS4xNjUgRSh2aWRlIG1vcmUgc3BlY2lc MjE0YyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUmVwYWlyXAogU3ltYm9scyByZXF1ZXN0ZWQg XChlLmcuIGFuIGluZGUpLS4xNjUgRSh4KS0uMTY1IEUocmFuZ2Ugb3IgYSBsaXN0IG9mIFwK c3ltYm9scyBhY2NlcHRlZFwpLiBJdCBpcyBhbHNvIHBvc3NpYmxlIHRvIGluY2x1ZGUgbXVs dGlwbGUgb2YgdGhlc2UgcmVcCnF1ZXN0IGluIGEpNzIgNjk1LjIgUShzaW5nbGUgZmVlZGJh Y2sgcGFjayk3MiA3MDguMiBRKGV0LiktLjExIEUoTHVieS9WKQo3MiA3NjkgUShpY2lzYW5v L0dlbW1lbGwvUml6em8vSGFuZGxlKS0uNjYgRSh5L0NybyktLjE2NSBFIDExNy4zNTYKKHdj cm9mdCBTZWN0aW9uKS0uMjc1IEYgMi43NSgxLiBbUCkyLjc1IEYoYWdlIDJdKS0uMTY1IEUg RVAKJSVQYWdlOiAzIDMKJSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAg MTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhw aXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEyMy43MjYg RShUaGlzIGRvY3VtZW50IGRvZXMgbm90IHBybyk3Mgo4NSBRKHZpZGUgYW4pLS4xNjUgRSAy Ljc1KHlkKS0uMTY1IEcKKGV0YWlsIGFib3V0IHRoZSBmb3JtYXQgb2YgRkVDIGluZm9ybWF0 aW9uIGluIGZlZWRiYWNrKS0yLjc1IEUocGFjayk3Mgo5OCBRKGV0cy4pLS4xMSBFL0YxIDEx L1RpbWVzLUJvbGRAMCBTRigxLjEuKTcyIDEzNyBRL0YyIDEzL1RpbWVzLUJvbGRAMApTRihG RUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVyKTUuNSBFIEYwKFRoaXMgaXMgYSBudW1lcmljIGlu ZGUpNzIgMTY2LjYgUQoyLjc1KHh0KS0uMTY1IEcoaGF0IGlkZW50aVwyMTRlcyBhIHNwZWNp XDIxNGMgRkVDIHNjaGVtZSBPUiBhIGNsYXNzIG9mIFwKZW5jb2Rpbmcgc2NoZW1lcyktMi43 NSBFKHRoYXQgc2hhcmUgdGhlIHNhbWUgZm9ybWF0IG9mICJGRUMgUCk3MiAxNzkuNiBRCihh eWxvYWQgSUQiIGFuZCAiRkVDIE9iamVjdCBUKS0uMTY1IEUocmFuc21pc3Npb24gSW5mb3Jt YXRpb24iLiktLjM4NSBFCihUaGUgRkVDIEVuY29kaW5nIElkZW50aVwyMTRlciBpZGVudGlc MjE0ZXMgYSBzcGVjaVwyMTRjIEZFQyBzY2hlbWUgd2hlXApuIHRoZSBlbmNvZGluZyBzY2hl bWUgaXMpNzIgMjA1LjYgUQooZm9ybWFsbHkgYW5kIGZ1bGx5IHNwZWNpXDIxNGVkLCBpbiBh IHcpNzIgMjE4LjYgUQooYXkgdGhhdCBpbmRlcGVuZGVudCBpbXBsZW1lbnRvcnMgY2FuIGlt cGxlbWVudCBib3RoIGVuY29kZXIpLS4xMSBFKGFuZFwKIGRlY29kZXIgZnJvbSB0aGUgc3Bl Y2lcMjE0Y2F0aW9uLiBDb21wYW5pb24gZG9jdW1lbnRzIG9mIHRoaXMgc3BlY2lcClwyMTRj YXRpb24gbWF5IHNwZWNpZnkgc3VjaCk3MiAyMzEuNiBRCihGRUMgc2NoZW1lcyBhbmQgYXNz b2NpYXRlIHRoZW0gd2l0aCAiRkVDIEVuY29kaW5nIElkZW50aVwyMTRlciIgdik3MgoyNDQu NiBRKGFsdWVzLiBUaGVzZSBkb2N1bWVudHMpLS4yNzUgRQooTVVTVCBhbHNvIHNwZWNpZnkg YSBjb3JyZXNwb25kZW50IGZvcm1hdCBmb3IgdGhlICJGRUMgUCk3MiAyNTcuNiBRCihheWxv YWQgSUQiIGFuZCAiRkVDIE9iamVjdCktLjE2NSBFIC0uMzg1KFRyKTcyIDI3MC42IFMKKGFu c21pc3Npb24gSW5mb3JtYXRpb24iLikuMzg1IEUKKEN1cnJlbnRseSBGRUMgRW5jb2Rpbmcg SWRlbnRpXDIxNGVycyBpbiB0aGUgcmFuZ2UgMC0xMjcgYXJlIHJlc2Vydik1LjUKRShlZCkt LjE2NSBFCihmb3IgdGhpcyBjbGFzcyBvZiBlbmNvZGluZyBzY2hlbWVzIFwoZnVsbHktc3Bl Y2lcMjE0ZWQgc2NoZW1lc1wpLik3MgoyODMuNiBRKEl0IGlzIHBvc3NpYmxlIHRoYXQgYSBG RUMgc2NoZW1lIGNhbm5vdCBiZSBjb21wbGV0ZWx5IHNwZWNpXDIxNFwKZWQgb3IgdGhhdCBz dWNoIGEgc3BlY2lcMjE0Y2F0aW9uIGlzKTcyIDMwOS42IFEoc2ltcGx5IG5vdCBhKTcyIDMy Mi42IFEKLS4yNzUodmEpLS4yMiBHKGlsYWJsZSBvciBhbHNvIHRoYXQgYSBwYXJ0eSBlKS4y NzUgRSh4aXN0cyB0aGF0IG8pLS4xNjUKRSh3bnMgdGhlIGVuY29kaW5nIHNjaGVtZSBhbmQg aXQgaXMgbm90IHdpbGxpbmcpLS4yNzUgRQoodG8gZGlzY2xvc2UgaXRzIGFsZ29yaXRobS4g Vyk3MiAzMzUuNiBRIDIuNzUoZXIpLS44OCBHCihlZmVyIHRvIHRoZXNlIGVuY29kaW5nIHNj aGVtZXMgYXMgIlVuZGVyKS0yLjc1IEUKKC1TcGVjaVwyMTRlZCIgc2NoZW1lcy4pLS4yMiBF KFVuZGVyKTcyIDM0OC42IFEKKC1zcGVjaVwyMTRlZCBzY2hlbWVzIGNhbiBzdGlsbCBiZSBp ZGVudGlcMjE0ZWQgYXMgZm9sbG8pLS4yMiBFKHdzOikKLS4yNzUgRSAxMShvQSk3Ny41IDM2 NS4yIFMoZm9ybWF0IG9mIHRoZSBcMjE0ZWxkcyAiRkVDIFApLTguMjUgRQooYXlsb2FkIElE IiBhbmQgIkZFQyBPYmplY3QgVCktLjE2NSBFKHJhbnNtaXNzaW9uIEluZm9ybWF0aW9uIikt LjM4NSBFCihNVVNUIGJlIGRlXDIxNG5lZCBmb3IgdGhlIGVuY29kaW5nIHNjaGVtZS4pOTQg Mzc4LjIgUSAxMShvQSk3Ny41IDM5NC44ClMgLS4yNzUodmEpLTguMjUgRyhsdWUgb2YgIkZF QyBFbmNvZGluZyBJZGVudGlcMjE0ZXIiIE1VU1QgYmUgcmVzZXJ2KQouMjc1IEUoZWQgYW5k IGFzc29jaWF0ZWQgdG8gdGhlIGZvcm1hdCktLjE2NSBFKGRlXDIxNG5pdGlvbnMgYWJvKTk0 CjQwNy44IFEgLS4xNjUodmUpLS4xNjUgRyAyLjc1KC5BKS4xNjUgRyAyLjc1KG5hKS0yLjc1 IEcobHJlYWR5IHJlc2VydikKLTIuNzUgRShlZCAiRkVDIEVuY29kaW5nIElkZW50aVwyMTRl ciIpLS4xNjUgRShNVVNUIGJlIHJldXNlZCBpZiBpdCBpcykKNS41IEUoYXNzb2NpYXRlZCB0 byB0aGUgc2FtZSBmb3JtYXQgb2YgIkZFQyBQKTk0IDQyMC44IFEKKGF5bG9hZCBJRCIgYW5k ICJGRUMgT2JqZWN0IFQpLS4xNjUgRShyYW5zbWlzc2lvbiktLjM4NSBFCihJbmZvcm1hdGlv biIgYXMgdGhlIG9uZXMgbmVlZGVkIGZvciB0aGUgbmUpOTQgNDMzLjggUSAyLjc1KHd1KS0u Mjc1IEcKKG5kZXIpLTIuNzUgRSgtc3BlY2lcMjE0ZWQgRkVDIHNjaGVtZS4pLS4yMiBFIDEx KG9BKTc3LjUgNDUwLjQgUyAtLjI3NQoodmEpLTguMjUgRyhsdWUgb2YgIkZFQyBFbmNvZGlu ZyBOYW1lIiBtdXN0IGJlIHJlc2VydikuMjc1IEUKKGVkIFwoc2VlIGJlbG8pLS4xNjUgRSh3 XCkuKS0uMjc1IEUoQW4gVW5kZXIpNzIgNDgwIFEoLXNwZWNpXDIxNGVkIEZFQyBcCnNjaGVt ZSBpcyBjb21wbGV0ZWx5IGlkZW50aVwyMTRlZCBieSB0aGUgdHVwbGUgXChGRUMgRW5jb2Rp bmcgSWRlbnRpXApcMjE0ZXIpLS4yMiBFKCwpLS40NCBFKEZFQyBFbmNvZGluZyBOYW1lXCku IFRoZSB0dXBsZSBNVVNUIGlkZW50aWZ5IGEgc1wKaW5nbGUgc2NoZW1lIHRoYXQgaGFzIGF0 IGxlYXN0IG9uZSk3MiA0OTMgUQooaW1wbGVtZW50YXRpb24uIFRoZSBwYXJ0eSB0aGF0IG8p NzIgNTA2IFEKKHducyB0aGlzIHR1cGxlIE1VU1QgYmUgYWJsZSB0byBwcm8pLS4yNzUgRSh2 aWRlIGluZm9ybWF0aW9uIG9uIGhvKS0uMTY1CkUgMi43NSh3dCktLjI3NSBHKG8pLTIuNzUg RShvYnRhaW4gdGhlIHVuZGVyKTcyIDUxOSBRKC1zcGVjaVwyMTRlZCBGRUMgXApzY2hlbWUg aWRlbnRpXDIxNGVkIGJ5IHRoZSB0dXBsZSBcKGUuZy4gYSBwb2ludGVyIHRvIGEgcHVibGlj bHkpLS4yMiBFCi0uMjIoYXYpNzIgNTMyIFMKKGFpbGFibGUgcmVmZXJlbmNlLWltcGxlbWVu dGF0aW9uIG9yIHRoZSBuYW1lIGFuZCBjb250YWN0cyBvZiBhIGNvbXBhbikKLS4wNTUgRSAy Ljc1KHl0KS0uMTY1IEcoaGF0IHNlbGxzIGl0LCBlaXRoZXIpLTIuNzUgRQooc2VwYXJhdGVs eSBvciBlbWJlZGRlZCBpbiBhbm90aGVyIHByb2R1Y3RcKS4pNzIgNTQ1IFEoIkZFQyBFbmNv ZGluZyBOYVwKbWVzIiBhcmUgbnVtZXJpYyBpZGVudGlcMjE0ZXJzIHNjb3BlZCBieSBhIEZF QyBFbmNvZGluZyBJZGVudGlcMjE0ZXIpNzIKNTcxIFEoLiktLjYwNSBFKFRoZSBGRUMgRW5j b2RpbmcgTmFtZSBNVVNUIGJlIHBhcnQgb2YgdGhlICJGRUMgT2JqZWN0IFQpCjcyIDU5NyBR KHJhbnNtaXNzaW9uIEluZm9ybWF0aW9uIiBhbmQpLS4zODUgRQoobXVzdCBiZSBjb21tdW5p Y2F0ZWQgdG8gcmVjZWkpNzIgNjEwIFEgLS4xNjUodmUpLS4yNzUgRwoocnMgdG9nZXRoZXIg d2l0aCB0aGUgRkVDIEVuY29kaW5nIElkZW50aVwyMTRlcikuMTY1IEUoLiktLjYwNSBFKERp Zik3Mgo2MzYgUQooZmVyZW50IEZFQyBzY2hlbWVzIHRoYXQgc2hhcmUgdGhlIHNhbWUgRkVD IEVuY29kaW5nIElkZW50aVwyMTRlciAtLSBiKQotLjI3NSBFKHV0IGhhKS0uMjIgRSAuMzMg LS4xNjUodmUgZCktLjIyIEgoaWYpLjE2NSBFKGZlcmVudCBGRUMpLS4yNzUgRQooRW5jb2Rp bmcgTmFtZXMgLS0gYWxzbyBzaGFyZSB0aGUgc2FtZSBmb3JtYXQgb2YgRkVDIFApNzIgNjQ5 IFEKKGF5bG9hZCBJRCBhbmQgRkVDIE9iamVjdCBUKS0uMTY1IEUocmFuc21pc3Npb24pLS4z ODUgRShJbmZvcm1hdGlvbi4pNzIKNjYyIFEoVGhpcyBzcGVjaVwyMTRjYXRpb24gcmVzZXJ2 KTcyIDY4OCBRCihlcyB0aGUgcmFuZ2UgMC0xMjcgb2YgRkVDIEVuY29kaW5nIElkZW50aVwy MTRlcnMgZm9yIGZ1bGx5LXNwZWNpXDIxNGVkKQotLjE2NSBFKGVuY29kaW5nIHNjaGVtZXMg YW5kIHRoZSByYW5nZSAxMjgtMjU1IGZvciB1bmRlcik3MiA3MDEgUQooLXNwZWNpXDIxNGVk IGVuY29kaW5nIHNjaGVtZXMuKS0uMjIgRShMdWJ5L1YpNzIgNzY5IFEKKGljaXNhbm8vR2Vt bWVsbC9SaXp6by9IYW5kbGUpLS42NiBFKHkvQ3JvKS0uMTY1IEUgMTA5LjEwNgood2Nyb2Z0 IFNlY3Rpb24pLS4yNzUgRiAyLjc1KDEuMS4gW1ApMi43NSBGKGFnZSAzXSktLjE2NSBFIEVQ CiUlUGFnZTogNCA0CiUlQmVnaW5QYWdlU2V0dXAKQlAKJSVFbmRQYWdlU2V0dXAKL0YwIDEx L1RpbWVzLVJvbWFuQDAgU0YoSU5URVJORVQpNzIgNDkgUSA3MS41ODcoLURSQUZUIEV4cGly ZXM6KS0xLjAxMiBGCihKYW51YXJ5IDIwMDIpMi43NSBFKEp1bHkgMjAwMSkxMjMuNzI2IEUv RjEgMTEvVGltZXMtQm9sZEAwIFNGKDEuMi4pNzIKODUgUS9GMiAxMy9UaW1lcy1Cb2xkQDAg U0YoRkVDIFApNS41IEUoYXlsb2FkIElEIGFuZCBGRUMgT2JqZWN0IFQpLS4xMyBFCihyYW5z bWlzc2lvbiBJbmYpLS45NjIgRShvcm1hdGlvbiktLjMyNSBFIEYwIDIuNzUoQWQpOTcgMTE0 LjYgUwoob2N1bWVudCB0aGF0IHNwZWNpXDIxNGVzIGFuIGVuY29kaW5nIHNjaGVtZSBhbmQg cmVzZXJ2KS0yLjc1IEUoZXMgYSB2KQotLjE2NSBFKGFsdWUgb2YgRkVDIEVuY29kaW5nKS0u Mjc1IEUoSWRlbnRpXDIxNGVyIE1VU1QgZGVcMjE0bmUgYSBwYWNrKQo3MiAxMjcuNiBRKGV0 LVwyMTRlbGQgZm9ybWF0IGZvciBGRUMgUCktLjExIEUKKGF5bG9hZCBJRCBhbmQgRkVDIE9i amVjdCBUKS0uMTY1IEUocmFuc21pc3Npb24pLS4zODUgRShJbmZvcm1hdGlvbiBhY2NcCm9y ZGluZyB0byB0aGUgbmVlZCBvZiB0aGUgZW5jb2Rpbmcgc2NoZW1lLiBUaGlzIGFsc28gYXBw bGllcyB0byBkb2N1bWVuXAp0cyB0aGF0KTcyIDE0MC42IFEocmVzZXJ2KTcyIDE1My42IFEo ZXMgdiktLjE2NSBFCihhbHVlcyBvZiBGRUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVycyBmb3Ig dW5kZXIpLS4yNzUgRQooLXNwZWNpXDIxNGVkIGVuY29kaW5nIHNjaGVtZXMuIEluIHRoaXMg Y2FzZSktLjIyIEUodGhlIEZFQyBPYmplY3QgVCk3MgoxNjYuNiBRKHJhbnNtaXNzaW9uIElu Zm9ybWF0aW9uIG11c3QgYWxzbyBpbmNsdWRlIGEgXDIxNGVsZCB0byBjb250YWluIFwKdGhl ICJGRUMgRW5jb2RpbmcpLS4zODUgRShOYW1lIi4pNzIgMTc5LjYgUSAyLjc1KEFwKTcyIDIw NS42IFMoYWNrKS0yLjc1CkUoZXQgXDIxNGVsZCBkZVwyMTRuaXRpb24gb2YgRkVDIE9iamVj dCBUKS0uMTEgRQoocmFuc21pc3Npb24gSW5mb3JtYXRpb24gTVVTVCBiZSBwcm8pLS4zODUg RSh2aWRlZCBkZXNwaXRlIHRoZSktLjE2NSBFCi0uMTEoZmEpNzIgMjE4LjYgUyhjdCB0aGF0 IGEgcHJvdG9jb2wgaW5zdGFudGlhdGlvbiBtYXkgZGVjaWRlIHRvIGNvbW11XApuaWNhdGUg dGhpcyBpbmZvcm1hdGlvbiBvdXQgb2YgYmFuZC4pLjExIEUoQWxsIHBhY2spNzIgMjQ0LjYg UQooZXQgXDIxNGVsZCBkZVwyMTRuaXRpb25zIFwoRkVDIFApLS4xMSBFKGF5bG9hZCBJRCBh bmQgRkVDIE9iamVjdCBUKQotLjE2NSBFKHJhbnNtaXNzaW9uIEluZm9ybWF0aW9uXCkgTVVT VCktLjM4NSBFCihiZSBmdWxseSBzcGVjaVwyMTRlZCBhdCB0aGUgbGUpNzIgMjU3LjYgUSAt LjE2NSh2ZSktLjI3NSBHIDIuNzUobG8pLjE2NQpHIDIuNzUoZmIpLTIuNzUgRyhpdC1cMjE0 ZWxkcyBhbmQgdGhlKS0yLjc1IEUgMi43NSh5bSktLjE2NSBHKHVzdCBoYSkKLTIuNzUgRSAu MzMgLS4xNjUodmUgYSBsKS0uMjIgSChlbmd0aCB0aGF0IGlzIGEgbXVsdGlwbGUgb2YgYSku MTY1IEUKKDQtYnl0ZSB3KTcyIDI3MC42IFEob3JkIFwodGhpcyBpcyB0byBmKS0uMTEgRQoo YWNpbGl0YXRlIHRoZSBhbGlnbm1lbnQgb2YgcGFjayktLjExIEUKKGV0IFwyMTRlbGRzIGlu IHByb3RvY29sIGluc3RhbnRpYXRpb25zXCkuKS0uMTEgRQooTm90ZSB0aGF0IHRoZSBzcGVj aVwyMTRjYXRpb24gb2YgRkVDIFApNzIgMjk2LjYgUShheWxvYWQgSUQgTVVTVCBhbGxvKQot LjE2NSBFIDIuNzUod2EpLS4yNzUgRyAyLjc1KG5pKS0yLjc1IEcobXBsZW1lbnRhdGlvbi1p bmRlcGVuZGVudCktMi43NQpFKGlkZW50aVwyMTRjYXRpb24gb2YgdGhlIHBhY2spNzIgMzA5 LjYgUShldCBwYXlsb2FkIGUpLS4xMSBFIC0uMTY1KHZlKQotLjI3NSBHIDIuNzUobmkpLjE2 NSBHIDIuNzUobnQpLTIuNzUgRyhoZSBjYXNlIG9mIFVuZGVyKS0yLjc1IEUKKC1TcGVjaVwy MTRlZCBlbmNvZGluZyBzY2hlbWVzLiktLjIyIEUgRjEoMi4pNzIgMzQ4LjYgUS9GMyAxNAov VGltZXMtQm9sZEAwIFNGKFByKTUuNSBFKGVhc3NpZ25lZCBGRUMgRW5jb2RpbmcgSWRlbnRp XDIxNGVycyktLjI1MiBFCkYwCihUaGlzIHNlY3Rpb24gc3BlY2lcMjE0ZXMgdGhlIEZFQyBF bmNvZGluZyBJZGVudGlcMjE0ZXIgYW5kIHRoZSByZWxhdGkpCjcyIDM2NS4yIFEgLjMzIC0u MTY1KHZlIHApLS4yNzUgSChhY2spLjE2NSBFCihldHMgXDIxNGVsZCBmb3IgYSBudW1iZXIg b2YpLS4xMSBFKGtubyk3MiAzNzguMiBRCih3biBzY2hlbWVzIHRoYXQgZm9sbG8pLS4yNzUg RSAyLjc1KHd1KS0uMjc1IEcobmRlciB0aGUgY2xhc3Mgb2YgdW5kZXIpCi0yLjc1IEUoLXNw ZWNpXDIxNGVkIEZFQyBzY2hlbWVzLiBPdGhlcnMgbWF5IGJlKS0uMjIgRQooc3BlY2lcMjE0 ZWQgaW4gY29tcGFuaW9uIGRvY3VtZW50cy4pNzIgMzkxLjIgUSBGMSgyLjEuKTcyIDQzMC4y IFEgRjIKKFNtYWxsIEJsb2NrLCBMYXIpNS41IEUoZ2UgQmxvY2sgYW5kIEV4cGFuZGFibGUg RkVDIENvZGVzKS0uMTMgRSBGMAooVGhpcyBzZWN0aW9uIHJlc2Vydik3MiA0NDYuOCBRCihl cyBhIEZFQyBFbmNvZGluZyBJZGVudGlcMjE0ZXIgZm9yIHRoZSBmKS0uMTY1IEUKKGFtaWxp ZXMgb2YgY29kZXMgZGVzY3JpYmVkIGluIFsxXSwgYW5kKS0uMTEgRShzcGVjaVwyMTRlcyB0 aGUgcmVsYXRpKTcyCjQ1OS44IFEgLjMzIC0uMTY1KHZlIHApLS4yNzUgSChhY2spLjE2NSBF KGV0IFwyMTRlbGRzLiktLjExIEUoVW5kZXIpNS41CkUoLXNwZWNpXDIxNGVkIEZFQyBzY2hl bWVzIHRoYXQgYmVsb25nIHRvIHRoaXMgY2xhc3MgTVVTVCktLjIyIEUKKHVzZSB0aGlzIGlk ZW50aVwyMTRlciBhbmQgcGFjayk3MiA0NzIuOCBRKGV0IFwyMTRlbGQgZGVcMjE0bml0aW9u cy4pCi0uMTEgRShUaGUgRkVDIEVuY29kaW5nIElkZW50aVwyMTRlciBmb3IgdW5kZXIgc3Bl Y2lcMjE0ZWQgY29kZXMgYXNzaWduXAplZCB0byBTbWFsbCBCbG9jaywgTGFyKTcyIDQ5OC44 IFEoZ2UgQmxvY2ssIGFuZCktLjE5OCBFCihFeHBhbmRhYmxlIEZFQyBDb2RlcyBpcyAxMjgu KTcyIDUxMS44IFEoVGhlIEZFQyBQKTcyIDUzNy44IFEoYXlsb2FkIElEXAogaXMgY29tcG9z ZWQgb2YgYW4gZW5jb2Rpbmcgc3ltYm9sIGlkZW50aVwyMTRlciBhbmQgYW4gZW5jb2Rpbmcg YmxvY2spCi0uMTY1IEUobnVtYmVyIHN0cnVjdHVyZWQgYXMgZm9sbG8pNzIgNTUwLjggUSh3 czopLS4yNzUgRS9GNCA4L0NvdXJpZXJAMApTRiA5MS4yKDAxMjMpNzYuOCA1ODkuOCBTIDQu OCgwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMSk3Ni44CjYwMi44IFMKKCstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rKTcyCjYxNS44IFEgMTAwLjgofGUpNzIgNjI4LjggUyhuY29kaW5nIGJsb2NrIG51 bWJlciktMTAwLjggRSh8KTEwMC44IEUKKCstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rKTcyCjY0MS44IFEgMTA1LjYo fGUpNzIgNjU0LjggUyhuY29kaW5nIHN5bWJvbCBJRCktMTA1LjYgRSh8KTExMC40IEUKKCst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rKTcyCjY2Ny44IFEvRjUgMTAvVGltZXMtUm9tYW5AMCBTRgooSW4gYWRkaXRp b24sIGEgb25lIGJpdCBGRUMgRW5jb2RpbmcgRmxhZyBNQSk3MiA3MDYuOCBRIDIuNShZYikt MS4wNSBHCjIuNShlaSktMi41IEcobmNsdWRlZCwgYW5kIHRoaXMgXDIxNWFnIGluZGljYXRl cyB3aGV0aGVyIHRoZSBlbmNvZGluZykKLTIuNSBFKHN5bWJvbFwoc1wpIGluIHRoZSBwYXls b2FkIG9mIHRoZSBwYWNrKTcyIDcxOS44IFEKKGV0IGFyZSBzb3VyY2Ugc3ltYm9sXChzXCkg b3IgcmVkdW5kYW50IHN5bWJvbFwoc1wpLiktLjEgRSBGMChMdWJ5L1YpNzIKNzY5IFEoaWNp c2Fuby9HZW1tZWxsL1JpenpvL0hhbmRsZSktLjY2IEUoeS9Dcm8pLS4xNjUgRSAxMDkuMTA2 Cih3Y3JvZnQgU2VjdGlvbiktLjI3NSBGIDIuNzUoMi4xLiBbUCkyLjc1IEYoYWdlIDRdKS0u MTY1IEUgRVAKJSVQYWdlOiA1IDUKJSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1 cAovRjAgMTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJB RlQgRXhwaXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEy My43MjYgRS9GMSAxMC9UaW1lcy1Sb21hbkAwIFNGCihUaGUgRkVDIE9iamVjdCBUKTcyIDg1 IFEocmFuc21pc3Npb24gSW5mb3JtYXRpb24gaGFzIHRoZSBmb2xsbyktLjM1IEUKKHdpbmcg c3RydWN0dXJlOiktLjI1IEUvRjIgOC9Db3VyaWVyQDAgU0YgOTEuMigwMTIzKTc2LjggMTI0 IFMgNC44CigwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMSk3Ni44IDEzNyBTCigr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKyk3MgoxNTAgUSAyOC44KHxGKTcyIDE2MyBTKEVDIEVuY29kaW5nIE5hbWUp LTI4LjggRSAyNCh8TykzOC40IEcKKGJqZWN0IExlbmd0aCBcKE1TQlwpKS0yNCBFKHwpMzMu NiBFCigrLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKyk3MgoxNzYgUSAxMDAuOCh8Tyk3MiAxODkgUyhiamVjdCBMZW5n dGggXChMU0JcKSktMTAwLjggRSh8KTExMC40IEUKKCstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rKTcyCjIwMiBRIDEw MC44KHxTKTcyIDIxNSBTKG91cmNlIEJsb2NrIExlbmd0aCktMTAwLjggRSh8KTExMC40IEUK KCstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rKTcyCjIyOCBRIEYxKE5vdGUgdGhhdCB0aGlzIHN0cnVjdHVyZSBsaW1p dHMgdGhlIHJhbmdlIG9mIHBvc3NpYmxlIEZFQyBFbmNvXApkaW5nIE5hbWVzIHRvIDAtOi02 NTUzNiwgZGVzcGl0ZSB0aGUgZik3MiAyNjcgUShhY3QgdGhhdCktLjEgRQoodGhlIEZFQyBP YmplY3QgVCk3MiAyODAgUQoocmFuc21pc3Npb24gSW5mb3JtYXRpb24gY2FuIGFsc28gYmUg dHJhbnNtaXR0ZWQgb3V0IG9mIGJhbmQuKS0uMzUgRShUaFwKZSBPYmplY3QgTGVuZ3RoLCBj b21wb3NlZCBvZiBhIE1vc3QgU2lnbmlcMjE0Y2FudCBCeXRlcyBwb3J0aW9uIFwoTVNCXClc CiBhbmQgYSBMZWFzdCBTaWduaVwyMTRjYW50IEJ5dGVzKTcyIDMwNiBRKHBvcnRpb24gXChM U0JcKSwgaXMgZSk3MiAzMTkgUQooeHByZXNzZWQgaW4gYnl0ZXMuKS0uMTUgRS9GMyAxMS9U aW1lcy1Cb2xkQDAgU0YoMi4yLik3MiAzNTggUS9GNCAxMwovVGltZXMtQm9sZEAwIFNGKFNt YWxsIEJsb2NrIFN5c3RlbWF0aWMgRkVDIENvZGVzKTUuNSBFIEYwKFRoZSBmb2xsbyk3Mgoz NzQuNiBRKHdpbmcgZGVcMjE0bml0aW9ucyBhcHBseSB0byBzeXN0ZW1hdGljIGNvZGVzIG9m IHNtYWxsIGxlbmd0aCBcKFwKdG90YWwgYmxvY2sgbGVuZ3RoIDwgMl4xNlwpLiktLjI3NSBF KFRoZSBGRUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVyIGZvciBcCnVuZGVyIHNwZWNpXDIxNGVk IGNvZGVzIGFzc2lnbmVkIHRvIFNtYWxsIEJsb2NrIFN5c3RlbWF0aWMgRkVDKTcyIDQwMC42 ClEoQ29kZXMgaXMgMTI5Lik3MiA0MTMuNiBRKEFsdGhvdWdoIHRoZXNlIGNvZGVzIGNhbiBn ZW5lcmFsbHkgYmUgYWNjb21tXApvZGF0ZWQgYnkgdGhlIEZFQyBFbmNvZGluZyBJZGVudGlc MjE0ZXIgZGVzY3JpYmVkKTcyIDQzOS42IFEoaW4gU2VjdGlvblwKIDIuMSwgYSBzcGVjaVwy MTRjIEVuY29kaW5nLUlEIGlzIGRlXDIxNG5lZCBmb3Igc3lzdGVtYXRpYyBjb2RlcyB0byBh bGxcCm8pNzIgNDUyLjYgUSAyLjc1KHdiKS0uMjc1IEcoZXR0ZXIgXDIxNWUpLTIuNzUgRSh4 aWJpbGl0eSktLjE2NSBFKGFuZCB0XApvIHJldGFpbiBoZWFkZXIgY29tcGFjdG5lc3MuIFRo ZSBzbWFsbCBzb3VyY2UgYmxvY2sgbGVuZ3RoIGFuZCBzbWFsbCBlKQo3MiA0NjUuNiBRKHhh cGFuc2lvbiBmKS0uMTY1IEUoYWN0b3IgdGhhdCktLjExIEUob2Z0ZW4gY2hhcmFjdGVyaXpl IHN5c1wKdGVtYXRpYyBjb2RlcyBtYXkgcmVxdWlyZSB0aGF0IHRoZSBkYXRhIHNvdXJjZSBj aGFuZ2VzIGZyZXF1ZW50bHkgdGhlKTcyCjQ3OC42IFEoc291cmNlIGJsb2NrIGxlbmd0aC4g VCk3MiA0OTEuNiBRIDIuNzUob2EpLS44OCBHKGxsbyktMi43NSBFCjIuNzUod3QpLS4yNzUg RyhoZSBkeW5hbWljIHYpLTIuNzUgRQooYXJpYXRpb24gb2YgdGhlIHNvdXJjZSBibG9jayBs ZW5ndGggYW5kIHRvKS0uMjc1IEUKKGNvbW11bmljYXRlIGl0IHRvIHRoZSByZWNlaSk3MiA1 MDQuNiBRIC0uMTY1KHZlKS0uMjc1IEcocnMgd2l0aCBsbykuMTY1CkUgMi43NSh3byktLjI3 NSBHIC0uMTY1KHZlKS0yLjkxNSBHCihyaGVhZCwgdGhlIGJsb2NrIGxlbmd0aCBpcyBpbmNs dWRlZCBpbiB0aGUgRkVDKS4xNjUgRSAtLjE2NShQYSk3MiA1MTcuNgpTKHlsb2FkIElELiku MTY1IEUoVGhlIEZFQyBQKTcyIDU0My42IFEKKGF5bG9hZCBJRCBpcyBjb21wb3NlZCBvZiB0 aGUgZW5jb2RpbmcgYmxvY2sgbnVtYmVyKS0uMTY1IEUgMi43NSgsdCktLjQ0CkcoaGUgZW5j b2Rpbmcgc3ltYm9sIGlkZW50aVwyMTRlciktMi43NSBFKGFuZCB0aGUgYmxvY2sgbGVuZ3Ro Oik3MiA1NTYuNgpRIEYyIDkxLjIoMDEyMyk3Ni44IDU5NS42IFMgNC44KDAxMjM0NTY3ODkw MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxKTc2LjgKNjA4LjYgUwooKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSspNzIKNjIx LjYgUSA5Nih8ZSk3MiA2MzQuNiBTKG5jb2RpbmcgYmxvY2sgbnVtYmVyKS05NiBFKHwpMTA1 LjYgRQooKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSspNzIKNjQ3LjYgUSAyOC44KHxTKTcyIDY2MC42IFMob3VyY2Ug YmxvY2sgbGVuZ3RoKS0yOC44IEUgMzMuNih8ZSkyOC44IEcKKG5jb2Rpbmcgc3ltYm9sIElE KS0zMy42IEUofCkyOC44IEUKKCstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rKTcyCjY3My42IFEgRjEoVGhlIEZFQyBP YmplY3QgVCk3MiA3MTIuNiBRCihyYW5zbWlzc2lvbiBJbmZvcm1hdGlvbiwgd2hlbiB1c2Vk LCBoYXMgdGhlIGZvbGxvKS0uMzUgRQood2luZyBzdHJ1Y3R1cmU6KS0uMjUgRSBGMChMdWJ5 L1YpNzIgNzY5IFEoaWNpc2Fuby9HZW1tZWxsL1JpenpvL0hhbmRsZSkKLS42NiBFKHkvQ3Jv KS0uMTY1IEUgMTA5LjEwNih3Y3JvZnQgU2VjdGlvbiktLjI3NSBGIDIuNzUoMi4yLiBbUCky Ljc1IEYKKGFnZSA1XSktLjE2NSBFIEVQCiUlUGFnZTogNiA2CiUlQmVnaW5QYWdlU2V0dXAK QlAKJSVFbmRQYWdlU2V0dXAKL0YwIDExL1RpbWVzLVJvbWFuQDAgU0YoSU5URVJORVQpNzIg NDkgUSA3MS41ODcoLURSQUZUIEV4cGlyZXM6KS0xLjAxMiBGCihKYW51YXJ5IDIwMDIpMi43 NSBFKEp1bHkgMjAwMSkxMjMuNzI2IEUvRjEgOC9Db3VyaWVyQDAgU0YgOTEuMigwMTIzKQo3 Ni44IDg1IFMgNC44KDAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxKTc2LjggOTgg UwooKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSspNzIKMTExIFEgMjguOCh8Rik3MiAxMjQgUyhFQyBFbmNvZGluZyBO YW1lKS0yOC44IEUgOS42KHxOKTM4LjQgRwoodW1iZXIgb2YgcmVkdW5kYW50IHN5bWJvbHMp LTkuNiBFKHwpOS42IEUKKCstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rKTcyCjEzNyBRL0YyIDEwL1RpbWVzLVJvbWFu QDAgU0YoV2hlbiB2KTcyIDE3NiBRKGFyaWFibGUgYmxvY2stbGVuZ3RoIGlzIHVzXAplZCwg dGhlIG51bWJlciBvZiByZWR1bmRhbnQgc3ltYm9scyBpcyB0byBiZSBpbnRlcnByZXRlZCBh cyBhIG1heGltdW0pCi0uMjUgRSAtLjI1KHZhKTcyIDE4OSBTKGx1ZSBcKHVwcGVyIGJvdW5k XCkuIFRoaXMgXDIxNGVsZCBpcyBwcm8pLjI1IEUKKHZpZGVkIGFzIGFuIGluZGljYXRpb24g dG8gYWxsbyktLjE1IEUgMi41KHdyKS0uMjUgRyhlY2VpKS0yLjUgRSAtLjE1Cih2ZSktLjI1 IEcgMi41KHN0KS4xNSBHIDIuNShvcCktMi41IEcocmVhbGxvY2F0ZSBhIGRlY29kZXIpLTIu NSBFCihzdWl0YWJsZSBmb3IgYWxsIHRoZSBvYmplY3QgYmxvY2tzLik3MiAyMDIgUShOb3Rl IHRoYXQgdGhpcyBzdHJ1Y3R1cmUgXApsaW1pdHMgdGhlIHJhbmdlIG9mIHBvc3NpYmxlIEZF QyBFbmNvZGluZyBOYW1lcyB0byAwLTotNjU1MzYsIGRlc3BpdGUgdFwKaGUgRkVDKTcyIDIy OCBRKE9iamVjdCBUKTcyIDI0MSBRCihyYW5zbWlzc2lvbiBJbmZvcm1hdGlvbiBjYW4gYWxz byBiZSB0cmFuc21pdHRlZCBvdXQgb2YgYmFuZC4pLS4zNSBFL0YzCjExL1RpbWVzLUJvbGRA MCBTRigzLik3MiAyODAgUS9GNCAxNC9UaW1lcy1Cb2xkQDAgU0YoSUFOKTUuNSBFIDMuNShB QykKLS4yOCBHKG9uc2lkZXJhdGlvbnMpLTMuNSBFIEYwIC0xLjIyMShWYSk3MiAyOTYuNiBT KGx1ZXMgb2YgRkVDIEVuY29kaW5cCmcgSWRlbnRpXDIxNGVycyBhbmQgRkVDIEVuY29kaW5n IE5hbWVzIGFyZSBzdWJqZWN0IHRvIElBTikxLjIyMSBFIDIuNzUKKEFyKS0uMzg1IEcgLS4x NjUoZWcpLTIuNzUgRyhpc3RyYXRpb24uKS4xNjUgRShGRUMgRW5jb2RpbmcgSWRlbnRpXDIx NGVcCnJzIGFuZCBGRUMgRW5jb2RpbmcgTmFtZXMgYXJlIGhpZXJhcmNoaWNhbDogRkVDIEVu Y29kaW5nIElkZW50aVwyMTRlcnMpCjcyIDMwOS42IFEoXChhdCB0aGUgdG9wIGxlKTcyIDMy Mi42IFEgLS4xNjUodmUpLS4yNzUgRyhsXCkgc2NvcGUgcmFuZ2VzXAogb2YgRkVDIEVuY29k aW5nIE5hbWVzLiBOb3QgYWxsIEZFQyBFbmNvZGluZyBJZGVudGlcMjE0ZXJzIGhhKS4xNjUg RSAuMzMKLS4xNjUodmUgYSktLjIyIEgoY29ycmVzcG9uZGluZyBGRUMgRW5jb2RpbmcgTmFt ZSBzY29wZSBcKHNlZSBiZWxvKTcyCjMzNS42IFEod1wpLiktLjI3NSBFIDIuNzUoQUYpNzIg MzYxLjYgUwooRUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVyIGlzIGEgbnVtZXJpYyBub24tbmUp LTIuNzUgRSAtLjA1NShnYSktLjE2NSBHCih0aSkuMDU1IEUgLjMzIC0uMTY1KHZlIGkpLS4y NzUgSChuZGUpLjE2NSBFKHguIFYpLS4xNjUgRQooYWx1ZSBmcm9tIDAgdG8gMTI3IGFyZSBy ZXNlcnYpLTEuMjIxIEUoZWQgZm9yKS0uMTY1IEUoRkVDIGVuY29kZXJzIHRoYVwKdCBhcmUg ZnVsbHkgc3BlY2lcMjE0ZWQsIGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDMuMS4gVGhlIGFz c2lnbm1lbnQgb2ZcCiBhIEZFQyk3MiAzNzQuNiBRKEVuY29kaW5nIElkZW50aVwyMTRlciBp biB0aGlzIHJhbmdlIGNhbiBvbmx5IGJlIGdyYW50XAplZCBpZiB0aGUgcmVxdWVzdG9yIGNh biBwcm8pNzIgMzg3LjYgUSh2aWRlIHN1Y2ggYSktLjE2NSBFCihzcGVjaVwyMTRjYXRpb24g cHVibGlzaGVkIGFzIGFuIElFVEYgUkZDLiBWKTcyIDQwMC42IFEKKGFsdWVzIGdyZWF0ZXIg dGhhbiAxMjcgY2FuIGJlIGFzc2lnbmVkIHRvIHVuZGVyKS0xLjIyMSBFKC0pLS4yMiBFKHNw ZWNcCmlcMjE0ZWQgZW5jb2Rpbmcgc2NoZW1lcy4gTm90ZTogdGhpcyBzcGVjaVwyMTRjYXRp b24gYWxyZWFkeSBhc3NpZ25zIHRoXAplIHYpNzIgNDEzLjYgUShhbHVlcyAxMjggYW5kIDEy OS4pLS4yNzUgRShJbiBhbik3MiA0MzkuNiBRIDIuNzUoeWMpLS4xNjUKRyhhc2UgdiktMi43 NSBFKGFsdWVzIG9mIEZFQyBFbmNvZGluZyBJZGVudGlcMjE0ZXJzIGNhbiBvbmx5IGJlIGFz c2lnbmVcCmQgaWYgdGhlIHJlcXVpcmVkIEZFQyBwYWNrKS0uMjc1IEUoZXQpLS4xMSBFKFwy MTRlbGRzIGNvcnJlc3BvbmRpbmcgdG8gXAppdCBcKHNlZSBzZWN0aW9uIDEuMlwpIGFyZSBz cGVjaVwyMTRlZCBpbiBhIFJGQy4pNzIgNDUyLjYgUQooRWFjaCBGRUMgRW5jb2RpbmcgSWRl bnRpXDIxNGVyIGFzc2lnbmVkIHRvIGFuIHVuZGVyKTcyIDQ3OC42IFEKKC1zcGVjaVwyMTRl ZCBlbmNvZGluZyBzY2hlbWUgc2NvcGVzIGFuKS0uMjIgRQooaW5kZXBlbmRlbnQgcmFuZ2Ug b2YgRkVDIEVuY29kaW5nIE5hbWVzIFwoaS5lLiB0aGUgc2FtZSB2KTcyIDQ5MS42IFEKKGFs dWUgb2YgRkVDIEVuY29kaW5nIE5hbWUgY2FuIGJlKS0uMjc1IEUocmV1c2VkIGZvciBkaWYp NzIgNTA0LjYgUShmZXJcCmVudCBGRUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVyc1wpLiBBbiBG RUMgRW5jb2RpbmcgTmFtZSBpcyBhIG51bWVyaWMgbm9uXAotKS0uMjc1IEUobmUpNzIgNTE3 LjYgUSAtLjA1NShnYSktLjE2NSBHKHRpKS4wNTUgRSAuMzMgLS4xNjUodmUgaSktLjI3NQpI KG5kZSkuMTY1IEUoeC4gVGhlIGRvY3VtZW50IHRoYXQgcmVzZXJ2KS0uMTY1IEUKKGVzIGEg RkVDIEVuY29kaW5nIElkZW50aVwyMTRlciBNQSktLjE2NSBFIDIuNzUoWWEpLTEuMTU1IEcK KGxzbyBzcGVjaWZ5IGEgcmFuZ2UpLTIuNzUgRShmb3IgdGhlIHN1Ym9yZGluYXRlIEZFQyBF bmNvZGluZyBOYW1lcy4pNzIKNTMwLjYgUShVbmRlciB0aGUgc2NvcGUgb2YgYSBGRUMgRW5j b2RpbmcgSWRlbnRpXDIxNGVyKTcyIDU1Ni42IFEgMi43NQooLEYpLS40NCBHKEVDIEVuY29k aW5nIE5hbWVzIGFyZSBhc3NpZ25lZCBvbiBhIEZpcnN0KS0yLjc1IEUKKENvbWUgRmlyc3Qg U2Vydik3MiA1NjkuNiBRKGVkIGJhc2UgdG8gcmVxdWVzdG9ycyB0aGF0IGFyZSBhYmxlIHRv IHBybykKLS4xNjUgRSh2aWRlIHBvaW50IG9mIGNvbnRhY3QgaW5mb3JtYXRpb24gYW5kIGEp LS4xNjUgRShwb2ludGVyIHRvIHB1YmxcCmljbHkgYWNjZXNzaWJsZSBkb2N1bWVudGF0aW9u IGRlc2NyaWJpbmcgdGhlIEZFQyBzY2hlbWUgYW5kIHcpNzIgNTgyLjYgUQooYXlzIHRvIG9i dGFpbiBpdCktLjExIEUoXChlLmcuIGEgcG9pbnRlciB0byBhIHB1YmxpY2x5IGEpNzIgNTk1 LjYgUQotLjI3NSh2YSktLjIyIEcKKGlsYWJsZSByZWZlcmVuY2UtaW1wbGVtZW50YXRpb24g b3IgdGhlIG5hbWUgYW5kIGNvbnRhY3RzIG9mIGEpLjI3NSBFCihjb21wYW4pNzIgNjA4LjYg USAyLjc1KHl0KS0uMTY1IEcoaGF0IHNlbGxzIGl0LCBlaXRoZXIgc2VwYXJhdGVseSBvciBl XAptYmVkZGVkIGluIGFub3RoZXIgcHJvZHVjdFwpLiBUaGUgcmVxdWVzdG9yIGlzKS0yLjc1 IEUKKHJlc3BvbnNpYmxlIGZvciBrKTcyIDYyMS42IFEoZWVwaW5nIHRoaXMgaW5mb3JtYXRp b24gdXAgdG8gZGF0ZS4pLS4xMSBFCkYzKDQuKTcyIDY2MC42IFEgRjQoQWNrbm8pNS41IEUo d2xlZGdtZW50cyktLjE0IEUgRjAKKEJyaWFuIEFkYW1zb24gY29udHJpYik3MiA2NzcuMiBR Cih1dGVkIHRvIHRoaXMgZG9jdW1lbnQgYnkgc2hhcGluZyBTZWN0aW9uIDIuMiBhbmQgcHJv KS0uMjIgRQoodmlkaW5nIGdlbmVyYWwpLS4xNjUgRShmZWVkYmFjay4gVyk3MiA2OTAuMiBR IDIuNzUoZWEpLS44OCBHCihsc28gd2lzaCB0byB0aGFuayBWKS0yLjc1IEUoaW5jZW50IFJv Y2EgZm9yIGhpcyBjb21tZW50cy4pLS42NiBFCihMdWJ5L1YpNzIgNzY5IFEoaWNpc2Fuby9H ZW1tZWxsL1JpenpvL0hhbmRsZSktLjY2IEUoeS9Dcm8pLS4xNjUgRQoxMTcuMzU2KHdjcm9m dCBTZWN0aW9uKS0uMjc1IEYgMi43NSg0LiBbUCkyLjc1IEYoYWdlIDZdKS0uMTY1IEUgRVAK JSVQYWdlOiA3IDcKJSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTEv VGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhwaXJl czopLTEuMDEyIEYKKEphbnVhcnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEyMy43MjYgRS9G MSAxMS9UaW1lcy1Cb2xkQDAgU0YoNS4pNzIgODUKUS9GMiAxNC9UaW1lcy1Cb2xkQDAgU0Yo UmVmZXIpNS41IEUoZW5jZXMpLS4yNTIgRSBGMChbMV0gTHVieSk3MiAxMTQuNiBRCjIuNzUo LE0pLS43MTUgRyguLCBWKS0yLjc1IEUKKGljaXNhbm8sIEdlbW1lbGwsIEouLCBMLiwgUml6 em8sIEwuLCBIYW5kbGUpLS42NiBFIDEuNDMgLS43MTUoeSwgTSkKLS4xNjUgSCAyLjc1KC4s IENybykuNzE1IEYod2Nyb2Z0LCBKLiwgIlRoZSB1c2Ugb2YpLS4yNzUgRSAtLjE2NShGbyk3 MgoxMjcuNiBTKHJ3KS4xNjUgRShhcmQgRXJyb3IgQ29ycmVjdGlvbiBpbiBSZWxpYWJsZSBN dWx0aWNhc3QiLCBJbnRlcm5ldFwKIGRyYWZ0IGRyYWZ0LWlldGYtcm10LWluZm8tZmVjLTAw LnR4dCwpLS4xMSBFKE5vKTcyIDE0MC42IFEgLS4xNjUodmUpCi0uMTY1IEcobWJlciAyMDAw LikuMTY1IEUgRjEoNi4pNzIgMTc5LjYgUSBGMiAtLjcoQXUpNS41IEcodGhvcnMnIEFkZHIp Ci43IEUoZXNzZXMpLS4yNTIgRSBGMChNaWNoYWVsIEx1YnkpODAuMjUgMTk2LjIgUQoobHVi eUBkaWdpdGFsZm91bnRhaW4uY29tKTgwLjI1IDIwOS4yIFEoRGlnaXRhbCBGKTgwLjI1IDIy Mi4yIFEKKG91bnRhaW4sIEluYy4pLS4xNjUgRSgzOTE0MSBDaSk4MC4yNSAyMzUuMiBRKHZp YyBDZW50ZXIgRHJpKS0uMjc1IEUKLS4xNjUodmUpLS4yNzUgRyhTdWl0ZSAzMDApODAuMjUg MjQ4LjIgUShGcmVtb250LCBDQSk4MC4yNSAyNjEuMiBRCig5NDUzOCk1LjUgRShMb3Jlbnpv IFYpODAuMjUgMjg3LjIgUShpY2lzYW5vKS0uNjYgRShsb3JlbnpvQGNpc2NvLmNvbSkKODAu MjUgMzAwLjIgUShjaXNjbyBTeXN0ZW1zLCBJbmMuKTgwLjI1IDMxMy4yIFEoMTcwIFcpODAu MjUgMzI2LjIgUQooZXN0IFQpLS44OCBFKGFzbWFuIERyKS0uODggRSguLCktLjYwNSBFKFNh biBKb3NlLCBDQSwgVVNBLCA5NTEzNCk4MC4yNQozMzkuMiBRKEppbSBHZW1tZWxsKTgwLjI1 IDM2NS4yIFEoamdlbW1lbGxAbWljcm9zb2Z0LmNvbSk4MC4yNSAzNzguMiBRCihNaWNyb3Nv ZnQgUmVzZWFyY2gpODAuMjUgMzkxLjIgUSgzMDEgSG8pODAuMjUgNDA0LjIgUSAtLjExKHdh KS0uMjc1IEcKKHJkIFN0LiwgIzgzMCkuMTEgRShTYW4gRnJhbmNpc2NvLCBDQSwgVVNBLCA5 NDEwNSk4MC4yNSA0MTcuMiBRCihMdWlnaSBSaXp6byk4MC4yNSA0NDMuMiBRKGx1aWdpQGll dC51bmlwaS5pdCk4MC4yNSA0NTYuMiBRIC0uNDQoQUMpCjgwLjI1IDQ2OS4yIFMoSVJJLCAx OTQ3IENlbnRlciBTdC4sIEJlcmspLjQ0IEUoZWxlKS0uMTEgRSAyLjc1KHlDKS0uMTY1Ckcg Mi43NShBOSktMi43NSBHKDQ3MDQpLTIuNzUgRShhbmQpODAuMjUgNDgyLjIgUQooRGlwLiBk aSBJbmcuIGRlbGwnSW5mb3JtYXppb25lKTgwLjI1IDQ5NS4yIFEoVW5pKTgwLjI1IDUwOC4y IFEgLS4xNjUKKHZlKS0uMjc1IEcocnNpdGFgIGRpIFBpc2EpLjE2NSBFKHZpYSBEaW90aXNh bHZpIDIsIDU2MTI2IFBpc2EsIEl0YWx5KQo4MC4yNSA1MjEuMiBRKE1hcmsgSGFuZGxlKTgw LjI1IDU0Ny4yIFEoeSktLjE2NSBFKG1qaEBhY2lyaS5vcik4MC4yNQo1NjAuMiBRKGcpLS4x OTggRSAtLjQ0KEFDKTgwLjI1IDU3My4yIFMoSVJJKS40NCBFKDE5NDcgQ2VudGVyIFN0Lik4 MC4yNQo1ODYuMiBRKEJlcmspODAuMjUgNTk5LjIgUShlbGUpLS4xMSBFIDIuNzUoeUMpLS4x NjUgRyhBLCBVU0EsIDk0NzA0KQotMi43NSBFKEpvbiBDcm8pODAuMjUgNjI1LjIgUSh3Y3Jv ZnQpLS4yNzUgRShKLkNybyk4MC4yNSA2MzguMiBRCih3Y3JvZnRAY3MudWNsLmFjLnVrKS0u Mjc1IEUoRGVwYXJ0bWVudCBvZiBDb21wdXRlciBTY2llbmNlKTgwLjI1IDY1MS4yClEoVW5p KTgwLjI1IDY2NC4yIFEgLS4xNjUodmUpLS4yNzUgRyhyc2l0eSBDb2xsZSkuMTY1IEUoZ2Ug TG9uZG9uKS0uMTY1CkUoR28pODAuMjUgNjc3LjIgUSh3ZXIgU3RyZWV0LCktLjI3NSBFKExv bmRvbiBXQzFFIDZCVCk4MC4yNSA2OTAuMiBRCjIuNzUoLFUpLS44MTQgRyhLKS0yLjc1IEUo THVieS9WKTcyIDc2OSBRKGljaXNhbm8vR2VtbWVsbC9SaXp6by9IYW5kbGUpCi0uNjYgRSh5 L0NybyktLjE2NSBFIDExNy4zNTYod2Nyb2Z0IFNlY3Rpb24pLS4yNzUgRiAyLjc1KDYuIFtQ KTIuNzUgRgooYWdlIDddKS0uMTY1IEUgRVAKJSVQYWdlOiA4IDgKJSVCZWdpblBhZ2VTZXR1 cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3 MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhwaXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMiky Ljc1IEUoSnVseSAyMDAxKTEyMy43MjYgRS9GMSAxMS9UaW1lcy1Cb2xkQDAgU0YoNy4pNzIg ODUKUS9GMiAxNC9UaW1lcy1Cb2xkQDAgU0YoRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50KTUu NSBFIEYwKENvcCk3MiAxMDEuNiBRCih5cmlnaHQgXChDXCkgVGhlIEludGVybmV0IFNvY2ll dHkgXCgyMDAwXCkuKS0uMTEgRShBbGwgUmlnaHRzIFJlc2VydikKNS41IEUoZWQuKS0uMTY1 IEUoVGhpcyBkb2N1bWVudCBhbmQgdHJhbnNsYXRpb25zIG9mIGl0IG1heSBiZSBjb3BpZWQg YW5cCmQgZnVybmlzaGVkIHRvIG90aGVycywgYW5kIGRlcmkpNzIgMTE4LjIgUSAtLjI3NSh2 YSktLjI3NSBHKHRpKS4yNzUgRQouMzMgLS4xNjUodmUgdyktLjI3NSBIKG9ya3MpLjA1NSBF KHRoYXQgY29tbWVudCBvbiBvciBvdGhlcndpc2UgZSk3MgoxMzEuMiBRCih4cGxhaW4gaXQg b3IgYXNzaXN0IGluIGl0cyBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQsIGNvcGll ZCwpCi0uMTY1IEUocHVibGlzaGVkIGFuZCBkaXN0cmliKTcyIDE0NC4yIFEKKHV0ZWQsIGlu IHdob2xlIG9yIGluIHBhcnQsIHdpdGhvdXQgcmVzdHJpY3Rpb24gb2YgYW4pLS4yMiBFIDIu NzUoeWspCi0uMTY1IEcoaW5kLCBwcm8pLTIuNzUgRSh2aWRlZCB0aGF0IHRoZSktLjE2NSBF KGFibyk3MiAxNTcuMiBRIC4zMyAtLjE2NQoodmUgYyktLjE2NSBIKG9wKS4xNjUgRSh5cmln aHQgbm90aWNlIGFuZCB0aGlzIHBhcmFncmFwaCBhcmUgaW5jbHVkZWQgb1wKbiBhbGwgc3Vj aCBjb3BpZXMgYW5kIGRlcmkpLS4xMSBFIC0uMjc1KHZhKS0uMjc1IEcodGkpLjI3NSBFIC4z MyAtLjE2NQoodmUgdyktLjI3NSBIKG9ya3MuKS4wNTUgRShIbyk3MiAxNzAuMiBRKHdlKS0u Mjc1IEUgLS4xNjUodmUpLS4yNzUgRyAuODgKLS40NChyLCB0KS4xNjUgSChoaXMgZG9jdW1l bnQgaXRzZWxmIG1heSBub3QgYmUgbW9kaVwyMTRlZCBpbiBhbikuNDQgRQoyLjc1KHl3KS0u MTY1IEcoYXkpLTIuODYgRSAyLjc1KCxzKS0uNzE1IEcodWNoIGFzIGJ5IHJlbW8pLTIuNzUg RQoodmluZyB0aGUpLS4xNjUgRShjb3ApNzIgMTgzLjIgUSh5cmlnaHQgbm90aWNlIG9yIHJl ZmVyZW5jZXMgdG8gdGhlIEludFwKZXJuZXQgU29jaWV0eSBvciBvdGhlciBJbnRlcm5ldCBv ciktLjExIEUgLS4wNTUoZ2EpLS4xOTggRyhuaXphdGlvbnMsIGUpCi4wNTUgRSh4Y2VwdCBh cyktLjE2NSBFKG5lZWRlZCBmb3IgdGhlIHB1cnBvc2Ugb2YgZGUpNzIgMTk2LjIgUSAtLjE2 NQoodmUpLS4yNzUgRyhsb3BpbmcgSW50ZXJuZXQgc3RhbmRhcmRzIGluIHdoaWNoIGNhc2Ug dGhlIHByb2NlZHVyZXMgZm9yKQouMTY1IEUoY29wKTcyIDIwOS4yIFEKKHlyaWdodHMgZGVc MjE0bmVkIGluIHRoZSBJbnRlcm5ldCBsYW5ndWFnZXMgb3RoZXIgdGhhbiBFbmdsaXNoLikt LjExIEUKKFRoZSBsaW1pdGVkIHBlcm1pc3Npb25zIGdyYW50ZWQgYWJvKTcyIDIyNS44IFEg LjMzIC0uMTY1KHZlIGEpLS4xNjUgSAoocmUgcGVycGV0dWFsIGFuZCB3aWxsIG5vdCBiZSBy ZSkuMTY1IEUgLS4yMih2byktLjI3NSBHIC0uMTEoa2UpLjIyIEcKMi43NShkYikuMTEgRyAy Ljc1KHl0KS0yLjc1IEcoaGUgSW50ZXJuZXQpLTIuNzUgRQooU29jaWV0eSBvciBpdHMgc3Vj Y2Vzc29ycyBvciBhc3NpZ25zLik3MiAyMzguOCBRCihUaGlzIGRvY3VtZW50IGFuZCB0aGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyBwcm8pNzIgMjU1LjQgUQoodmlkZWQg b24gYW4gIkFTIElTIiBiYXNpcyBhbmQgVEhFKS0uMTY1IEUKKElOVEVSTkVUIFNPQ0lFVFkg QU5EIFRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyBUKTcyIDI2OC40IFEKKEFTSyBGT1JDRSBE SVNDTEFJTVMpLTEuMDIzIEUoQUxMIFcpNzIgMjgxLjQgUQooQVJSQU5USUVTLCBFWFBSRVNT IE9SIElNUExJRUQsIElOQ0xVRElORyBCKS0xLjMyIEUoVVQgTk8pLS4xMSBFIDIuNzUKKFRM KS0uNDQgRyhJTUlURUQgVCktMi43NSBFIDIuNzUoT0EpLS4xOTggRyhOWSktMi43NSBFIC0x LjMyKFdBKTcyIDI5NC40ClMoUlJBTlRZIFRIQSkxLjMyIEUgMi43NShUVCktMS4yMjEgRyhI RSBVU0UgT0YgVEhFIElORk9STUEpLTIuNzUgRQooVElPTiBIRVJFSU4gV0lMTCBOTyktMS4y MjEgRSAyLjc1KFRJKS0uNDQgRyhORlJJTkdFKS0yLjc1IEUKKEFOWSBSSUdIVFMgT1IgQU5Z IElNUExJRUQgVyk3MiAzMDcuNCBRKEFSUkFOVElFUyBPRiBNRVJDSEFOVCktMS4zMiBFCihB QklMSVRZIE9SIEZJVE5FU1MpLTEuMDIzIEUoRk9SIEEgUCk3MiAzMjAuNCBRKEFSKS0xLjAx MiBFCihUSUNVTEFSIFBVUlBPU0UuIiktLjY2IEUoTHVieS9WKTcyIDc2OSBRKGljaXNhbm8v R2VtbWVsbC9SaXp6by9IYW5kbGUpCi0uNjYgRSh5L0NybyktLjE2NSBFIDExNy4zNTYod2Ny b2Z0IFNlY3Rpb24pLS4yNzUgRiAyLjc1KDcuIFtQKTIuNzUgRgooYWdlIDhdKS0uMTY1IEUg RVAKJSVQYWdlOiA5IDkKJSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAg MTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhw aXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEyMy43MjYg RShMdWJ5L1YpNzIgNzY5IFEKKGljaXNhbm8vR2VtbWVsbC9SaXp6by9IYW5kbGUpLS42NiBF KHkvQ3JvKS0uMTY1IEUgMTE3LjM1Ngood2Nyb2Z0IFNlY3Rpb24pLS4yNzUgRiAyLjc1KDcu IFtQKTIuNzUgRihhZ2UgOV0pLS4xNjUgRSBFUAolJVRyYWlsZXIKZW5kCiUlRU9GCg== --==_Exmh_5297534880-- >From owner-rmt@listserv.lbl.gov Thu Jul 19 23:08:07 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6K67KM16714; Thu, 19 Jul 2001 23:07: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.11.2/8.11.2) with ESMTP id f6K67JR16710 for ; Thu, 19 Jul 2001 23:07:19 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6K67It05223 for ; Thu, 19 Jul 2001 23:07:18 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6K67IA05220 for ; Thu, 19 Jul 2001 23:07:18 -0700 (PDT) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6K0C4X18278; Thu, 19 Jul 2001 17:12:04 -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 RAA01812; Thu, 19 Jul 2001 17:11:45 -0700 (PDT) Message-Id: <200107200011.RAA01812@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI] To: internet-drafts@ietf.org cc: adamson@itd.nrl.navy.mil, jgemmell@MICROSOFT.com, luigi@iet.unipi.it, mjh@aciri.org, J.Crowcroft@cs.ucl.ac.uk, lorenzo@cisco.com, rmt@lbl.gov Subject: draft-ietf-rmt-bb-fec-03.txt Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_5297534880" Date: Thu, 19 Jul 2001 17:11:45 -0700 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk This is a multipart MIME message. --==_Exmh_5297534880 Content-Type: text/plain; charset=us-ascii Please post this draft on the IETF Internet Drafts archive. This is an update of an existing WG draft (RMT). Thank you, Lorenzo Vicisano --==_Exmh_5297534880 Content-Type: text/plain ; name="draft-ietf-rmt-bb-fec-03.txt"; charset=us-ascii Content-Description: draft-ietf-rmt-bb-fec-03.txt Content-Disposition: attachment; filename="draft-ietf-rmt-bb-fec-03.txt" Internet Engineering Task Force RMT WG INTERNET-DRAFT M.Luby/Digital Fountain draft-ietf-rmt-bb-fec-03.txt L.Vicisano/Cisco J.Gemmell/Microsoft L.Rizzo/ACIRI and Univ. Pisa M.Handley/ACIRI J. Crowcroft/UCL 19 July 2001 Expires: January 2002 RMT BB Forward Error Correction Codes 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". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This document is a product of the IETF RMT WG. Comments should be addressed to the authors, or the WG's mailing list at rmt@isi.edu. Abstract This memo describes the abstract packet formats and IANA registration procedures for use of Forward Error Correction (FEC) codes within the context of reliable IP multicast transport. This memo should be read in conjunction with and uses the terminology of the companion memo [1], which describes the use of Forward Error Correction (FEC) codes within the context of reliable IP multicast transport and Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft [Page 1] ^L INTERNET-DRAFT Expires: January 2002 July 2001 provides an introduction to some commonly used FEC codes. 1. FEC Abstract Packet Fields and Out-of-Band Information This section specifies the information that protocol packets must carry to implement the various forms of FEC-based reliability. A session is defined to be all the information associated with a transmission of data about a particular object by a single sender. There are three classes of packets that may contain FEC information within a session: data packets, session-control packets and feedback packets. They generally contain different kinds of FEC information. Note that some protocols do not use feedback packets. Data packets may sometime serve as session-control packets as well; both data and session-control packets generally travel downstream (from the sender towards receivers) and are addressed to a multicast IP address (sometime they might be addressed to the unicast address of a specific receiver). In the following, for simplicity we will refer to both data and session control packets as downstream-traveling packets, or simply downstream packets. As a general rule, feedback packets travel upstream (from receivers to the sender) and are addressed to the unicast address of the sender. Sometimes, however, they might be addressed to a multicast IP address or to the unicast address of a receiver or also the the unicast address of some different node (an intermediate node that provides recovery services or a neighboring router). The FEC-related information that can be present in downstream packets can be classified as follows: 1) FEC Encoding Identifier Identifies the FEC encoding being used and has the purpose of allowing receivers to select the appropriate FEC decoder. As a general rule, the "FEC Encoding Identifier" MUST be the same for a given session, i.e., for all transmission of data related to a particular object, but MAY vary across different transmissions of data about different objects in different sessions, even if transmitted using the same set of multicast groups and/or using a single upper-layer session. 2) FEC payload ID Identifies the symbol(s) in the payload of the packet. The content of this piece of information depends on the encoder being used Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1. [Page 2] ^L INTERNET-DRAFT Expires: January 2002 July 2001 (e.g. in Block FEC codes this may be the combination of block index and encoding symbol identifier; in ideal expandable FEC codes this may be just a flat encoding symbol identifier). 3) FEC Object Transmission Information This is information regarding the encoding of a specific object needed by the FEC decoder (e.g. for Block FEC codes this may be the combination of block length and object length). This might also include general parameters of the FEC encoder. Note that, in strict terms, the "FEC Encoding Identifier" belongs to this class of information, however, for practical purposes, we will consider it separately. All the classes of information above, except 2), can either be transmitted within the transport session (using protocol packet-header fields) or out of band. The information described in 2) MUST be transmitted in data-packet header fields, as it provides a description of the data contained in the packet. In the following we will specify the content of 1), 2) and 3) regardless of whether these pieces of information are transmitted in protocol packets or out of band. This document neither specifies out-of-band methods to transport the information nor does it specify the way out-of-band information is associated with packet payloads. This last task is devolved to an upper- layer protocol. Within the context of FEC repair schemes, feedback packets are (optionally) used to request FEC retransmission. The FEC-related information present in feedback packets usually contains an FEC Block Identifier, that defines the block that is being repaired, and the number of Repair Symbols requested. Although this is the most common case, variants are possible in which the receivers provide more specific information about the Repair Symbols requested (e.g. an index range or a list of symbols accepted). It is also possible to include multiple of these request in a single feedback packet. This document does not provide any detail about the format of FEC information in feedback packets. 1.1. FEC Encoding Identifier This is a numeric index that identifies a specific FEC scheme OR a class of encoding schemes that share the same format of "FEC Payload ID" and "FEC Object Transmission Information". Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1.1. [Page 3] ^L INTERNET-DRAFT Expires: January 2002 July 2001 The FEC Encoding Identifier identifies a specific FEC scheme when the encoding scheme is formally and fully specified, in a way that independent implementors can implement both encoder and decoder from the specification. Companion documents of this specification may specify such FEC schemes and associate them with "FEC Encoding Identifier" values. These documents MUST also specify a correspondent format for the "FEC Payload ID" and "FEC Object Transmission Information". Currently FEC Encoding Identifiers in the range 0-127 are reserved for this class of encoding schemes (fully-specified schemes). It is possible that a FEC scheme cannot be completely specified or that such a specification is simply not available or also that a party exists that owns the encoding scheme and it is not willing to disclose its algorithm. We refer to these encoding schemes as "Under-Specified" schemes. Under-specified schemes can still be identified as follows: o A format of the fields "FEC Payload ID" and "FEC Object Transmission Information" MUST be defined for the encoding scheme. o A value of "FEC Encoding Identifier" MUST be reserved and associated to the format definitions above. An already reserved "FEC Encoding Identifier" MUST be reused if it is associated to the same format of "FEC Payload ID" and "FEC Object Transmission Information" as the ones needed for the new under-specified FEC scheme. o A value of "FEC Encoding Name" must be reserved (see below). An Under-specified FEC scheme is completely identified by the tuple (FEC Encoding Identifier, FEC Encoding Name). The tuple MUST identify a single scheme that has at least one implementation. The party that owns this tuple MUST be able to provide information on how to obtain the under-specified FEC scheme identified by the tuple (e.g. a pointer to a publicly available reference-implementation or the name and contacts of a company that sells it, either separately or embedded in another product). "FEC Encoding Names" are numeric identifiers scoped by a FEC Encoding Identifier. The FEC Encoding Name MUST be part of the "FEC Object Transmission Information" and must be communicated to receivers together with the FEC Encoding Identifier. Different FEC schemes that share the same FEC Encoding Identifier -- but have different FEC Encoding Names -- also share the same format of FEC Payload ID and FEC Object Transmission Information. Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1.1. [Page 4] ^L INTERNET-DRAFT Expires: January 2002 July 2001 This specification reserves the range 0-127 of FEC Encoding Identifiers for fully-specified encoding schemes and the range 128-255 for under- specified encoding schemes. 1.2. FEC Payload ID and FEC Object Transmission Information A document that specifies an encoding scheme and reserves a value of FEC Encoding Identifier MUST define a packet-field format for FEC Payload ID and FEC Object Transmission Information according to the need of the encoding scheme. This also applies to documents that reserves values of FEC Encoding Identifiers for under-specified encoding schemes. In this case the FEC Object Transmission Information must also include a field to contain the "FEC Encoding Name". A packet field definition of FEC Object Transmission Information MUST be provided despite the fact that a protocol instantiation may decide to communicate this information out of band. All packet field definitions (FEC Payload ID and FEC Object Transmission Information) MUST be fully specified at the level of bit-fields and they must have a length that is a multiple of a 4-byte word (this is to facilitate the alignment of packet fields in protocol instantiations). Note that the specification of FEC Payload ID MUST allow an implementation-independent identification of the packet payload even in the case of Under-Specified encoding schemes. 2. Preassigned FEC Encoding Identifiers This section specifies the FEC Encoding Identifier and the relative packets field for a number of known schemes that follow under the class of under-specified FEC schemes. Others may be specified in companion documents. 2.1. Small Block, Large Block and Expandable FEC Codes This section reserves a FEC Encoding Identifier for the families of codes described in [1], and specifies the relative packet fields. Under-specified FEC schemes that belong to this class MUST use this identifier and packet field definitions. The FEC Encoding Identifier for under specified codes assigned to Small Block, Large Block, and Expandable FEC Codes is 128. Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.1. [Page 5] ^L INTERNET-DRAFT Expires: January 2002 July 2001 The FEC Payload ID is composed of an encoding symbol identifier and an encoding block number structured as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | encoding block number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | encoding symbol ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In addition, a one bit FEC Encoding Flag MAY be included, and this flag indicates whether the encoding symbol(s) in the payload of the packet are source symbol(s) or redundant symbol(s). The FEC Object Transmission Information has the following structure: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Encoding Name | Object Length (MSB) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Object Length (LSB) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that this structure limits the range of possible FEC Encoding Names to 0-:-65536, despite the fact that the FEC Object Transmission Information can also be transmitted out of band. The Object Length, composed of a Most Significant Bytes portion (MSB) and a Least Significant Bytes portion (LSB), is expressed in bytes. 2.2. Small Block Systematic FEC Codes The following definitions apply to systematic codes of small length (total block length < 2^16). The FEC Encoding Identifier for under specified codes assigned to Small Block Systematic FEC Codes is 129. Although these codes can generally be accommodated by the FEC Encoding Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.2. [Page 6] ^L INTERNET-DRAFT Expires: January 2002 July 2001 Identifier described in Section 2.1, a specific Encoding-ID is defined for systematic codes to allow better flexibility and to retain header compactness. The small source block length and small exapansion factor that often characterize systematic codes may require that the data source changes frequently the source block length. To allow the dynamic variation of the source block length and to communicate it to the receivers with low overhead, the block length is included in the FEC Payload ID. The FEC Payload ID is composed of the encoding block number, the encoding symbol identifier and the block length: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | encoding block number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source block length | encoding symbol ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The FEC Object Transmission Information, when used, has the following structure: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Encoding Name | Number of redundant symbols | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When variable block-length is used, the number of redundant symbols is to be interpreted as a maximum value (upper bound). This field is provided as an indication to allow receives to preallocate a decoder suitable for all the object blocks. Note that this structure limits the range of possible FEC Encoding Names to 0-:-65536, despite the FEC Object Transmission Information can also be transmitted out of band. 3. IANA Considerations Values of FEC Encoding Identifiers and FEC Encoding Names are subject to IANA registration. FEC Encoding Identifiers and FEC Encoding Names are hierarchical: FEC Encoding Identifiers (at the top level) scope ranges Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 3. [Page 7] ^L INTERNET-DRAFT Expires: January 2002 July 2001 of FEC Encoding Names. Not all FEC Encoding Identifiers have a corresponding FEC Encoding Name scope (see below). A FEC Encoding Identifier is a numeric non-negative index. Value from 0 to 127 are reserved for FEC encoders that are fully specified, as described in section 3.1. The assignment of a FEC Encoding Identifier in this range can only be granted if the requestor can provide such a specification published as an IETF RFC. Values greater than 127 can be assigned to under-specified encoding schemes. Note: this specification already assigns the values 128 and 129. In any case values of FEC Encoding Identifiers can only be assigned if the required FEC packet fields corresponding to it (see section 1.2) are specified in a RFC. Each FEC Encoding Identifier assigned to an under-specified encoding scheme scopes an independent range of FEC Encoding Names (i.e. the same value of FEC Encoding Name can be reused for different FEC Encoding Identifiers). An FEC Encoding Name is a numeric non-negative index. The document that reserves a FEC Encoding Identifier MAY also specify a range for the subordinate FEC Encoding Names. Under the scope of a FEC Encoding Identifier, FEC Encoding Names are assigned on a First Come First Served base to requestors that are able to provide point of contact information and a pointer to publicly accessible documentation describing the FEC scheme and ways to obtain it (e.g. a pointer to a publicly available reference-implementation or the name and contacts of a company that sells it, either separately or embedded in another product). The requestor is responsible for keeping this information up to date. 4. Acknowledgments Brian Adamson contributed to this document by shaping Section 2.2 and providing general feedback. We also wish to thank Vincent Roca for his comments. 5. References [1] Luby, M., Vicisano, Gemmell, J., L., Rizzo, L., Handley, M., Crowcroft, J., "The use of Forward Error Correction in Reliable Multicast", Internet draft draft-ietf-rmt-info-fec-00.txt, November 2000. Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 5. [Page 8] ^L INTERNET-DRAFT Expires: January 2002 July 2001 6. Authors' Addresses Michael Luby luby@digitalfountain.com Digital Fountain, Inc. 39141 Civic Center Drive Suite 300 Fremont, CA 94538 Lorenzo Vicisano lorenzo@cisco.com cisco Systems, Inc. 170 West Tasman Dr., San Jose, CA, USA, 95134 Jim Gemmell jgemmell@microsoft.com Microsoft Research 301 Howard St., #830 San Francisco, CA, USA, 94105 Luigi Rizzo luigi@iet.unipi.it ACIRI, 1947 Center St., Berkeley CA 94704 and Dip. di Ing. dell'Informazione Universita` di Pisa via Diotisalvi 2, 56126 Pisa, Italy Mark Handley mjh@aciri.org ACIRI 1947 Center St. Berkeley CA, USA, 94704 Jon Crowcroft J.Crowcroft@cs.ucl.ac.uk Department of Computer Science University College London Gower Street, London WC1E 6BT, UK Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 6. [Page 9] ^L INTERNET-DRAFT Expires: January 2002 July 2001 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." Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 7. [Page 10] ^L INTERNET-DRAFT Expires: January 2002 July 2001 Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 7. [Page 11] --==_Exmh_5297534880 Content-Type: application/postscript ; name="draft-ietf-rmt-bb-fec-03.ps" Content-Description: draft-ietf-rmt-bb-fec-03.ps Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-rmt-bb-fec-03.ps" JSFQUy1BZG9iZS0zLjAKJSVDcmVhdG9yOiBncm9mZiB2ZXJzaW9uIDEuMTYuMQolJUNyZWF0 aW9uRGF0ZTogVGh1IEp1bCAxOSAxNzowODoxNCAyMDAxCiUlRG9jdW1lbnROZWVkZWRSZXNv dXJjZXM6IGZvbnQgQ291cmllci1Cb2xkCiUlKyBmb250IFRpbWVzLUJvbGQKJSUrIGZvbnQg VGltZXMtUm9tYW4KJSUrIGZvbnQgQ291cmllcgolJURvY3VtZW50U3VwcGxpZWRSZXNvdXJj ZXM6IHByb2NzZXQgZ3JvcHMgMS4xNiAxCiUlUGFnZXM6IDkKJSVQYWdlT3JkZXI6IEFzY2Vu ZAolJU9yaWVudGF0aW9uOiBQb3J0cmFpdAolJUVuZENvbW1lbnRzCiUlQmVnaW5Qcm9sb2cK JSVCZWdpblJlc291cmNlOiBwcm9jc2V0IGdyb3BzIDEuMTYgMQovc2V0cGFja2luZyB3aGVy ZXsKcG9wCmN1cnJlbnRwYWNraW5nCnRydWUgc2V0cGFja2luZwp9aWYKL2dyb3BzIDEyMCBk aWN0IGR1cCBiZWdpbgovU0MgMzIgZGVmCi9BL3Nob3cgbG9hZCBkZWYKL0J7MCBTQyAzIC0x IHJvbGwgd2lkdGhzaG93fWJpbmQgZGVmCi9DezAgZXhjaCBhc2hvd31iaW5kIGRlZgovRHsw IGV4Y2ggMCBTQyA1IDIgcm9sbCBhd2lkdGhzaG93fWJpbmQgZGVmCi9FezAgcm1vdmV0byBz aG93fWJpbmQgZGVmCi9GezAgcm1vdmV0byAwIFNDIDMgLTEgcm9sbCB3aWR0aHNob3d9Ymlu ZCBkZWYKL0d7MCBybW92ZXRvIDAgZXhjaCBhc2hvd31iaW5kIGRlZgovSHswIHJtb3ZldG8g MCBleGNoIDAgU0MgNSAyIHJvbGwgYXdpZHRoc2hvd31iaW5kIGRlZgovSXswIGV4Y2ggcm1v dmV0byBzaG93fWJpbmQgZGVmCi9KezAgZXhjaCBybW92ZXRvIDAgU0MgMyAtMSByb2xsIHdp ZHRoc2hvd31iaW5kIGRlZgovS3swIGV4Y2ggcm1vdmV0byAwIGV4Y2ggYXNob3d9YmluZCBk ZWYKL0x7MCBleGNoIHJtb3ZldG8gMCBleGNoIDAgU0MgNSAyIHJvbGwgYXdpZHRoc2hvd31i aW5kIGRlZgovTXtybW92ZXRvIHNob3d9YmluZCBkZWYKL057cm1vdmV0byAwIFNDIDMgLTEg cm9sbCB3aWR0aHNob3d9YmluZCBkZWYKL097cm1vdmV0byAwIGV4Y2ggYXNob3d9YmluZCBk ZWYKL1B7cm1vdmV0byAwIGV4Y2ggMCBTQyA1IDIgcm9sbCBhd2lkdGhzaG93fWJpbmQgZGVm Ci9Re21vdmV0byBzaG93fWJpbmQgZGVmCi9Se21vdmV0byAwIFNDIDMgLTEgcm9sbCB3aWR0 aHNob3d9YmluZCBkZWYKL1N7bW92ZXRvIDAgZXhjaCBhc2hvd31iaW5kIGRlZgovVHttb3Zl dG8gMCBleGNoIDAgU0MgNSAyIHJvbGwgYXdpZHRoc2hvd31iaW5kIGRlZgovU0Z7CmZpbmRm b250IGV4Y2gKW2V4Y2ggZHVwIDAgZXhjaCAwIGV4Y2ggbmVnIDAgMF1tYWtlZm9udApkdXAg c2V0Zm9udApbZXhjaC9zZXRmb250IGN2eF1jdnggYmluZCBkZWYKfWJpbmQgZGVmCi9NRnsK ZmluZGZvbnQKWzUgMiByb2xsCjAgMyAxIHJvbGwKbmVnIDAgMF1tYWtlZm9udApkdXAgc2V0 Zm9udApbZXhjaC9zZXRmb250IGN2eF1jdnggYmluZCBkZWYKfWJpbmQgZGVmCi9sZXZlbDAg MCBkZWYKL1JFUyAwIGRlZgovUEwgMCBkZWYKL0xTIDAgZGVmCi9NQU5VQUx7CnN0YXR1c2Rp Y3QgYmVnaW4vbWFudWFsZmVlZCB0cnVlIHN0b3JlIGVuZAp9YmluZCBkZWYKL1BMR3sKZ3Nh dmUgbmV3cGF0aCBjbGlwcGF0aCBwYXRoYmJveCBncmVzdG9yZQpleGNoIHBvcCBhZGQgZXhj aCBwb3AKfWJpbmQgZGVmCi9CUHsKL2xldmVsMCBzYXZlIGRlZgoxIHNldGxpbmVjYXAKMSBz ZXRsaW5lam9pbgo3MiBSRVMgZGl2IGR1cCBzY2FsZQpMU3sKOTAgcm90YXRlCn17CjAgUEwg dHJhbnNsYXRlCn1pZmVsc2UKMSAtMSBzY2FsZQp9YmluZCBkZWYKL0VQewpsZXZlbDAgcmVz dG9yZQpzaG93cGFnZQp9YmluZCBkZWYKL0RBewpuZXdwYXRoIGFyY24gc3Ryb2tlCn1iaW5k IGRlZgovU057CnRyYW5zZm9ybQouMjUgc3ViIGV4Y2ggLjI1IHN1YiBleGNoCnJvdW5kIC4y NSBhZGQgZXhjaCByb3VuZCAuMjUgYWRkIGV4Y2gKaXRyYW5zZm9ybQp9YmluZCBkZWYKL0RM ewpTTgptb3ZldG8KU04KbGluZXRvIHN0cm9rZQp9YmluZCBkZWYKL0RDewpuZXdwYXRoIDAg MzYwIGFyYyBjbG9zZXBhdGgKfWJpbmQgZGVmCi9UTSBtYXRyaXggZGVmCi9ERXsKVE0gY3Vy cmVudG1hdHJpeCBwb3AKdHJhbnNsYXRlIHNjYWxlIG5ld3BhdGggMCAwIC41IDAgMzYwIGFy YyBjbG9zZXBhdGgKVE0gc2V0bWF0cml4Cn1iaW5kIGRlZgovUkMvcmN1cnZldG8gbG9hZCBk ZWYKL1JML3JsaW5ldG8gbG9hZCBkZWYKL1NUL3N0cm9rZSBsb2FkIGRlZgovTVQvbW92ZXRv IGxvYWQgZGVmCi9DTC9jbG9zZXBhdGggbG9hZCBkZWYKL0ZMewpjdXJyZW50Z3JheSBleGNo IHNldGdyYXkgZmlsbCBzZXRncmF5Cn1iaW5kIGRlZgovQkwvZmlsbCBsb2FkIGRlZgovTFcv c2V0bGluZXdpZHRoIGxvYWQgZGVmCi9SRXsKZmluZGZvbnQKZHVwIG1heGxlbmd0aCAxIGlu ZGV4L0ZvbnROYW1lIGtub3duIG5vdHsxIGFkZH1pZiBkaWN0IGJlZ2luCnsKMSBpbmRleC9G SUQgbmV7ZGVmfXtwb3AgcG9wfWlmZWxzZQp9Zm9yYWxsCi9FbmNvZGluZyBleGNoIGRlZgpk dXAvRm9udE5hbWUgZXhjaCBkZWYKY3VycmVudGRpY3QgZW5kIGRlZmluZWZvbnQgcG9wCn1i aW5kIGRlZgovREVGUyAwIGRlZgovRUJFR0lOewptb3ZldG8KREVGUyBiZWdpbgp9YmluZCBk ZWYKL0VFTkQvZW5kIGxvYWQgZGVmCi9DTlQgMCBkZWYKL2xldmVsMSAwIGRlZgovUEJFR0lO ewovbGV2ZWwxIHNhdmUgZGVmCnRyYW5zbGF0ZQpkaXYgMyAxIHJvbGwgZGl2IGV4Y2ggc2Nh bGUKbmVnIGV4Y2ggbmVnIGV4Y2ggdHJhbnNsYXRlCjAgc2V0Z3JheQowIHNldGxpbmVjYXAK MSBzZXRsaW5ld2lkdGgKMCBzZXRsaW5lam9pbgoxMCBzZXRtaXRlcmxpbWl0CltdMCBzZXRk YXNoCi9zZXRzdHJva2VhZGp1c3Qgd2hlcmV7CnBvcApmYWxzZSBzZXRzdHJva2VhZGp1c3QK fWlmCi9zZXRvdmVycHJpbnQgd2hlcmV7CnBvcApmYWxzZSBzZXRvdmVycHJpbnQKfWlmCm5l d3BhdGgKL0NOVCBjb3VudGRpY3RzdGFjayBkZWYKdXNlcmRpY3QgYmVnaW4KL3Nob3dwYWdl e31kZWYKfWJpbmQgZGVmCi9QRU5EewpjbGVhcgpjb3VudGRpY3RzdGFjayBDTlQgc3Vie2Vu ZH1yZXBlYXQKbGV2ZWwxIHJlc3RvcmUKfWJpbmQgZGVmCmVuZCBkZWYKL3NldHBhY2tpbmcg d2hlcmV7CnBvcApzZXRwYWNraW5nCn1pZgolJUVuZFJlc291cmNlCiUlSW5jbHVkZVJlc291 cmNlOiBmb250IENvdXJpZXItQm9sZAolJUluY2x1ZGVSZXNvdXJjZTogZm9udCBUaW1lcy1C b2xkCiUlSW5jbHVkZVJlc291cmNlOiBmb250IFRpbWVzLVJvbWFuCiUlSW5jbHVkZVJlc291 cmNlOiBmb250IENvdXJpZXIKZ3JvcHMgYmVnaW4vREVGUyAxIGRpY3QgZGVmIERFRlMgYmVn aW4vdXsuMDAxIG11bH1iaW5kIGRlZiBlbmQvUkVTIDcyCmRlZi9QTCA3OTIgZGVmL0xTIGZh bHNlIGRlZi9FTkMwWy9hc2NpaWNpcmN1bS9hc2NpaXRpbGRlL1NjYXJvbi9aY2Fyb24KL3Nj YXJvbi96Y2Fyb24vWWRpZXJlc2lzL3RyYWRlbWFyay9xdW90ZXNpbmdsZS8ubm90ZGVmLy5u b3RkZWYvLm5vdGRlZgovLm5vdGRlZi8ubm90ZGVmLy5ub3RkZWYvLm5vdGRlZi8ubm90ZGVm Ly5ub3RkZWYvLm5vdGRlZi8ubm90ZGVmLy5ub3RkZWYKLy5ub3RkZWYvLm5vdGRlZi8ubm90 ZGVmLy5ub3RkZWYvLm5vdGRlZi8ubm90ZGVmLy5ub3RkZWYvLm5vdGRlZi8ubm90ZGVmCi8u bm90ZGVmLy5ub3RkZWYvc3BhY2UvZXhjbGFtL3F1b3RlZGJsL251bWJlcnNpZ24vZG9sbGFy L3BlcmNlbnQKL2FtcGVyc2FuZC9xdW90ZXJpZ2h0L3BhcmVubGVmdC9wYXJlbnJpZ2h0L2Fz dGVyaXNrL3BsdXMvY29tbWEvaHlwaGVuCi9wZXJpb2Qvc2xhc2gvemVyby9vbmUvdHdvL3Ro cmVlL2ZvdXIvZml2ZS9zaXgvc2V2ZW4vZWlnaHQvbmluZS9jb2xvbgovc2VtaWNvbG9uL2xl c3MvZXF1YWwvZ3JlYXRlci9xdWVzdGlvbi9hdC9BL0IvQy9EL0UvRi9HL0gvSS9KL0svTC9N L04vTwovUC9RL1IvUy9UL1UvVi9XL1gvWS9aL2JyYWNrZXRsZWZ0L2JhY2tzbGFzaC9icmFj a2V0cmlnaHQvY2lyY3VtZmxleAovdW5kZXJzY29yZS9xdW90ZWxlZnQvYS9iL2MvZC9lL2Yv Zy9oL2kvai9rL2wvbS9uL28vcC9xL3Ivcy90L3Uvdi93L3gveQovei9icmFjZWxlZnQvYmFy L2JyYWNlcmlnaHQvdGlsZGUvLm5vdGRlZi9xdW90ZXNpbmdsYmFzZS9ndWlsbGVtb3RsZWZ0 Ci9ndWlsbGVtb3RyaWdodC9idWxsZXQvZmxvcmluL2ZyYWN0aW9uL3BlcnRob3VzYW5kL2Rh Z2dlci9kYWdnZXJkYmwKL2VuZGFzaC9lbWRhc2gvZmYvZmkvZmwvZmZpL2ZmbC9kb3RsZXNz aS9kb3RsZXNzai9ncmF2ZS9odW5nYXJ1bWxhdXQKL2RvdGFjY2VudC9icmV2ZS9jYXJvbi9y aW5nL29nb25lay9xdW90ZWRibGxlZnQvcXVvdGVkYmxyaWdodC9vZS9sc2xhc2gKL3F1b3Rl ZGJsYmFzZS9PRS9Mc2xhc2gvLm5vdGRlZi9leGNsYW1kb3duL2NlbnQvc3RlcmxpbmcvY3Vy cmVuY3kveWVuCi9icm9rZW5iYXIvc2VjdGlvbi9kaWVyZXNpcy9jb3B5cmlnaHQvb3JkZmVt aW5pbmUvZ3VpbHNpbmdsbGVmdAovbG9naWNhbG5vdC9taW51cy9yZWdpc3RlcmVkL21hY3Jv bi9kZWdyZWUvcGx1c21pbnVzL3R3b3N1cGVyaW9yCi90aHJlZXN1cGVyaW9yL2FjdXRlL211 L3BhcmFncmFwaC9wZXJpb2RjZW50ZXJlZC9jZWRpbGxhL29uZXN1cGVyaW9yCi9vcmRtYXNj dWxpbmUvZ3VpbHNpbmdscmlnaHQvb25lcXVhcnRlci9vbmVoYWxmL3RocmVlcXVhcnRlcnMK L3F1ZXN0aW9uZG93bi9BZ3JhdmUvQWFjdXRlL0FjaXJjdW1mbGV4L0F0aWxkZS9BZGllcmVz aXMvQXJpbmcvQUUKL0NjZWRpbGxhL0VncmF2ZS9FYWN1dGUvRWNpcmN1bWZsZXgvRWRpZXJl c2lzL0lncmF2ZS9JYWN1dGUvSWNpcmN1bWZsZXgKL0lkaWVyZXNpcy9FdGgvTnRpbGRlL09n cmF2ZS9PYWN1dGUvT2NpcmN1bWZsZXgvT3RpbGRlL09kaWVyZXNpcwovbXVsdGlwbHkvT3Ns YXNoL1VncmF2ZS9VYWN1dGUvVWNpcmN1bWZsZXgvVWRpZXJlc2lzL1lhY3V0ZS9UaG9ybgov Z2VybWFuZGJscy9hZ3JhdmUvYWFjdXRlL2FjaXJjdW1mbGV4L2F0aWxkZS9hZGllcmVzaXMv YXJpbmcvYWUvY2NlZGlsbGEKL2VncmF2ZS9lYWN1dGUvZWNpcmN1bWZsZXgvZWRpZXJlc2lz L2lncmF2ZS9pYWN1dGUvaWNpcmN1bWZsZXgvaWRpZXJlc2lzCi9ldGgvbnRpbGRlL29ncmF2 ZS9vYWN1dGUvb2NpcmN1bWZsZXgvb3RpbGRlL29kaWVyZXNpcy9kaXZpZGUvb3NsYXNoCi91 Z3JhdmUvdWFjdXRlL3VjaXJjdW1mbGV4L3VkaWVyZXNpcy95YWN1dGUvdGhvcm4veWRpZXJl c2lzXWRlZgovQ291cmllckAwIEVOQzAvQ291cmllciBSRS9UaW1lcy1Sb21hbkAwIEVOQzAv VGltZXMtUm9tYW4gUkUKL1RpbWVzLUJvbGRAMCBFTkMwL1RpbWVzLUJvbGQgUkUvQ291cmll ci1Cb2xkQDAgRU5DMC9Db3VyaWVyLUJvbGQgUkUKJSVFbmRQcm9sb2cKJSVQYWdlOiAxIDEK JSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTAvQ291cmllci1Cb2xk QDAgU0YoSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSk3MiA4NSBRKFJNVCBXRykK MjA5Ljk5OSBFIDIwMy45OTkoSU5URVJORVQtRFJBRlQgTS5MdWJ5L0RpZ2l0YWwpNzIgOTgg UihGb3VudGFpbik2IEUKMTY3Ljk5OShkcmFmdC1pZXRmLXJtdC1iYi1mZWMtMDMucHMgTC5W aWNpc2Fuby9DaXNjbyk3MiAxMTEgUgooSi5HZW1tZWxsL01pY3Jvc29mdCkzODkuOTk5IDEy NCBRKEwuUml6em8vQUNJUkkgYW5kIFVuaXYuIFBpc2EpMzM1Ljk5OQoxMzcgUShNLkhhbmRs ZXkvQUNJUkkpNDEzLjk5OSAxNTAgUShKLiBDcm93Y3JvZnQvVUNMKTQwNy45OTkgMTYzIFEK KDE5IEp1bHkgMjAwMSk0MzEuOTk5IDE3NiBRKEV4cGlyZXM6IEphbnVhcnkgMjAwMikzNzcu OTk5IDE4OSBRL0YxIDE0Ci9UaW1lcy1Cb2xkQDAgU0YoUk1UIEJCIEYpMTU5LjE0NCAyMTQg UShvcndhcmQgRXJyKS0uMzUgRShvciBDb3JyKS0uMjUyCkUoZWN0aW9uIENvZGVzKS0uMjUy IEUvRjIgMTEvVGltZXMtUm9tYW5AMCBTRihUaGlzIGRvY3VtZW50IGlzIGFuIEludGVyXApu ZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCBhbGwgcHJvKTcyIDIz MyBRCih2aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YpLS4xNjUgRShSRkMyMDI2Lik3MiAyNDYg UQooSW50ZXJuZXQtRHJhZnRzIGFyZSB3KTcyIDI3MiBRCihvcmtpbmcgZG9jdW1lbnRzIG9m IHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZyBUKS0uMTEgRShhc2sgRiktLjg4IEUKKG9yY2Ug XChJRVRGXCksIGl0cyBhcmVhcywpLS4xNjUgRShhbmQgaXRzIHcpNzIgMjg1IFEob3JraW5n IGdyb3Vwcy4pCi0uMTEgRShOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3Ry aWIpNS41IEUodXRlIHcpLS4yMiBFCihvcmtpbmcgZG9jdW1lbnRzIGFzKS0uMTEgRShJbnRl cm5ldC1EcmFmdHMuKTcyIDI5OCBRCihJbnRlcm5ldC1EcmFmdHMgYXJlIHYpNzIgMzI0IFEK KGFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwg cmVwbGFjZWQsIG9yKS0uMjc1CkUob2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBh bik3MiAzMzcgUSAyLjc1KHl0KS0uMTY1IEcgMi43NQooaW1lLiBJdCktMi43NSBGKGlzIGlu YXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UpCjIuNzUg RShtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyBhICJ3KTcyIDM1MCBR CihvcmsgaW4gcHJvZ3Jlc3MiLiktLjExIEUKKFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJu ZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCBodHRwOi8vd3d3KTcyCjM3NiBRKC5pZXRm Lm9yKS0uNzE1IEUoZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0KS0uMTk4IEUgMS43NiAtLjg4 KFRvIHYpCjcyIDQwMiBUKGllKS44OCBFIDIuNzUod3QpLS4yNzUgRyhoZSBsaXN0IEludGVy bmV0LURyYWZ0IFNoYWRvKS0yLjc1IEUKMi43NSh3RCktLjI3NSBHKGlyZWN0b3JpZXMsIHNl ZSBodHRwOi8vd3d3KS0yLjc1IEUoLmlldGYub3IpLS43MTUgRQooZy9zaGFkbyktLjE5OCBF IC0uNzE1KHcuKS0uMjc1IEcoaHRtbC4pLjcxNSBFCihUaGlzIGRvY3VtZW50IGlzIGEgcHJv ZHVjdCBvZiB0aGUgSUVURiBSTVQgV0cuKTcyIDQyOCBRCihDb21tZW50cyBzaG91bGQgYmUg YWRkcmVzc2VkIHRvIHRoZSk1LjUgRShhdXRob3JzLCBvciB0aGUgV0cnKTcyIDQ0MSBRCjIu NzUoc20pLS42MDUgRyhhaWxpbmcgbGlzdCBhdCBybXRAaXNpLmVkdS4pLTIuNzUgRS9GMyAx MS9UaW1lcy1Cb2xkQDAKU0YoQWJzdHJhY3QpMjY3LjUzNCA0NzMgUSBGMihUaGlzIG1lbW8g ZGVzY3JpYmVzIHRoZSBhYnN0cmFjdCBwYWNrKTk3CjQ5NS42IFEoZXQgZm9ybWF0cyBhbmQg SUFOKS0uMTEgRSAyLjc1KEFyKS0uMzg1IEcgLS4xNjUoZWcpLTIuNzUgRwooaXN0cmF0aW9u IHByb2NlZHVyZXMpLjE2NSBFKGZvciB1c2Ugb2YgRik5NyA1MDguNiBRKG9ydyktLjE2NSBF CihhcmQgRXJyb3IgQ29ycmVjdGlvbiBcKEZFQ1wpIGNvZGVzIHdpdGhpbiB0aGUgY29udGUp LS4xMSBFCih4dCBvZiByZWxpYWJsZSBJUCktLjE2NSBFKG11bHRpY2FzdCB0cmFuc3BvcnQu KTk3IDUyMS42IFEKKFRoaXMgbWVtbyBzaG91bGQgYmUgcmVhZCBpbiBjb25qdW5jdGlvbiB3 aXRoIGFuZCB1c2VzIHRoZSk1LjUgRQoodGVybWlub2xvZ3kgb2YgdGhlIGNvbXBhbmlvbiBt ZW1vIFsxXSwgd2hpY2ggZGVzY3JpYmVzIHRoZSB1c2Ugb2YgRik5Nwo1MzQuNiBRKG9ydykt LjE2NSBFKGFyZCBFcnJvciktLjExIEUKKENvcnJlY3Rpb24gXChGRUNcKSBjb2RlcyB3aXRo aW4gdGhlIGNvbnRlKTk3IDU0Ny42IFEKKHh0IG9mIHJlbGlhYmxlIElQIG11bHRpY2FzdCB0 cmFuc3BvcnQgYW5kKS0uMTY1IEUocHJvKTk3IDU2MC42IFEKKHZpZGVzIGFuIGludHJvZHVj dGlvbiB0byBzb21lIGNvbW1vbmx5IHVzZWQgRkVDIGNvZGVzLiktLjE2NSBFIEYzKDEuKTcy CjU5OS42IFEgRjEoRkVDIEFic3RyYWN0IFApNS41IEUoYWNrKS0uMTQgRQooZXQgRmllbGRz IGFuZCBPdXQtb2YtQmFuZCBJbmYpLS4xNCBFKG9ybWF0aW9uKS0uMzUgRSBGMgooVGhpcyBz ZWN0aW9uIHNwZWNpXDIxNGVzIHRoZSBpbmZvcm1hdGlvbiB0aGF0IHByb3RvY29sIHBhY2sp NzIgNjE2LjIgUQooZXRzIG11c3QgY2FycnkgdG8gaW1wbGVtZW50IHRoZSB2KS0uMTEgRShh cmlvdXMpLS4yNzUgRQooZm9ybXMgb2YgRkVDLWJhc2VkIHJlbGlhYmlsaXR5KTcyIDYyOS4y IFEgNS41KC5BKS0uNzE1IEcKKHNlc3Npb24gaXMgZGVcMjE0bmVkIHRvIGJlIGFsbCB0aGUg aW5mb3JtYXRpb24gYXNzb2NpYXRlZCB3aXRoIGEpLTIuNzUKRSh0cmFuc21pc3Npb24gb2Yg ZGF0YSBhYm91dCBhIHBhcnRpY3VsYXIgb2JqZWN0IGJ5IGEgc2luZ2xlIHNlbmRlcik3Mgo2 NDIuMiBRIDUuNSguVCktLjYwNSBHKGhlcmUgYXJlIHRocmVlIGNsYXNzZXMgb2YpLTUuNSBF KHBhY2spNzIgNjU1LjIgUQooZXRzIHRoYXQgbWF5IGNvbnRhaW4gRkVDIGluZm9ybWF0aW9u IHdpdGhpbiBhIHNlc3Npb246IGRhdGEgcGFjayktLjExIEUKKGV0cywgc2Vzc2lvbi1jb250 cm9sIHBhY2spLS4xMSBFKGV0cyktLjExIEUoYW5kIGZlZWRiYWNrIHBhY2spNzIgNjY4LjIK USAyLjc1KGV0cy4gVGhlKS0uMTEgRiAyLjc1KHlnKS0uMTY1IEcoZW5lcmFsbHkgY29udGFp biBkaWYpLTIuNzUgRQooZmVyZW50IGtpbmRzIG9mIEZFQyBpbmZvcm1hdGlvbi4pLS4yNzUg RShOb3RlIHRoYXQpNS41IEUKKHNvbWUgcHJvdG9jb2xzIGRvIG5vdCB1c2UgZmVlZGJhY2sg cGFjayk3MiA2ODEuMiBRKGV0cy4pLS4xMSBFCihEYXRhIHBhY2spNzIgNzA3LjIgUShldHMg bWF5IHNvbWV0aW1lIHNlcnYpLS4xMSBFIDIuNzUoZWEpLS4xNjUgRyAyLjc1CihzcyktMi43 NSBHKGVzc2lvbi1jb250cm9sIHBhY2spLTIuNzUgRQooZXRzIGFzIHdlbGw7IGJvdGggZGF0 YSBhbmQgc2Vzc2lvbi0pLS4xMSBFKGNvbnRyb2wgcGFjayk3MiA3MjAuMiBRCihldHMgZ2Vu ZXJhbGx5IHRyYSktLjExIEUgLS4xNjUodmUpLS4yMiBHIDIuNzUobGQpLjE2NSBHIC0uMjc1 KG93KS0yLjc1CkcobnN0cmVhbSBcKGZyb20gdGhlIHNlbmRlciB0bykuMjc1IEUgLS4xMSh3 YSktLjI3NSBHKHJkcyByZWNlaSkuMTEgRQotLjE2NSh2ZSktLjI3NSBHKHJzXCkgYW5kIGFy ZSkuMTY1IEUoTHVieS9WKTcyIDc2OSBRCihpY2lzYW5vL0dlbW1lbGwvUml6em8vSGFuZGxl KS0uNjYgRSh5L0NybyktLjE2NSBFIDExNy4zNTYKKHdjcm9mdCBTZWN0aW9uKS0uMjc1IEYg Mi43NSgxLiBbUCkyLjc1IEYoYWdlIDFdKS0uMTY1IEUgRVAKJSVQYWdlOiAyIDIKJSVCZWdp blBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTEvVGltZXMtUm9tYW5AMCBTRihJ TlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhwaXJlczopLTEuMDEyIEYKKEphbnVh cnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEyMy43MjYgRQooYWRkcmVzc2VkIHRvIGEgbXVs dGljYXN0IElQIGFkZHJlc3MgXChzb21ldGltZSB0aGUpNzIgODUgUSAyLjc1KHltKQotLjE2 NSBHKGlnaHQgYmUgYWRkcmVzc2VkIHRvIHRoZSB1bmljYXN0IGFkZHJlc3Mgb2YgYSktMi43 NSBFCihzcGVjaVwyMTRjIHJlY2VpKTcyIDk4IFEgLS4xNjUodmUpLS4yNzUgRyhyXCkuIElu IHRoZSBmb2xsbykuMTY1IEUKKHdpbmcsIGZvciBzaW1wbGljaXR5IHdlIHdpbGwgcmVmZXIg dG8gYm90aCBkYXRhIGFuZCBzZXNzaW9uIGNvbnRyb2wpCi0uMjc1IEUocGFjayk3MiAxMTEg UShldHMgYXMgZG8pLS4xMSBFKHduc3RyZWFtLXRyYSktLjI3NSBFIC0uMTY1KHZlKQotLjIy IEcobGluZyBwYWNrKS4xNjUgRShldHMsIG9yIHNpbXBseSBkbyktLjExIEUod25zdHJlYW0g cGFjayktLjI3NSBFCihldHMuKS0uMTEgRShBcyBhIGdlbmVyYWwgcnVsZSwgZmVlZGJhY2sg cGFjayk3MiAxMzcgUShldHMgdHJhKS0uMTEgRQotLjE2NSh2ZSktLjIyIEcgMi43NShsdSku MTY1IEcocHN0cmVhbSBcKGZyb20gcmVjZWkpLTIuNzUgRSAtLjE2NSh2ZSkKLS4yNzUgRyhy cyB0byB0aGUgc2VuZGVyXCkgYW5kIGFyZSkuMTY1IEUKKGFkZHJlc3NlZCB0byB0aGUgdW5p Y2FzdCBhZGRyZXNzIG9mIHRoZSBzZW5kZXIpNzIgMTUwIFEgMi43NSguUyktLjYwNSBHCihv bWV0aW1lcywgaG8pLTIuNzUgRSh3ZSktLjI3NSBFIC0uMTY1KHZlKS0uMjc1IEcgLjg4IC0u NDQociwgdCkuMTY1IEgKKGhlKS40NCBFIDIuNzUoeW0pLS4xNjUgRyhpZ2h0IGJlIGFkZHJl c3NlZCB0byBhKS0yLjc1IEUKKG11bHRpY2FzdCBJUCBhZGRyZXNzIG9yIHRvIHRoZSB1bmlj YXN0IGFkZHJlc3Mgb2YgYSByZWNlaSk3MiAxNjMgUQotLjE2NSh2ZSktLjI3NSBHIDIuNzUo cm8pLjE2NSBHIDIuNzUocmEpLTIuNzUgRwoobHNvIHRoZSB0aGUgdW5pY2FzdCBhZGRyZXNz IG9mIHNvbWUpLTIuNzUgRShkaWYpNzIgMTc2IFEKKGZlcmVudCBub2RlIFwoYW4gaW50ZXJt ZWRpYXRlIG5vZGUgdGhhdCBwcm8pLS4yNzUgRSh2aWRlcyByZWNvKS0uMTY1IEUKLS4xNjUo dmUpLS4xNjUgRyhyeSBzZXJ2aWNlcyBvciBhIG5laWdoYm9yaW5nIHJvdXRlclwpLikuMTY1 IEUKKFRoZSBGRUMtcmVsYXRlZCBpbmZvcm1hdGlvbiB0aGF0IGNhbiBiZSBwcmVzZW50IGlu IGRvKTcyIDIwMiBRCih3bnN0cmVhbSBwYWNrKS0uMjc1IEUoZXRzIGNhbiBiZSBjbGFzc2lc MjE0ZWQgYXMpLS4xMSBFKGZvbGxvKTcyIDIxNSBRCih3czopLS4yNzUgRSA3LjMzNygxXCkg RkVDKTc0Ljc1IDI0NC42IFIoRW5jb2RpbmcgSWRlbnRpXDIxNGVyKTIuNzUgRQooSWRlbnRp XDIxNGVzIHRoZSBGRUMgZW5jb2RpbmcgYmVpbmcgdXNlZCBhbmQgaGFzIHRoZSBwdXJwb3Nl IG9mIGFsbG8pCjEwNSAyNjEuMiBRKHdpbmcgcmVjZWkpLS4yNzUgRSAtLjE2NSh2ZSktLjI3 NSBHKHJzIHRvIHNlbGVjdCkuMTY1IEUKKHRoZSBhcHByb3ByaWF0ZSBGRUMgZGVjb2Rlcikx MDUgMjc0LjIgUSAyLjc1KC5BKS0uNjA1IEcgMi43NShzYWcpLTIuNzUKRyhlbmVyYWwgcnVs ZSwgdGhlICJGRUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVyIiBNVVNUIGJlKS0yLjc1IEUKKHRo ZSBzYW1lIGZvciBhIGdpKTEwNSAyODcuMiBRIC0uMTY1KHZlKS0uMjc1IEcgMi43NShucyku MTY1IEcoZXNzaW9uLCBcCmkuZS4sIGZvciBhbGwgdHJhbnNtaXNzaW9uIG9mIGRhdGEgcmVs YXRlZCB0byBhIHBhcnRpY3VsYXIgb2JqZWN0LCktMi43NQpFIC0uMjIoYnUpMTA1IDMwMC4y IFMgMi43NSh0TSkuMjIgRyAyLjMxIC0xLjE1NShBWSB2KS0yLjc1IEgKKGFyeSBhY3Jvc3Mg ZGlmKS44OCBFKGZlcmVudCB0cmFuc21pc3Npb25zIG9mIGRhdGEgYWJvdXQgZGlmKS0uMjc1 IEUKKGZlcmVudCBvYmplY3RzIGluIGRpZiktLjI3NSBFKGZlcmVudCktLjI3NSBFKHNlc3Np b25zLCBlKTEwNSAzMTMuMiBRCi0uMTY1KHZlKS0uMjc1IEcgMi43NShuaSkuMTY1IEcgMi43 NShmdCktMi43NSBHKHJhbnNtaXR0ZWQgdXNpbmcgdGhlIHNhXAptZSBzZXQgb2YgbXVsdGlj YXN0IGdyb3VwcyBhbmQvb3IgdXNpbmcgYSBzaW5nbGUpLTIuNzUgRSh1cHBlcikxMDUgMzI2 LjIKUSgtbGF5ZXIgc2Vzc2lvbi4pLS4yMiBFIDcuMzM3KDJcKSBGRUMpNzQuNzUgMzQyLjgg UihwYXlsb2FkIElEKTIuNzUgRQooSWRlbnRpXDIxNGVzIHRoZSBzeW1ib2xcKHNcKSBpbiB0 aGUgcGF5bG9hZCBvZiB0aGUgcGFjaykxMDUgMzU5LjQgUQooZXQuIFRoZSBjb250ZW50IG9m IHRoaXMgcGllY2Ugb2YpLS4xMSBFKGluZm9ybWF0aW9uIGRlcGVuZHMgb24gdGhlIGVuY1wK b2RlciBiZWluZyB1c2VkIFwoZS5nLiBpbiBCbG9jayBGRUMgY29kZXMgdGhpcyBtYXkgYmUg dGhlKTEwNSAzNzIuNCBRCihjb21iaW5hdGlvbiBvZiBibG9jayBpbmRlKTEwNSAzODUuNCBR IDIuNzUoeGEpLS4xNjUgRwoobmQgZW5jb2Rpbmcgc3ltYm9sIGlkZW50aVwyMTRlcjsgaW4g aWRlYWwgZSktMi43NSBFKHhwYW5kYWJsZSBGRUMpLS4xNjUKRShjb2RlcyB0aGlzIG1heSBi ZSBqdXN0IGEgXDIxNWF0IGVuY29kaW5nIHN5bWJvbCBpZGVudGlcMjE0ZXJcKS4pMTA1CjM5 OC40IFEgNy4zMzcoM1wpIEZFQyk3NC43NSA0MTUgUihPYmplY3QgVCkyLjc1IEUKKHJhbnNt aXNzaW9uIEluZm9ybWF0aW9uKS0uMzg1IEUoVGhpcyBpcyBpbmZvcm1hdGlvbiByZSkxMDUg NDMxLjYgUQotLjA1NShnYSktLjE2NSBHCihyZGluZyB0aGUgZW5jb2Rpbmcgb2YgYSBzcGVj aVwyMTRjIG9iamVjdCBuZWVkZWQgYnkgdGhlIEZFQyBkZWNvZGVyKQouMDU1IEUoXChlLmcu IGZvciBCbG9jayBGRUMgY29kZXMgdGhpcyBtYXkgYmUgdGhlIGNvbWJpbmF0aW9uIG9mIGJs b2NrIFwKbGVuZ3RoIGFuZCBvYmplY3QgbGVuZ3RoXCkuKTEwNSA0NDQuNiBRCihUaGlzIG1p Z2h0IGFsc28gaW5jbHVkZSBnZW5lcmFsIHBhcmFtZXRlcnMgb2YgdGhlIEZFQyBlbmNvZGVy KTEwNSA0NTcuNgpRIDIuNzUoLk4pLS42MDUgRyhvdGUgdGhhdCwgaW4gc3RyaWN0IHRlcm1z LCktMi43NSBFKHRoZSAiRkVDIEVuY29kaW5nIFwKSWRlbnRpXDIxNGVyIiBiZWxvbmdzIHRv IHRoaXMgY2xhc3Mgb2YgaW5mb3JtYXRpb24sIGhvKTEwNSA0NzAuNiBRKHdlKQotLjI3NSBF IC0uMTY1KHZlKS0uMjc1IEcgLjg4IC0uNDQociwgZikuMTY1IEgob3IgcHJhY3RpY2FsKS40 NCBFCihwdXJwb3Nlcywgd2Ugd2lsbCBjb25zaWRlciBpdCBzZXBhcmF0ZWx5KTEwNSA0ODMu NiBRKC4pLS43MTUgRQooQWxsIHRoZSBjbGFzc2VzIG9mIGluZm9ybWF0aW9uIGFibyk5NyA1 MTMuMiBRIC0uMTY1KHZlKS0uMTY1IEcgMi43NSgsZSkKLjE2NSBHKHhjZXB0IDJcKSwgY2Fu IGVpdGhlciBiZSB0cmFuc21pdHRlZCB3aXRoaW4gdGhlKS0yLjkxNSBFCih0cmFuc3BvcnQg c2Vzc2lvbiBcKHVzaW5nIHByb3RvY29sIHBhY2spNzIgNTI2LjIgUQooZXQtaGVhZGVyIFwy MTRlbGRzXCkgb3Igb3V0IG9mIGJhbmQuIFRoZSBpbmZvcm1hdGlvbiBkZXNjcmliZWQpLS4x MSBFCihpbiAyXCkgTVVTVCBiZSB0cmFuc21pdHRlZCBpbiBkYXRhLXBhY2spNzIgNTM5LjIg UQooZXQgaGVhZGVyIFwyMTRlbGRzLCBhcyBpdCBwcm8pLS4xMSBFKHZpZGVzIGEgZGVzY3Jp cHRpb24gb2YgdGhlIGRhdGEpCi0uMTY1IEUoY29udGFpbmVkIGluIHRoZSBwYWNrKTcyIDU1 Mi4yIFEoZXQuIEluIHRoZSBmb2xsbyktLjExIEUKKHdpbmcgd2Ugd2lsbCBzcGVjaWZ5IHRo ZSBjb250ZW50IG9mIDFcKSwgMlwpIGFuZCAzXCkgcmUpLS4yNzUgRSAtLjA1NQooZ2EpLS4x NjUgRyhyZGxlc3Mgb2YpLjA1NSBFCih3aGV0aGVyIHRoZXNlIHBpZWNlcyBvZiBpbmZvcm1h dGlvbiBhcmUgdHJhbnNtaXR0ZWQgaW4gcHJvdG9jb2wgcGFjayk3Mgo1NjUuMiBRKGV0cyBv ciBvdXQgb2YgYmFuZC4gVGhpcyktLjExIEUoZG9jdW1lbnQgbmVpdGhlciBzcGVjaVwyMTRl cyBvdVwKdC1vZi1iYW5kIG1ldGhvZHMgdG8gdHJhbnNwb3J0IHRoZSBpbmZvcm1hdGlvbiBu b3IgZG9lcyBpdCBzcGVjaWZ5KTcyCjU3OC4yIFEodGhlIHcpNzIgNTkxLjIgUQooYXkgb3V0 LW9mLWJhbmQgaW5mb3JtYXRpb24gaXMgYXNzb2NpYXRlZCB3aXRoIHBhY2spLS4xMSBFCihl dCBwYXlsb2Fkcy4gVGhpcyBsYXN0IHRhc2sgaXMgZGUpLS4xMSBFIC0uMjIodm8pLS4yNzUg RyhsdikuMjIgRQooZWQgdG8pLS4xNjUgRShhbiB1cHBlcik3MiA2MDQuMiBRKC1sYXllciBw cm90b2NvbC4pLS4yMiBFIC0uNDQoV2kpNzIKNjMwLjIgUyh0aGluIHRoZSBjb250ZSkuNDQg RSh4dCBvZiBGRUMgcmVwYWlyIHNjaGVtZXMsIGZlZWRiYWNrIHBhY2spCi0uMTY1IEUoZXRz IGFyZSBcKG9wdGlvbmFsbHlcKSB1c2VkIHRvIHJlcXVlc3QgRkVDKS0uMTEgRSAyLjc1Cihy ZXRyYW5zbWlzc2lvbi4gVGhlKTcyIDY0My4yIFIKKEZFQy1yZWxhdGVkIGluZm9ybWF0aW9u IHByZXNlbnQgaW4gZmVlZGJhY2sgcGFjaykyLjc1IEUKKGV0cyB1c3VhbGx5IGNvbnRhaW5z IGFuKS0uMTEgRShGRUMgQmxvY2sgSWRlbnRpXDIxNGVyKTcyIDY1Ni4yIFEgMi43NQooLHQp LS40NCBHKGhhdCBkZVwyMTRuZXMgdGhlIGJsb2NrIHRoYXQgaXMgYmVpbmcgcmVwYWlyZWQs IGFuZCB0aGUgbnVtYlwKZXIgb2YgUmVwYWlyKS0yLjc1IEUKKFN5bWJvbHMgcmVxdWVzdGVk LiBBbHRob3VnaCB0aGlzIGlzIHRoZSBtb3N0IGNvbW1vbiBjYXNlLCB2KTcyIDY2OS4yIFEK KGFyaWFudHMgYXJlIHBvc3NpYmxlIGluIHdoaWNoIHRoZSktLjI3NSBFKHJlY2VpKTcyIDY4 Mi4yIFEgLS4xNjUodmUpCi0uMjc1IEcocnMgcHJvKS4xNjUgRSh2aWRlIG1vcmUgc3BlY2lc MjE0YyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUmVwYWlyXAogU3ltYm9scyByZXF1ZXN0ZWQg XChlLmcuIGFuIGluZGUpLS4xNjUgRSh4KS0uMTY1IEUocmFuZ2Ugb3IgYSBsaXN0IG9mIFwK c3ltYm9scyBhY2NlcHRlZFwpLiBJdCBpcyBhbHNvIHBvc3NpYmxlIHRvIGluY2x1ZGUgbXVs dGlwbGUgb2YgdGhlc2UgcmVcCnF1ZXN0IGluIGEpNzIgNjk1LjIgUShzaW5nbGUgZmVlZGJh Y2sgcGFjayk3MiA3MDguMiBRKGV0LiktLjExIEUoTHVieS9WKQo3MiA3NjkgUShpY2lzYW5v L0dlbW1lbGwvUml6em8vSGFuZGxlKS0uNjYgRSh5L0NybyktLjE2NSBFIDExNy4zNTYKKHdj cm9mdCBTZWN0aW9uKS0uMjc1IEYgMi43NSgxLiBbUCkyLjc1IEYoYWdlIDJdKS0uMTY1IEUg RVAKJSVQYWdlOiAzIDMKJSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAg MTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhw aXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEyMy43MjYg RShUaGlzIGRvY3VtZW50IGRvZXMgbm90IHBybyk3Mgo4NSBRKHZpZGUgYW4pLS4xNjUgRSAy Ljc1KHlkKS0uMTY1IEcKKGV0YWlsIGFib3V0IHRoZSBmb3JtYXQgb2YgRkVDIGluZm9ybWF0 aW9uIGluIGZlZWRiYWNrKS0yLjc1IEUocGFjayk3Mgo5OCBRKGV0cy4pLS4xMSBFL0YxIDEx L1RpbWVzLUJvbGRAMCBTRigxLjEuKTcyIDEzNyBRL0YyIDEzL1RpbWVzLUJvbGRAMApTRihG RUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVyKTUuNSBFIEYwKFRoaXMgaXMgYSBudW1lcmljIGlu ZGUpNzIgMTY2LjYgUQoyLjc1KHh0KS0uMTY1IEcoaGF0IGlkZW50aVwyMTRlcyBhIHNwZWNp XDIxNGMgRkVDIHNjaGVtZSBPUiBhIGNsYXNzIG9mIFwKZW5jb2Rpbmcgc2NoZW1lcyktMi43 NSBFKHRoYXQgc2hhcmUgdGhlIHNhbWUgZm9ybWF0IG9mICJGRUMgUCk3MiAxNzkuNiBRCihh eWxvYWQgSUQiIGFuZCAiRkVDIE9iamVjdCBUKS0uMTY1IEUocmFuc21pc3Npb24gSW5mb3Jt YXRpb24iLiktLjM4NSBFCihUaGUgRkVDIEVuY29kaW5nIElkZW50aVwyMTRlciBpZGVudGlc MjE0ZXMgYSBzcGVjaVwyMTRjIEZFQyBzY2hlbWUgd2hlXApuIHRoZSBlbmNvZGluZyBzY2hl bWUgaXMpNzIgMjA1LjYgUQooZm9ybWFsbHkgYW5kIGZ1bGx5IHNwZWNpXDIxNGVkLCBpbiBh IHcpNzIgMjE4LjYgUQooYXkgdGhhdCBpbmRlcGVuZGVudCBpbXBsZW1lbnRvcnMgY2FuIGlt cGxlbWVudCBib3RoIGVuY29kZXIpLS4xMSBFKGFuZFwKIGRlY29kZXIgZnJvbSB0aGUgc3Bl Y2lcMjE0Y2F0aW9uLiBDb21wYW5pb24gZG9jdW1lbnRzIG9mIHRoaXMgc3BlY2lcClwyMTRj YXRpb24gbWF5IHNwZWNpZnkgc3VjaCk3MiAyMzEuNiBRCihGRUMgc2NoZW1lcyBhbmQgYXNz b2NpYXRlIHRoZW0gd2l0aCAiRkVDIEVuY29kaW5nIElkZW50aVwyMTRlciIgdik3MgoyNDQu NiBRKGFsdWVzLiBUaGVzZSBkb2N1bWVudHMpLS4yNzUgRQooTVVTVCBhbHNvIHNwZWNpZnkg YSBjb3JyZXNwb25kZW50IGZvcm1hdCBmb3IgdGhlICJGRUMgUCk3MiAyNTcuNiBRCihheWxv YWQgSUQiIGFuZCAiRkVDIE9iamVjdCktLjE2NSBFIC0uMzg1KFRyKTcyIDI3MC42IFMKKGFu c21pc3Npb24gSW5mb3JtYXRpb24iLikuMzg1IEUKKEN1cnJlbnRseSBGRUMgRW5jb2Rpbmcg SWRlbnRpXDIxNGVycyBpbiB0aGUgcmFuZ2UgMC0xMjcgYXJlIHJlc2Vydik1LjUKRShlZCkt LjE2NSBFCihmb3IgdGhpcyBjbGFzcyBvZiBlbmNvZGluZyBzY2hlbWVzIFwoZnVsbHktc3Bl Y2lcMjE0ZWQgc2NoZW1lc1wpLik3MgoyODMuNiBRKEl0IGlzIHBvc3NpYmxlIHRoYXQgYSBG RUMgc2NoZW1lIGNhbm5vdCBiZSBjb21wbGV0ZWx5IHNwZWNpXDIxNFwKZWQgb3IgdGhhdCBz dWNoIGEgc3BlY2lcMjE0Y2F0aW9uIGlzKTcyIDMwOS42IFEoc2ltcGx5IG5vdCBhKTcyIDMy Mi42IFEKLS4yNzUodmEpLS4yMiBHKGlsYWJsZSBvciBhbHNvIHRoYXQgYSBwYXJ0eSBlKS4y NzUgRSh4aXN0cyB0aGF0IG8pLS4xNjUKRSh3bnMgdGhlIGVuY29kaW5nIHNjaGVtZSBhbmQg aXQgaXMgbm90IHdpbGxpbmcpLS4yNzUgRQoodG8gZGlzY2xvc2UgaXRzIGFsZ29yaXRobS4g Vyk3MiAzMzUuNiBRIDIuNzUoZXIpLS44OCBHCihlZmVyIHRvIHRoZXNlIGVuY29kaW5nIHNj aGVtZXMgYXMgIlVuZGVyKS0yLjc1IEUKKC1TcGVjaVwyMTRlZCIgc2NoZW1lcy4pLS4yMiBF KFVuZGVyKTcyIDM0OC42IFEKKC1zcGVjaVwyMTRlZCBzY2hlbWVzIGNhbiBzdGlsbCBiZSBp ZGVudGlcMjE0ZWQgYXMgZm9sbG8pLS4yMiBFKHdzOikKLS4yNzUgRSAxMShvQSk3Ny41IDM2 NS4yIFMoZm9ybWF0IG9mIHRoZSBcMjE0ZWxkcyAiRkVDIFApLTguMjUgRQooYXlsb2FkIElE IiBhbmQgIkZFQyBPYmplY3QgVCktLjE2NSBFKHJhbnNtaXNzaW9uIEluZm9ybWF0aW9uIikt LjM4NSBFCihNVVNUIGJlIGRlXDIxNG5lZCBmb3IgdGhlIGVuY29kaW5nIHNjaGVtZS4pOTQg Mzc4LjIgUSAxMShvQSk3Ny41IDM5NC44ClMgLS4yNzUodmEpLTguMjUgRyhsdWUgb2YgIkZF QyBFbmNvZGluZyBJZGVudGlcMjE0ZXIiIE1VU1QgYmUgcmVzZXJ2KQouMjc1IEUoZWQgYW5k IGFzc29jaWF0ZWQgdG8gdGhlIGZvcm1hdCktLjE2NSBFKGRlXDIxNG5pdGlvbnMgYWJvKTk0 CjQwNy44IFEgLS4xNjUodmUpLS4xNjUgRyAyLjc1KC5BKS4xNjUgRyAyLjc1KG5hKS0yLjc1 IEcobHJlYWR5IHJlc2VydikKLTIuNzUgRShlZCAiRkVDIEVuY29kaW5nIElkZW50aVwyMTRl ciIpLS4xNjUgRShNVVNUIGJlIHJldXNlZCBpZiBpdCBpcykKNS41IEUoYXNzb2NpYXRlZCB0 byB0aGUgc2FtZSBmb3JtYXQgb2YgIkZFQyBQKTk0IDQyMC44IFEKKGF5bG9hZCBJRCIgYW5k ICJGRUMgT2JqZWN0IFQpLS4xNjUgRShyYW5zbWlzc2lvbiktLjM4NSBFCihJbmZvcm1hdGlv biIgYXMgdGhlIG9uZXMgbmVlZGVkIGZvciB0aGUgbmUpOTQgNDMzLjggUSAyLjc1KHd1KS0u Mjc1IEcKKG5kZXIpLTIuNzUgRSgtc3BlY2lcMjE0ZWQgRkVDIHNjaGVtZS4pLS4yMiBFIDEx KG9BKTc3LjUgNDUwLjQgUyAtLjI3NQoodmEpLTguMjUgRyhsdWUgb2YgIkZFQyBFbmNvZGlu ZyBOYW1lIiBtdXN0IGJlIHJlc2VydikuMjc1IEUKKGVkIFwoc2VlIGJlbG8pLS4xNjUgRSh3 XCkuKS0uMjc1IEUoQW4gVW5kZXIpNzIgNDgwIFEoLXNwZWNpXDIxNGVkIEZFQyBcCnNjaGVt ZSBpcyBjb21wbGV0ZWx5IGlkZW50aVwyMTRlZCBieSB0aGUgdHVwbGUgXChGRUMgRW5jb2Rp bmcgSWRlbnRpXApcMjE0ZXIpLS4yMiBFKCwpLS40NCBFKEZFQyBFbmNvZGluZyBOYW1lXCku IFRoZSB0dXBsZSBNVVNUIGlkZW50aWZ5IGEgc1wKaW5nbGUgc2NoZW1lIHRoYXQgaGFzIGF0 IGxlYXN0IG9uZSk3MiA0OTMgUQooaW1wbGVtZW50YXRpb24uIFRoZSBwYXJ0eSB0aGF0IG8p NzIgNTA2IFEKKHducyB0aGlzIHR1cGxlIE1VU1QgYmUgYWJsZSB0byBwcm8pLS4yNzUgRSh2 aWRlIGluZm9ybWF0aW9uIG9uIGhvKS0uMTY1CkUgMi43NSh3dCktLjI3NSBHKG8pLTIuNzUg RShvYnRhaW4gdGhlIHVuZGVyKTcyIDUxOSBRKC1zcGVjaVwyMTRlZCBGRUMgXApzY2hlbWUg aWRlbnRpXDIxNGVkIGJ5IHRoZSB0dXBsZSBcKGUuZy4gYSBwb2ludGVyIHRvIGEgcHVibGlj bHkpLS4yMiBFCi0uMjIoYXYpNzIgNTMyIFMKKGFpbGFibGUgcmVmZXJlbmNlLWltcGxlbWVu dGF0aW9uIG9yIHRoZSBuYW1lIGFuZCBjb250YWN0cyBvZiBhIGNvbXBhbikKLS4wNTUgRSAy Ljc1KHl0KS0uMTY1IEcoaGF0IHNlbGxzIGl0LCBlaXRoZXIpLTIuNzUgRQooc2VwYXJhdGVs eSBvciBlbWJlZGRlZCBpbiBhbm90aGVyIHByb2R1Y3RcKS4pNzIgNTQ1IFEoIkZFQyBFbmNv ZGluZyBOYVwKbWVzIiBhcmUgbnVtZXJpYyBpZGVudGlcMjE0ZXJzIHNjb3BlZCBieSBhIEZF QyBFbmNvZGluZyBJZGVudGlcMjE0ZXIpNzIKNTcxIFEoLiktLjYwNSBFKFRoZSBGRUMgRW5j b2RpbmcgTmFtZSBNVVNUIGJlIHBhcnQgb2YgdGhlICJGRUMgT2JqZWN0IFQpCjcyIDU5NyBR KHJhbnNtaXNzaW9uIEluZm9ybWF0aW9uIiBhbmQpLS4zODUgRQoobXVzdCBiZSBjb21tdW5p Y2F0ZWQgdG8gcmVjZWkpNzIgNjEwIFEgLS4xNjUodmUpLS4yNzUgRwoocnMgdG9nZXRoZXIg d2l0aCB0aGUgRkVDIEVuY29kaW5nIElkZW50aVwyMTRlcikuMTY1IEUoLiktLjYwNSBFKERp Zik3Mgo2MzYgUQooZmVyZW50IEZFQyBzY2hlbWVzIHRoYXQgc2hhcmUgdGhlIHNhbWUgRkVD IEVuY29kaW5nIElkZW50aVwyMTRlciAtLSBiKQotLjI3NSBFKHV0IGhhKS0uMjIgRSAuMzMg LS4xNjUodmUgZCktLjIyIEgoaWYpLjE2NSBFKGZlcmVudCBGRUMpLS4yNzUgRQooRW5jb2Rp bmcgTmFtZXMgLS0gYWxzbyBzaGFyZSB0aGUgc2FtZSBmb3JtYXQgb2YgRkVDIFApNzIgNjQ5 IFEKKGF5bG9hZCBJRCBhbmQgRkVDIE9iamVjdCBUKS0uMTY1IEUocmFuc21pc3Npb24pLS4z ODUgRShJbmZvcm1hdGlvbi4pNzIKNjYyIFEoVGhpcyBzcGVjaVwyMTRjYXRpb24gcmVzZXJ2 KTcyIDY4OCBRCihlcyB0aGUgcmFuZ2UgMC0xMjcgb2YgRkVDIEVuY29kaW5nIElkZW50aVwy MTRlcnMgZm9yIGZ1bGx5LXNwZWNpXDIxNGVkKQotLjE2NSBFKGVuY29kaW5nIHNjaGVtZXMg YW5kIHRoZSByYW5nZSAxMjgtMjU1IGZvciB1bmRlcik3MiA3MDEgUQooLXNwZWNpXDIxNGVk IGVuY29kaW5nIHNjaGVtZXMuKS0uMjIgRShMdWJ5L1YpNzIgNzY5IFEKKGljaXNhbm8vR2Vt bWVsbC9SaXp6by9IYW5kbGUpLS42NiBFKHkvQ3JvKS0uMTY1IEUgMTA5LjEwNgood2Nyb2Z0 IFNlY3Rpb24pLS4yNzUgRiAyLjc1KDEuMS4gW1ApMi43NSBGKGFnZSAzXSktLjE2NSBFIEVQ CiUlUGFnZTogNCA0CiUlQmVnaW5QYWdlU2V0dXAKQlAKJSVFbmRQYWdlU2V0dXAKL0YwIDEx L1RpbWVzLVJvbWFuQDAgU0YoSU5URVJORVQpNzIgNDkgUSA3MS41ODcoLURSQUZUIEV4cGly ZXM6KS0xLjAxMiBGCihKYW51YXJ5IDIwMDIpMi43NSBFKEp1bHkgMjAwMSkxMjMuNzI2IEUv RjEgMTEvVGltZXMtQm9sZEAwIFNGKDEuMi4pNzIKODUgUS9GMiAxMy9UaW1lcy1Cb2xkQDAg U0YoRkVDIFApNS41IEUoYXlsb2FkIElEIGFuZCBGRUMgT2JqZWN0IFQpLS4xMyBFCihyYW5z bWlzc2lvbiBJbmYpLS45NjIgRShvcm1hdGlvbiktLjMyNSBFIEYwIDIuNzUoQWQpOTcgMTE0 LjYgUwoob2N1bWVudCB0aGF0IHNwZWNpXDIxNGVzIGFuIGVuY29kaW5nIHNjaGVtZSBhbmQg cmVzZXJ2KS0yLjc1IEUoZXMgYSB2KQotLjE2NSBFKGFsdWUgb2YgRkVDIEVuY29kaW5nKS0u Mjc1IEUoSWRlbnRpXDIxNGVyIE1VU1QgZGVcMjE0bmUgYSBwYWNrKQo3MiAxMjcuNiBRKGV0 LVwyMTRlbGQgZm9ybWF0IGZvciBGRUMgUCktLjExIEUKKGF5bG9hZCBJRCBhbmQgRkVDIE9i amVjdCBUKS0uMTY1IEUocmFuc21pc3Npb24pLS4zODUgRShJbmZvcm1hdGlvbiBhY2NcCm9y ZGluZyB0byB0aGUgbmVlZCBvZiB0aGUgZW5jb2Rpbmcgc2NoZW1lLiBUaGlzIGFsc28gYXBw bGllcyB0byBkb2N1bWVuXAp0cyB0aGF0KTcyIDE0MC42IFEocmVzZXJ2KTcyIDE1My42IFEo ZXMgdiktLjE2NSBFCihhbHVlcyBvZiBGRUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVycyBmb3Ig dW5kZXIpLS4yNzUgRQooLXNwZWNpXDIxNGVkIGVuY29kaW5nIHNjaGVtZXMuIEluIHRoaXMg Y2FzZSktLjIyIEUodGhlIEZFQyBPYmplY3QgVCk3MgoxNjYuNiBRKHJhbnNtaXNzaW9uIElu Zm9ybWF0aW9uIG11c3QgYWxzbyBpbmNsdWRlIGEgXDIxNGVsZCB0byBjb250YWluIFwKdGhl ICJGRUMgRW5jb2RpbmcpLS4zODUgRShOYW1lIi4pNzIgMTc5LjYgUSAyLjc1KEFwKTcyIDIw NS42IFMoYWNrKS0yLjc1CkUoZXQgXDIxNGVsZCBkZVwyMTRuaXRpb24gb2YgRkVDIE9iamVj dCBUKS0uMTEgRQoocmFuc21pc3Npb24gSW5mb3JtYXRpb24gTVVTVCBiZSBwcm8pLS4zODUg RSh2aWRlZCBkZXNwaXRlIHRoZSktLjE2NSBFCi0uMTEoZmEpNzIgMjE4LjYgUyhjdCB0aGF0 IGEgcHJvdG9jb2wgaW5zdGFudGlhdGlvbiBtYXkgZGVjaWRlIHRvIGNvbW11XApuaWNhdGUg dGhpcyBpbmZvcm1hdGlvbiBvdXQgb2YgYmFuZC4pLjExIEUoQWxsIHBhY2spNzIgMjQ0LjYg UQooZXQgXDIxNGVsZCBkZVwyMTRuaXRpb25zIFwoRkVDIFApLS4xMSBFKGF5bG9hZCBJRCBh bmQgRkVDIE9iamVjdCBUKQotLjE2NSBFKHJhbnNtaXNzaW9uIEluZm9ybWF0aW9uXCkgTVVT VCktLjM4NSBFCihiZSBmdWxseSBzcGVjaVwyMTRlZCBhdCB0aGUgbGUpNzIgMjU3LjYgUSAt LjE2NSh2ZSktLjI3NSBHIDIuNzUobG8pLjE2NQpHIDIuNzUoZmIpLTIuNzUgRyhpdC1cMjE0 ZWxkcyBhbmQgdGhlKS0yLjc1IEUgMi43NSh5bSktLjE2NSBHKHVzdCBoYSkKLTIuNzUgRSAu MzMgLS4xNjUodmUgYSBsKS0uMjIgSChlbmd0aCB0aGF0IGlzIGEgbXVsdGlwbGUgb2YgYSku MTY1IEUKKDQtYnl0ZSB3KTcyIDI3MC42IFEob3JkIFwodGhpcyBpcyB0byBmKS0uMTEgRQoo YWNpbGl0YXRlIHRoZSBhbGlnbm1lbnQgb2YgcGFjayktLjExIEUKKGV0IFwyMTRlbGRzIGlu IHByb3RvY29sIGluc3RhbnRpYXRpb25zXCkuKS0uMTEgRQooTm90ZSB0aGF0IHRoZSBzcGVj aVwyMTRjYXRpb24gb2YgRkVDIFApNzIgMjk2LjYgUShheWxvYWQgSUQgTVVTVCBhbGxvKQot LjE2NSBFIDIuNzUod2EpLS4yNzUgRyAyLjc1KG5pKS0yLjc1IEcobXBsZW1lbnRhdGlvbi1p bmRlcGVuZGVudCktMi43NQpFKGlkZW50aVwyMTRjYXRpb24gb2YgdGhlIHBhY2spNzIgMzA5 LjYgUShldCBwYXlsb2FkIGUpLS4xMSBFIC0uMTY1KHZlKQotLjI3NSBHIDIuNzUobmkpLjE2 NSBHIDIuNzUobnQpLTIuNzUgRyhoZSBjYXNlIG9mIFVuZGVyKS0yLjc1IEUKKC1TcGVjaVwy MTRlZCBlbmNvZGluZyBzY2hlbWVzLiktLjIyIEUgRjEoMi4pNzIgMzQ4LjYgUS9GMyAxNAov VGltZXMtQm9sZEAwIFNGKFByKTUuNSBFKGVhc3NpZ25lZCBGRUMgRW5jb2RpbmcgSWRlbnRp XDIxNGVycyktLjI1MiBFCkYwCihUaGlzIHNlY3Rpb24gc3BlY2lcMjE0ZXMgdGhlIEZFQyBF bmNvZGluZyBJZGVudGlcMjE0ZXIgYW5kIHRoZSByZWxhdGkpCjcyIDM2NS4yIFEgLjMzIC0u MTY1KHZlIHApLS4yNzUgSChhY2spLjE2NSBFCihldHMgXDIxNGVsZCBmb3IgYSBudW1iZXIg b2YpLS4xMSBFKGtubyk3MiAzNzguMiBRCih3biBzY2hlbWVzIHRoYXQgZm9sbG8pLS4yNzUg RSAyLjc1KHd1KS0uMjc1IEcobmRlciB0aGUgY2xhc3Mgb2YgdW5kZXIpCi0yLjc1IEUoLXNw ZWNpXDIxNGVkIEZFQyBzY2hlbWVzLiBPdGhlcnMgbWF5IGJlKS0uMjIgRQooc3BlY2lcMjE0 ZWQgaW4gY29tcGFuaW9uIGRvY3VtZW50cy4pNzIgMzkxLjIgUSBGMSgyLjEuKTcyIDQzMC4y IFEgRjIKKFNtYWxsIEJsb2NrLCBMYXIpNS41IEUoZ2UgQmxvY2sgYW5kIEV4cGFuZGFibGUg RkVDIENvZGVzKS0uMTMgRSBGMAooVGhpcyBzZWN0aW9uIHJlc2Vydik3MiA0NDYuOCBRCihl cyBhIEZFQyBFbmNvZGluZyBJZGVudGlcMjE0ZXIgZm9yIHRoZSBmKS0uMTY1IEUKKGFtaWxp ZXMgb2YgY29kZXMgZGVzY3JpYmVkIGluIFsxXSwgYW5kKS0uMTEgRShzcGVjaVwyMTRlcyB0 aGUgcmVsYXRpKTcyCjQ1OS44IFEgLjMzIC0uMTY1KHZlIHApLS4yNzUgSChhY2spLjE2NSBF KGV0IFwyMTRlbGRzLiktLjExIEUoVW5kZXIpNS41CkUoLXNwZWNpXDIxNGVkIEZFQyBzY2hl bWVzIHRoYXQgYmVsb25nIHRvIHRoaXMgY2xhc3MgTVVTVCktLjIyIEUKKHVzZSB0aGlzIGlk ZW50aVwyMTRlciBhbmQgcGFjayk3MiA0NzIuOCBRKGV0IFwyMTRlbGQgZGVcMjE0bml0aW9u cy4pCi0uMTEgRShUaGUgRkVDIEVuY29kaW5nIElkZW50aVwyMTRlciBmb3IgdW5kZXIgc3Bl Y2lcMjE0ZWQgY29kZXMgYXNzaWduXAplZCB0byBTbWFsbCBCbG9jaywgTGFyKTcyIDQ5OC44 IFEoZ2UgQmxvY2ssIGFuZCktLjE5OCBFCihFeHBhbmRhYmxlIEZFQyBDb2RlcyBpcyAxMjgu KTcyIDUxMS44IFEoVGhlIEZFQyBQKTcyIDUzNy44IFEoYXlsb2FkIElEXAogaXMgY29tcG9z ZWQgb2YgYW4gZW5jb2Rpbmcgc3ltYm9sIGlkZW50aVwyMTRlciBhbmQgYW4gZW5jb2Rpbmcg YmxvY2spCi0uMTY1IEUobnVtYmVyIHN0cnVjdHVyZWQgYXMgZm9sbG8pNzIgNTUwLjggUSh3 czopLS4yNzUgRS9GNCA4L0NvdXJpZXJAMApTRiA5MS4yKDAxMjMpNzYuOCA1ODkuOCBTIDQu OCgwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMSk3Ni44CjYwMi44IFMKKCstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rKTcyCjYxNS44IFEgMTAwLjgofGUpNzIgNjI4LjggUyhuY29kaW5nIGJsb2NrIG51 bWJlciktMTAwLjggRSh8KTEwMC44IEUKKCstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rKTcyCjY0MS44IFEgMTA1LjYo fGUpNzIgNjU0LjggUyhuY29kaW5nIHN5bWJvbCBJRCktMTA1LjYgRSh8KTExMC40IEUKKCst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rKTcyCjY2Ny44IFEvRjUgMTAvVGltZXMtUm9tYW5AMCBTRgooSW4gYWRkaXRp b24sIGEgb25lIGJpdCBGRUMgRW5jb2RpbmcgRmxhZyBNQSk3MiA3MDYuOCBRIDIuNShZYikt MS4wNSBHCjIuNShlaSktMi41IEcobmNsdWRlZCwgYW5kIHRoaXMgXDIxNWFnIGluZGljYXRl cyB3aGV0aGVyIHRoZSBlbmNvZGluZykKLTIuNSBFKHN5bWJvbFwoc1wpIGluIHRoZSBwYXls b2FkIG9mIHRoZSBwYWNrKTcyIDcxOS44IFEKKGV0IGFyZSBzb3VyY2Ugc3ltYm9sXChzXCkg b3IgcmVkdW5kYW50IHN5bWJvbFwoc1wpLiktLjEgRSBGMChMdWJ5L1YpNzIKNzY5IFEoaWNp c2Fuby9HZW1tZWxsL1JpenpvL0hhbmRsZSktLjY2IEUoeS9Dcm8pLS4xNjUgRSAxMDkuMTA2 Cih3Y3JvZnQgU2VjdGlvbiktLjI3NSBGIDIuNzUoMi4xLiBbUCkyLjc1IEYoYWdlIDRdKS0u MTY1IEUgRVAKJSVQYWdlOiA1IDUKJSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1 cAovRjAgMTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJB RlQgRXhwaXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEy My43MjYgRS9GMSAxMC9UaW1lcy1Sb21hbkAwIFNGCihUaGUgRkVDIE9iamVjdCBUKTcyIDg1 IFEocmFuc21pc3Npb24gSW5mb3JtYXRpb24gaGFzIHRoZSBmb2xsbyktLjM1IEUKKHdpbmcg c3RydWN0dXJlOiktLjI1IEUvRjIgOC9Db3VyaWVyQDAgU0YgOTEuMigwMTIzKTc2LjggMTI0 IFMgNC44CigwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMSk3Ni44IDEzNyBTCigr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKyk3MgoxNTAgUSAyOC44KHxGKTcyIDE2MyBTKEVDIEVuY29kaW5nIE5hbWUp LTI4LjggRSAyNCh8TykzOC40IEcKKGJqZWN0IExlbmd0aCBcKE1TQlwpKS0yNCBFKHwpMzMu NiBFCigrLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKyk3MgoxNzYgUSAxMDAuOCh8Tyk3MiAxODkgUyhiamVjdCBMZW5n dGggXChMU0JcKSktMTAwLjggRSh8KTExMC40IEUKKCstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rKTcyCjIwMiBRIDEw MC44KHxTKTcyIDIxNSBTKG91cmNlIEJsb2NrIExlbmd0aCktMTAwLjggRSh8KTExMC40IEUK KCstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rKTcyCjIyOCBRIEYxKE5vdGUgdGhhdCB0aGlzIHN0cnVjdHVyZSBsaW1p dHMgdGhlIHJhbmdlIG9mIHBvc3NpYmxlIEZFQyBFbmNvXApkaW5nIE5hbWVzIHRvIDAtOi02 NTUzNiwgZGVzcGl0ZSB0aGUgZik3MiAyNjcgUShhY3QgdGhhdCktLjEgRQoodGhlIEZFQyBP YmplY3QgVCk3MiAyODAgUQoocmFuc21pc3Npb24gSW5mb3JtYXRpb24gY2FuIGFsc28gYmUg dHJhbnNtaXR0ZWQgb3V0IG9mIGJhbmQuKS0uMzUgRShUaFwKZSBPYmplY3QgTGVuZ3RoLCBj b21wb3NlZCBvZiBhIE1vc3QgU2lnbmlcMjE0Y2FudCBCeXRlcyBwb3J0aW9uIFwoTVNCXClc CiBhbmQgYSBMZWFzdCBTaWduaVwyMTRjYW50IEJ5dGVzKTcyIDMwNiBRKHBvcnRpb24gXChM U0JcKSwgaXMgZSk3MiAzMTkgUQooeHByZXNzZWQgaW4gYnl0ZXMuKS0uMTUgRS9GMyAxMS9U aW1lcy1Cb2xkQDAgU0YoMi4yLik3MiAzNTggUS9GNCAxMwovVGltZXMtQm9sZEAwIFNGKFNt YWxsIEJsb2NrIFN5c3RlbWF0aWMgRkVDIENvZGVzKTUuNSBFIEYwKFRoZSBmb2xsbyk3Mgoz NzQuNiBRKHdpbmcgZGVcMjE0bml0aW9ucyBhcHBseSB0byBzeXN0ZW1hdGljIGNvZGVzIG9m IHNtYWxsIGxlbmd0aCBcKFwKdG90YWwgYmxvY2sgbGVuZ3RoIDwgMl4xNlwpLiktLjI3NSBF KFRoZSBGRUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVyIGZvciBcCnVuZGVyIHNwZWNpXDIxNGVk IGNvZGVzIGFzc2lnbmVkIHRvIFNtYWxsIEJsb2NrIFN5c3RlbWF0aWMgRkVDKTcyIDQwMC42 ClEoQ29kZXMgaXMgMTI5Lik3MiA0MTMuNiBRKEFsdGhvdWdoIHRoZXNlIGNvZGVzIGNhbiBn ZW5lcmFsbHkgYmUgYWNjb21tXApvZGF0ZWQgYnkgdGhlIEZFQyBFbmNvZGluZyBJZGVudGlc MjE0ZXIgZGVzY3JpYmVkKTcyIDQzOS42IFEoaW4gU2VjdGlvblwKIDIuMSwgYSBzcGVjaVwy MTRjIEVuY29kaW5nLUlEIGlzIGRlXDIxNG5lZCBmb3Igc3lzdGVtYXRpYyBjb2RlcyB0byBh bGxcCm8pNzIgNDUyLjYgUSAyLjc1KHdiKS0uMjc1IEcoZXR0ZXIgXDIxNWUpLTIuNzUgRSh4 aWJpbGl0eSktLjE2NSBFKGFuZCB0XApvIHJldGFpbiBoZWFkZXIgY29tcGFjdG5lc3MuIFRo ZSBzbWFsbCBzb3VyY2UgYmxvY2sgbGVuZ3RoIGFuZCBzbWFsbCBlKQo3MiA0NjUuNiBRKHhh cGFuc2lvbiBmKS0uMTY1IEUoYWN0b3IgdGhhdCktLjExIEUob2Z0ZW4gY2hhcmFjdGVyaXpl IHN5c1wKdGVtYXRpYyBjb2RlcyBtYXkgcmVxdWlyZSB0aGF0IHRoZSBkYXRhIHNvdXJjZSBj aGFuZ2VzIGZyZXF1ZW50bHkgdGhlKTcyCjQ3OC42IFEoc291cmNlIGJsb2NrIGxlbmd0aC4g VCk3MiA0OTEuNiBRIDIuNzUob2EpLS44OCBHKGxsbyktMi43NSBFCjIuNzUod3QpLS4yNzUg RyhoZSBkeW5hbWljIHYpLTIuNzUgRQooYXJpYXRpb24gb2YgdGhlIHNvdXJjZSBibG9jayBs ZW5ndGggYW5kIHRvKS0uMjc1IEUKKGNvbW11bmljYXRlIGl0IHRvIHRoZSByZWNlaSk3MiA1 MDQuNiBRIC0uMTY1KHZlKS0uMjc1IEcocnMgd2l0aCBsbykuMTY1CkUgMi43NSh3byktLjI3 NSBHIC0uMTY1KHZlKS0yLjkxNSBHCihyaGVhZCwgdGhlIGJsb2NrIGxlbmd0aCBpcyBpbmNs dWRlZCBpbiB0aGUgRkVDKS4xNjUgRSAtLjE2NShQYSk3MiA1MTcuNgpTKHlsb2FkIElELiku MTY1IEUoVGhlIEZFQyBQKTcyIDU0My42IFEKKGF5bG9hZCBJRCBpcyBjb21wb3NlZCBvZiB0 aGUgZW5jb2RpbmcgYmxvY2sgbnVtYmVyKS0uMTY1IEUgMi43NSgsdCktLjQ0CkcoaGUgZW5j b2Rpbmcgc3ltYm9sIGlkZW50aVwyMTRlciktMi43NSBFKGFuZCB0aGUgYmxvY2sgbGVuZ3Ro Oik3MiA1NTYuNgpRIEYyIDkxLjIoMDEyMyk3Ni44IDU5NS42IFMgNC44KDAxMjM0NTY3ODkw MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxKTc2LjgKNjA4LjYgUwooKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSspNzIKNjIx LjYgUSA5Nih8ZSk3MiA2MzQuNiBTKG5jb2RpbmcgYmxvY2sgbnVtYmVyKS05NiBFKHwpMTA1 LjYgRQooKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSspNzIKNjQ3LjYgUSAyOC44KHxTKTcyIDY2MC42IFMob3VyY2Ug YmxvY2sgbGVuZ3RoKS0yOC44IEUgMzMuNih8ZSkyOC44IEcKKG5jb2Rpbmcgc3ltYm9sIElE KS0zMy42IEUofCkyOC44IEUKKCstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rKTcyCjY3My42IFEgRjEoVGhlIEZFQyBP YmplY3QgVCk3MiA3MTIuNiBRCihyYW5zbWlzc2lvbiBJbmZvcm1hdGlvbiwgd2hlbiB1c2Vk LCBoYXMgdGhlIGZvbGxvKS0uMzUgRQood2luZyBzdHJ1Y3R1cmU6KS0uMjUgRSBGMChMdWJ5 L1YpNzIgNzY5IFEoaWNpc2Fuby9HZW1tZWxsL1JpenpvL0hhbmRsZSkKLS42NiBFKHkvQ3Jv KS0uMTY1IEUgMTA5LjEwNih3Y3JvZnQgU2VjdGlvbiktLjI3NSBGIDIuNzUoMi4yLiBbUCky Ljc1IEYKKGFnZSA1XSktLjE2NSBFIEVQCiUlUGFnZTogNiA2CiUlQmVnaW5QYWdlU2V0dXAK QlAKJSVFbmRQYWdlU2V0dXAKL0YwIDExL1RpbWVzLVJvbWFuQDAgU0YoSU5URVJORVQpNzIg NDkgUSA3MS41ODcoLURSQUZUIEV4cGlyZXM6KS0xLjAxMiBGCihKYW51YXJ5IDIwMDIpMi43 NSBFKEp1bHkgMjAwMSkxMjMuNzI2IEUvRjEgOC9Db3VyaWVyQDAgU0YgOTEuMigwMTIzKQo3 Ni44IDg1IFMgNC44KDAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxKTc2LjggOTgg UwooKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSspNzIKMTExIFEgMjguOCh8Rik3MiAxMjQgUyhFQyBFbmNvZGluZyBO YW1lKS0yOC44IEUgOS42KHxOKTM4LjQgRwoodW1iZXIgb2YgcmVkdW5kYW50IHN5bWJvbHMp LTkuNiBFKHwpOS42IEUKKCstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rKTcyCjEzNyBRL0YyIDEwL1RpbWVzLVJvbWFu QDAgU0YoV2hlbiB2KTcyIDE3NiBRKGFyaWFibGUgYmxvY2stbGVuZ3RoIGlzIHVzXAplZCwg dGhlIG51bWJlciBvZiByZWR1bmRhbnQgc3ltYm9scyBpcyB0byBiZSBpbnRlcnByZXRlZCBh cyBhIG1heGltdW0pCi0uMjUgRSAtLjI1KHZhKTcyIDE4OSBTKGx1ZSBcKHVwcGVyIGJvdW5k XCkuIFRoaXMgXDIxNGVsZCBpcyBwcm8pLjI1IEUKKHZpZGVkIGFzIGFuIGluZGljYXRpb24g dG8gYWxsbyktLjE1IEUgMi41KHdyKS0uMjUgRyhlY2VpKS0yLjUgRSAtLjE1Cih2ZSktLjI1 IEcgMi41KHN0KS4xNSBHIDIuNShvcCktMi41IEcocmVhbGxvY2F0ZSBhIGRlY29kZXIpLTIu NSBFCihzdWl0YWJsZSBmb3IgYWxsIHRoZSBvYmplY3QgYmxvY2tzLik3MiAyMDIgUShOb3Rl IHRoYXQgdGhpcyBzdHJ1Y3R1cmUgXApsaW1pdHMgdGhlIHJhbmdlIG9mIHBvc3NpYmxlIEZF QyBFbmNvZGluZyBOYW1lcyB0byAwLTotNjU1MzYsIGRlc3BpdGUgdFwKaGUgRkVDKTcyIDIy OCBRKE9iamVjdCBUKTcyIDI0MSBRCihyYW5zbWlzc2lvbiBJbmZvcm1hdGlvbiBjYW4gYWxz byBiZSB0cmFuc21pdHRlZCBvdXQgb2YgYmFuZC4pLS4zNSBFL0YzCjExL1RpbWVzLUJvbGRA MCBTRigzLik3MiAyODAgUS9GNCAxNC9UaW1lcy1Cb2xkQDAgU0YoSUFOKTUuNSBFIDMuNShB QykKLS4yOCBHKG9uc2lkZXJhdGlvbnMpLTMuNSBFIEYwIC0xLjIyMShWYSk3MiAyOTYuNiBT KGx1ZXMgb2YgRkVDIEVuY29kaW5cCmcgSWRlbnRpXDIxNGVycyBhbmQgRkVDIEVuY29kaW5n IE5hbWVzIGFyZSBzdWJqZWN0IHRvIElBTikxLjIyMSBFIDIuNzUKKEFyKS0uMzg1IEcgLS4x NjUoZWcpLTIuNzUgRyhpc3RyYXRpb24uKS4xNjUgRShGRUMgRW5jb2RpbmcgSWRlbnRpXDIx NGVcCnJzIGFuZCBGRUMgRW5jb2RpbmcgTmFtZXMgYXJlIGhpZXJhcmNoaWNhbDogRkVDIEVu Y29kaW5nIElkZW50aVwyMTRlcnMpCjcyIDMwOS42IFEoXChhdCB0aGUgdG9wIGxlKTcyIDMy Mi42IFEgLS4xNjUodmUpLS4yNzUgRyhsXCkgc2NvcGUgcmFuZ2VzXAogb2YgRkVDIEVuY29k aW5nIE5hbWVzLiBOb3QgYWxsIEZFQyBFbmNvZGluZyBJZGVudGlcMjE0ZXJzIGhhKS4xNjUg RSAuMzMKLS4xNjUodmUgYSktLjIyIEgoY29ycmVzcG9uZGluZyBGRUMgRW5jb2RpbmcgTmFt ZSBzY29wZSBcKHNlZSBiZWxvKTcyCjMzNS42IFEod1wpLiktLjI3NSBFIDIuNzUoQUYpNzIg MzYxLjYgUwooRUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVyIGlzIGEgbnVtZXJpYyBub24tbmUp LTIuNzUgRSAtLjA1NShnYSktLjE2NSBHCih0aSkuMDU1IEUgLjMzIC0uMTY1KHZlIGkpLS4y NzUgSChuZGUpLjE2NSBFKHguIFYpLS4xNjUgRQooYWx1ZSBmcm9tIDAgdG8gMTI3IGFyZSBy ZXNlcnYpLTEuMjIxIEUoZWQgZm9yKS0uMTY1IEUoRkVDIGVuY29kZXJzIHRoYVwKdCBhcmUg ZnVsbHkgc3BlY2lcMjE0ZWQsIGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDMuMS4gVGhlIGFz c2lnbm1lbnQgb2ZcCiBhIEZFQyk3MiAzNzQuNiBRKEVuY29kaW5nIElkZW50aVwyMTRlciBp biB0aGlzIHJhbmdlIGNhbiBvbmx5IGJlIGdyYW50XAplZCBpZiB0aGUgcmVxdWVzdG9yIGNh biBwcm8pNzIgMzg3LjYgUSh2aWRlIHN1Y2ggYSktLjE2NSBFCihzcGVjaVwyMTRjYXRpb24g cHVibGlzaGVkIGFzIGFuIElFVEYgUkZDLiBWKTcyIDQwMC42IFEKKGFsdWVzIGdyZWF0ZXIg dGhhbiAxMjcgY2FuIGJlIGFzc2lnbmVkIHRvIHVuZGVyKS0xLjIyMSBFKC0pLS4yMiBFKHNw ZWNcCmlcMjE0ZWQgZW5jb2Rpbmcgc2NoZW1lcy4gTm90ZTogdGhpcyBzcGVjaVwyMTRjYXRp b24gYWxyZWFkeSBhc3NpZ25zIHRoXAplIHYpNzIgNDEzLjYgUShhbHVlcyAxMjggYW5kIDEy OS4pLS4yNzUgRShJbiBhbik3MiA0MzkuNiBRIDIuNzUoeWMpLS4xNjUKRyhhc2UgdiktMi43 NSBFKGFsdWVzIG9mIEZFQyBFbmNvZGluZyBJZGVudGlcMjE0ZXJzIGNhbiBvbmx5IGJlIGFz c2lnbmVcCmQgaWYgdGhlIHJlcXVpcmVkIEZFQyBwYWNrKS0uMjc1IEUoZXQpLS4xMSBFKFwy MTRlbGRzIGNvcnJlc3BvbmRpbmcgdG8gXAppdCBcKHNlZSBzZWN0aW9uIDEuMlwpIGFyZSBz cGVjaVwyMTRlZCBpbiBhIFJGQy4pNzIgNDUyLjYgUQooRWFjaCBGRUMgRW5jb2RpbmcgSWRl bnRpXDIxNGVyIGFzc2lnbmVkIHRvIGFuIHVuZGVyKTcyIDQ3OC42IFEKKC1zcGVjaVwyMTRl ZCBlbmNvZGluZyBzY2hlbWUgc2NvcGVzIGFuKS0uMjIgRQooaW5kZXBlbmRlbnQgcmFuZ2Ug b2YgRkVDIEVuY29kaW5nIE5hbWVzIFwoaS5lLiB0aGUgc2FtZSB2KTcyIDQ5MS42IFEKKGFs dWUgb2YgRkVDIEVuY29kaW5nIE5hbWUgY2FuIGJlKS0uMjc1IEUocmV1c2VkIGZvciBkaWYp NzIgNTA0LjYgUShmZXJcCmVudCBGRUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVyc1wpLiBBbiBG RUMgRW5jb2RpbmcgTmFtZSBpcyBhIG51bWVyaWMgbm9uXAotKS0uMjc1IEUobmUpNzIgNTE3 LjYgUSAtLjA1NShnYSktLjE2NSBHKHRpKS4wNTUgRSAuMzMgLS4xNjUodmUgaSktLjI3NQpI KG5kZSkuMTY1IEUoeC4gVGhlIGRvY3VtZW50IHRoYXQgcmVzZXJ2KS0uMTY1IEUKKGVzIGEg RkVDIEVuY29kaW5nIElkZW50aVwyMTRlciBNQSktLjE2NSBFIDIuNzUoWWEpLTEuMTU1IEcK KGxzbyBzcGVjaWZ5IGEgcmFuZ2UpLTIuNzUgRShmb3IgdGhlIHN1Ym9yZGluYXRlIEZFQyBF bmNvZGluZyBOYW1lcy4pNzIKNTMwLjYgUShVbmRlciB0aGUgc2NvcGUgb2YgYSBGRUMgRW5j b2RpbmcgSWRlbnRpXDIxNGVyKTcyIDU1Ni42IFEgMi43NQooLEYpLS40NCBHKEVDIEVuY29k aW5nIE5hbWVzIGFyZSBhc3NpZ25lZCBvbiBhIEZpcnN0KS0yLjc1IEUKKENvbWUgRmlyc3Qg U2Vydik3MiA1NjkuNiBRKGVkIGJhc2UgdG8gcmVxdWVzdG9ycyB0aGF0IGFyZSBhYmxlIHRv IHBybykKLS4xNjUgRSh2aWRlIHBvaW50IG9mIGNvbnRhY3QgaW5mb3JtYXRpb24gYW5kIGEp LS4xNjUgRShwb2ludGVyIHRvIHB1YmxcCmljbHkgYWNjZXNzaWJsZSBkb2N1bWVudGF0aW9u IGRlc2NyaWJpbmcgdGhlIEZFQyBzY2hlbWUgYW5kIHcpNzIgNTgyLjYgUQooYXlzIHRvIG9i dGFpbiBpdCktLjExIEUoXChlLmcuIGEgcG9pbnRlciB0byBhIHB1YmxpY2x5IGEpNzIgNTk1 LjYgUQotLjI3NSh2YSktLjIyIEcKKGlsYWJsZSByZWZlcmVuY2UtaW1wbGVtZW50YXRpb24g b3IgdGhlIG5hbWUgYW5kIGNvbnRhY3RzIG9mIGEpLjI3NSBFCihjb21wYW4pNzIgNjA4LjYg USAyLjc1KHl0KS0uMTY1IEcoaGF0IHNlbGxzIGl0LCBlaXRoZXIgc2VwYXJhdGVseSBvciBl XAptYmVkZGVkIGluIGFub3RoZXIgcHJvZHVjdFwpLiBUaGUgcmVxdWVzdG9yIGlzKS0yLjc1 IEUKKHJlc3BvbnNpYmxlIGZvciBrKTcyIDYyMS42IFEoZWVwaW5nIHRoaXMgaW5mb3JtYXRp b24gdXAgdG8gZGF0ZS4pLS4xMSBFCkYzKDQuKTcyIDY2MC42IFEgRjQoQWNrbm8pNS41IEUo d2xlZGdtZW50cyktLjE0IEUgRjAKKEJyaWFuIEFkYW1zb24gY29udHJpYik3MiA2NzcuMiBR Cih1dGVkIHRvIHRoaXMgZG9jdW1lbnQgYnkgc2hhcGluZyBTZWN0aW9uIDIuMiBhbmQgcHJv KS0uMjIgRQoodmlkaW5nIGdlbmVyYWwpLS4xNjUgRShmZWVkYmFjay4gVyk3MiA2OTAuMiBR IDIuNzUoZWEpLS44OCBHCihsc28gd2lzaCB0byB0aGFuayBWKS0yLjc1IEUoaW5jZW50IFJv Y2EgZm9yIGhpcyBjb21tZW50cy4pLS42NiBFCihMdWJ5L1YpNzIgNzY5IFEoaWNpc2Fuby9H ZW1tZWxsL1JpenpvL0hhbmRsZSktLjY2IEUoeS9Dcm8pLS4xNjUgRQoxMTcuMzU2KHdjcm9m dCBTZWN0aW9uKS0uMjc1IEYgMi43NSg0LiBbUCkyLjc1IEYoYWdlIDZdKS0uMTY1IEUgRVAK JSVQYWdlOiA3IDcKJSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTEv VGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhwaXJl czopLTEuMDEyIEYKKEphbnVhcnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEyMy43MjYgRS9G MSAxMS9UaW1lcy1Cb2xkQDAgU0YoNS4pNzIgODUKUS9GMiAxNC9UaW1lcy1Cb2xkQDAgU0Yo UmVmZXIpNS41IEUoZW5jZXMpLS4yNTIgRSBGMChbMV0gTHVieSk3MiAxMTQuNiBRCjIuNzUo LE0pLS43MTUgRyguLCBWKS0yLjc1IEUKKGljaXNhbm8sIEdlbW1lbGwsIEouLCBMLiwgUml6 em8sIEwuLCBIYW5kbGUpLS42NiBFIDEuNDMgLS43MTUoeSwgTSkKLS4xNjUgSCAyLjc1KC4s IENybykuNzE1IEYod2Nyb2Z0LCBKLiwgIlRoZSB1c2Ugb2YpLS4yNzUgRSAtLjE2NShGbyk3 MgoxMjcuNiBTKHJ3KS4xNjUgRShhcmQgRXJyb3IgQ29ycmVjdGlvbiBpbiBSZWxpYWJsZSBN dWx0aWNhc3QiLCBJbnRlcm5ldFwKIGRyYWZ0IGRyYWZ0LWlldGYtcm10LWluZm8tZmVjLTAw LnR4dCwpLS4xMSBFKE5vKTcyIDE0MC42IFEgLS4xNjUodmUpCi0uMTY1IEcobWJlciAyMDAw LikuMTY1IEUgRjEoNi4pNzIgMTc5LjYgUSBGMiAtLjcoQXUpNS41IEcodGhvcnMnIEFkZHIp Ci43IEUoZXNzZXMpLS4yNTIgRSBGMChNaWNoYWVsIEx1YnkpODAuMjUgMTk2LjIgUQoobHVi eUBkaWdpdGFsZm91bnRhaW4uY29tKTgwLjI1IDIwOS4yIFEoRGlnaXRhbCBGKTgwLjI1IDIy Mi4yIFEKKG91bnRhaW4sIEluYy4pLS4xNjUgRSgzOTE0MSBDaSk4MC4yNSAyMzUuMiBRKHZp YyBDZW50ZXIgRHJpKS0uMjc1IEUKLS4xNjUodmUpLS4yNzUgRyhTdWl0ZSAzMDApODAuMjUg MjQ4LjIgUShGcmVtb250LCBDQSk4MC4yNSAyNjEuMiBRCig5NDUzOCk1LjUgRShMb3Jlbnpv IFYpODAuMjUgMjg3LjIgUShpY2lzYW5vKS0uNjYgRShsb3JlbnpvQGNpc2NvLmNvbSkKODAu MjUgMzAwLjIgUShjaXNjbyBTeXN0ZW1zLCBJbmMuKTgwLjI1IDMxMy4yIFEoMTcwIFcpODAu MjUgMzI2LjIgUQooZXN0IFQpLS44OCBFKGFzbWFuIERyKS0uODggRSguLCktLjYwNSBFKFNh biBKb3NlLCBDQSwgVVNBLCA5NTEzNCk4MC4yNQozMzkuMiBRKEppbSBHZW1tZWxsKTgwLjI1 IDM2NS4yIFEoamdlbW1lbGxAbWljcm9zb2Z0LmNvbSk4MC4yNSAzNzguMiBRCihNaWNyb3Nv ZnQgUmVzZWFyY2gpODAuMjUgMzkxLjIgUSgzMDEgSG8pODAuMjUgNDA0LjIgUSAtLjExKHdh KS0uMjc1IEcKKHJkIFN0LiwgIzgzMCkuMTEgRShTYW4gRnJhbmNpc2NvLCBDQSwgVVNBLCA5 NDEwNSk4MC4yNSA0MTcuMiBRCihMdWlnaSBSaXp6byk4MC4yNSA0NDMuMiBRKGx1aWdpQGll dC51bmlwaS5pdCk4MC4yNSA0NTYuMiBRIC0uNDQoQUMpCjgwLjI1IDQ2OS4yIFMoSVJJLCAx OTQ3IENlbnRlciBTdC4sIEJlcmspLjQ0IEUoZWxlKS0uMTEgRSAyLjc1KHlDKS0uMTY1Ckcg Mi43NShBOSktMi43NSBHKDQ3MDQpLTIuNzUgRShhbmQpODAuMjUgNDgyLjIgUQooRGlwLiBk aSBJbmcuIGRlbGwnSW5mb3JtYXppb25lKTgwLjI1IDQ5NS4yIFEoVW5pKTgwLjI1IDUwOC4y IFEgLS4xNjUKKHZlKS0uMjc1IEcocnNpdGFgIGRpIFBpc2EpLjE2NSBFKHZpYSBEaW90aXNh bHZpIDIsIDU2MTI2IFBpc2EsIEl0YWx5KQo4MC4yNSA1MjEuMiBRKE1hcmsgSGFuZGxlKTgw LjI1IDU0Ny4yIFEoeSktLjE2NSBFKG1qaEBhY2lyaS5vcik4MC4yNQo1NjAuMiBRKGcpLS4x OTggRSAtLjQ0KEFDKTgwLjI1IDU3My4yIFMoSVJJKS40NCBFKDE5NDcgQ2VudGVyIFN0Lik4 MC4yNQo1ODYuMiBRKEJlcmspODAuMjUgNTk5LjIgUShlbGUpLS4xMSBFIDIuNzUoeUMpLS4x NjUgRyhBLCBVU0EsIDk0NzA0KQotMi43NSBFKEpvbiBDcm8pODAuMjUgNjI1LjIgUSh3Y3Jv ZnQpLS4yNzUgRShKLkNybyk4MC4yNSA2MzguMiBRCih3Y3JvZnRAY3MudWNsLmFjLnVrKS0u Mjc1IEUoRGVwYXJ0bWVudCBvZiBDb21wdXRlciBTY2llbmNlKTgwLjI1IDY1MS4yClEoVW5p KTgwLjI1IDY2NC4yIFEgLS4xNjUodmUpLS4yNzUgRyhyc2l0eSBDb2xsZSkuMTY1IEUoZ2Ug TG9uZG9uKS0uMTY1CkUoR28pODAuMjUgNjc3LjIgUSh3ZXIgU3RyZWV0LCktLjI3NSBFKExv bmRvbiBXQzFFIDZCVCk4MC4yNSA2OTAuMiBRCjIuNzUoLFUpLS44MTQgRyhLKS0yLjc1IEUo THVieS9WKTcyIDc2OSBRKGljaXNhbm8vR2VtbWVsbC9SaXp6by9IYW5kbGUpCi0uNjYgRSh5 L0NybyktLjE2NSBFIDExNy4zNTYod2Nyb2Z0IFNlY3Rpb24pLS4yNzUgRiAyLjc1KDYuIFtQ KTIuNzUgRgooYWdlIDddKS0uMTY1IEUgRVAKJSVQYWdlOiA4IDgKJSVCZWdpblBhZ2VTZXR1 cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3 MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhwaXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMiky Ljc1IEUoSnVseSAyMDAxKTEyMy43MjYgRS9GMSAxMS9UaW1lcy1Cb2xkQDAgU0YoNy4pNzIg ODUKUS9GMiAxNC9UaW1lcy1Cb2xkQDAgU0YoRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50KTUu NSBFIEYwKENvcCk3MiAxMDEuNiBRCih5cmlnaHQgXChDXCkgVGhlIEludGVybmV0IFNvY2ll dHkgXCgyMDAwXCkuKS0uMTEgRShBbGwgUmlnaHRzIFJlc2VydikKNS41IEUoZWQuKS0uMTY1 IEUoVGhpcyBkb2N1bWVudCBhbmQgdHJhbnNsYXRpb25zIG9mIGl0IG1heSBiZSBjb3BpZWQg YW5cCmQgZnVybmlzaGVkIHRvIG90aGVycywgYW5kIGRlcmkpNzIgMTE4LjIgUSAtLjI3NSh2 YSktLjI3NSBHKHRpKS4yNzUgRQouMzMgLS4xNjUodmUgdyktLjI3NSBIKG9ya3MpLjA1NSBF KHRoYXQgY29tbWVudCBvbiBvciBvdGhlcndpc2UgZSk3MgoxMzEuMiBRCih4cGxhaW4gaXQg b3IgYXNzaXN0IGluIGl0cyBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQsIGNvcGll ZCwpCi0uMTY1IEUocHVibGlzaGVkIGFuZCBkaXN0cmliKTcyIDE0NC4yIFEKKHV0ZWQsIGlu IHdob2xlIG9yIGluIHBhcnQsIHdpdGhvdXQgcmVzdHJpY3Rpb24gb2YgYW4pLS4yMiBFIDIu NzUoeWspCi0uMTY1IEcoaW5kLCBwcm8pLTIuNzUgRSh2aWRlZCB0aGF0IHRoZSktLjE2NSBF KGFibyk3MiAxNTcuMiBRIC4zMyAtLjE2NQoodmUgYyktLjE2NSBIKG9wKS4xNjUgRSh5cmln aHQgbm90aWNlIGFuZCB0aGlzIHBhcmFncmFwaCBhcmUgaW5jbHVkZWQgb1wKbiBhbGwgc3Vj aCBjb3BpZXMgYW5kIGRlcmkpLS4xMSBFIC0uMjc1KHZhKS0uMjc1IEcodGkpLjI3NSBFIC4z MyAtLjE2NQoodmUgdyktLjI3NSBIKG9ya3MuKS4wNTUgRShIbyk3MiAxNzAuMiBRKHdlKS0u Mjc1IEUgLS4xNjUodmUpLS4yNzUgRyAuODgKLS40NChyLCB0KS4xNjUgSChoaXMgZG9jdW1l bnQgaXRzZWxmIG1heSBub3QgYmUgbW9kaVwyMTRlZCBpbiBhbikuNDQgRQoyLjc1KHl3KS0u MTY1IEcoYXkpLTIuODYgRSAyLjc1KCxzKS0uNzE1IEcodWNoIGFzIGJ5IHJlbW8pLTIuNzUg RQoodmluZyB0aGUpLS4xNjUgRShjb3ApNzIgMTgzLjIgUSh5cmlnaHQgbm90aWNlIG9yIHJl ZmVyZW5jZXMgdG8gdGhlIEludFwKZXJuZXQgU29jaWV0eSBvciBvdGhlciBJbnRlcm5ldCBv ciktLjExIEUgLS4wNTUoZ2EpLS4xOTggRyhuaXphdGlvbnMsIGUpCi4wNTUgRSh4Y2VwdCBh cyktLjE2NSBFKG5lZWRlZCBmb3IgdGhlIHB1cnBvc2Ugb2YgZGUpNzIgMTk2LjIgUSAtLjE2 NQoodmUpLS4yNzUgRyhsb3BpbmcgSW50ZXJuZXQgc3RhbmRhcmRzIGluIHdoaWNoIGNhc2Ug dGhlIHByb2NlZHVyZXMgZm9yKQouMTY1IEUoY29wKTcyIDIwOS4yIFEKKHlyaWdodHMgZGVc MjE0bmVkIGluIHRoZSBJbnRlcm5ldCBsYW5ndWFnZXMgb3RoZXIgdGhhbiBFbmdsaXNoLikt LjExIEUKKFRoZSBsaW1pdGVkIHBlcm1pc3Npb25zIGdyYW50ZWQgYWJvKTcyIDIyNS44IFEg LjMzIC0uMTY1KHZlIGEpLS4xNjUgSAoocmUgcGVycGV0dWFsIGFuZCB3aWxsIG5vdCBiZSBy ZSkuMTY1IEUgLS4yMih2byktLjI3NSBHIC0uMTEoa2UpLjIyIEcKMi43NShkYikuMTEgRyAy Ljc1KHl0KS0yLjc1IEcoaGUgSW50ZXJuZXQpLTIuNzUgRQooU29jaWV0eSBvciBpdHMgc3Vj Y2Vzc29ycyBvciBhc3NpZ25zLik3MiAyMzguOCBRCihUaGlzIGRvY3VtZW50IGFuZCB0aGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyBwcm8pNzIgMjU1LjQgUQoodmlkZWQg b24gYW4gIkFTIElTIiBiYXNpcyBhbmQgVEhFKS0uMTY1IEUKKElOVEVSTkVUIFNPQ0lFVFkg QU5EIFRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyBUKTcyIDI2OC40IFEKKEFTSyBGT1JDRSBE SVNDTEFJTVMpLTEuMDIzIEUoQUxMIFcpNzIgMjgxLjQgUQooQVJSQU5USUVTLCBFWFBSRVNT IE9SIElNUExJRUQsIElOQ0xVRElORyBCKS0xLjMyIEUoVVQgTk8pLS4xMSBFIDIuNzUKKFRM KS0uNDQgRyhJTUlURUQgVCktMi43NSBFIDIuNzUoT0EpLS4xOTggRyhOWSktMi43NSBFIC0x LjMyKFdBKTcyIDI5NC40ClMoUlJBTlRZIFRIQSkxLjMyIEUgMi43NShUVCktMS4yMjEgRyhI RSBVU0UgT0YgVEhFIElORk9STUEpLTIuNzUgRQooVElPTiBIRVJFSU4gV0lMTCBOTyktMS4y MjEgRSAyLjc1KFRJKS0uNDQgRyhORlJJTkdFKS0yLjc1IEUKKEFOWSBSSUdIVFMgT1IgQU5Z IElNUExJRUQgVyk3MiAzMDcuNCBRKEFSUkFOVElFUyBPRiBNRVJDSEFOVCktMS4zMiBFCihB QklMSVRZIE9SIEZJVE5FU1MpLTEuMDIzIEUoRk9SIEEgUCk3MiAzMjAuNCBRKEFSKS0xLjAx MiBFCihUSUNVTEFSIFBVUlBPU0UuIiktLjY2IEUoTHVieS9WKTcyIDc2OSBRKGljaXNhbm8v R2VtbWVsbC9SaXp6by9IYW5kbGUpCi0uNjYgRSh5L0NybyktLjE2NSBFIDExNy4zNTYod2Ny b2Z0IFNlY3Rpb24pLS4yNzUgRiAyLjc1KDcuIFtQKTIuNzUgRgooYWdlIDhdKS0uMTY1IEUg RVAKJSVQYWdlOiA5IDkKJSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAg MTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhw aXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEyMy43MjYg RShMdWJ5L1YpNzIgNzY5IFEKKGljaXNhbm8vR2VtbWVsbC9SaXp6by9IYW5kbGUpLS42NiBF KHkvQ3JvKS0uMTY1IEUgMTE3LjM1Ngood2Nyb2Z0IFNlY3Rpb24pLS4yNzUgRiAyLjc1KDcu IFtQKTIuNzUgRihhZ2UgOV0pLS4xNjUgRSBFUAolJVRyYWlsZXIKZW5kCiUlRU9GCg== --==_Exmh_5297534880-- >From owner-rmt@listserv.lbl.gov Fri Jul 20 08:52:24 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6KFpOD18179; Fri, 20 Jul 2001 08:51: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 (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6KFpNR18175 for ; Fri, 20 Jul 2001 08:51:23 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6KFpMj11702 for ; Fri, 20 Jul 2001 08:51:22 -0700 (PDT) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6KFpLA11693 for ; Fri, 20 Jul 2001 08:51:21 -0700 (PDT) Received: from localhost (speakman@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA18748; Fri, 20 Jul 2001 08:50:45 -0700 (PDT) Message-Id: <200107201550.IAA18748@cisco.com> To: internet-drafts@ietf.org cc: rmt@lbl.gov Subject: draft-ietf-rmt-gra-arch-02.txt Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Date: Fri, 20 Jul 2001 08:50:45 -0700 From: Tony Speakman Sender: owner-rmt@lbl.gov Precedence: bulk Please post the following draft for discussion in the RMT WG: ftp://ftp-eng.cisco.com/speakman/draft-ietf-rmt-gra-arch-02.txt Thanks, Tony S >From owner-rmt@listserv.lbl.gov Fri Jul 20 12:16:44 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6KJG8I26455; Fri, 20 Jul 2001 12:16: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.11.2/8.11.2) with ESMTP id f6KJG6R26451 for ; Fri, 20 Jul 2001 12:16:06 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6KJG5s25529 for ; Fri, 20 Jul 2001 12:16:05 -0700 (PDT) Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f6KJG4A25515 for ; Fri, 20 Jul 2001 12:16:04 -0700 (PDT) Received: (qmail 23642 invoked from network); 20 Jul 2001 19:15:50 -0000 Received: from mail.intranet (10.1.1.37) by mx.digitalfountain.com with SMTP; 20 Jul 2001 19:15:50 -0000 Received: from leningrad (leningrad.intranet [10.1.3.72]) by mail.intranet (8.9.3/8.9.3) with SMTP id MAA29212; Fri, 20 Jul 2001 12:15:24 -0700 X-Authentication-Warning: mail.intranet: Host leningrad.intranet [10.1.3.72] claimed to be leningrad From: "Mike Luby" To: Cc: "Michael Luby" , "Jim Gemmell" , "Luigi Rizzo" , "Lorenzo Vicisano" , "Mark Handley" , "Jon Crowcroft" , "Roger Kermode" , Subject: Date: Fri, 20 Jul 2001 12:17:04 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0002_01C11115.E3203A10" 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 Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C11115.E3203A10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please post this draft on the IETF Internet Drafts archive. This is an update of an existing WG draft (RMT). Michael Luby Chief Technical Officer Digital Fountain, Inc. 39141 Civic Center Drive Suite 300 Fremont, CA 94538 www.digitalfountain.com luby@digitalfountain.com (510) 284-1420 (phone) (510) 284-1499 (fax) (510) 284-1400 (main) ------=_NextPart_000_0002_01C11115.E3203A10 Content-Type: text/plain; name="submitted draft-ietf-rmt-bb-alc-02-mgl-7-20-2001.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="submitted draft-ietf-rmt-bb-alc-02-mgl-7-20-2001.txt" Internet Engineering Task Force RMT WG=0A= INTERNET-DRAFT M.Luby/Digital Fountain=0A= draft-ietf-rmt-pi-alc-02.txt J.Gemmell/Microsoft=0A= L.Vicisano/Cisco=0A= L.Rizzo/ACIRI and Univ. Pisa=0A= J. Crowcroft/UCL=0A= 20 July 2001=0A= Expires: January 2002=0A= =0A= =0A= Asynchronous Layered Coding:=0A= A massively scalable reliably content delivery protocol=0A= =0A= =0A= =0A= Status of this Document=0A= =0A= This document is an Internet-Draft and is in full conformance with all=0A= provisions of Section 10 of RFC2026.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering Task=0A= Force (IETF), its areas, and its working groups. Note that other groups=0A= may also distribute working documents as Internet-Drafts.=0A= =0A= Internet-Drafts are valid for a maximum of six months and MAY be=0A= updated, replaced, or obsoleted by other documents at any time. It is=0A= inappropriate to use Internet-Drafts as reference material or to cite=0A= them other than as a "work in progress".=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt=0A= =0A= To view the list Internet-Draft Shadow Directories, see=0A= http://www.ietf.org/shadow.html.=0A= =0A= This document is a product of the IETF RMT WG. Comments should be=0A= addressed to the authors, or the WG's mailing list at rmt@lbl.gov.=0A= =0A= =0A= Abstract=0A= =0A= =0A= This document describes the Asynchronous Layered Coding=0A= protocol, a massively scalable reliable content delivery=0A= protocol, hereafter referred to as ALC. ALC can be used for=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft [Page 1]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= multi-rate reliable delivery of content to large sets of=0A= receivers. ALC uses the LCT transport described in [3]=0A= augmented with a congestion control protocol that is compliant=0A= with RFC2387 such as one of the layered congestion control=0A= protocols described [4]. ALC achieves reliability based on FEC=0A= codecs as generally described in [1], and in particular based=0A= on the details provided in the FEC building block described in=0A= [2].=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft [Page 2]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= Table of Contents=0A= =0A= =0A= 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4=0A= 1.1. Related Documents. . . . . . . . . . . . . . . . . . 5=0A= 1.2. Environmental Requirements and Considerations. . . . 5=0A= 2. General Architecture. . . . . . . . . . . . . . . . . . 6=0A= 2.1. Delivery service models. . . . . . . . . . . . . . . 6=0A= 2.2. Congestion Control . . . . . . . . . . . . . . . . . 7=0A= 3. Type of packets used by the ALC protocol. . . . . . . . 7=0A= 3.1. Packet format for the ALC protocol . . . . . . . . . 8=0A= 3.2. Packet header fields for the ALC protocol. . . . . . 8=0A= 4. Procedures. . . . . . . . . . . . . . . . . . . . . . . 9=0A= 4.1. Sender Operation . . . . . . . . . . . . . . . . . . 9=0A= 4.2. Receiver Operation . . . . . . . . . . . . . . . . . 10=0A= 5. Security Considerations . . . . . . . . . . . . . . . . 10=0A= 6. IANA Considerations . . . . . . . . . . . . . . . . . . 10=0A= 7. Intellectual Property Issues. . . . . . . . . . . . . . 10=0A= 8. Authors' Addresses. . . . . . . . . . . . . . . . . . . 11=0A= 9. Full Copyright Statement. . . . . . . . . . . . . . . . 13=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft [Page 3]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= 1. Introduction=0A= =0A= This document describes a massively scalable reliable content delivery=0A= protocol, Asynchronous Layered Coding (ALC), for multi-rate reliable=0A= content delivery. ALC is a protocol instantiation as defined in=0A= RFC3048. ALC uses the LCT transport [3]. Thus, like the LCT transport,=0A= the ALC protocol is primarily designed to be used with the IP multicast=0A= network service, but MAY also be used with other basic underlying=0A= network or transport services such as unicast UDP. ALC uses FEC codes=0A= to provide reliability as generally described in [1], i.e. all packets=0A= in a session contain FEC coded information in formats that are compliant=0A= with the FEC building block described in [2]. A crucial point is that=0A= ALC strongly relies on FEC codecs in the sense that there is no request=0A= for retransmission of individual packets from receivers that miss=0A= packets in order to assure reliable reception of an object, and the=0A= packets and their rate of transmission out of the sender can be=0A= independent of the number and the individual reception experiences of=0A= the receivers. In some delivery service models it is appropriate that=0A= receivers send out of band messages to the sender to provide guaranteed=0A= delivery of content. For example, in a push reliable delivery model=0A= receivers may send messages to a sender to continue the session if=0A= receivers have not yet received enough packets to recover the content or=0A= to terminate the session when receivers have received enough packets to=0A= recover the content. To be able to track usage of the system, receivers=0A= may also send messages out of band to the sender that contain statistics=0A= on their reception experience. ALC, however, does not require nor=0A= specify such messages, with the aim of avoiding unnecessary limitation=0A= to the scalability of the basic ALC protocol.=0A= =0A= The LCT transport provides support for congestion control, and the ALC=0A= protocol uses this support. The congestion control protocol must=0A= conform with RFC 2357. It is recommended that the congestion control=0A= protocol used for ALC be a multi-rate protocol, as described in [4]. In=0A= this case, a sender sends packets in the session to several LCT channels=0A= at potentially different rates. Then, individual receivers can adjust=0A= their reception rate within a session by adjusting which set of LCT=0A= channels they are joined to at each point in time depending on the=0A= available bandwidth between the receiver and the sender, but independent=0A= of other receivers. A single rate congestion control protocol can also=0A= be used, but this may limit the scalability of the session in terms of=0A= the number of receivers that can concurrently participate.=0A= =0A= Receiver may join and leave a session asynchronously at their=0A= discretion.=0A= =0A= An ALC packet thus consists of an LCT packet header, an FEC packet=0A= header, optional by additional parameters and packet payload.=0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 1. [Page 4]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= ALC has the following properties when the LCT transport uses multicast=0A= to deliver packets:=0A= =0A= =0A= o To each receiver, it appears as if though there is a dedicated session=0A= from the sender to the receiver, where the reception rate adjusts to=0A= congestion along the path from sender to receiver.=0A= =0A= o To the sender, there is no difference in load or outgoing rate if one=0A= receiver is joined to the session or a million (or any number of)=0A= receivers are joined to the session, independent of when the receivers=0A= join and leave.=0A= =0A= o On each link in the network, the packet traffic from the session and=0A= its reaction to competing traffic is the same whether there is one=0A= receiver or a million receivers beyond the link.=0A= =0A= Thus, ALC provides a massively scalable content delivery system that=0A= is network friendly.=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in RFC2119.=0A= =0A= =0A= 1.1. Related Documents=0A= =0A= The LCT transport that ALC MUST use is described in [3]. A more in-=0A= depth description of the use of FEC codecs in reliable content delivery=0A= protocols is given in [1]. All packets in a session MUST contain FEC=0A= coded information in formats that are compliant with the FEC building=0A= block described in [2]. Implementors of ALC MUST also implement a=0A= congestion control protocol in accordance to RFC2357, where the=0A= congestion control is over the entire session. Some possible schemes=0A= are specified in [4]. Congestion control MUST be integrated into ALC=0A= through the support provided in the LCT transport.=0A= =0A= It is RECOMMENDED that ALC implementors use some authentication scheme=0A= to protect the protocol from attacks. An example of a possibly suitable=0A= scheme is described in [5]. Authentication in ALC, if used, is to be=0A= integrated through the support provided in the LCT transport.=0A= =0A= =0A= 1.2. Environmental Requirements and Considerations=0A= =0A= ALC is intended for congestion controlled, multi-rate delivery of=0A= objects, i.e., reliable content delivery.=0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 1.2. [Page 5]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= All of the environmental requirements and considerations that apply to=0A= the LCT transport and to the FEC building block also apply to ALC.=0A= =0A= =0A= 2. General Architecture=0A= =0A= ALC protocol consists basically of using FEC codecs in the form=0A= described in [2] with the LCT transport as described in [3]. Thus, the=0A= terminology used in the description of the LCT transport and the FEC=0A= building block are inherited by the ALC protocol and this terminology is=0A= used below. In particular, the definition of a session for the ALC=0A= protocol is the same as it is for the LCT transport.=0A= =0A= Packets used within the ALC protocol are specialized versions of LCT=0A= packets. In particular, a packet consists of an LCT packet header, an=0A= FEC payload ID, optional additional parameters as appropriate, and the=0A= packet payload. From the point of view of the LCT transport, the FEC=0A= payload ID, the additional parameters if present, and the packet payload=0A= are all part of the LCT packet payload.=0A= =0A= The out of band information used by the ALC protocol consists of the out=0A= of band all information required for both the LCT transport and for the=0A= FEC building block. The possible means for acquiring this out of band=0A= information is the same as for the LCT transport and the FEC building=0A= block, and in particular is outside the scope of the ALC protocol.=0A= =0A= Congestion control for the ALC protocol MUST conform to RFC 2387, and=0A= MUST be provided through the mechanisms provided by the LCT transport.=0A= Although it is not mandatory, ALC is most scalable when multi-rate=0A= congestion control is used that does not require feedback from receivers=0A= to the sender, and thus use of a mult-rate congestion control as=0A= described in [4] is RECOMMENDED.=0A= =0A= =0A= 2.1. Delivery service models=0A= =0A= ALC can support several different delivery service models. Two examples=0A= are briefly described here.=0A= =0A= =0A= Push service model.=0A= =0A= One way a push service model can be used for reliable content delivery=0A= is to deliver a series of objects. For example, a receiver could join=0A= the session and dynamically adapt the number of LCT channels the=0A= receiver is joined to until enough packets have been received to=0A= reconstruct an object. After reconstructing the object the receiver may=0A= stay in the session and wait for the transmission of the next object.=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 2.1. [Page 6]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= The push model is particularly attractive in satellite networks and=0A= wireless networks. In these cases, a session may consist of one fixed=0A= rate LCT channel.=0A= =0A= =0A= On-demand content delivery model.=0A= =0A= For an on-demand content delivery service model, senders typically=0A= transmit for some given time period selected to be long enough to allow=0A= all the intended receivers to join the session and recover a single=0A= object. For example a popular software update might be transmitted=0A= using ALC for several days, even though a receiver may be able to=0A= complete the download in one hour total of connection time, perhaps=0A= spread over several intervals of time.=0A= =0A= In this case the receivers join the session at any point in time when it=0A= is active and dynamically adapt the number of LCT channels they=0A= subscribe to according to the available bandwidth using a multi-rate=0A= congestion control protocol. Receivers leave the session when they have=0A= received enough packets to recover the object.=0A= =0A= =0A= Other service models.=0A= =0A= =0A= There may be other delivery service models that can be supported by ALC.=0A= The description of the potential applications, the appropriate delivery=0A= service model, and the additional mechanisms to support such=0A= functionalities when combined with ALC is beyond the scope of this=0A= document.=0A= =0A= =0A= 2.2. Congestion Control=0A= =0A= The specific congestion control protocol to be used for ALC sessions=0A= should be suitable for reliable content delivery. While the general=0A= behavior of the congestion control protocol is to reduce the throughput=0A= in presence of congestion and gradually increase it in the absence of=0A= congestion, the actual dynamic behavior (e.g. response to single losses)=0A= can vary.=0A= =0A= Some possible multi-rate congestion control protocols for reliable=0A= content delivery using LCT are described in [4].=0A= =0A= 3. Type of packets used by the ALC protocol=0A= =0A= The type of packet used by the ALC protocol is a specialized version of=0A= an LCT packet. LCT packets are sent by senders to LCT channels.=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 3. [Page 7]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= Some instances of sessions MAY require the generation of feedback from=0A= the receivers to the sender. However, the mechanism for doing this is=0A= outside the scope of ALC.=0A= =0A= =0A= 3.1. Packet format for the ALC protocol=0A= =0A= The packet format used for ALC protocol is depicted in Figure 1.=0A= =0A= =0A= 0 1 2 3=0A= 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | LCT packet header |=0A= | |=0A= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=0A= | FEC Payload ID |=0A= | |=0A= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=0A= | Additional parameters |=0A= | (optional) |=0A= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=0A= | Payload |=0A= | |=0A= | |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= =0A= =0A= Figure 1 - Packet format for ALC protocol=0A= =0A= =0A= 3.2. Packet header fields for the ALC protocol=0A= =0A= The description of the fields and their functions within the LCT packet=0A= header can be found in [3]. The information that needs to be=0A= communicated out of band for the LCT transport and the possible=0A= mechanisms for achieving this are described in [3].=0A= =0A= The description of the fields and their functions within the FEC payload=0A= ID can be found in [2], with the exception that the FEC Encoding Flag=0A= value, if applicable, MAY be communicated via the value of the Codepoint=0A= field within LCT packet header. The information that needs to be=0A= communicated out of band for the FEC codecs and the possible mechanisms=0A= for achieving this are described in [2]. The mechanisms for=0A= communicating the out of band information needed for the LCT transport,=0A= including the mapping between the Codepoint field values in the LCT=0A= packet header and the interpretations of the values, MAY be the same as=0A= those used for communicating the out of band information needed for the=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 3.2. [Page 8]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= FEC building block, with the exception that portions of the information=0A= needed for FEC building blocks may be communicated either through the=0A= use of the Codepoint field in the LCT packet header, or through the=0A= Additional Parameters fields that follow the FEC payload ID.=0A= =0A= The fields and formats of the optional Additional Parameters fields MUST=0A= be communicated to the receivers out of band. The particular Additional=0A= Parameters fields that may appear in packets MUST be communicated out of=0A= band. The specification of which Additional Parameters fields that=0A= appear in a packet MUST be communicated via the value of the Codepoint=0A= field in the LCT packet header, and the mapping between Codepoint field=0A= values and the Additional Parameters fields that appear in a packet MUST=0A= be communicated out of band. It is RECOMMENDED that the format of any=0A= Additonal Parameters fields adhere to the format of Header-Extension=0A= Fields defined for the LCT transport in [3].=0A= =0A= 4. Procedures=0A= =0A= =0A= 4.1. Sender Operation=0A= =0A= The sender operation when using the ALC protocol includes all the points=0A= made about the sender operation when using the LCT transport as=0A= described in [3], and the FEC building block as described in [2]. The=0A= following description highlights some of the additional considerations=0A= to be taken into account with respect to the ALC protocol.=0A= =0A= Before a session starts, a sender using the ALC protocol MUST make=0A= available all applicable information regarding the session. This=0A= information includes:=0A= =0A= o Any information needed by the LCT transport;=0A= =0A= o The congestion control protocol being used within the LCT transport;=0A= =0A= o The mapping between values of the Codepoint field in the LCT packet=0A= header and interpretations of these values;=0A= =0A= o Any information needed for the FEC building block;=0A= =0A= o If used, the authentication scheme being used within the LCT=0A= transport, and all relevant information which is necessary for=0A= sender authentication purposes;=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 4.1. [Page 9]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= 4.2. Receiver Operation=0A= =0A= The receiver operation when using the ALC protocol includes all the=0A= points made about the receiver operation that pertain to reliable=0A= content delivery when using the LCT transport as described in [3], and=0A= that pertain to using the FEC building block as described in [2]. The=0A= following description highlights some of the additional considerations=0A= to be taken into account with respect to the ALC protocol.=0A= =0A= When a receiver receives a packet, the receiver MUST process the LCT=0A= packet header (excluding the Codepoint field) as described in [3]=0A= before processing any other fields of the packet.=0A= =0A= =0A= 5. Security Considerations=0A= =0A= The same security consideration that apply to the LCT transport and to=0A= the FEC building block also apply to the ALC protocol. In addition, any=0A= security considerations that apply to the congestion control protocol=0A= used by the ALC protocol within the LCT transport also apply.=0A= =0A= =0A= 6. IANA Considerations=0A= =0A= No information in this specification is directly subject to IANA=0A= registration. However, building blocks components used by the ALC=0A= protcol may introduce additional IANA considerations. In particular,=0A= the FEC building block used by the ALC protocol does require IANA=0A= registration of the FEC codecs used.=0A= =0A= =0A= 7. Intellectual Property Issues=0A= =0A= =0A= No specific reliability protocol or congestion control protocol is=0A= specified or referenced as mandatory in this document.=0A= =0A= ALC MAY be used with congestion control protocols and other protocols=0A= which are proprietary, or have pending or granted patents.=0A= =0A= =0A= =0A= [1] Luby, M., Gemmell, Vicisano, L., J., Rizzo, L., Handley, M.,=0A= Crowcroft, J., "The use of Forward Error Correction in Reliable=0A= Multicast", Internet Draft draft-ietf-rmt-info-fec-00.txt, November=0A= 2000, a work in progress.=0A= =0A= [2] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M.,=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 7. [Page 10]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= Crowcroft, J., "RMT BB Forward Error Correction Codes", Internet Draft=0A= draft-ietf-rmt-bb-fec-03.txt, July 2001.=0A= =0A= [3] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M.,=0A= Crowcroft, J., "Layered Coding Transport: A massively scalable content=0A= delivery transport", Internet Draft draft-ietf-rmt-bb-lct-01.txt, July=0A= 2001.=0A= =0A= [4] Luby, M., Vicisano, L., Haken, A., "RMT BB Layered congestion=0A= control", draft-ietf-rmt-bb-lcc-00.txt, November 2000, a work in=0A= progress.=0A= =0A= [5] Perrig, A., Canetti, R., Briscoe, B., Tygar, D., Song, D., "TESLA:=0A= Multicast Source Authentication Transform", draft-irtf-smug-=0A= tesla-00.txt, November, 2000, a work in progress.=0A= =0A= =0A= =0A= 8. Authors' Addresses=0A= =0A= Michael Luby=0A= luby@digitalfountain.com=0A= Digital Fountain=0A= 39141 Civic Center Drive=0A= Suite 300=0A= Fremont, CA, USA, 94538=0A= =0A= Jim Gemmell=0A= jgemmell@microsoft.com=0A= Microsoft Research=0A= 301 Howard St., #830=0A= San Francisco, CA, USA, 94105=0A= =0A= Lorenzo Vicisano=0A= lorenzo@cisco.com=0A= cisco Systems, Inc.=0A= 170 West Tasman Dr.,=0A= San Jose, CA, USA, 95134=0A= =0A= Luigi Rizzo=0A= luigi@iet.unipi.it=0A= Dip. Ing. dell'Informazione,=0A= Univ. di Pisa=0A= via Diotisalvi 2, 56126 Pisa, Italy=0A= =0A= Jon Crowcroft=0A= J.Crowcroft@cs.ucl.ac.uk=0A= Department of Computer Science=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 8. [Page 11]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= University College London=0A= Gower Street,=0A= London WC1E 6BT, UK=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 8. [Page 12]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= 9. Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2000). All Rights Reserved.=0A= =0A= This document and translations of it may be copied and furnished to=0A= others, and derivative works that comment on or otherwise explain it or=0A= assist in its implementation may be prepared, copied, published and=0A= distributed, in whole or in part, without restriction of any kind,=0A= provided that the above copyright notice and this paragraph are included=0A= on all such copies and derivative works. However, this document itself=0A= may not be modified in any way, such as by removing the copyright notice=0A= or references to the Internet Society or other Internet organizations,=0A= except as needed for the purpose of developing Internet standards in=0A= which case the procedures for copyrights defined in the Internet=0A= languages other than English.=0A= =0A= The limited permissions granted above are perpetual and will not be=0A= revoked by the Internet Society or its successors or assigns.=0A= =0A= This document and the information contained herein is provided on an "AS=0A= IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK=0A= FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT=0A= LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT=0A= INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR=0A= FITNESS FOR A PARTICULAR PURPOSE."=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 9. [Page 13]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 9. [Page 14]=0A= ------=_NextPart_000_0002_01C11115.E3203A10 Content-Type: application/pdf; name="submitted draft-ietf-rmt-bb-alc-02-mgl-7-20-2001.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="submitted draft-ietf-rmt-bb-alc-02-mgl-7-20-2001.pdf" JVBERi0xLjMNJeLjz9MNCjUwIDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyA1MiANL0ggWyA3 NTQgMjcxIF0gDS9MIDMyNDgyIA0vRSAxMDQ2OSANL04gMTEgDS9UIDMxMzY0IA0+PiANZW5kb2Jq DSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTUwIDE2IA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDA2NjcgMDAwMDAgbg0KMDAw MDAwMTAyNSAwMDAwMCBuDQowMDAwMDAxMTc5IDAwMDAwIG4NCjAwMDAwMDEzMDQgMDAwMDAgbg0K MDAwMDAwMjA5NCAwMDAwMCBuDQowMDAwMDAyNDY1IDAwMDAwIG4NCjAwMDAwMDM5MzAgMDAwMDAg bg0KMDAwMDAwNTA1NiAwMDAwMCBuDQowMDAwMDA1MjYxIDAwMDAwIG4NCjAwMDAwMDU0NjIgMDAw MDAgbg0KMDAwMDAwNTY2MSAwMDAwMCBuDQowMDAwMDA2NzE5IDAwMDAwIG4NCjAwMDAwMDY4NTgg MDAwMDAgbg0KMDAwMDAwMDc1NCAwMDAwMCBuDQowMDAwMDAxMDA0IDAwMDAwIG4NCnRyYWlsZXIN PDwNL1NpemUgNjYNL0luZm8gNDkgMCBSIA0vUm9vdCA1MSAwIFIgDS9QcmV2IDMxMzU0IA0vSURb PGJhMWYzZGJmNzc2MGIxODBlZjRkNTllNWVlYmU4M2NlPjxiYTFmM2RiZjc3NjBiMTgwZWY0ZDU5 ZTVlZWJlODNjZT5dDT4+DXN0YXJ0eHJlZg0wDSUlRU9GDSAgICAgDTUxIDAgb2JqDTw8IA0vVHlw ZSAvQ2F0YWxvZyANL1BhZ2VzIDM3IDAgUiANL0pUIDQ4IDAgUiANL1BhZ2VMYWJlbHMgMzUgMCBS IA0+PiANZW5kb2JqDTY0IDAgb2JqDTw8IC9TIDE1NiAvTCAyMDUgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgL0xlbmd0aCA2NSAwIFIgPj4gDXN0cmVhbQ0KSIliYGBgZmBg+sTAAiR1GfgYEIAPKAaCHBPA 3I4G9YVXXatEXrgYqrpEs0rYf2BgmJaWmebmAJJlb522HIaWRVSeXVcRmQVE7VFggkFQUKKBgQEZ CXYwMEowMHAAIYjAZjoQyDMwJP8B0jxAzA8WqWXgYbzAoDnhW/Dhl6wMPiyLlzK8Zdd0ZD2kAJZW YmAo1QPSTEDsDRBgAGy1L/QNZW5kc3RyZWFtDWVuZG9iag02NSAwIG9iag0xNTggDWVuZG9iag01 MiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMzYgMCBSIA0vUmVzb3VyY2VzIDUzIDAg UiANL0NvbnRlbnRzIDU2IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3gg WyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNNTMgMCBvYmoNPDwgDS9Qcm9j U2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjIgNTcgMCBSIC9GMyA2MSAwIFIgL0Y0IDU0 IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDYyIDAgUiA+PiANPj4gDWVuZG9iag01NCAwIG9i ag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0ZpcnN0Q2hhciAzMiANL0xhc3RD aGFyIDE4MSANL1dpZHRocyBbIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2MDAgNjAw IF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL0RFSUFMRytDb3VyaWVy LUJvbGQgDS9Gb250RGVzY3JpcHRvciA1NSAwIFIgDT4+IA1lbmRvYmoNNTUgMCBvYmoNPDwgDS9U eXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA2MjYgDS9DYXBIZWlnaHQgNTYyIA0vRGVzY2Vu dCAtMTQyIA0vRmxhZ3MgMjYyMTc5IA0vRm9udEJCb3ggWyAtMTEzIC0yNTAgNzQ5IDgwMSBdIA0v Rm9udE5hbWUgL0RFSUFMRytDb3VyaWVyLUJvbGQgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMTA2 IA0vWEhlaWdodCA0MzkgDS9DaGFyU2V0ICgvbi9sL3AvZS9OL0cvRS9oeXBoZW4vei9mL1UvSS9w ZXJpb2Qvci9zcGFjZS9WL0ovUC9zL3NsYXNoL2kvRi9XL2EvTC90L3pcDWVyby9NL3Uvb25lL1Qv ay9BL3YvZy9tL3R3by9iL2NvbG9uL0Mvdy94L28vYy9SL0QvZC95KQ0vRm9udEZpbGUzIDYzIDAg UiANPj4gDWVuZG9iag01NiAwIG9iag08PCAvTGVuZ3RoIDEzOTAgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSImMVlFv4jgQfudXjO4pOTUmCU2BfboeLVWrdrVqs7s6sX0wiQHfJjGy nVL2Z9wvvhk7gXbbW52QwCTjmW+++WbsP/PBcH4KCeSrQRIDffBnnMI4HkNeD2JYD4ZXDwmsDa7z gr52g0Vw3VihG2HhslnLRggtmzXk3HyHudKFCKM0nk6nbBrc3+Xw9Sp8zG9wa5SwEeQXgzRmI3zd ufqYX95/vMyji/vzeQ537LZd7ocXci0tr8LoLI6DuWoby2Xj3OS/D5JTNu32B6XmKxtJYVeRrm20 lRGviihO2dbADbsSdS2qangnC62MWtkw/3swGrGMtvdwXE7BLfsiC2l4o4YzaQpFltGYpQcztLiX P36o4fns+v4aeFPC50Y+MfiEu8j6lfENg5lWOwy7ssPPs1sySNnp0SCN4aat9pDGceJiZS/fXj5v pRbmA9zwpuXamaVkNpyPunKd+nJh9aYjFo8mkE0TqtkiODf7ptjoMJkEqlGtgVu+D5M4EO6RKGGm SizYB8dndMrGZ0kGUcym6eSMoqMHrGAWBzU3RtLOJ7cd0ZqCV3xZCfCuKol/9lAo1ENjocQHR3NE vfUgrCpU5aIliUedkMiy0YgABw+WW0SpVmA30sCFKtoa3fl0U5+uU08WU4oEMCfDsjMEXPMGelFG F6QJVyB8IRtYtVVFGFdK17wpBOyk3QDHh1utwiQLnqSRqnEIHkRhcU1toFZH3SaTZOIKcz+fpXF6 xggcvknZ6GzUkfY6PkLSGImYUPo79UcPt8tUwPtdFE7iwHUSIaNugm/B9WU+/xaegPRuuTl5C20R uIzR4mXQtVbt1rAwyrCRPiorMDK3oDC+7l5CzffIhlFQSmO1XIZpHLT2v8Bz0/fhzxn/X1KewjQL eCVLwIoAx/jPsm5rosXIZ6hRTRvj6nd3jhCy4C8vx2WIqvLLdltyK8oT0GJb8YJWSr/HiVoaVQk0 heW+y/pFKqQSonnvvVpZCwZ+fW39r5MQ36JStlpy4k9BawS8ScwglpXQAgXWE7TADkIryStERxsL 6Qog6g4K1qKhnRx+68kmwWKwNXa/+Y31Kb2kNEfpVFgp4qtotaYO+BlNgX6XAnhRoBtMHjPdWLv9 MBzudrvwLAsYjUymXH+uh/RnmMgy4ktUAC+wlvbZHtNwolT0hezg95MUVMNdR1sP6KcOfNjwUr2w u8CRVlilpTAnYIT4JSRz3EzvNrau2AtAb/qfSCvbwh6aC1sG/PHTqX+mal92s1FtVTp+ylJ7grA4 uOvdrmrtRmlz4kqIjr9e/RNmWWD6ESkr6g+XP7KMh9Af1bJiaz9YHHbn9Ti4x2w8ziZU02k3z4Lz jvZXIy9KMpx4o4Qs4+w0e2/ylcIU2LHCOGjd4D8MfVRjP+yJHjeGT1zD0VxPCR+CxLn+Xt7HUe/H vHg95g+73ZjvfaOoBZYepe2aQXtmUeHnt7OuDLjq5HksZ0sloGFQt5WVkaY+O4R9E45030FB5xX3 ihEoKT9bUWXi5Q7T9zSG7saH8YwdJtntLAesQGO2Sh9ZLakZF6NH4O2a6MYH/uig+Gth3ElBULSq DiT4ASsN1ZJcF6reYiYI1u2lA2Q0GYNpiw0RoxrRS7bqKvYL573XRXDEuDh9ZMQvdvvG96XPG6dl J1JPJQrV7mHJiWt0Pb/EOqhSFG52rUUjNB6J+1fJHyu0SB5P/JGK44lrK4sWiT96I/ylwFtaZY6n aukZpHcUzR8ssnJ6XFaq+H7g/zXj6aM7SlD36TgdoyxTNu5aJZmwSTId+7ujuyr2d7wv4RlO6+4K 529qeANzE8TdwmDxiVBxFArqBZ2wcZA8OgSX+eDfAQAU81mcCmVuZHN0cmVhbQ1lbmRvYmoNNTcg MCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTEgDS9GaXJzdENoYXIgMTkgDS9M YXN0Q2hhciAyNTUgDS9XaWR0aHMgWyA2MTEgMjc4IDU2NCAxNjcgMzMzIDMzMyAyNzggMzMzIDMz MyAzMzMgMzMzIDU1NiA1NTYgMjUwIDMzMyA0MDggNTAwIA01MDAgODMzIDc3OCAxODAgMzMzIDMz MyA1MDAgNTY0IDI1MCAzMzMgMjUwIDI3OCA1MDAgNTAwIDUwMCA1MDAgDTUwMCA1MDAgNTAwIDUw MCA1MDAgNTAwIDI3OCAyNzggNTY0IDU2NCA1NjQgNDQ0IDkyMSA3MjIgNjY3IDY2NyANNzIyIDYx MSA1NTYgNzIyIDcyMiAzMzMgMzg5IDcyMiA2MTEgODg5IDcyMiA3MjIgNTU2IDcyMiA2NjcgNTU2 IA02MTEgNzIyIDcyMiA5NDQgNzIyIDcyMiA2MTEgMzMzIDI3OCAzMzMgNDY5IDUwMCAzMzMgNDQ0 IDUwMCA0NDQgDTUwMCA0NDQgMzMzIDUwMCA1MDAgMjc4IDI3OCA1MDAgMjc4IDc3OCA1MDAgNTAw IDUwMCA1MDAgMzMzIDM4OSANMjc4IDUwMCA1MDAgNzIyIDUwMCA1MDAgNDQ0IDQ4MCAyMDAgNDgw IDU0MSAzNTAgMCAzNTAgMzMzIDUwMCA0NDQgDTEwMDAgNTAwIDUwMCAzMzMgMTAwMCA1NTYgMzMz IDg4OSAzNTAgNjExIDM1MCAzNTAgMzMzIDMzMyA0NDQgNDQ0IA0zNTAgNTAwIDEwMDAgMzMzIDk4 MCAzODkgMzMzIDcyMiAzNTAgNDQ0IDcyMiAyNTAgMzMzIDUwMCA1MDAgNTAwIA01MDAgMjAwIDUw MCAzMzMgNzYwIDI3NiA1MDAgNTY0IDMzMyA3NjAgMzMzIDQwMCA1NjQgMzAwIDMwMCAzMzMgDTUw MCA0NTMgMjUwIDMzMyAzMDAgMzEwIDUwMCA3NTAgNzUwIDc1MCA0NDQgNzIyIDcyMiA3MjIgNzIy IDcyMiANNzIyIDg4OSA2NjcgNjExIDYxMSA2MTEgNjExIDMzMyAzMzMgMzMzIDMzMyA3MjIgNzIy IDcyMiA3MjIgNzIyIA03MjIgNzIyIDU2NCA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA1NTYgNTAw IDQ0NCA0NDQgNDQ0IDQ0NCA0NDQgDTQ0NCA2NjcgNDQ0IDQ0NCA0NDQgNDQ0IDQ0NCAyNzggMjc4 IDI3OCAyNzggNTAwIDUwMCA1MDAgNTAwIDUwMCANNTAwIDUwMCA1NjQgNTAwIDUwMCA1MDAgNTAw IDUwMCA1MDAgNTAwIDUwMCBdIA0vRW5jb2RpbmcgNjAgMCBSIA0vQmFzZUZvbnQgL1RpbWVzLVJv bWFuIA0vRm9udERlc2NyaXB0b3IgNTkgMCBSIA0+PiANZW5kb2JqDTU4IDAgb2JqDTw8IA0vVHlw ZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgNjk5IA0vQ2FwSGVpZ2h0IDY3NiANL0Rlc2NlbnQg LTIwNSANL0ZsYWdzIDI2MjE3OCANL0ZvbnRCQm94IFsgLTE2OCAtMjE4IDEwMDAgOTM1IF0gDS9G b250TmFtZSAvVGltZXMtQm9sZCANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAxMzkgDS9YSGVpZ2h0 IDQ2MSANPj4gDWVuZG9iag01OSAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNj ZW50IDY5OSANL0NhcEhlaWdodCA2NjIgDS9EZXNjZW50IC0yMTcgDS9GbGFncyAzNCANL0ZvbnRC Qm94IFsgLTE2OCAtMjE4IDEwMDAgODk4IF0gDS9Gb250TmFtZSAvVGltZXMtUm9tYW4gDS9JdGFs aWNBbmdsZSAwIA0vU3RlbVYgODQgDS9YSGVpZ2h0IDQ1MCANPj4gDWVuZG9iag02MCAwIG9iag08 PCANL1R5cGUgL0VuY29kaW5nIA0vQmFzZUVuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9EaWZm ZXJlbmNlcyBbIDE5IC9Mc2xhc2ggL2xzbGFzaCAvbWludXMgL2ZyYWN0aW9uIC9icmV2ZSAvY2Fy b24gL2RvdGxlc3NpIC9kb3RhY2NlbnQgDS9odW5nYXJ1bWxhdXQgL29nb25layAvcmluZyAvZmkg L2ZsIF0gDT4+IA1lbmRvYmoNNjEgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlw ZTEgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAyNTUgDS9XaWR0aHMgWyAyNTAgMzMzIDU1NSA1 MDAgNTAwIDEwMDAgODMzIDI3OCAzMzMgMzMzIDUwMCA1NzAgMjUwIDMzMyAyNTAgMjc4IA01MDAg NTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgMzMzIDMzMyA1NzAgNTcwIDU3MCA1 MDAgDTkzMCA3MjIgNjY3IDcyMiA3MjIgNjY3IDYxMSA3NzggNzc4IDM4OSA1MDAgNzc4IDY2NyA5 NDQgNzIyIDc3OCANNjExIDc3OCA3MjIgNTU2IDY2NyA3MjIgNzIyIDEwMDAgNzIyIDcyMiA2Njcg MzMzIDI3OCAzMzMgNTgxIDUwMCANMzMzIDUwMCA1NTYgNDQ0IDU1NiA0NDQgMzMzIDUwMCA1NTYg Mjc4IDMzMyA1NTYgMjc4IDgzMyA1NTYgNTAwIA01NTYgNTU2IDQ0NCAzODkgMzMzIDU1NiA1MDAg NzIyIDUwMCA1MDAgNDQ0IDM5NCAyMjAgMzk0IDUyMCAwIDcyMiANNzIyIDcyMiA2NjcgNzIyIDc3 OCA3MjIgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNDQ0IDQ0NCA0NDQgNDQ0IA00NDQgMjc4IDI3 OCAyNzggMjc4IDU1NiA1MDAgNTAwIDUwMCA1MDAgNTAwIDU1NiA1NTYgNTU2IDU1NiA1MDAgDTQw MCA1MDAgNTAwIDUwMCAzNTAgNTQwIDU1NiA3NDcgNzQ3IDEwMDAgMzMzIDMzMyAwIDEwMDAgNzc4 IDAgNTcwIA0wIDAgNTAwIDU1NiAwIDAgMCAwIDAgMzAwIDMzMCAwIDcyMiA1MDAgNTAwIDMzMyA1 NzAgMCA1MDAgMCAwIDUwMCANNTAwIDEwMDAgMjUwIDcyMiA3MjIgNzc4IDEwMDAgNzIyIDUwMCAx MDAwIDUwMCA1MDAgMzMzIDMzMyA1NzAgMCANNTAwIDcyMiAxNjcgNTAwIDMzMyAzMzMgNTU2IDU1 NiA1MDAgMjUwIDMzMyA1MDAgMTAwMCA3MjIgNjY3IDcyMiANNjY3IDY2NyAzODkgMzg5IDM4OSAz ODkgNzc4IDc3OCAwIDc3OCA3MjIgNzIyIDcyMiAyNzggMzMzIDMzMyAzMzMgDTMzMyAzMzMgMzMz IDMzMyAzMzMgMzMzIDMzMyBdIA0vRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcgDS9CYXNlRm9u dCAvVGltZXMtQm9sZCANL0ZvbnREZXNjcmlwdG9yIDU4IDAgUiANPj4gDWVuZG9iag02MiAwIG9i ag08PCANL1R5cGUgL0V4dEdTdGF0ZSANL1NBIGZhbHNlIA0vU00gMC4wMiANL09QIGZhbHNlIA0v b3AgZmFsc2UgDS9PUE0gMSANL0JHMiAvRGVmYXVsdCANL1VDUjIgL0RlZmF1bHQgDS9UUjIgL0Rl ZmF1bHQgDT4+IA1lbmRvYmoNNjMgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0 aCAzMzY4IC9TdWJ0eXBlIC9UeXBlMUMgPj4gDXN0cmVhbQ0KSIlkVAtUE2cWniGZGR4hVmJizWgS WVdaxSGKVZCHgLo21sfyKOJZX8gziIAEFRSkiq0iAvXVWqCCiqj44iXiiiK6iOsLRVHQrmt1ZX7t 6bJ60Dv2T9v9k9Lu2dMzOffkvzP3u/d+97s/TckdKJqmh0yfYQqePXPstNRV6ea49HEhqcmxNn+Q xFPScFoa4SDpZNIQ+TYFjTMUshaFXNIrNJjBRW83vD3F6CronwsKfrEKDgoHQdPgi8OV+9wohqYd 07Lzio3GiYLRaJyWmpaVbk5IzDC8F/O+Ybyvj68nsb5Gux1vt952O8luJ9utjyE4NnVZnCE8y5IR t8JiMKXEpKanpaZHZ8TFCgZDcHKyIcyGaTGExVni0lcT70AfBlsfA///rzWKJg+lZCieotwpapSc GkNT4xyo8RTlTVEfyKgQlppFUbMZKtyRGk8oohwoGTWUmkTNpb6gTtNy2o/+hL7poHVY7HBQ5ibz lmXL9su+k7vL18q7GWcmgtnK3GJNbBXbx4Vx1ZzkaHb80vGZk8wp1emCM+Mc69zgEuSy1qXN5QfF R4pKxQvXoUolhIk0jIQ7MmkphKlFfMeLU+aCLw3LIFQm6W+r65afnhMaHx29sjLiTkt9TZNOiYe9 vU3flRbKpINvPdT+NVbXH4/1xDPKXFGaLdL/FiGtVyZthRb16yyIwSa8YBPOC5pYgi0wDz7eCRu6 dMYtar8cPHycRy4M69ZVcm2F28HjJf+6GE8J1SsLEA3liKBrEA6Q9nK4JJIxchBwnLEacbDAKQue S4GI7hUh4alMWq2Bid4mHMKBEuRMd+fV5j7toS2Hcg/oWtPmXfDkAz9MmrtA7y3u5W6g4u1trYmm mMykqMU6/Dm2MAH2Zh//r1+4+/uGcZH89yQUoA4EqxBdDBvBFXJkEtKgcA5HSRYGfyrAIBZPtmqY PwuwEX3AHu5gIJs9PJPxEdgy2KHGRrYH5tgZM/bSLQgeijLpWrc6vINZtXz6Uj8eayJf9cM4cDjf 2XJ+TVqj3lOEHK9obvf6qKM+PJ6AOfwODsTcdTwXkurAtfzWfRtvkgbR/SJUEbR2OKd+kdTv2awr j128fQmPjwsPrBp/AXaz8B682wFZeq/N6pmZ00LjdavNcflLeV9JAwwLTqcn/9GG9e2Rk+L+xvvI DVTia1SPVH3SWQ3ECdgR54HnaxPiVD9DhsCp+kwjwR3yyBG7IEi05gvdtkRkTAjGoMqGbgKhE9+I J5Hqkeon6SL8qIYE60ahy6oJEqAR4UGc6hGMeTNL5FQ/QYYXOZkM8AfIJUfsTAZE0oO5163hOdzs 9UGqfukfMFeNcDXJLYH7BNacx2xKSclfwUdEftUYp0+qXd96QQuGJ7dFnaq//fjqFc16LwTrhUVc ZWxixQwee2IFdsWzcSiMGA1j9CpJ7GvcWa4HD26AQ9j5QibtIvKbRDiZhKxTBPC1arAvaSq3VxqF 6IsIsojIv5UsamR9V4DpuJr7cHPEhKzMwuK1utA9loo2LVACXsutO9IX1cdXVRXt2q8v3MZ01Rxp 6tfC6d8yjRZhDdH6RQ3sE/B0vIYkVCDcLrywajyFX7/qQnCCzFSypcPzOUzh2lFQy+C/CPfYdURm EQJsRp5sKdz5D65l2tl+OFGCbzGCTX2RbI6kYQaAnomwgwC9tAOVCAj/jcObpZEMninct2qmCvA1 GgMdLHxh9WSeShaWhL1EEE7q1IuQTiJPSYPUZ9c3JZ/UNS+dXmLi8R6hxy6rMwgrX4ITCy4937zS exWpF6WnZ27U5axILDDz/hD+jK2s3vLJAf3R7PLlCVqbNrQIvAnwYJEMVybd06AgDnPgWfcl01J6 qr1Te3nlpcgjuvLEJUXLeFwp3LOnyUfBoO1mn2LlgaR98aWJw3IkcgX5b16iGw/e8A5beW1LyK+b UI9AafsN8SHb8EYNKdZynIJgMCjJLBUCPEHYldCtxIPJWJHkjujvRdhEmnwxQM9zXMZNzFjogem8 axd0cFy0OXtwJTdtx59uLdGlnGn47Czf2LC7rFZ/7XBVV4cWznDKitWSBdFbYSvQUCCTvrdjFQjP ODwc/4AN8APTjfBWoYuFeVYLg1gwkStjICofsmAsZMqkV/aoTAFxZlwzGg4wJtYDH0yEOobUkCX8 lb1GYh+wwEArcLiV6WGv21By0RT0SryJ3NpEKHimypauaFAgTOFqCuqzj+oexmN5wRo+JCg97SP9 ST9m38W2ssv8ga78efpcrtgcW5TI4/SNeESmXtU8q90f5KfPfVV2SKfKLjiyt2SXbiGnaoYJ8qWL wsyz+JjYr482d5Wev1Tzaf5hPdlRPwQl6CFyeyrCMaTKVjVL5yBVDU5jQY6Hz49aa47TQQaeKjzg VNnWmQECBBK4Wi6t5mRGJw+Gf4EjcHphmzpwzuwp0e8fBIe7p2709TVMWqAj4HBYpC+LUEF0Uv+N en4nExMxf/lU3j+gSXxwpb2vtnZDdrXevxeijJncHnPC9ngeB/uRFaexByh8wFV8XNd6Q2+n55cq mxDUiISfJxo0VarECQK4YDV3LP7j0kgejxiLHbArIQEP6hsJI1rOlx6tIywkcPmQrCZeF0yvSwqc 1d7Tc7Xt0flLK5aVkbe71nxusWhJrd+hx4i+jqCJCOnSFXX0fSZ57oyVITx2Xv7345/ppcHstt2F Jyq0oHR/hN3IRT40AAvY+Z+YBp8nT6tPdeoMEKvG9Wxb+dWqNv5Se3bEQZuioVD8b5FlH9PUFYZx 0d1e1A1njyXAnS1uZiqTy/yIQyhiQGEKDhzTjS/riuCU8qkoAk6rY2GBAmr5KKLIR1CBSd3QMjdx i5nZdGpxIGVB45R4TwlEnTPvTV7+2Gk1WXL+Ped9z3mf5/ecMal8rxLSJEKJQ+6Wn6gIDa/lqnIM lQZBt/VwwU7N1uyyxES/nMVBY2haLMq+FLeACbZIuOUcf97UfMfWazx8gSV4rPMpZWwIocpOJ1gf k3H5LowxxWl5MmLgz2Yk1ScK+M7CAPTCWROBMO9yn+Xsec02Pr4sBfmIoNbadHVBIFd4/07xoAAb Tk3AFA0ZhwG2+33kVeEJKSsi1/TdHbjZNzxyLVnrSkuooNdgkQfU0Gnwj2xUwaJ5uIiHlkkjKxsM Ttwvgj9WYOjL4DBRymJjtmQHM+rgKwb9IW/6Lq+/rB3Ud8Gbkg+Rn1I0iycVyz7igDXO+BXN4iQU onjyb1fLd5kXMr7d5psnuhAmRzPOmBll6xjSQ9i8q0RYOhnt5rm7s1Cq/F2Cqa415y0yIqM3/Rhy mEAHk34L0ev3ZeWpe/Iyju4WDFkHdjN7jDRjmOjAilUilNMwly8K+cYTLcdbBesxw14NXoXFNA5y +c7WdnOj0GXOMWrQ/qqWVlI+kyBTYiMcYMyDHTzp7TCeKWlTXzAkWz4VNiXsy9VriKPTZZb/S/RC Gn/xpxt1Z4RbRwzbNPhJuCuMKLRTD5sTHOxyVyBbBdxKmI6r0RuJFgMxDALjGYZ48LsNK9SiSRUQ +nlYvD9z14M7P4/CzN7VcUwMMXRYgnqqpUoWD8wW4yyj81RkBJagnz1g86aizHQ1GT+HqxjqI1hG XKf4NszhS5qufOEQwGfsOajYkwR9owqOTojQzW+H11jFKU3fD95MXv5q9OxsWEuJXb4JD1XEerK0 sfS4uu1QljVKiIrTpSVqiL0fU0WYghX+oqykuB6W8cTafbb7dE+LZ21Ta22z0FZlzK90mViE+AmI EKnyoaR9BAXS2lHSQGrkU+CjGkiwxVSrcXYNt8v04RGrX8+D6mY1aeixHSru0pCOBPbFqIWIoN28 ZXuqWScsX5C+EN8Af2N/qYZYusts1R1FnrWllcaDfjtiizavSzpuzleTpH72J2nAeOkMX3Sx70Cf QGpg2ujVRy7sgYVJawl7fduPqmKJK96+QLdeWP217aIGIpjB8BD4iugbK17Hz3ic+2xv/5Cj8/Qf jGmPta53UT55DDskUij3u0DtdMmYjRpTecPOjKw4IbTslxYNdDCxDWMMn15VcKRIva5lKPe6cLn3 RJtVQwoNrsABJ/Wog/IJKJ4mPwAnM1Sx+CvPIFaAU6GAu+HKn3sKCEcnN6SAEHCy7wAsxblsY+su qiyFdEgFHUmRn7s360Q7T7o2YsxKSONiFeGYxpGUeIjhblNMZ9kDHu6D/oTke5jMDSpeuA90X+cE lGA27LkPmZgGJcRBBuRhbxrKM8H4ccQBM0DB/UUxU2xUbEzYcJVrorjH1ZoXenJklCWkD7dShBKa rXAMDYdzucy+TJ5yJFUehXwmio4fIJtQ+W93n9mijcdZqGeX1HOXKOaLAwpYjpeCcS6rhVNF6KDr FWCWI7mX/PR4IYGBYbnSG9YEBWMUww+0c7cm52OINAgf8NiMrdwa3uvLetlehwEWCKyrbmAHHJtM qOD3W2R7Pb5ngYencG25Jxw8+rR8sts0nc6gMyte95LH5/wHHaJ4cAplbmRzdHJlYW0NZW5kb2Jq DTEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDM2IDAgUiANL1Jlc291cmNlcyAyIDAg UiANL0NvbnRlbnRzIDMgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBb IDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0yIDAgb2JqDTw8IA0vUHJvY1Nl dCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL0YyIDU3IDAgUiAvRjMgNjEgMCBSID4+IA0vRXh0 R1N0YXRlIDw8IC9HUzEgNjIgMCBSID4+IA0+PiANZW5kb2JqDTMgMCBvYmoNPDwgL0xlbmd0aCA4 NTQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImUls1ym0gUhfd6iNRdNguh/qFp mJ1iyy67Us6UTc1GlQWGtkQGgaYBJ8pj5InnNuDEEgjHVpWlsrt1vj733Nt8jGaLKw4MoqcZY0Dx hW+Kg/IERLsZhc1scf3AYFPh5yixv77N1uTmLlrd360iJ+Rkfnm/vIrAmfuSKjckq+/7zOjqL2fO JSW3cdHE5gCcUu7MGeOecgNy2+Ttn5jzJbpFBNEjiA5BABehy7gPiirLsSatVPyYayif4KIsal3U Vb/75QC0200hVOD7od1ImAs3RW3KtEnqrCyc6OurgzKfvixk9nTEHf1pN/36ck95L5taS4iw/58L 31UwZy6H6NLKovC9zuNap3BZJs2u5T1S50yCL9WU+ohyt6FT9obKa5TmLqwKx6PkOTNlYZXjHGH+ a7AuLQfERWpNrLJUm9j60ln5m01wZPPkGNsIU7fwiEm9dgOBrnWBUjksTbLNap3UjdEndlBcjqpC TNZjRF6INyzhthqXOs8cLsmzwyTRGMlKm+cs0bArU52fGsB54Cqk4WyCZoSlW9+xyJFgcFsdtH6j K+t7G2VT5iPJoJO5HJGm4UBaHdkgXIicgJLDvu2ifZz86zBKNAaiqTCnjweotxqWny5gb8q6TJDr xJVAWFdkeC61Q6x+bYflj1VH2Or8bavyCwieSrOL27c3kRQFGYwm9QxQIN8E4gOgrY6xV+CDztPq j7BC5aJR6kyYR7CUGGAdNZGHTKZMdIqdUw3nmPSnknpO1H8VVzUSV8/W5kEX9uyf9/2wGO1b6U3P 0RFxL5wUX6M6t1M00a8a16HEdFfLb54T67F7pHjnXO03HMEc2S+tD0ljsvpwOjoHvSv52TyeUedy Un1NfLzHlneOkGTZnX5yfL/UhL13lvY7OpBgxAbV3qc6z+0Ix3mOkcQyoCc3VdWc5rIfopK+b4j2 689DBC4sm3pbmuonLNMU+6EatERg+88L3rjch+L9lrPiaxK6cNXkOaZgb4fDwWSbbQ0PNd719nYd SaOn3pNGfLboN3QQjB4fDR/PeFfXwA2YHa/2kexT83hYXOvdDmuz+MfxKcmSrIqLcnGf/fhRLi5M aZvoW2LKpxrW3XjbaHBYgF/iKsK/tOSraPa/AAMA8k1QiAplbmRzdHJlYW0NZW5kb2JqDTQgMCBv YmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDM2IDAgUiANL1Jlc291cmNlcyA1IDAgUiANL0Nv bnRlbnRzIDYgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2 MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag01IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9Q REYgL1RleHQgXSANL0ZvbnQgPDwgL0YyIDU3IDAgUiAvRjMgNjEgMCBSID4+IA0vRXh0R1N0YXRl IDw8IC9HUzEgNjIgMCBSID4+IA0+PiANZW5kb2JqDTYgMCBvYmoNPDwgL0xlbmd0aCAyMDk2IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJtFddc9u2En33j+hg+kTekWVSH5bdN1/H 7nXGTXMd5s50nDxAJCQhIQGWIKOqv75nAVCgLDntyx3P0JRE7J49u3t2+e/s7OJ+wlKWrc7SlCX4 w7/FhC1mU5ZVZwlbn138/CFla4P7LKfL9uw5eniX3T29u8vi60l0/ubp5j5j8fnlPFmMr6O7P2rZ CPNTfD6ZJ9Fbrjre7NgkSSbxeZpOZovxVfS2K+1Xafw5ewsIUwchYefT8WQxWbDszVmUjuPsy1k6 c7Bm7Go+XszZIlkQMmBQbROnV5EuuryVWnlTp6K5vE7GM3cq20jDCp13lVAtK4TJG7kUhnFWcWNk PJlH3+J0HgkANDkv+bIUrBGltDe5Vq07Vw4eRXh1o1ud63LEbsxO5ZtGK90ZCwlBpeP0Kr2ioJ6j R74TjSjYrS6kWrNP0c3j7ad4xFa6YVVXtvK84e0/cBlfzqNxfD5PErLAJIXQo2BSmZarVvI9Mdm/ 4JsjdPGDgnep2NP97TSZXY0ZHe8MOGg3gj3eZqxtuDK1blr2PP08ZtmmMyNWyq9xmkTCpfXo0ZE9 DVPBW0BjgExWvJEgFZTLNUFoNVsKclywrWw39vzDe8dBzk3LlGi35FI3X5kRzTeZixFbxpMk6lr2 yw1+mke/OTi8NGQt+A5mNew2bMmNzFmnCtGUO+J9aBzMh5C9J8NMl28YGOuUg/Pxzfs4TdMh6cRa 8Hl/d4tsFUSkplRQor7Jos+lLGW7I4NroUTDS8eFLT+bj+f084jJsRgz/MZqnju+W0M/cuBCeWpl 64FLdeyWjKCIKptzOuM+UFp5y3hDpVTVQIJi2hNOhx2lsrT1uCx1/vUAWPD0PEE1OMJv3L+86XLJ gVZLWJXeF1FjWrTAGjFS8KAEkHqguY2IvBuhjHBnKEuCLCgdHDbi906AeuqNRtgcVdLRoFcwUriO kEXHDxlbNbrCiVwMW8ajIwsv6dUNCoPSBg3oGjFE4NuQjNWt98xxXX4ROaqeq8KGMjTov5MATa2M A4fQUb70nSOAHOd8wDKaApGJmn5S+ydVVy3xZO/uRewBnaBY/6hFI4WiKvbHj7joE/mg3H+jq0HY R/rmu4JVyF8JymyyeY0qR2dTkJbaY8YpwD7gJYGvUMZ87XpkwECrD3Rj3zprDA8UrEAlHmGCSS+O viXv6RcdJ1HjYnJccBQ9hMM2Ud2ZTZDWI4s2uuMoArSK71xIwzB4CMICkqoTPjaXcLk6wcyGU9u5 j3RBPnBVumU7ccQkYip8TJgr682ArEHdwT/OOfL6Y03Q636SaIu0FU0llUtdgLrdCPWPwf4fQfqM ZvEVJJou8Ijr0o8fmz4KooFlyDBSsW+pnWlFNToRBCXPDgpK1yCnfSqHZfqiOqm4vfBC2aCwBjPK iprv81f6zw7XUfC10YRoKw5Ia+JZEo3ogiBxLbQgGaQi+L3DKoX7hpla5HK1c1OphzwKQs5lZZXJ 5QkXLa2ed0oBGx7HxuBhRKWsZOvGRB+n3XTchPI8uolJUt7PcbuOYZuZjKeX00u3zWRHK8Oge2mG 1vZLEnDwB8htP8MaWpZ6ORu66XcReXJ98hZ7+YJ/P4mOrAeDVWds+mggOsaw+7DJdL7wZfZg5YzK sqoo44XN+J4vX5ev2rfLBoVIYUC++XCRC5uh3b6GA3+GcfqgXKig1lYIVg2I1V5S6N/RtBo2bEvl PChzDAPKR77hSDyUGoVba+oo6TYOuaKHVxi2UAICaMahPMGmGp2aLYeNhHHFePGFWH1Z/jZkovhg Z1nu/PNUkduNRAkb0Qa/KLkD0LBKvna+2dECX7BguJ0RAQkOA37lAAOyIimneUnmXU/uG2EecemW eOrrrSzazXDUtlsh1KkJGVSpr1GXEder9od+FX0xrd3C+erA9ZuTAVZaK4ivUFsB2lGRWdLdmmsL LqzCVD9W3Gxfv9bP+2GkrPT3m0Hw6DcMfWpYOQHktvbzrqHiQTHVvIEMyhoxjPteHYrD02uUEljK qO3/UpwcLjzc9tD54NUK7nlffoVEVwnib1DLN8qpyr518HBnKAAD9TZ+jaOyGzyyEfwwxxyg/YZE 6+v3HtW2A9Awy90p4eJFIf0D4I1XoiViiYCB0ZrvSs2Lk2xSNBvu3tJWuizdKKGSpy1MIBWQTTu/ j9/jrKSGNyu00eHuE1IzkJqfAorL6+TaodAHg9lNe2rHU+1zONZk6ymta8EpdEOLUbuhVSGs/xzI CqBs0e193u02f7As7is3PST571FsraO+4Qei5QTK+CWu13pe4t4v+JgbFklAccrdfB659J1bbPPk On2VuZOyMngTOpDrnLZ+RuVBGxyWlbWm5FvwIFKr72iYxK1xt0FJX+GwZx1OMMhkWdKHTxF9VANV 3svFp/iEYBxq9kB/Ri/lkio2dO3Jd5XXtCL5PtO/ht61JVpK9bUfnwrKT2Wum6+jF+9v1DaW9R/y YeV5CQII2dKuwPN+gcLWUAsabafYHBiTrncNep+itmNin+zvpm/wTsO9gvq8HHO1dKNT+6lFQZ+U kwxqOOoXr7CxIeUcoQaTEFo3TcrwBnH8emiXbjcmqHIDu6AQm3BR7uLLvjH6VYM5wl1N7cXeH8TW 8+MvHz9kP47cf/buV+oR+/np7r/00MeHp7s39PnDf24eH/c34cl9cczG6Ww+o7jT2XiaXi9YtgWG x265u/hZYOcry4v/xZfok1warvTFk/zzT31x2ziNzRu9atkHYTPu+E8xztNZcnk9XkTP7wk9vYLg K1jHV9PP1vdddvbXANc+noQKZW5kc3RyZWFtDWVuZG9iag03IDAgb2JqDTw8IA0vVHlwZSAvUGFn ZSANL1BhcmVudCAzNiAwIFIgDS9SZXNvdXJjZXMgOCAwIFIgDS9Db250ZW50cyA5IDAgUiANL01l ZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRl IDAgDT4+IA1lbmRvYmoNOCAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250 IDw8IC9GMiA1NyAwIFIgL0YzIDYxIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDYyIDAgUiA+ PiANPj4gDWVuZG9iag05IDAgb2JqDTw8IC9MZW5ndGggMTYyMSAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQpIiYRX226jSBB990eMWnmClU3MzXb2zZs4s4lyGSXMSqsoD21o2z0LNEvD ZDJfv1XVYLBNZhXJwUBXnTpVdar8RzQ6v/aYy6LNyHXZFP7g39xj88BnUTaasu3o/POzy7YarqMY P95GL9bNQ7R6elhF9oVnTa6eltcRsyezcDp3LqzVj0KWQv9uT7xwat3yvOblO/OmU8+euK4XzJ2F dVundMu1X6PbkcsmvuPNvTmLrsD42fOfj1/vrs7GrLliD492MLUivPO0uny8v189XK3ohful7U5D 62+45nnCzh6/RDePD7YfWsu7MyZzVu2kJidTNnEdd+Eu0ImVqLjORF4xXgpWKbYW8HIlyqIUlUgY 1ywROi7lGr6AlafrS891Lxw7+gaE+YawCeEOgzAkk2Cdnru+4dFnFwGb4cNsZD2JlKPhq8avNpaG qJ/5CyfAQy9WtBPs7jJiVclzXaiygnB4xZZ3l+z+63PEag2wj6C++K+OPQmnU2tpMpCpEoObJKKo ds27RSVVztQG7IlTdl4sNAxPr1eXLFaJiDVaLkUq+ToVcAuoAu4SuGF7ofXddkNLQJKLUlUqVqlG VNveM3tq5QaN7C5f3FeHLdOUFTz+B9JoiYr8cKaF1gCQkEW/AR6KFt1yeN6iwnA3qsw4BQMPzBdt SMLExiorADNAfZMQOwRLh9e2N7VqmSYy37J1qsD73tMhl17L5Q0YEpg4VWpkZp8CnmrFZPsUsAPK rdAECQGXKt3TAiY7RzyOVZnwPKb6wwLzw/mYve0EVuRODBkCVhXyuSe1NEzi6+Ad2q6lroH9rDLB CgW3IG+dbx3vAK4mjnQhYvmpiTeAjFye+qVImxZB19uSihm+KmKi2pWq3u721WSc1AWVLERPmKXJ GMV2UNROW4Ge48/8GTXTTYXB9pq9q3zZTwUWqsYgeQ12gYLYVIOJEJlF8kVcETbouaNC36dmU6qM 8aqCUtRQlTmjQH9wdIYJ5y2N70zXsqI+aJycdGD46nQ0LA+BwXMIYszkBrEnYzzd6U+P3B6n7H+o bJ1ZPUr7QjU90invVKeCcNaKzipHsf0uS9tdWCpHpnnKnsS/tblF3GuSWygVDVhKCs3I7LCmBf6F szDmKYWaos0xDGjagVJPkZqsTis5QTpOpQZSotbfILEaKHSEMz6RpyFdOzZjz0JroPwAJciSkUdo rIaPPRclcdHjIT7godGfooBagdSe1DsdqdQQvo8VygjN3iiw6DR8Dya5SXFgchCwRejMQ+YHizYN n0UOeFO2pJzGO4lNUpsE/yKRvu85Hk00zOO+e4gADWysuYZKT1NKUK0R/uEQwQhRp9mx0HYSjRV9 3KlWj72BgceiXQ2FgKdhiGcyV6navlOHtU5PB99hVtClEWbMzi/yQNMUVFpil67f6d0DMowB7Ose FKkNmrVIFVbgW1d65PUmhzFYgkzUKS+x4MadtCfiUy5b4PvpSJ1z4hzdomJw1ERgnHS0ffNjrTgq /y/YH72pTNAxQQ2Zh/G2U4Sn8ie81zSXpl4AxEhzb8Q7zER206wBg2Hzoe7ojHQFh4zkRy7YTnDo xgNz+60D01rw91TxhN1cjZmikoBO4Ekim0uABPxB+qC9dW9kFxBzUUoQpDFry6TntjHbzN5rnCj0 hgKxQ6DfpTCpJyAKMG26JB8U47itwM55HzM+HIYLYwVWWA3K9CuElDJOm1dZ9bqh7+00qtMpjfup qsnCGr319zFT7QPt0U9ddWQAMfWMDAzsRnvN3FirTjKO9LUt+eEublIU7brtiGUCzuO5/o6GzvAU 9fNHoR71XK/bjkV/ANC+IQmYyZrsiwEznnHAGDexKkRLXp/ZoUYeWOYGZaNdsEmazT7KPH8xN3ja /a+/fwyPr25nyUS847nUmT5cW5qSONoAzQ+WtNrReaNauapYBu45bHo0qZtmNhvEnrdM6QpI4SkN f9if8/7iMLxFU3HSmE6UMJ6awmIbIZI1VD9thPuhUIpY9DcH3U52jVvMgdRQnmuzmpJeI5oPwZxM s+CVdb9YAyeYe3Mk1w0c372AyzdAc1ev388/iywTaXr+lz2Dn1Wx1DxX50/y5091flmaGROXalOx Z5js2EwEzwP5dYPp7MKZWy9G5rcCb4F1uBW8kutVNPpvAInp+70KZW5kc3RyZWFtDWVuZG9iag0x MCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMzYgMCBSIA0vUmVzb3VyY2VzIDExIDAg UiANL0NvbnRlbnRzIDEyIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3gg WyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTEgMCBvYmoNPDwgDS9Qcm9j U2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjIgNTcgMCBSIC9GMyA2MSAwIFIgPj4gDS9F eHRHU3RhdGUgPDwgL0dTMSA2MiAwIFIgPj4gDT4+IA1lbmRvYmoNMTIgMCBvYmoNPDwgL0xlbmd0 aCAxNTUyIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjFfJcts4EL37IzI4klMR TVKilrllbCWVVLZyWDMHJwcQhEQkIMECwHGUr59ugNRi0XIqVYpMAr28fv269Xd+df06JQnJN1dJ QmL4B/8tUrKYTUleX8Vke3X95ktCtga+5ww/Hq7ug7cf8/Xdx3UertJgcnv36nVOwsk8ixfRKlj/ bIXm5q9wkmZx8I42HdU7ksZxGk6SJJ0tomXwrpPuURJ+y9+B0ck0ShfpguS3V8Hd+ubThw/rj7fr 2yjMv0OAUx+gO5bNsswdS6PEvU6mPuwpWc3IfL7EsO+DWy5FmMTBf/jBwb/h2v0tGCe1Krk0zvV4 9vMsiWbe0Kv3N4TRhpiubZW2YCdMMzSbgVkqSSk2+GDDNW8sKdHt4b1ze+QyInm4jIMHjEThB6CG 8eHpn7RuJTeEak4KLfgfO7BmmBYFLweUkihZJkuXfgUOL8BzH3zuTHWedXSatbOZxavE3/nUcOKC oztCSdtbONx2SBScdIaXZKM00ZAvLSQnTDV2FABhiFWPHodxoD07qP8PnAhIXW3OE70PVPGdMwvY +bOv0QS4PgLtJQSrOeOjLpjqZEm+K9EQW3HIxxihGkKbkpS7htaCUQlkpCVtrTvRdHXBNQRD3t/k LqD8TwiDVbRpoIbuzJPeBHw1/iu6BJgg+66xQhLeqG5bkZayH46U1pCKhmk82IAPpEMWFJw3Ix5K b9aGyB33Fc6oxljdMQv5HEL1iEXk1cZyrNH+lGi2Lnx/4HImNXDAWPgYAc5zRFjHAXh5cG01bUwt /FGA0AHqS2V7t9FQ5DSazqdzX+Qczjm+eZ4Ba1qqrWCdpBqrY8EwxH8U6B4u0fQkopZLKSw6tL7F 9A/j4wVBgt4yJ28GQr3t70Ooho8RkFHIHTk2QIDQIKbCWMxRQde8+OmiKomGKJA4pOfL0HDjTfqp mZS8xhBPGuhYuH6jbX1LHHdVHPRJqXEHT0rUS/izKbkGmu/avjX6mvpqG1Vzsj1lzACgqEfxa6G7 VQmGJVTfdwRoiFRAxr4n4Al4Umj0oU9BSscdgUGXiOspT7WTlbGuPnARiY+HnxId6AbJ96ScZHF8 huSRyKAgqhb5CBhsPI1Qq7u2xJLXYltZzGtACzPt0AeBEXIIymH4eIbQHfDr6OGekQ6dC+KGTASf ToIBD6YwUogGMSk9no1UtMQmRpqCQWhYZak8UosNcqMBEBBBLOJLAiWraGuIaTWH26MwmhDxcUGl 2IvpLPbpYM20e0ilcSIANke7/i1WD3odO2xMjaDK5yV2Wgdvdz6MFg5YJ1LghTxUoJ1AVTD6lF48 Uv4xxj4xDMjxDDgKwXSFH9SOyIwpXTqlVc5Er/EIh5CuUgWE8CBKW/UEoYdi1J20YuJEBIqy5cYV BXtXK0laraxiSkbk7gwoyUeHyTF0DpzT0KsQ+8EHGLsi4u1hupxNoH2cI8MM0n2q4w4z5xk5hIN6 ZFU7l780mq/i1X52QB/2raCciWf2MAABaNQvM/1mB+1a7LBXeynAieQXsNb6YTbGFMysVSisAphP 21YCq/A8NLQrfgs1a7XAgj6nvEhMd6csBZoAgzVHyglTm6MRqw7LaMcqsuka5o/DLdiiXJVBCQq3 fjwIoBkusdARha+86v0YplruhzS8LBXrasjjUoVg6U7Pl+5kmUXZarXyC/PNgbY3SNswWQZKXli2 k7m76QA3LWfiBbvE/X587FdQzK0nOOhV5bY9V1VhXbPBGYz4Ud2eXVzDeRb0TPi3EtLL05Y3TuEK 3m9uQulhy7kUsluChwqC77Jj3qCtNPZR2zkFA7GF6ctcTY7MIS+2mpadm8aiYaDJoJfCDqsZLYZr mKnfVvfXex4y2+Gk8bp3msDXgEfbCJrXtIChE7F+NkplANqvoWsVL2EDMiNq/gVXgxauCAT295TM /ObPCC+UqMEwc0d+Du1/KiEm97NvUV/z+f5IAjSerxb+9+v7rthdv+F1DRvj9T/hHBZ3Jgxt1PWd +PVLXd9oPzyZhlFPvvjZ6LUMW4CEyXSarKJFcP8ZI6Rbjo/APjzKvrn41vnV/wMAuFud6wplbmRz dHJlYW0NZW5kb2JqDTEzIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAzNiAwIFIgDS9S ZXNvdXJjZXMgMTQgMCBSIA0vQ29udGVudHMgMTUgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5 MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xNCAw IG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMSAzMSAwIFIgL0Yy IDU3IDAgUiAvRjMgNjEgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNjIgMCBSID4+IA0+PiAN ZW5kb2JqDTE1IDAgb2JqDTw8IC9MZW5ndGggMTI5NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIicRW247bNhB990cU8yi1a62ouwv0YbvZTROkQZAIBYrNPtASbbORRVWUstkg39pv 6QxpSfbazR0obMiyKM6cOTNzhr/ms/PrABjkqxlj4OMHf9IA0iiEfDvzYT07f/yKwVrjfV7Q5W52 4zx5nl+9fH6Vu4vAmT96eXGdgztPYj/1Fs7Vu0a2Qv/szoPYd57yuuftPQS+H7hzxoIo9TLnaV+Z R8y9zZ8ihNBC8GEeekEapJA/mjmh5+Z/zVhkYUWQxV4aQ+qnhOzGyd00cu4bAWoFDS/euMx3RKeh 16KE5T10GwEXzy6haV2WOapThap27k5FnCx8L9pZxp3dkeUThq1RkBo46EYUklfyPb701mWxI1ot VU02eA3PLvM9Ux5YcvCpQYRxM49lLKO4b5z9aHgrQIu6I8f4W6JV6JSxV2x4XYtKe4ONwAuTMLE2 XqmtAFnrjteF0IRCC02ANPx+gcZj50+LoRV/95gvE9Va1KLl3Q72SohyiVBg1aqtWW9FIaQbxM4Q IEHBhVNBWLBuHDueO4993/nN9R1Fm+/wRlgreAE3iPB/6+L1jC7IDV7J3VZQiFJvYaVaKJWs1+gN 2cav6jstSwtbF8omC7PinaioOIrjXUUxW1OhTXwIiwjixWJI/AtifUr4ivCpdsvH2y8tqjgLvGwq qr1iWlm7pqYouocFVYpGFh0uyhqu5brHDLEhNmY9ZcZRBhnzEoij0HpijKIpZo7PgpCCNXlJAsOA j28Oa1GcpNni9B3tm9PLe1vNxp/m3/ghy/mPyMcHVIMQJcAZWgNJ2QhONTNnUYQLH0y4+DLe4a4w 80gKKI/m/9w8mAA6P/3yjZ9DbBlCuL66hBf8vlK8hCeP8Gmc/O/AAoJwUZaS+pRXyF3Lt6LDbhwW R3wspnzf7TYa7K8d1diNr10YXzSy/t1wsoRKcXCbUJIHEh94/Dz+PpPl71GaUxv7to19auPQXwxt PPQizOEFieBRRz9s5kM9OlCHIPWtWRSm4FiYxuUjYbJ9Av+IqtRfK01BHHnBJE2l0EUrm0H7ydgP xjyvS/onW1j1ddGZCXInUYZr89LhYBuQFTjylgK56GujYDfhrXc8JIxjWVviyHG3QQJrHDtmsKCB Qm23fS0LTkqIkk/QloRotQuY3Hctr3Wj2m7AOrZLo3DkLau9SaLNTl5spJ1A40ihOWs5WIoTkGN/ wUbIX8sVqUkzqskxScHt2SjY0yAlA2a7oHp7V4hm4mqwelUXqqRYriu+BjNXedWLM5B4+miaChlE Gs4ejP6lGcTm9oDot5IPbXpjBvFocAj3UuF8wnncmcCHGE/Wwt4J4FPpnpx+Mu8UNIYsipF0+LJk jxJ+mPTg1oN8c2RjwmNtiANQ+zFROGLEOVbiQZ1iWuqi6svB1hZTRPdL0d0JUZ9ieMyAhpONN1G3 68CBFbQg2qYVHbfluEvgZO8jRWHOVjhbgGOCNkqL6bhyQMhhsXweMyaDSzfwnV5WhollpYo3Z/Cx cifyKIrJ4S6c//Bz2odGwu+P1EWgX0HQWtWvLQKM9sjTg7x8TAXtidYwqZDUdiB1crA3xe0wGSb5 Tk8o6AnBSlXV7gA9pudQUkbBir0wSEPSD4bH32SR2nH8rF/enz8W262oqvM/3MR3ZCE1r9X5S/n+ vTq/bK39olWrDl4JI2HWGU0ocFkYsoWXOjcW7lrQI7SPj5Jb4/wqn/07AEesBl4KZW5kc3RyZWFt DWVuZG9iag0xNiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMzYgMCBSIA0vUmVzb3Vy Y2VzIDE3IDAgUiANL0NvbnRlbnRzIDE4IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSAN L0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTcgMCBvYmoN PDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjIgNTcgMCBSIC9GMyA2MSAw IFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA2MiAwIFIgPj4gDT4+IA1lbmRvYmoNMTggMCBvYmoN PDwgL0xlbmd0aCAxMzg3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJrFdNc5tI EL37R7jmCFsWZpDQR/aU2HI2qdhJ2ezuQfFhBGNpNoihZoY4yq/f7hkkwEJRUpVyWcJAf0z3e6/b b5Kzy5uIUJI8nVFKQviBr0lEJqMhSTZnIVmdXb59oGSl4TpJ8eP5bOG9u0vm93fzxJ9F3uD6/vVN QvzBOA4nwcybfyuF4vqVP4ji0HvPioqpLYnCMPIHlEajSTD13le5vUX9x+Q9OB0Mg2gSTUhyDc6T NSfnPM80YUVGnqTaMKOJfCIGHsjSCFmwnLzOMlFffvJp7DHFNtxwpWvb278fErLkJJWbTVWIlBme ESN3AWlAp3TqAqJfxVMu/Cj2vqIzdCMrg0GXkETgD+IwtImVTBmRVjlTJzMwa2bIhm0JK0sO74sC rNMvPg09brRNJPkDwvdm2h9dlzwV5/AGhMXHz2uRrk8l0kSyGTXZsFY+/fX6Kpit+lesDMsrvmvD lcx4KUVhbAh0hnc/XCVNsJbvNWcZV/4o9C4cKrCxaLCBZESxgrjmmfPipdt9WAcFtDh61iZwq/q/ ctbDir8zRGhyP7/6eHs7v7ueX1un7XLyGp5oyArMZ+sOaNM8Dg2WrbniAEfS9fGXK1QUeoP5N8ML jX2+Ee0uehk/L7jlxa7mxChW6FIqgyddDB8DP/kPiD10xAa0R8FwPBwj2r2RfUhHjuwjMo2DSUzi WYh8X3iflE+nnkx5Vtkr7gJ3xCGOKb4MrqhzNnQPh2Q22j984AUchXwsubJwdSn1aU08HAUja2Mh 7uzkzg4wDsCoNMLEAuDDFSmVNDKVORw3zasM4ZHn9qkFjwZcZZywJbbU7H1iBi+YfzRKt6pMEwiS KrHkWV3iiz0ib+ZXZIktq0SeWTDnMv0CNg1QusbRY0AS2/Y8l4jwZ7Ry71h1I2uxWufwCyfRcrMn HWuwn0rARlYnrxFIS94CJnNILyAePGJpKivg1LMwaxA6FBGzw167nMFOHBu4LLw3HJAGsaGI2sJR G5BAfWHv2FYd6Y0l2abOpKY9lsmRWuRsmXPbNyBpDhyEPw/FeRAGIYwJO3rqK5w/onCcwXwU9+kI 5s6KqWyXSJ2r43FAAVhA5LbRDjivXMggxqBxOKMYtD3pJAwtiOu99kOvJjh8wLSDz7bDgvMM+rvc HsLnz6YxO2/YfmjhimtrDJdGQcn2tVtyPEmlwSM2rZHXk15fKmpLQk9JNzlQbMS4o78rUEMcMOeq VNzUAHS+dWtSaJfggHZr+8sV3elcP816qvAO/D45vGEBLxx1KvgsjKhHp07XHHj1E2V2PEeYKg4A tQsCnrAwfYXpHMANZwBeAbuF1rgF4WFq1rzIqKxUKTVWrS3dgwhXo3gUx7V2R4eCOwynTj4X3r1d YihyzJIu9JQrRKPCmHS/DEczGkydn+RwIWp8/U5l7tvGfiKwne3wl2HYMomtEVZOkEhQVBDTvL3M bU/J+zGpbnS+G7DxdFT9Sa/oN4F+t/qTftHfrw2nxd+Nx7b2/4tVY8ehcPhA74TefjWC4lh41JGd FZAJ8uQHcvQZbMDwG0ILqnZsl+8q3GffbXM9QxzKZodbHRkb0dniJHhT9cpWd6FJKqi51GxZLabG vVsWHdcUg+0orZQwW8i13crjSxIdxUHUsFPDPglKUjvp4GG/+cK/WHWfX8AdAS1/gN6+urJcy67T LnjcwlzsUXrRrWR/qvow14YgP5qPVrLrWduRnWMyTpr8/XHs7TedaTCpWwY7xJDOJm7qf6iW28u3 fLPheX75jz8OPZEKzQp5eS++f5eXV8pRN1XyyRBoptVWe9I4ILCPhONZMPEWbvlfcbwF3uHW5NGG nidn/w8ACh+92gplbmRzdHJlYW0NZW5kb2JqDTE5IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1Bh cmVudCAzNiAwIFIgDS9SZXNvdXJjZXMgMjAgMCBSIA0vQ29udGVudHMgMjEgMCBSIA0vTWVkaWFC b3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCAN Pj4gDWVuZG9iag0yMCAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8 IC9GMiA1NyAwIFIgL0YzIDYxIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDYyIDAgUiA+PiAN Pj4gDWVuZG9iag0yMSAwIG9iag08PCAvTGVuZ3RoIDEzMjkgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KSIm8Vttu2zgQffdHLAbdF2lhKbpacp/qOE6bIAmKWLvAwsgDLdE2W0n0klRT 9z/3f3ZIyZfETrLYAosgNEVRwzNnzszwPOudXQbgQ7bo+T54+Ic/SQBJFEJW9TxY9s4+Tn1YSpxn uR4eezPr6i6b3N9NMnsYWM7F/egyA9sZxF7iDq3J9zUTVL63nSD2rGtSN0RsIPC8wHZ8P4gSN7Wu m9Is+fZDdo0QwhaCB07oBkmQQHbRswaunX3p+VELK4I0dpMYEi/RyBDD6M4OPGvUnjPmtWQFFUQx nHVmT3k2GHpu1Fq448DqBReV+QjnoFZMglzTnP2Sd4sSCnQnVwhYNvMvOAPFQR8extvDhe1Z1PZj a8mkaiG40L76xO0gth6pHr/pLdTW+yPP6usBd+E41440rCxYvTTQkQjf9VM/1UTMrHnJ868Scl6t eU1rJaGRtID5BgFTGN2MYS24ynkJFdmgH0rwoskpkKJgGgwpnwHOn7C1xXpVm8Oz3/DINRGK5U1J Oqxmgz7tcjKGQ7xgwJ0ExDWiglMJgv7VIItv0wZ8scWwOy3nBc1bl40insoljuLYyCU5KZeBH2zD fVUrWpYYwAb5+CxsP7X4mgq1gSspG/qaaOI0cFNtRWum0wc6VTIyZyVDCzt3uUC89ZJK4w1OMRbl /vVOXsgWbhV0QQWtc3wiUsN/EnirInVBFBebnTYLnjcVKsDtNgduOAgHrUo07bcj2/di68+W4Lkh 2ExNfB6ZWr0GTwIeCByJFwdrjyuWr4Bg+HBtLRhVmND2IEZVnNAqerUiWh+d2nFAeeG4prXRC25Y CoKxKGBNlFazu7UTummX/DNr5j/ATTPvDjI+3Lp9+EirCqPYhz/sgWexnElS8z7c4Ktr/L9nP350 j5/Ql9Kc39kYGCQ4ajtj0SZmLvhCtd++y1BwyNNWg88cu9SmuHhEgi0iCpgIga6MudDVoasf90YS JYXbpsT0IVK964PWnaipggtBFgoKPTrI4sIRFU6wAjkLmjue56rvqr9PwTuuT2xprOYYEiyYXh8I GAhcfNUnYkiWWG33HB4qYha8zqH2+pjHn+Lw/jaD8/P/xN8Y81y+ydd83rIVGrZg10lOExD+7wTc kA2mdKG9eaGaZ7oEYgbINRfqPYywaEvJ9g1Cd5qclEZHOkMxRaBAYe13YEFQWwP/hrBdSS1z5SBV z5k7riWz6CRxx1x9Il91QGndh9E+/rBl4bjYIN4XAD6jqcx3OQE/mwqO5+IHvrnBdDN9jZnFD/CZ CsGWLfoxQRYVQwXgw7lgMucUJ/iQ2ckQ7zYbGy351hK7YqifW2pw5QL3TNHXPlyYSjKZ3oze76sA vmtETo/dPLxUjRosvLX+wPC1k4m+oexZE8iarJqlo6gsyYsMHXTtt7k67KiRiyU4NO0nPdlRg8h3 g7ajjmzdWdSKC/k3jIrC9FS0+nIvTT03QBNB5MbD4dB01FvsLoSWrdyOWmCJqx8KtmSKlAve1Iqw 2sWLkN5pquRF+w7a8tJu2NfQcOhHPozb3GE5jKnOFUyUg2zaZce0YYpC6HmdcetS0ApVi8IY9eH3 KQ7DKA7To3yxrlm1LSrHLnxZtm8+VAwLhcRSceCAdr9dxOYhKRH5audaiDrt7o/bojlVKK9f09Db gyY1XKJMcq3WJ0jxIqBNoWIxak7shl1c/cgN/WHSik6zftZBPztM7zNTBc+elDiYtqW61VWK90Y/ 8gZDN7FmnzWVZEn1ElrHpfTBYJxkvX8GAOtqfEcKZW5kc3RyZWFtDWVuZG9iag0yMiAwIG9iag08 PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMzYgMCBSIA0vUmVzb3VyY2VzIDIzIDAgUiANL0NvbnRl bnRzIDI0IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEy IDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMjMgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BE RiAvVGV4dCBdIA0vRm9udCA8PCAvRjIgNTcgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNjIg MCBSID4+IA0+PiANZW5kb2JqDTI0IDAgb2JqDTw8IC9MZW5ndGggNTUyIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJZFJNT+MwEL3nV8zRXiWu7eaj2RPQFkS3Qoi6y6HikA1u5d3E rhIHaH/G/uK1E9oFoUgTe+bpzZs3vhLB6JoDA7ENGAPqPvfLOGTxGEQdUNgFo5sVg13rzqL04TXY oNs7MX+4mwuccxTNHi6vBeAoTWhGcjR/26tGtt9xxBOKFoXuiuYAnFKOI8Z4nJEJWnRVn2L4SSwC SrIEojHhGc9AzBz/0jRSHw38xClFqlRtoc0AhYgRNmETj0PVALtwgNKQ0tRY/A7EtwD1CVgdWivr NoRbXZL30gaxjMIjnlAkWwvCH4q2LjTMGpwkiIR9H0+ycsmFaWUI08sQ1isX8oSNY8/kdHAyTsdp r2PZqZ2CB3U8mvfiR5G+eKGkJZ1We0WUPamcqT1x2nYEnmVV/b3VW9PUxVEZLcN3DCU0TQbP11ph nqAXnDqVPsCzGjy+d/6cVPcLQi+qgJky1hWqFwU8hCRlPAWPdHbYojp8mWKDFkbDtDG+y2vZmK39 arkDkU+Qi7IlXVmRoiTdn7N1M7kvGltLbcFsYWrqfWdlA6tSSV3K8yrOI7EEyaZV9uCwVSX9fSdh afSz0SfSDboZ+noi20hpw/+lAQqPUzaH9ErgLEbhYM4aU/SjB0bDO4s5oTnN/TQsJmOWZ4O/y+7X YXQj69rtYvTx4Y36xY4+jQ0rWVq3qKHHhABmMU1zkqHNvVdfOPku5dhdKn/q+89F8E+AAQBnx+8K CmVuZHN0cmVhbQ1lbmRvYmoNMjUgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDM2IDAg UiANL1Jlc291cmNlcyAyNiAwIFIgDS9Db250ZW50cyAyNyAwIFIgDS9NZWRpYUJveCBbIDAgMCA2 MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2Jq DTI2IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL0YyIDU3IDAg UiAvRjMgNjEgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNjIgMCBSID4+IA0+PiANZW5kb2Jq DTI3IDAgb2JqDTw8IC9MZW5ndGggMTIzNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIiZRW32+bSBB+9x9RjfoEJ5uw/kV8b9TBCT0HR0DuLkr7sMZre6+YRQvEdf/6m1ns2q4inU6R NsuyM/PNN98M/pR2bmZ9YJCuO4yBi3/4z+uDNxxAuuu4sOnc3CcMNhXu04yWfefVCqM0iKMgtSd9 q3cX+7MU7N545HrOxAq+l1KL6ne71x+51mdeNFwfoO+6fbvHWH/oObfW5yY3R8z+mn5GCIMWggu9 gdP3+h6kdx1r4tjpPx02bGEN4XbkeCPwXI+QWbMmz2GqyoOWm20NSc1rsRNFTTbv5zSeuM6QbF8t tLOZax1tv1jTLzakWwFhUQtdCHSnMinqA75ClO4X27F7I9e1fIwZk00FsaiEfrPZyBIrx6SB6Jkz cieM0L9a6VZWsFJZQ6iAFyuoNS+qnNdSFRWoNcgadvwASwGZKqVYmUvrRhey2uJTrUDVW6Grrnmx Elra/ZH1Rgs6afcUnxbkH9c9ZaX0t+oMiN2y2xZQveU1RtoZPKoApVv/e1kJME6+lzmXBeHCd7yq ZFWDea5A7src8Gvgn3CXWpRci1X3mEHXxE1/w2hls8zbPAx4dKXl0u67VlPTfXS736pcUCTco5e6 C3tZb1VTA8oHb2cmEvLECwJ3aAX1TRZoXmpFZ29yRURRYpjJKXjPdVw2MnJ13EGrWG74WZpVvSHj 7c6spTEcOu6wj2JBri6lftRIoWqZibaMVFgEzDeal1vA/DGDLG8ICgLmqJGqybYtJdX/r12rpl6L 56qCD4oM9+LC3LW0PXStLi3oB9f6SndYO5GvTb0wBarZTq3kB4SKrF8Ra+Lzgz0eoTdzYrLgFSwP WJHdkfBi8yvV2MZHrs2OSMPU7QnOgmvysNRarIUWRYa8oLzr91ruJMvzG6VtRpNlwwv5o22fLgl2 iGffM1Fid1UnQJelK4SgmqzRI0UqG10qlDoqanVBYY5lwqR+RqtqrBjXq6rVqKRKcjQzLrTKxKpB fZLXs9izy3mC7IsPRcvwVYY5LzYN36BxmyDqtoCg2FCfvDNCLJpIudxJbBgohd5J7EgaHai7gs74 sh2QjhlzaHEWvtG4eeuMx8MLVWMnoF7RWynqhudGnXuJkj2qQx+ZwUZVKK5vlBapbNVKYonbo14u U2sVy3BAe8NLyVoXRaUpgorC0ldKV6cJsykqM+b/e3huqc2Q9V07gTKFs0gSzUiloClVXU8FasUC PvoJhMlHWHKcZsZR+hC8Nx1PnzRIFtMwSF/Aj+7oLvx8EUT3YRQEcRjdA375Bpaf/AGzRTwN4C5M pnM/fEzOkvDnc/jLZsijH8d+lIZB0oXg76c4SBJYxBA+Ps3D4K6L/qfz5zty+onIfk4hWlA3py3N 8/AxTAOEYrNba9Ge+dHLOdBlkBdE7NuMsZM1JfCcBLCYHXNBvI/HG+EigocgDsII/goR7VVYvEmJ BhcJRS8Qh/cPqYFPT8cUfk2Tgj0G8fQBHw1Nn8J5iNDQahamEeZ/djojV/BEvyN8lFZsjxFBOH2e +zE8PcdPiyRwPp7KNXQd71gvNnBu2cRr+3zeLA839wI/bHl+8ye5kJmseKFuYvnjh7qZ6nZuZlqt cc4I82Fp05w4YLPBaDxxPOv1icSD/UlH6B2PmPvVBA/Szr8DAHFOoP0KZW5kc3RyZWFtDWVuZG9i ag0yOCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMzggMCBSIA0vUmVzb3VyY2VzIDI5 IDAgUiANL0NvbnRlbnRzIDMwIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BC b3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMjkgMCBvYmoNPDwgDS9Q cm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjIgNTcgMCBSID4+IA0vRXh0R1N0YXRl IDw8IC9HUzEgNjIgMCBSID4+IA0+PiANZW5kb2JqDTMwIDAgb2JqDTw8IC9MZW5ndGggMjI2IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJJI3LasMwEEX3+opZSgtLGtmyou7axgk1 JRRHdBOycI1iBH4UOyZNvr5KwsDM5cDc8+aI2ChAcCeCCDJOPEaByVJwPZHQErHdI7RzzK65rws5 0I+dK6pd4ZhVNFlXrxsHLMm1NNzS4u83TH5+YYnSkpb1sNTTFZSUiiWIKjN8RculeyBkR1fG0vjL M51pcGuCKV+hNU/R5/JzFVvf977rxDfLJQ1NmOthFFW43UbxPo1MaXpppvF0hr1vzmEcnmbLgWGq c8sNPXwx1LRu/R3F9ogQjw954ci/AAMAsYFCPgplbmRzdHJlYW0NZW5kb2JqDTMxIDAgb2JqDTw8 IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIg MTgxIA0vV2lkdGhzIFsgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IA02MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYwMCA2MDAgXSAN L0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvREVJQkpFK0NvdXJpZXIgDS9G b250RGVzY3JpcHRvciAzMiAwIFIgDT4+IA1lbmRvYmoNMzIgMCBvYmoNPDwgDS9UeXBlIC9Gb250 RGVzY3JpcHRvciANL0FzY2VudCA2MjkgDS9DYXBIZWlnaHQgNTYyIA0vRGVzY2VudCAtMTU3IA0v RmxhZ3MgMzUgDS9Gb250QkJveCBbIC0yOCAtMjUwIDYyOCA4MDUgXSANL0ZvbnROYW1lIC9ERUlC SkUrQ291cmllciANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViA1MSANL1hIZWlnaHQgNDI2IA0vQ2hh clNldCAoL24vZm91ci9wL2UvbC9FL2h5cGhlbi9maXZlL2VxdWFsL0kvc2l4L3NwYWNlL2gvci9Q L3NldmVuL2Jhci9GL2kvTC9hL3MvXA1wYXJlbmxlZnQvdC96ZXJvL2VpZ2h0L3BhcmVucmlnaHQv b25lL25pbmUvVC9rL0EvdHdvL20vQy9wbHVzL3RocmVlL28vYy9cDUQvZC95KQ0vRm9udEZpbGUz IDMzIDAgUiANPj4gDWVuZG9iag0zMyAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVu Z3RoIDMxMzkgL1N1YnR5cGUgL1R5cGUxQyA+PiANc3RyZWFtDQpIiTxUaVQUVxqt6qa6GiXN2J3C mS6swmWIG06jIKBxEAFFBYSmWrZGoAFZDgo2KBIFjIKCQCaSCRk0KG4sjktsRNxA6rHoGERHjduY mVFjxIkaNZqvzOucTIEmp965P96533fuvfW+jyQcFARJks5BwQvnLQqeEpiz2pqZZh268pdYQnIl pTEKaYxSGu1Q5UTifCflWScHaYyTSw7+6LX69UmKayB/qax8g0405DnDoVHI9Z1gLaEkSfWaIoPB a5rBYAjMyS20ZqZn5LtNTJnk5unn6zdVRj/DMHoO4/RhnDGMM4fRZxh93QJScyxpblGFeflpK/Lc Fq5MybHm5liT89NSp7m5BWRnuxmHOue5GdPy0qxr5NtfXRCk/BGOJOFEEBqCGOVIcAQxjiAmKInJ BOFBEJ4E4U0Q8wgiSEEsJIlQiohSEHEEkUAQU+RcCAWhJLyIDKKCqCdpcgpZRL5QjFesVvyiHKfc 4fA7hz85FDlcpNypTGov1UP9TxWsKlC9poPoPfTP6nnqtepL6ieOKY5tjj+NSB5xeKT3yIKRHSOv aDSTXxeRYENKyfLalTGpgjEZjae66/F7F7B7ryfXpTL/JxA4mKAHTeurrqfcm4I6pITLYGOeRcPU YCA5k6opmuqa2DoWa/R4QiDmzD5yae+DC+AO7+k1YBRJaBSVUi0YGRGHQ4QJR+BIE0TiCBEiaA2s QiTwcE0pJcIqBuFrAq0pQdIH8q0Dgia5shQ6mZNb7qf2c30ZiU0hbEFB+eZC3teabtjgp96SXb6s WD9lF06GuRBWA9mPONMWZiPt/gEei0fMyL2+t4wrOVna0aEHuhG0oGi35ac2cI0x28KrwtWaSiTt LyDhkJzCX1wQ9pf203hdDCXQEHSEsifiIFmNzMkRySci7JPFWF1AawrCe2jwB556dffUmdv65k0t xXu5/gz/pnA2IDQ3OpYPEumBq809Ny7Fz16/pWhzEVeS9X7QqgKcj4N+HzHkD7LlI2qld8W1XbpB KRumMc/mtGR+wume2Zpszbf0Bzfu27CLa8szHQlhQyLyM5fy9YnU33afO9TP3rUtjYlNCXPjy4Ud Kt1gc3NFaRN/eOPpFYJ+4SLztMgl9fXxXJH5SBGVd/5K2W720Y9dQPGyjR8RnDtNwn3Z7FoX5PHj I+QBMJvG1fhnKg4a3bBC9q2QGhh8DmcOq9yGYJb8I5wRNMjey8GfeRRyF49KMJcULucgBtoRfop7 adtG6uiFrsrt7FMxdHFguGlsWHh9g8BvEKiC8xfXDrDgfwLUA7ymGMFGBKZu7WMRdv/T2KV7qZOk Ymkv0xNELwhflxnD+0ZFeOHJemwC5/B7nO7lD9e/+n4w9A5WeJvNaSv5KiBPfXunXa2TGmyddSeq qyqq2cqGqgbu09rKrTW87qXRrmRMmYsnGmMPnlnDldV92FS+R93Z2Nfaz7a3F6bv4WsLa6z5ek3D GqkOkc9EaOtTSpVSLdNrd8djxK+hjcYx9jrqvEpT3A253bC8W/uDmIpgq5gu6l5IG8DAfBN+OL2O 0z0+XN/e8m/9QMog1o//c+T4sKbk01ZO92J1yfwUT/3My7NhFAfOV24M8rrHgdDAhEYnB2bOqH34 dPCT5hunzZEytR7vY/zm5EaYp2x/8OS7z9tu9luCOU1xDyzshio5d0cRDsm5fwS3mWvr7kWe5Vqy 4nfEs1g518fD0OsJ7/R92dh1kP8Q+8wLNVjVm1ZmbckqLasuZaONA6qjto//auNhRPMjICBCH2Vj lhctMQexXmZ05SrquGVrX5+5j29YuSOhKkWtAYX4HJH/lQKGJnUng+wBAi0FYAMj2gNMQzMAKgQn UapNWwYZEAFpusfS9y7IRONUqY7CFQKMV+HFdgsVJkAGMqiOg4qCNtUJrKImCaoDkM/gCpXuDoyE f1DyO5DWi+TFbslZdieeZ/JOUalLQ3IXsFg7+SFMhzAY03X9y75sczs/S4RMUzi9YifVmBy3fSmL PcdjPfbAft/iP8Li2zebT5wfetqSZWhfiPBAftsIzjLgO+f2uD3cthVZVeks3izcslvmCJClam+r rmnlX+28dR8W64VNjLHYmLuMC02bWxTAYoVkeaq631qe1MH/PadpkZd+yHYigiSkBVcRvNBXKA7p 7LqfpC9cIErArvg0JILXPATLhADsBUm0zg5t2BVBlD1PuGO3vC+ofmtBggcCb3RdFtgpaRkw2q3C TbvFX4DtCI+W+3i/7eMNSdCOWfpXV/vlihJ5N/lIFvBBdq0AvnYL9hV+I0xHw1u80wU+FfAybJN5 oxC2Ca/slrHDLJiEoFYmeiM4LBM7pNHMvdgneCqHG94GY0PYAybBaFX/QF13K7/7wGfHjukFl1Wl 1pICLjo7bLORxRTUygSxsyiuRZ6ij1fl698KOIUgcOi86yv1STQDCfbPcAKS13+grNNZABFhZ1lT IHYf2ilJCKZ3g6Zb29sNSNStl864ID8ooxsrmtY3crY1sS0z2QXzC/Ii+ToTtf3A1cZL7KGD5YXN /P51NRlZ+my6JjGuRp4B36VeEbzuzKKe4Oc3Lh/vQpxuvQ+9FSYzujNLYkPMs9jwpGNHG3fs3lXH 7/9CrD7FtreVlbbxmhIRnneTVxE8lKNoHmBWI2q1dU7kLBYbkoDq/+bq16Dq6SpKP87Pl00J8fSB hPjPI1kcMB//wYAngtILtINXDp7s49+YeYDktLWdCL4bMvMvFzRbuoz/X2W1xkRxhVGR7s6WJrt1 h5HKwEytCSSVSGOKkVawPAQ1NFoZcFteFhDQQEHiIzxsaZCKJTy6IF22ogQoUAJlreEhIS57QaJI kRLUDYVNBYI0QrQR+034SNO7u7FJ/97cx7nn+875zhEJvDCJuftZ5A8xPPL+vshRrKiyohJ8Jsd+ uv0LhbuX+QZyKdytEaG+uPHw/NyTidlndB34Tp8IB9A9BLRDLqPD8IK6VMctLn9QkRQUlBfPxyd+ 13RcTG/Msgx6Vss7GNDuB1cMwC1b/VFAtwl0hbAZW0vXmHAQTnL4l3KkemQcFDwI7T65dr04YbuA 2gKNVIPT9hromdGzD1G170Baok4AI4rSH+t1uyXIIbuhgunpv9M7xs8aP5VELAx09pWVLINGC8ZJ ibBL7HN4LLdyoAlHDQOl660cYdglDJE1mCKBH1rpMFU6T4FAFeVugc2QiSGQwa7K9+g8YlL7k/uP 3Qi9/xYrgz+oFU8JZko3lRiO3gqZ+w+PNxxihrsV7OqNk7N7Bj5WSY5r7X4OzbSml6hWQmkNzkgQ vF6HYa+gHhvSjhO7WHYSdy92Rl7eTI6CkWEHer4aSG0SavPyKs7xutSM9GzRdP5Ep45PysrOyhbZ mb63JfO65iXR0b3wI9N2ramzj/+1Yu/XIt7+23HH5cqfxwhfW3uppEbsOF2WluqJ1x2vPhr6nP5U ZSeZtcpTdpZrGLbPdKE3q1m4cjbTEMdH7M9K0ImsdRS9o234yMk33QPVzM3u+113+J6hLyNErA50 5CKgJm0mspdd75DFzR+Bd1CiSee193EbblnZDu+B39MV8BCkbznfD0NRiXzUk5mlKRu8CQGdqI4R 1BhLgCWwQCi0Zxb4k1An76fRy1RsKmwX2BlbSsj1YD7gUHp8Op1cv6G3ZFs3Ulg9do9IZVLaSfIi D+rlFeApOfQddN11IHBH0OTq4tgsHTUenaj8RHBynmzRQhxhJ1iTPAZrXOm1i/VFV1TNBadqMnm/ qBDpoMhOgAr3S7CJ9scmSXYjGAsJDGt6ARv6Osx8c2PJCb3o/Lh2icRboMuSaW+2KdkAHpztcENE lRBR5V+a0KYqvFxUX+95d97QI7BWQvJzukUaMXfGpDAtiTGGaOrvYbEBufqcq/niYJy18kGJil3o vWjWtxxXVV0oLyjxDMGNxWlR0lVTnDAiYTDpY04PDJz5nWenwHV6+LEDxgLtsm1UMd/3ciUWxbmj H2VE8jmnKutyxC+MxV3tnlBErRZrgYtBLlyaRANDjXNDnvnBw7aWUQf5spFoGyAafUC/CJE0/M3J Gpp7I6UhBj9AMyXZrLhHMFoaV0IUvnwXAxWsFV0k0JNdSuiTjQo1lq8VuEDrLVeYxnJurUD3TwGj Pl8nTxhwex3MNeC+MiUU6Z+XrXeVM/9fV71af524kTfkZfd/AeiZqJcKZW5kc3RyZWFtDWVuZG9i ag0zNCAwIG9iag08PCANL1MgL0QgDT4+IA1lbmRvYmoNMzUgMCBvYmoNPDwgDS9OdW1zIFsgMCAz NCAwIFIgXSANPj4gDWVuZG9iag0zNiAwIG9iag08PCANL1R5cGUgL1BhZ2VzIA0vS2lkcyBbIDUy IDAgUiAxIDAgUiA0IDAgUiA3IDAgUiAxMCAwIFIgMTMgMCBSIDE2IDAgUiAxOSAwIFIgMjIgMCBS IDI1IDAgUiANXSANL0NvdW50IDEwIA0vUGFyZW50IDM3IDAgUiANPj4gDWVuZG9iag0zNyAwIG9i ag08PCANL1R5cGUgL1BhZ2VzIA0vS2lkcyBbIDM2IDAgUiAzOCAwIFIgXSANL0NvdW50IDExIA0+ PiANZW5kb2JqDTM4IDAgb2JqDTw8IA0vVHlwZSAvUGFnZXMgDS9LaWRzIFsgMjggMCBSIF0gDS9D b3VudCAxIA0vUGFyZW50IDM3IDAgUiANPj4gDWVuZG9iag0zOSAwIG9iag08PCANL0R0IChEOjIw MDEwNzIwMTEwNzExKQ0vSlRNIChEaXN0aWxsZXIpDT4+IA1lbmRvYmoNNDAgMCBvYmoNL1RoaXMg DWVuZG9iag00MSAwIG9iag08PCANL0NQIChEaXN0aWxsZXIpDS9GaSA0MCAwIFIgDT4+IA1lbmRv YmoNNDIgMCBvYmoNPDwgDS9SIFsgMTIwMCAxMjAwIF0gDT4+IA1lbmRvYmoNNDMgMCBvYmoNPDwg DS9KVEYgMCANL01CIFsgMCAwIDYxMiA3OTIgXSANL1IgNDIgMCBSIA0vVyBbIDAgMTAgXSANPj4g DWVuZG9iag00NCAwIG9iag08PCANL0ZpIFsgNDEgMCBSIF0gDS9QIFsgNDMgMCBSIF0gDT4+IA1l bmRvYmoNNDUgMCBvYmoNPDwgDS9EbSBbIDYxMiA3OTIgNjEyIDc5MiBdIA0+PiANZW5kb2JqDTQ2 IDAgb2JqDTw8IA0vTWUgNDUgMCBSIA0+PiANZW5kb2JqDTQ3IDAgb2JqDTw8IA0vRCBbIDQ0IDAg UiBdIA0vTVMgNDYgMCBSIA0vVHlwZSAvSm9iVGlja2V0Q29udGVudHMgDT4+IA1lbmRvYmoNNDgg MCBvYmoNPDwgDS9BIFsgMzkgMCBSIF0gDS9DbiBbIDQ3IDAgUiBdIA0vViAxLjEwMDAxIA0+PiAN ZW5kb2JqDTQ5IDAgb2JqDTw8IA0vQ3JlYXRpb25EYXRlIChEOjIwMDEwNzIwMTEwNzExKQ0vUHJv ZHVjZXIgKEFjcm9iYXQgRGlzdGlsbGVyIDQuMCBmb3IgV2luZG93cykNL0NyZWF0b3IgKGdyb2Zm IHZlcnNpb24gMS4xNSkNL01vZERhdGUgKEQ6MjAwMTA3MjAxMTA3MTEtMDcnMDAnKQ0+PiANZW5k b2JqDXhyZWYNMCA1MCANMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDEwMzE4IDAwMDAwIG4NCjAw MDAwMTA0NjkgMDAwMDAgbg0KMDAwMDAxMDU4MiAwMDAwMCBuDQowMDAwMDExNTA5IDAwMDAwIG4N CjAwMDAwMTE2NjAgMDAwMDAgbg0KMDAwMDAxMTc3MyAwMDAwMCBuDQowMDAwMDEzOTQzIDAwMDAw IG4NCjAwMDAwMTQwOTQgMDAwMDAgbg0KMDAwMDAxNDIwNyAwMDAwMCBuDQowMDAwMDE1OTAyIDAw MDAwIG4NCjAwMDAwMTYwNTYgMDAwMDAgbg0KMDAwMDAxNjE3MCAwMDAwMCBuDQowMDAwMDE3Nzk3 IDAwMDAwIG4NCjAwMDAwMTc5NTEgMDAwMDAgbg0KMDAwMDAxODA3NiAwMDAwMCBuDQowMDAwMDE5 NDQ1IDAwMDAwIG4NCjAwMDAwMTk1OTkgMDAwMDAgbg0KMDAwMDAxOTcxMyAwMDAwMCBuDQowMDAw MDIxMTc1IDAwMDAwIG4NCjAwMDAwMjEzMjkgMDAwMDAgbg0KMDAwMDAyMTQ0MyAwMDAwMCBuDQow MDAwMDIyODQ3IDAwMDAwIG4NCjAwMDAwMjMwMDEgMDAwMDAgbg0KMDAwMDAyMzEwNCAwMDAwMCBu DQowMDAwMDIzNzMwIDAwMDAwIG4NCjAwMDAwMjM4ODQgMDAwMDAgbg0KMDAwMDAyMzk5OCAwMDAw MCBuDQowMDAwMDI1MzEwIDAwMDAwIG4NCjAwMDAwMjU0NjQgMDAwMDAgbg0KMDAwMDAyNTU2NyAw MDAwMCBuDQowMDAwMDI1ODY3IDAwMDAwIG4NCjAwMDAwMjY2NTIgMDAwMDAgbg0KMDAwMDAyNzAz OCAwMDAwMCBuDQowMDAwMDMwMjY5IDAwMDAwIG4NCjAwMDAwMzAzMDAgMDAwMDAgbg0KMDAwMDAz MDM0NCAwMDAwMCBuDQowMDAwMDMwNDg4IDAwMDAwIG4NCjAwMDAwMzA1NjIgMDAwMDAgbg0KMDAw MDAzMDY0NCAwMDAwMCBuDQowMDAwMDMwNzA4IDAwMDAwIG4NCjAwMDAwMzA3MzEgMDAwMDAgbg0K MDAwMDAzMDc4MyAwMDAwMCBuDQowMDAwMDMwODI1IDAwMDAwIG4NCjAwMDAwMzA5MDIgMDAwMDAg bg0KMDAwMDAzMDk1NyAwMDAwMCBuDQowMDAwMDMxMDA2IDAwMDAwIG4NCjAwMDAwMzEwNDIgMDAw MDAgbg0KMDAwMDAzMTExOSAwMDAwMCBuDQowMDAwMDMxMTg2IDAwMDAwIG4NCnRyYWlsZXINPDwN L1NpemUgNTANL0lEWzxiYTFmM2RiZjc3NjBiMTgwZWY0ZDU5ZTVlZWJlODNjZT48YmExZjNkYmY3 NzYwYjE4MGVmNGQ1OWU1ZWViZTgzY2U+XQ0+Pg1zdGFydHhyZWYNMTczDSUlRU9GDQ== ------=_NextPart_000_0002_01C11115.E3203A10 Content-Type: application/postscript; name="submitted draft-ietf-rmt-bb-alc-02-mgl-7-20-2001.ps" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="submitted draft-ietf-rmt-bb-alc-02-mgl-7-20-2001.ps" %!PS-Adobe-3.0=0A= %%Creator: groff version 1.15=0A= %%CreationDate: Fri Jul 20 10:58:42 2001=0A= %%DocumentNeededResources: font Courier-Bold=0A= %%+ font Times-Bold=0A= %%+ font Times-Roman=0A= %%+ font Courier=0A= %%DocumentSuppliedResources: procset grops 1.15 1=0A= %%Pages: 11=0A= %%PageOrder: Ascend=0A= %%Orientation: Portrait=0A= %%EndComments=0A= %%BeginProlog=0A= %%BeginResource: procset grops 1.15 1=0A= /setpacking where{=0A= pop=0A= currentpacking=0A= true setpacking=0A= }if=0A= /grops 120 dict dup begin=0A= /SC 32 def=0A= /A/show load def=0A= /B{0 SC 3 -1 roll widthshow}bind def=0A= /C{0 exch ashow}bind def=0A= /D{0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /E{0 rmoveto show}bind def=0A= /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def=0A= /G{0 rmoveto 0 exch ashow}bind def=0A= /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /I{0 exch rmoveto show}bind def=0A= /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def=0A= /K{0 exch rmoveto 0 exch ashow}bind def=0A= /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /M{rmoveto show}bind def=0A= /N{rmoveto 0 SC 3 -1 roll widthshow}bind def=0A= /O{rmoveto 0 exch ashow}bind def=0A= /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /Q{moveto show}bind def=0A= /R{moveto 0 SC 3 -1 roll widthshow}bind def=0A= /S{moveto 0 exch ashow}bind def=0A= /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /SF{=0A= findfont exch=0A= [exch dup 0 exch 0 exch neg 0 0]makefont=0A= dup setfont=0A= [exch/setfont cvx]cvx bind def=0A= }bind def=0A= /MF{=0A= findfont=0A= [5 2 roll=0A= 0 3 1 roll=0A= neg 0 0]makefont=0A= dup setfont=0A= [exch/setfont cvx]cvx bind def=0A= }bind def=0A= /level0 0 def=0A= /RES 0 def=0A= /PL 0 def=0A= /LS 0 def=0A= /MANUAL{=0A= statusdict begin/manualfeed true store end=0A= }bind def=0A= /PLG{=0A= gsave newpath clippath pathbbox grestore=0A= exch pop add exch pop=0A= }bind def=0A= /BP{=0A= /level0 save def=0A= 1 setlinecap=0A= 1 setlinejoin=0A= 72 RES div dup scale=0A= LS{=0A= 90 rotate=0A= }{=0A= 0 PL translate=0A= }ifelse=0A= 1 -1 scale=0A= }bind def=0A= /EP{=0A= level0 restore=0A= showpage=0A= }bind def=0A= /DA{=0A= newpath arcn stroke=0A= }bind def=0A= /SN{=0A= transform=0A= .25 sub exch .25 sub exch=0A= round .25 add exch round .25 add exch=0A= itransform=0A= }bind def=0A= /DL{=0A= SN=0A= moveto=0A= SN=0A= lineto stroke=0A= }bind def=0A= /DC{=0A= newpath 0 360 arc closepath=0A= }bind def=0A= /TM matrix def=0A= /DE{=0A= TM currentmatrix pop=0A= translate scale newpath 0 0 .5 0 360 arc closepath=0A= TM setmatrix=0A= }bind def=0A= /RC/rcurveto load def=0A= /RL/rlineto load def=0A= /ST/stroke load def=0A= /MT/moveto load def=0A= /CL/closepath load def=0A= /FL{=0A= currentgray exch setgray fill setgray=0A= }bind def=0A= /BL/fill load def=0A= /LW/setlinewidth load def=0A= /RE{=0A= findfont=0A= dup maxlength 1 index/FontName known not{1 add}if dict begin=0A= {=0A= 1 index/FID ne{def}{pop pop}ifelse=0A= }forall=0A= /Encoding exch def=0A= dup/FontName exch def=0A= currentdict end definefont pop=0A= }bind def=0A= /DEFS 0 def=0A= /EBEGIN{=0A= moveto=0A= DEFS begin=0A= }bind def=0A= /EEND/end load def=0A= /CNT 0 def=0A= /level1 0 def=0A= /PBEGIN{=0A= /level1 save def=0A= translate=0A= div 3 1 roll div exch scale=0A= neg exch neg exch translate=0A= 0 setgray=0A= 0 setlinecap=0A= 1 setlinewidth=0A= 0 setlinejoin=0A= 10 setmiterlimit=0A= []0 setdash=0A= /setstrokeadjust where{=0A= pop=0A= false setstrokeadjust=0A= }if=0A= /setoverprint where{=0A= pop=0A= false setoverprint=0A= }if=0A= newpath=0A= /CNT countdictstack def=0A= userdict begin=0A= /showpage{}def=0A= }bind def=0A= /PEND{=0A= clear=0A= countdictstack CNT sub{end}repeat=0A= level1 restore=0A= }bind def=0A= end def=0A= /setpacking where{=0A= pop=0A= setpacking=0A= }if=0A= %%EndResource=0A= %%IncludeResource: font Courier-Bold=0A= %%IncludeResource: font Times-Bold=0A= %%IncludeResource: font Times-Roman=0A= %%IncludeResource: font Courier=0A= grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72=0A= def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron=0A= /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef=0A= /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef=0A= /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef=0A= /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent=0A= /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen=0A= /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon=0A= /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O=0A= /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex=0A= /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y=0A= /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft=0A= /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl=0A= /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut=0A= /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash=0A= /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen=0A= /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft=0A= /logicalnot/minus/registered/macron/degree/plusminus/twosuperior=0A= /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior=0A= /ordmasculine/guilsinglright/onequarter/onehalf/threequarters=0A= /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE=0A= /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex=0A= /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis=0A= /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn=0A= /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla=0A= /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis=0A= /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash=0A= /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def=0A= /Courier@0 ENC0/Courier RE/Times-Roman@0 ENC0/Times-Roman RE=0A= /Times-Bold@0 ENC0/Times-Bold RE/Courier-Bold@0 ENC0/Courier-Bold RE=0A= %%EndProlog=0A= %%Page: 1 1=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 10/Courier-Bold@0 SF(Internet Engineering Task Force)72 85 Q(RMT WG)=0A= 209.999 E 203.999(INTERNET-DRAFT M.Luby/Digital)72 98 R(Fountain)6 E=0A= 149.999(draft-ietf-rmt-pi-alc-02.ps J.Gemmell/Microsoft)72 111 R=0A= (L.Vicisano/Cisco)407.999 124 Q(L.Rizzo/ACIRI and Univ. Pisa)335.999 137=0A= Q(J. Crowcroft/UCL)407.999 150 Q(20 July 2001)431.999 163 Q=0A= (Expires: January 2002)377.999 176 Q/F1 14/Times-Bold@0 SF(Asynchr)=0A= 193.038 201 Q(onous Lay)-.252 E(er)-.14 E(ed Coding:)-.252 E 3.5(Am)=0A= 126.377 214 S(assi)-3.5 E -.14(ve)-.14 G(ly scalable r).14 E=0A= (eliably content deli)-.252 E -.14(ve)-.14 G(ry pr).14 E(otocol)-.252 E=0A= /F2 11/Times-Bold@0 SF(Status of this Document)72 259 Q/F3 11=0A= /Times-Roman@0 SF(This document is an Internet-Draft and is in full con\=0A= formance with all pro)72 275.6 Q(visions of Section 10 of)-.165 E=0A= (RFC2026.)72 288.6 Q(Internet-Drafts are w)72 314.6 Q=0A= (orking documents of the Internet Engineering T)-.11 E(ask F)-.88 E=0A= (orce \(IETF\), its areas,)-.165 E(and its w)72 327.6 Q(orking groups.)=0A= -.11 E(Note that other groups may also distrib)5.5 E(ute w)-.22 E=0A= (orking documents as)-.11 E(Internet-Drafts.)72 340.6 Q=0A= (Internet-Drafts are v)72 366.6 Q=0A= (alid for a maximum of six months and MA)-.275 E 2.75(Yb)-1.155 G 2.75=0A= (eu)-2.75 G(pdated, replaced, or)-2.75 E=0A= (obsoleted by other documents at an)72 379.6 Q 2.75(yt)-.165 G 2.75=0A= (ime. It)-2.75 F(is inappropriate to use Internet-Drafts as reference)=0A= 2.75 E(material or to cite them other than as a "w)72 392.6 Q=0A= (ork in progress".)-.11 E=0A= (The list of current Internet-Drafts can be accessed at http://www)72=0A= 418.6 Q(.ietf.or)-.715 E(g/ietf/1id-abstracts.txt)-.198 E 1.76 -.88=0A= (To v)72 444.6 T(ie).88 E 2.75(wt)-.275 G(he list Internet-Draft Shado)=0A= -2.75 E 2.75(wD)-.275 G(irectories, see http://www)-2.75 E(.ietf.or)=0A= -.715 E(g/shado)-.198 E -.715(w.)-.275 G(html.).715 E=0A= (This document is a product of the IETF RMT WG.)72 470.6 Q=0A= (Comments should be addressed to the)5.5 E(authors, or the WG')72 483.6=0A= Q 2.75(sm)-.605 G(ailing list at rmt@lbl.go)-2.75 E -.715(v.)-.165 G F2=0A= (Abstract)267.534 515.6 Q F3(This document describes the Asynchronous L\=0A= ayered Coding protocol, a massi)97 538.2 Q -.165(ve)-.275 G(ly).165 E=0A= (scalable reliable content deli)97 551.2 Q -.165(ve)-.275 G=0A= (ry protocol, hereafter referred to as ALC.).165 E(ALC can be)5.5 E=0A= (used for multi-rate reliable deli)97 564.2 Q -.165(ve)-.275 G=0A= (ry of content to lar).165 E(ge sets of recei)-.198 E -.165(ve)-.275 G=0A= 2.75(rs. ALC).165 F(uses the)2.75 E(LCT transport described in [3] augm\=0A= ented with a congestion control protocol that is)97 577.2 Q(compliant w\=0A= ith RFC2387 such as one of the layered congestion control protocols)97=0A= 590.2 Q(described [4]. ALC achie)97 603.2 Q -.165(ve)-.275 G 2.75(sr)=0A= .165 G(eliability based on FEC codecs as generally described in)-2.75 E=0A= ([1], and in particular based on the details pro)97 616.2 Q=0A= (vided in the FEC b)-.165 E(uilding block)-.22 E(described in [2].)97=0A= 629.2 Q(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66 E 207.017=0A= (wcroft [P)-.275 F(age 1])-.165 E EP=0A= %%Page: 2 2=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 71.587(-DRAFT Expires:)-1.012 F=0A= (January 2002)2.75 E(July 2001)123.726 E/F1 13/Times-Bold@0 SF -1.196=0A= (Ta)239.126 85 S(ble of Contents)1.196 E/F2 10/Times-Roman@0 SF=0A= (1. Introduction)97 123 Q F0 11(......................)3.56 G F2(3)11.5=0A= E(1.1. Related Documents)107 135 Q F0 11(..................)11.9 G F2(4)=0A= 11.5 E(1.2. En)107 147 Q(vironmental Requirements and Considerations)-.4=0A= E F0 11(..........)3.97 G F2(4)11.5 E(2. General Architecture)97 159 Q=0A= F0 11(...................)10.12 G F2(4)11.5 E(2.1. Deli)107 171 Q -.15=0A= (ve)-.25 G(ry service models).15 E F0 11(.................)7.45 G F2(5)=0A= 11.5 E(2.2. Congestion Control)107 183 Q F0 11(..................)11.88=0A= G F2(5)11.5 E(3. T)97 195 Q(ype of pack)-.8 E=0A= (ets used by the ALC protocol)-.1 E F0 11(.............)7.4 G F2(6)11.5=0A= E(3.1. P)107 207 Q(ack)-.15 E(et format for the ALC protocol)-.1 E F0 11=0A= (..............)2.72 G F2(6)11.5 E(3.2. P)107 219 Q(ack)-.15 E=0A= (et header \214elds for the ALC protocol)-.1 E F0 11(............)6.06 G=0A= F2(6)11.5 E(4. Procedures)97 231 Q F0 11(......................)8.57 G=0A= F2(7)11.5 E(4.1. Sender Operation)107 243 Q F0 11(...................)=0A= 6.49 G F2(7)11.5 E(4.2. Recei)107 255 Q -.15(ve)-.25 G 2.5(rO).15 G=0A= (peration)-2.5 E F0 11(..................)12.87 G F2(7)11.5 E=0A= (5. Security Considerations)97 267 Q F0 11(..................)12.17 G F2=0A= (7)11.5 E(6. IAN)97 279 Q 2.5(AC)-.35 G(onsiderations)-2.5 E F0 11=0A= (...................)7.11 G F2(8)11.5 E(7. Intellectual Property Issues)=0A= 97 291 Q F0 11(.................)12.88 G F2(8)11.5 E=0A= (8. Authors' Addresses)97 303 Q F0 11(....................)1.35 G F2(8)=0A= 11.5 E(9. Full Cop)97 315 Q(yright Statement)-.1 E F0 11=0A= (..................)6.42 G F2(10)6.5 E F0(Luby/Gemmell/V)72 769 Q=0A= (icisano/Rizzo/Cro)-.66 E 207.017(wcroft [P)-.275 F(age 2])-.165 E EP=0A= %%Page: 3 3=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 71.587(-DRAFT Expires:)-1.012 F=0A= (January 2002)2.75 E(July 2001)123.726 E/F1 11/Times-Bold@0 SF(1.)72 85=0A= Q/F2 14/Times-Bold@0 SF(Intr)5.5 E(oduction)-.252 E F0=0A= (This document describes a massi)72 101.6 Q -.165(ve)-.275 G=0A= (ly scalable reliable content deli).165 E -.165(ve)-.275 G=0A= (ry protocol, Asynchronous).165 E=0A= (Layered Coding \(ALC\), for multi-rate reliable content deli)72 114.6 Q=0A= -.165(ve)-.275 G(ry).165 E 5.5(.A)-.715 G=0A= (LC is a protocol instantiation)-5.5 E=0A= (as de\214ned in RFC3048. ALC uses the LCT transport [3]. Thus, lik)72=0A= 127.6 Q 2.75(et)-.11 G(he LCT transport, the ALC)-2.75 E=0A= (protocol is primarily designed to be used with the IP multicast netw)72=0A= 140.6 Q(ork service, b)-.11 E(ut MA)-.22 E 2.75(Ya)-1.155 G(lso be)-2.75=0A= E(used with other basic underlying netw)72 153.6 Q=0A= (ork or transport services such as unicast UDP)-.11 E 5.5(.A)-1.221 G=0A= (LC uses)-5.5 E(FEC codes to pro)72 166.6 Q=0A= (vide reliability as generally described in [1], i.e. all pack)-.165 E=0A= (ets in a session contain)-.11 E=0A= (FEC coded information in formats that are compliant with the FEC b)72=0A= 179.6 Q(uilding block described in)-.22 E 2.75([2]. A)72 192.6 R(crucia\=0A= l point is that ALC strongly relies on FEC codecs in the sense that the\=0A= re is no)2.75 E(request for retransmission of indi)72 205.6 Q=0A= (vidual pack)-.275 E(ets from recei)-.11 E -.165(ve)-.275 G=0A= (rs that miss pack).165 E(ets in order to assure)-.11 E=0A= (reliable reception of an object, and the pack)72 218.6 Q=0A= (ets and their rate of transmission out of the sender can)-.11 E=0A= (be independent of the number and the indi)72 231.6 Q=0A= (vidual reception e)-.275 E(xperiences of the recei)-.165 E -.165(ve)=0A= -.275 G 2.75(rs. In).165 F(some)2.75 E(deli)72 244.6 Q -.165(ve)-.275 G=0A= (ry service models it is appropriate that recei).165 E -.165(ve)-.275 G=0A= (rs send out of band messages to the sender to).165 E(pro)72 257.6 Q=0A= (vide guaranteed deli)-.165 E -.165(ve)-.275 G(ry of content.).165 E=0A= -.165(Fo)5.5 G 2.75(re).165 G(xample, in a push reliable deli)-2.915 E=0A= -.165(ve)-.275 G(ry model recei).165 E -.165(ve)-.275 G(rs).165 E=0A= (may send messages to a sender to continue the session if recei)72 270.6=0A= Q -.165(ve)-.275 G(rs ha).165 E .33 -.165(ve n)-.22 H(ot yet recei).165=0A= E -.165(ve)-.275 G 2.75(de).165 G(nough)-2.75 E(pack)72 283.6 Q=0A= (ets to reco)-.11 E -.165(ve)-.165 G 2.75(rt).165 G=0A= (he content or to terminate the session when recei)-2.75 E -.165(ve)=0A= -.275 G(rs ha).165 E .33 -.165(ve r)-.22 H(ecei).165 E -.165(ve)-.275 G=0A= 2.75(de).165 G(nough)-2.75 E(pack)72 296.6 Q(ets to reco)-.11 E -.165=0A= (ve)-.165 G 2.75(rt).165 G(he content.)-2.75 E 1.76 -.88(To b)5.5 H 2.75=0A= (ea).88 G(ble to track usage of the system, recei)-2.75 E -.165(ve)-.275=0A= G(rs may also send).165 E(messages out of band to the sender that conta\=0A= in statistics on their reception e)72 309.6 Q(xperience. ALC,)-.165 E=0A= (ho)72 322.6 Q(we)-.275 E -.165(ve)-.275 G .88 -.44(r, d).165 H=0A= (oes not require nor specify such messages, with the aim of a).44 E -.22=0A= (vo)-.22 G(iding unnecessary).22 E=0A= (limitation to the scalability of the basic ALC protocol.)72 335.6 Q=0A= (The LCT transport pro)72 361.6 Q=0A= (vides support for congestion control, and the ALC protocol uses this)=0A= -.165 E 2.75(support. The)72 374.6 R=0A= (congestion control protocol must conform with RFC 2357.)2.75 E=0A= (It is recommended that)5.5 E(the congestion control protocol used for \=0A= ALC be a multi-rate protocol, as described in [4]. In this)72 387.6 Q=0A= (case, a sender sends pack)72 400.6 Q(ets in the session to se)-.11 E=0A= -.165(ve)-.275 G(ral LCT channels at potentially dif).165 E=0A= (ferent rates.)-.275 E(Then, indi)72 413.6 Q(vidual recei)-.275 E -.165=0A= (ve)-.275 G(rs can adjust their reception rate within a session by adju\=0A= sting which set).165 E(of LCT channels the)72 426.6 Q 2.75(ya)-.165 G=0A= (re joined to at each point in time depending on the a)-2.75 E -.275(va)=0A= -.22 G(ilable bandwidth).275 E(between the recei)72 439.6 Q -.165(ve)=0A= -.275 G 2.75(ra).165 G(nd the sender)-2.75 E 2.75(,b)-.44 G=0A= (ut independent of other recei)-2.97 E -.165(ve)-.275 G 2.75(rs. A).165=0A= F(single rate congestion)2.75 E(control protocol can also be used, b)72=0A= 452.6 Q=0A= (ut this may limit the scalability of the session in terms of the)-.22 E=0A= (number of recei)72 465.6 Q -.165(ve)-.275 G=0A= (rs that can concurrently participate.).165 E(Recei)72 491.6 Q -.165(ve)=0A= -.275 G 2.75(rm).165 G(ay join and lea)-2.75 E .33 -.165(ve a s)-.22 H=0A= (ession asynchronously at their discretion.).165 E(An ALC pack)72 517.6=0A= Q(et thus consists of an LCT pack)-.11 E(et header)-.11 E 2.75(,a)-.44 G=0A= 2.75(nF)-2.75 G(EC pack)-2.75 E(et header)-.11 E 2.75(,o)-.44 G=0A= (ptional by)-2.75 E(additional parameters and pack)72 530.6 Q=0A= (et payload.)-.11 E(ALC has the follo)72 556.6 Q=0A= (wing properties when the LCT transport uses multicast to deli)-.275 E=0A= -.165(ve)-.275 G 2.75(rp).165 G(ack)-2.75 E(ets:)-.11 E 5.5(oT)72 586.2=0A= S 2.75(oe)-6.38 G(ach recei)-2.75 E -.165(ve)-.275 G .88 -.44(r, i).165=0A= H 2.75(ta).44 G(ppears as if though there is a dedicated session from t\=0A= he sender to the)-2.75 E(recei)83 599.2 Q -.165(ve)-.275 G .88 -.44=0A= (r, w).165 H(here the reception rate adjusts to congestion along the pa\=0A= th from sender to recei).44 E -.165(ve)-.275 G -.605(r.).165 G 5.5(oT)72=0A= 615.8 S 2.75(ot)-6.38 G(he sender)-2.75 E 2.75(,t)-.44 G(here is no dif)=0A= -2.75 E(ference in load or outgoing rate if one recei)-.275 E -.165(ve)=0A= -.275 G 2.75(ri).165 G 2.75(sj)-2.75 G(oined to the)-2.75 E=0A= (session or a million \(or an)83 628.8 Q 2.75(yn)-.165 G=0A= (umber of\) recei)-2.75 E -.165(ve)-.275 G=0A= (rs are joined to the session, independent of when).165 E(the recei)83=0A= 641.8 Q -.165(ve)-.275 G(rs join and lea).165 E -.165(ve)-.22 G(.).165 E=0A= 5.5(oO)72 658.4 S 2.75(ne)-5.5 G(ach link in the netw)-2.75 E=0A= (ork, the pack)-.11 E(et traf)-.11 E=0A= (\214c from the session and its reaction to competing)-.275 E(traf)83=0A= 671.4 Q(\214c is the same whether there is one recei)-.275 E -.165(ve)=0A= -.275 G 2.75(ro).165 G 2.75(ram)-2.75 G(illion recei)-2.75 E -.165(ve)=0A= -.275 G(rs be).165 E(yond the link.)-.165 E(Thus, ALC pro)83 697.4 Q=0A= (vides a massi)-.165 E -.165(ve)-.275 G(ly scalable content deli).165 E=0A= -.165(ve)-.275 G(ry system that is netw).165 E(ork friendly)-.11 E(.)=0A= -.715 E(The k)83 723.4 Q .33 -.165(ey w)-.11 H(ords "MUST", "MUST NO)=0A= .055 E(T", "REQ)-.44 E(UIRED", "SHALL", "SHALL NO)-.11 E(T",)-.44 E=0A= (Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66 E 157.517=0A= (wcroft Section)-.275 F 2.75(1. [P)2.75 F(age 3])-.165 E EP=0A= %%Page: 4 4=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 71.587(-DRAFT Expires:)-1.012 F=0A= (January 2002)2.75 E(July 2001)123.726 E("SHOULD", "SHOULD NO)83 85 Q=0A= (T", "RECOMMENDED", "MA)-.44 E(Y", and "OPTION)-1.155 E(AL" in this)=0A= -.385 E(document are to be interpreted as described in RFC2119.)83 98 Q=0A= /F1 11/Times-Bold@0 SF(1.1.)72 137 Q/F2 13/Times-Bold@0 SF=0A= (Related Documents)5.5 E F0=0A= (The LCT transport that ALC MUST use is described in [3].)72 153.6 Q=0A= 2.75(Am)5.5 G(ore in-depth description of the)-2.75 E=0A= (use of FEC codecs in reliable content deli)72 166.6 Q -.165(ve)-.275 G=0A= (ry protocols is gi).165 E -.165(ve)-.275 G 2.75(ni).165 G 2.75(n[)-2.75=0A= G(1]. All pack)-2.75 E(ets in a session)-.11 E(MUST contain FEC coded i\=0A= nformation in formats that are compliant with the FEC b)72 179.6 Q=0A= (uilding block)-.22 E(described in [2].)72 192.6 Q(Implementors of ALC \=0A= MUST also implement a congestion control protocol in)5.5 E=0A= (accordance to RFC2357, where the congestion control is o)72 205.6 Q=0A= -.165(ve)-.165 G 2.75(rt).165 G(he entire session.)-2.75 E=0A= (Some possible)5.5 E=0A= (schemes are speci\214ed in [4]. Congestion control MUST be inte)72=0A= 218.6 Q(grated into ALC through the)-.165 E(support pro)72 231.6 Q=0A= (vided in the LCT transport.)-.165 E(It is RECOMMENDED that ALC impleme\=0A= ntors use some authentication scheme to protect the)72 257.6 Q=0A= (protocol from attacks. An e)72 270.6 Q=0A= (xample of a possibly suitable scheme is described in [5].)-.165 E=0A= (Authentication in ALC, if used, is to be inte)72 283.6 Q=0A= (grated through the support pro)-.165 E(vided in the LCT)-.165 E=0A= (transport.)72 296.6 Q F1(1.2.)72 335.6 Q F2(En)5.5 E(vir)-.52 E=0A= (onmental Requir)-.234 E(ements and Considerations)-.234 E F0=0A= (ALC is intended for congestion controlled, multi-rate deli)72 352.2 Q=0A= -.165(ve)-.275 G(ry of objects, i.e., reliable content).165 E(deli)72=0A= 365.2 Q -.165(ve)-.275 G(ry).165 E(.)-.715 E(All of the en)72 391.2 Q(v\=0A= ironmental requirements and considerations that apply to the LCT transp\=0A= ort and to)-.44 E(the FEC b)72 404.2 Q(uilding block also apply to ALC.)=0A= -.22 E F1(2.)72 443.2 Q/F3 14/Times-Bold@0 SF(General Ar)5.5 E=0A= (chitectur)-.252 E(e)-.252 E F0(ALC protocol consists basically of usin\=0A= g FEC codecs in the form described in [2] with the LCT)72 459.8 Q(trans\=0A= port as described in [3]. Thus, the terminology used in the description\=0A= of the LCT transport)72 472.8 Q(and the FEC b)72 485.8 Q(uilding block\=0A= are inherited by the ALC protocol and this terminology is used belo)=0A= -.22 E -.715(w.)-.275 G(In particular)72 498.8 Q 2.75(,t)-.44 G(he de\=0A= \214nition of a session for the ALC protocol is the same as it is for t\=0A= he LCT)-2.75 E(transport.)72 511.8 Q -.165(Pa)72 537.8 S(ck).165 E=0A= (ets used within the ALC protocol are specialized v)-.11 E=0A= (ersions of LCT pack)-.165 E 2.75(ets. In)-.11 F(particular)2.75 E 2.75=0A= (,a)-.44 G(pack)72 550.8 Q(et consists of an LCT pack)-.11 E(et header)=0A= -.11 E 2.75(,a)-.44 G 2.75(nF)-2.75 G=0A= (EC payload ID, optional additional parameters as)-2.75 E=0A= (appropriate, and the pack)72 563.8 Q(et payload.)-.11 E=0A= (From the point of vie)5.5 E 2.75(wo)-.275 G 2.75(ft)-2.75 G=0A= (he LCT transport, the FEC)-2.75 E=0A= (payload ID, the additional parameters if present, and the pack)72 576.8=0A= Q(et payload are all part of the LCT)-.11 E(pack)72 589.8 Q(et payload.)=0A= -.11 E(The out of band information used by the ALC protocol consists of\=0A= the out of band all information)72 615.8 Q=0A= (required for both the LCT transport and for the FEC b)72 628.8 Q=0A= (uilding block.)-.22 E(The possible means for)5.5 E(acquiring this out \=0A= of band information is the same as for the LCT transport and the FEC b)=0A= 72 641.8 Q(uilding)-.22 E=0A= (block, and in particular is outside the scope of the ALC protocol.)72=0A= 654.8 Q(Congestion control for the ALC protocol MUST conform to RFC 238\=0A= 7, and MUST be pro)72 680.8 Q(vided)-.165 E(through the mechanisms pro)=0A= 72 693.8 Q(vided by the LCT transport.)-.165 E=0A= (Although it is not mandatory)5.5 E 2.75(,A)-.715 G(LC is)-2.75 E(most \=0A= scalable when multi-rate congestion control is used that does not requi\=0A= re feedback from)72 706.8 Q(recei)72 719.8 Q -.165(ve)-.275 G=0A= (rs to the sender).165 E 2.75(,a)-.44 G=0A= (nd thus use of a mult-rate congestion control as described in [4] is)=0A= -2.75 E(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66 E 157.517=0A= (wcroft Section)-.275 F 2.75(2. [P)2.75 F(age 4])-.165 E EP=0A= %%Page: 5 5=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 71.587(-DRAFT Expires:)-1.012 F=0A= (January 2002)2.75 E(July 2001)123.726 E(RECOMMENDED.)72 85 Q/F1 11=0A= /Times-Bold@0 SF(2.1.)72 124 Q/F2 13/Times-Bold@0 SF(Deli)5.5 E -.13(ve)=0A= -.13 G(ry ser).13 E(vice models)-.13 E F0(ALC can support se)72 140.6 Q=0A= -.165(ve)-.275 G(ral dif).165 E(ferent deli)-.275 E -.165(ve)-.275 G=0A= (ry service models. T).165 E .22 -.11(wo e)-.88 H=0A= (xamples are brie\215y described)-.055 E(here.)72 153.6 Q F1(Push ser)72=0A= 192.6 Q(vice model.)-.11 E F0(One w)72 209.2 Q=0A= (ay a push service model can be used for reliable content deli)-.11 E=0A= -.165(ve)-.275 G(ry is to deli).165 E -.165(ve)-.275 G 2.75(ras).165 G=0A= (eries of)-2.75 E 2.75(objects. F)72 222.2 R(or e)-.165 E=0A= (xample, a recei)-.165 E -.165(ve)-.275 G 2.75(rc).165 G=0A= (ould join the session and dynamically adapt the number of LCT)-2.75 E=0A= (channels the recei)72 235.2 Q -.165(ve)-.275 G 2.75(ri).165 G 2.75(sj)=0A= -2.75 G(oined to until enough pack)-2.75 E(ets ha)-.11 E .33 -.165(ve b)=0A= -.22 H(een recei).165 E -.165(ve)-.275 G 2.75(dt).165 G 2.75(or)-2.75 G=0A= (econstruct an)-2.75 E=0A= (object. After reconstructing the object the recei)72 248.2 Q -.165(ve)=0A= -.275 G 2.75(rm).165 G(ay stay in the session and w)-2.75 E(ait for the)=0A= -.11 E(transmission of the ne)72 261.2 Q(xt object.)-.165 E=0A= (The push model is particularly attracti)72 287.2 Q .33 -.165(ve i)-.275=0A= H 2.75(ns).165 G(atellite netw)-2.75 E(orks and wireless netw)-.11 E=0A= 2.75(orks. In)-.11 F(these)2.75 E=0A= (cases, a session may consist of one \214x)72 300.2 Q=0A= (ed rate LCT channel.)-.165 E F1(On-demand content deli)72 339.2 Q -.11=0A= (ve)-.11 G(ry model.).11 E F0 -.165(Fo)72 355.8 S 2.75(ra).165 G 2.75=0A= (no)-2.75 G(n-demand content deli)-2.75 E -.165(ve)-.275 G=0A= (ry service model, senders typically transmit for some gi).165 E -.165=0A= (ve)-.275 G 2.75(nt).165 G(ime)-2.75 E=0A= (period selected to be long enough to allo)72 368.8 Q 2.75(wa)-.275 G=0A= (ll the intended recei)-2.75 E -.165(ve)-.275 G=0A= (rs to join the session and).165 E(reco)72 381.8 Q -.165(ve)-.165 G 2.75=0A= (ras).165 G(ingle object.)-2.75 E -.165(Fo)5.5 G 2.75(re).165 G=0A= (xample a popular softw)-2.915 E=0A= (are update might be transmitted using ALC)-.11 E(for se)72 394.8 Q=0A= -.165(ve)-.275 G(ral days, e).165 E -.165(ve)-.275 G 2.75(nt).165 G=0A= (hough a recei)-2.75 E -.165(ve)-.275 G 2.75(rm).165 G=0A= (ay be able to complete the do)-2.75 E(wnload in one hour total)-.275 E=0A= (of connection time, perhaps spread o)72 407.8 Q -.165(ve)-.165 G 2.75=0A= (rs).165 G -2.365 -.275(ev e)-2.75 H(ral interv).275 E(als of time.)=0A= -.275 E(In this case the recei)72 433.8 Q -.165(ve)-.275 G=0A= (rs join the session at an).165 E 2.75(yp)-.165 G=0A= (oint in time when it is acti)-2.75 E .33 -.165(ve a)-.275 H=0A= (nd dynamically).165 E(adapt the number of LCT channels the)72 446.8 Q=0A= 2.75(ys)-.165 G(ubscribe to according to the a)-2.75 E -.275(va)-.22 G=0A= (ilable bandwidth using a).275 E=0A= (multi-rate congestion control protocol. Recei)72 459.8 Q -.165(ve)-.275=0A= G(rs lea).165 E .33 -.165(ve t)-.22 H(he session when the).165 E 2.75=0A= (yh)-.165 G -2.475 -.22(av e)-2.75 H(recei)2.97 E -.165(ve)-.275 G(d)=0A= .165 E(enough pack)72 472.8 Q(ets to reco)-.11 E -.165(ve)-.165 G 2.75=0A= (rt).165 G(he object.)-2.75 E F1(Other ser)72 511.8 Q(vice models.)-.11=0A= E F0(There may be other deli)72 541.4 Q -.165(ve)-.275 G=0A= (ry service models that can be supported by ALC.).165 E=0A= (The description of)5.5 E=0A= (the potential applications, the appropriate deli)72 554.4 Q -.165(ve)=0A= -.275 G(ry service model, and the additional mechanisms).165 E=0A= (to support such functionalities when combined with ALC is be)72 567.4 Q=0A= (yond the scope of this document.)-.165 E F1(2.2.)72 606.4 Q F2=0A= (Congestion Contr)5.5 E(ol)-.234 E F0(The speci\214c congestion control\=0A= protocol to be used for ALC sessions should be suitable for)72 623 Q=0A= (reliable content deli)72 636 Q -.165(ve)-.275 G(ry).165 E 5.5(.W)-.715=0A= G(hile the general beha)-5.5 E=0A= (vior of the congestion control protocol is to)-.22 E(reduce the throug\=0A= hput in presence of congestion and gradually increase it in the absence\=0A= of)72 649 Q(congestion, the actual dynamic beha)72 662 Q=0A= (vior \(e.g. response to single losses\) can v)-.22 E(ary)-.275 E(.)=0A= -.715 E(Some possible multi-rate congestion control protocols for relia\=0A= ble content deli)72 688 Q -.165(ve)-.275 G(ry using LCT are).165 E=0A= (described in [4].)72 701 Q(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)=0A= -.66 E 149.267(wcroft Section)-.275 F 2.75(2.2. [P)2.75 F(age 5])-.165 E=0A= EP=0A= %%Page: 6 6=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 71.587(-DRAFT Expires:)-1.012 F=0A= (January 2002)2.75 E(July 2001)123.726 E/F1 11/Times-Bold@0 SF(3.)72 85=0A= Q/F2 14/Times-Bold@0 SF -1.036(Ty)5.5 G(pe of pack)1.036 E=0A= (ets used by the ALC pr)-.14 E(otocol)-.252 E F0(The type of pack)72=0A= 101.6 Q(et used by the ALC protocol is a specialized v)-.11 E=0A= (ersion of an LCT pack)-.165 E 2.75(et. LCT)-.11 F(pack)72 114.6 Q=0A= (ets are sent by senders to LCT channels.)-.11 E=0A= (Some instances of sessions MA)72 140.6 Q 2.75(Yr)-1.155 G=0A= (equire the generation of feedback from the recei)-2.75 E -.165(ve)-.275=0A= G(rs to the).165 E(sender)72 153.6 Q 5.5(.H)-.605 G -.275(ow)-5.5 G=0A= -2.365 -.275(ev e).275 H .88 -.44(r, t).275 H=0A= (he mechanism for doing this is outside the scope of ALC.).44 E F1(3.1.)=0A= 72 192.6 Q/F3 13/Times-Bold@0 SF -.13(Pa)5.5 G(ck).13 E(et f)-.13 E=0A= (ormat f)-.325 E(or the ALC pr)-.325 E(otocol)-.234 E F0(The pack)72=0A= 209.2 Q(et format used for ALC protocol is depicted in Figure 1.)-.11 E=0A= /F4 8/Courier@0 SF 91.2(0123)81.6 248.2 S 4.8=0A= (01234567890123456789012345678901)81.6 261.2 S=0A= (+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A= 274.2 Q 105.6(|L)76.8 287.2 S(CT packet header)-105.6 E(|)115.2 E 302.4=0A= (||)76.8 300.2 S=0A= (+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+)76.8=0A= 313.2 Q 110.4(|F)76.8 326.2 S(EC Payload ID)-110.4 E(|)124.8 E 302.4(||)=0A= 76.8 339.2 S=0A= (+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+)76.8=0A= 352.2 Q 100.8(|A)76.8 365.2 S(dditional parameters)-100.8 E(|)100.8 E=0A= 124.8(|\()76.8 378.2 S 124.8(optional\) |)-124.8 F=0A= (+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+)76.8=0A= 391.2 Q 129.6(|P)76.8 404.2 S 134.4(ayload |)-129.6 F 302.4(||)76.8=0A= 417.2 S 302.4(||)76.8 430.2 S=0A= (+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A= 443.2 Q/F5 10/Times-Roman@0 SF(Figure 1 - P)72 482.2 Q(ack)-.15 E=0A= (et format for ALC protocol)-.1 E F1(3.2.)72 521.2 Q F3 -.13(Pa)5.5 G=0A= (ck).13 E(et header \214elds f)-.13 E(or the ALC pr)-.325 E(otocol)-.234=0A= E F0(The description of the \214elds and their functions within the LCT\=0A= pack)72 537.8 Q(et header can be found in [3].)-.11 E(The information \=0A= that needs to be communicated out of band for the LCT transport and the)=0A= 72 550.8 Q(possible mechanisms for achie)72 563.8 Q=0A= (ving this are described in [3].)-.275 E(The description of the \214eld\=0A= s and their functions within the FEC payload ID can be found in [2],)72=0A= 580.4 Q(with the e)72 593.4 Q(xception that the FEC Encoding Flag v)=0A= -.165 E(alue, if applicable, MA)-.275 E 2.75(Yb)-1.155 G 2.75(ec)-2.75 G=0A= (ommunicated via)-2.75 E(the v)72 606.4 Q=0A= (alue of the Codepoint \214eld within LCT pack)-.275 E(et header)-.11 E=0A= 5.5(.T)-.605 G(he information that needs to be)-5.5 E(communicated out \=0A= of band for the FEC codecs and the possible mechanisms for achie)72=0A= 619.4 Q(ving this are)-.275 E(described in [2]. The mechanisms for comm\=0A= unicating the out of band information needed for the)72 632.4 Q=0A= (LCT transport, including the mapping between the Codepoint \214eld v)72=0A= 645.4 Q(alues in the LCT pack)-.275 E(et)-.11 E=0A= (header and the interpretations of the v)72 658.4 Q(alues, MA)-.275 E=0A= 2.75(Yb)-1.155 G 2.75(et)-2.75 G=0A= (he same as those used for communicating)-2.75 E=0A= (the out of band information needed for the FEC b)72 671.4 Q=0A= (uilding block, with the e)-.22 E(xception that portions)-.165 E=0A= (of the information needed for FEC b)72 684.4 Q=0A= (uilding blocks may be communicated either through the use)-.22 E=0A= (of the Codepoint \214eld in the LCT pack)72 697.4 Q(et header)-.11 E=0A= 2.75(,o)-.44 G 2.75(rt)-2.75 G(hrough the Additional P)-2.75 E=0A= (arameters \214elds that)-.165 E(follo)72 710.4 Q 2.75(wt)-.275 G=0A= (he FEC payload ID.)-2.75 E(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)=0A= -.66 E 149.267(wcroft Section)-.275 F 2.75(3.2. [P)2.75 F(age 6])-.165 E=0A= EP=0A= %%Page: 7 7=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 71.587(-DRAFT Expires:)-1.012 F=0A= (January 2002)2.75 E(July 2001)123.726 E=0A= (The \214elds and formats of the optional Additional P)72 85 Q=0A= (arameters \214elds MUST be communicated to)-.165 E(the recei)72 98 Q=0A= -.165(ve)-.275 G(rs out of band.).165 E(The particular Additional P)5.5=0A= E(arameters \214elds that may appear in pack)-.165 E(ets)-.11 E=0A= (MUST be communicated out of band.)72 111 Q=0A= (The speci\214cation of which Additional P)5.5 E(arameters \214elds)=0A= -.165 E(that appear in a pack)72 124 Q=0A= (et MUST be communicated via the v)-.11 E=0A= (alue of the Codepoint \214eld in the LCT)-.275 E(pack)72 137 Q=0A= (et header)-.11 E 2.75(,a)-.44 G=0A= (nd the mapping between Codepoint \214eld v)-2.75 E=0A= (alues and the Additional P)-.275 E(arameters)-.165 E=0A= (\214elds that appear in a pack)72 150 Q=0A= (et MUST be communicated out of band.)-.11 E(It is RECOMMENDED that)5.5=0A= E(the format of an)72 163 Q 2.75(yA)-.165 G(dditonal P)-2.75 E=0A= (arameters \214elds adhere to the format of Header)-.165 E=0A= (-Extension Fields)-.22 E(de\214ned for the LCT transport in [3].)72 176=0A= Q/F1 11/Times-Bold@0 SF(4.)72 202 Q/F2 14/Times-Bold@0 SF(Pr)5.5 E=0A= (ocedur)-.252 E(es)-.252 E F1(4.1.)72 241 Q/F3 13/Times-Bold@0 SF=0A= (Sender Operation)5.5 E F0(The sender operation when using the ALC prot\=0A= ocol includes all the points made about the sender)72 257.6 Q(operation\=0A= when using the LCT transport as described in [3], and the FEC b)72=0A= 270.6 Q(uilding block as)-.22 E(described in [2]. The follo)72 283.6 Q(\=0A= wing description highlights some of the additional considerations to be)=0A= -.275 E(tak)72 296.6 Q=0A= (en into account with respect to the ALC protocol.)-.11 E=0A= (Before a session starts, a sender using the ALC protocol MUST mak)72=0A= 322.6 Q 2.75(ea)-.11 G -.275(va)-2.97 G(ilable all applicable).275 E=0A= (information re)72 335.6 Q -.055(ga)-.165 G(rding the session.).055 E=0A= (This information includes:)5.5 E 11(oA)77.5 352.2 S .33 -.165(ny i)-11=0A= H(nformation needed by the LCT transport;).165 E 11(oT)77.5 368.8 S=0A= (he congestion control protocol being used within the LCT transport;)-11=0A= E 11(oT)77.5 385.4 S(he mapping between v)-11 E=0A= (alues of the Codepoint \214eld in the LCT pack)-.275 E(et header and)=0A= -.11 E(interpretations of these v)94 398.4 Q(alues;)-.275 E 11(oA)77.5=0A= 415 S .33 -.165(ny i)-11 H(nformation needed for the FEC b).165 E=0A= (uilding block;)-.22 E 11(oI)77.5 431.6 S 2.75(fu)-11 G(sed, the authen\=0A= tication scheme being used within the LCT transport, and all rele)-2.75=0A= E -.275(va)-.275 G(nt).275 E=0A= (information which is necessary for sender authentication purposes;)94=0A= 444.6 Q F1(4.2.)72 483.6 Q F3(Recei)5.5 E -.13(ve)-.13 G 3.25(rO).13 G=0A= (peration)-3.25 E F0(The recei)72 500.2 Q -.165(ve)-.275 G 2.75(ro).165=0A= G(peration when using the ALC protocol includes all the points made abo\=0A= ut the)-2.75 E(recei)72 513.2 Q -.165(ve)-.275 G 2.75(ro).165 G=0A= (peration that pertain to reliable content deli)-2.75 E -.165(ve)-.275 G=0A= (ry when using the LCT transport as).165 E=0A= (described in [3], and that pertain to using the FEC b)72 526.2 Q=0A= (uilding block as described in [2]. The)-.22 E(follo)72 539.2 Q(wing de\=0A= scription highlights some of the additional considerations to be tak)=0A= -.275 E(en into account)-.11 E(with respect to the ALC protocol.)72=0A= 552.2 Q(When a recei)72 578.2 Q -.165(ve)-.275 G 2.75(rr).165 G(ecei)=0A= -2.75 E -.165(ve)-.275 G 2.75(sap).165 G(ack)-2.75 E(et, the recei)-.11=0A= E -.165(ve)-.275 G 2.75(rM).165 G(UST process the LCT pack)-2.75 E=0A= (et header \(e)-.11 E(xcluding)-.165 E(the Codepoint \214eld\))72 591.2=0A= Q(as described in [3] before processing an)5.5 E 2.75(yo)-.165 G=0A= (ther \214elds of the pack)-2.75 E(et.)-.11 E F1(5.)72 630.2 Q F2=0A= (Security Considerations)5.5 E F0(The same security consideration that \=0A= apply to the LCT transport and to the FEC b)72 646.8 Q(uilding block)=0A= -.22 E(also apply to the ALC protocol.)72 659.8 Q(In addition, an)5.5 E=0A= 2.75(ys)-.165 G(ecurity considerations that apply to the)-2.75 E(conges\=0A= tion control protocol used by the ALC protocol within the LCT transport\=0A= also apply)72 672.8 Q(.)-.715 E(Luby/Gemmell/V)72 769 Q=0A= (icisano/Rizzo/Cro)-.66 E 157.517(wcroft Section)-.275 F 2.75(5. [P)2.75=0A= F(age 7])-.165 E EP=0A= %%Page: 8 8=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 71.587(-DRAFT Expires:)-1.012 F=0A= (January 2002)2.75 E(July 2001)123.726 E/F1 11/Times-Bold@0 SF(6.)72 85=0A= Q/F2 14/Times-Bold@0 SF(IAN)5.5 E 3.5(AC)-.28 G(onsiderations)-3.5 E F0=0A= (No information in this speci\214cation is directly subject to IAN)72=0A= 101.6 Q 2.75(Ar)-.385 G -.165(eg)-2.75 G 2.75(istration. Ho).165 F(we)=0A= -.275 E -.165(ve)-.275 G .88 -.44(r, b).165 H(uilding).22 E=0A= (blocks components used by the ALC protcol may introduce additional IAN)=0A= 72 114.6 Q 2.75(Ac)-.385 G 2.75(onsiderations. In)-2.75 F(particular)72=0A= 127.6 Q 2.75(,t)-.44 G(he FEC b)-2.75 E=0A= (uilding block used by the ALC protocol does require IAN)-.22 E 2.75(Ar)=0A= -.385 G -.165(eg)-2.75 G(istration of).165 E(the FEC codecs used.)72=0A= 140.6 Q F1(7.)72 179.6 Q F2(Intellectual Pr)5.5 E(operty Issues)-.252 E=0A= F0(No speci\214c reliability protocol or congestion control protocol is\=0A= speci\214ed or referenced as)72 209.2 Q(mandatory in this document.)72=0A= 222.2 Q(ALC MA)72 248.2 Q 2.75(Yb)-1.155 G 2.75(eu)-2.75 G(sed with con\=0A= gestion control protocols and other protocols which are proprietary)=0A= -2.75 E(,)-.715 E(or ha)72 261.2 Q .33 -.165(ve p)-.22 H=0A= (ending or granted patents.).165 E([1] Luby)72 303.8 Q 2.75(,M)-.715 G=0A= (., Gemmell, V)-2.75 E(icisano, L., J., Rizzo, L., Handle)-.66 E 1.43=0A= -.715(y, M)-.165 H(., Cro).715 E(wcroft, J., "The use of)-.275 E -.165=0A= (Fo)72 316.8 S(rw).165 E(ard Error Correction in Reliable Multicast", I\=0A= nternet Draft draft-ietf-rmt-info-fec-00.txt,)-.11 E(No)72 329.8 Q -.165=0A= (ve)-.165 G(mber 2000, a w).165 E(ork in progress.)-.11 E([2] Luby)72=0A= 355.8 Q 2.75(,M)-.715 G(., Gemmell, J., V)-2.75 E=0A= (icisano, L., Rizzo, L., Handle)-.66 E 1.43 -.715(y, M)-.165 H(., Cro)=0A= .715 E(wcroft, J., "RMT BB)-.275 E -.165(Fo)72 368.8 S(rw).165 E(ard Er\=0A= ror Correction Codes", Internet Draft draft-ietf-rmt-bb-fec-03.txt, Jul\=0A= y 2001.)-.11 E([3] Luby)72 394.8 Q 2.75(,M)-.715 G(., Gemmell, J., V)=0A= -2.75 E(icisano, L., Rizzo, L., Handle)-.66 E 1.43 -.715(y, M)-.165 H=0A= (., Cro).715 E(wcroft, J., "Layered Coding)-.275 E -.385(Tr)72 407.8 S=0A= (ansport: A massi).385 E -.165(ve)-.275 G(ly scalable content deli).165=0A= E -.165(ve)-.275 G(ry transport", Internet Draft draft-ietf-rmt-bb-).165=0A= E(lct-01.txt, July 2001.)72 420.8 Q([4] Luby)72 446.8 Q 2.75(,M)-.715 G=0A= (., V)-2.75 E(icisano, L., Hak)-.66 E=0A= (en, A., "RMT BB Layered congestion control", draft-ietf-rmt-bb-)-.11 E=0A= (lcc-00.txt, No)72 459.8 Q -.165(ve)-.165 G(mber 2000, a w).165 E=0A= (ork in progress.)-.11 E([5] Perrig, A., Canetti, R., Briscoe, B., T)72=0A= 485.8 Q(yg)-.88 E(ar)-.055 E 2.75(,D)-.44 G=0A= (., Song, D., "TESLA: Multicast Source)-2.75 E(Authentication T)72 498.8=0A= Q(ransform", draft-irtf-smug-tesla-00.txt, No)-.385 E -.165(ve)-.165 G=0A= (mber).165 E 2.75(,2)-.44 G(000, a w)-2.75 E(ork in progress.)-.11 E F1=0A= (8.)72 550.8 Q F2 -.7(Au)5.5 G(thors' Addr).7 E(esses)-.252 E F0=0A= (Michael Luby)80.25 567.4 Q(luby@digitalfountain.com)80.25 580.4 Q=0A= (Digital F)80.25 593.4 Q(ountain)-.165 E(39141 Ci)80.25 606.4 Q=0A= (vic Center Dri)-.275 E -.165(ve)-.275 G(Suite 300)80.25 619.4 Q=0A= (Fremont, CA, USA, 94538)80.25 632.4 Q(Jim Gemmell)80.25 658.4 Q=0A= (jgemmell@microsoft.com)80.25 671.4 Q(Microsoft Research)80.25 684.4 Q=0A= (301 Ho)80.25 697.4 Q -.11(wa)-.275 G(rd St., #830).11 E=0A= (San Francisco, CA, USA, 94105)80.25 710.4 Q(Luby/Gemmell/V)72 769 Q=0A= (icisano/Rizzo/Cro)-.66 E 157.517(wcroft Section)-.275 F 2.75(8. [P)2.75=0A= F(age 8])-.165 E EP=0A= %%Page: 9 9=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 71.587(-DRAFT Expires:)-1.012 F=0A= (January 2002)2.75 E(July 2001)123.726 E(Lorenzo V)80.25 85 Q(icisano)=0A= -.66 E(lorenzo@cisco.com)80.25 98 Q(cisco Systems, Inc.)80.25 111 Q=0A= (170 W)80.25 124 Q(est T)-.88 E(asman Dr)-.88 E(.,)-.605 E=0A= (San Jose, CA, USA, 95134)80.25 137 Q(Luigi Rizzo)80.25 163 Q=0A= (luigi@iet.unipi.it)80.25 176 Q(Dip. Ing. dell'Informazione,)80.25 189 Q=0A= (Uni)80.25 202 Q 1.43 -.715(v. d)-.275 H 2.75(iP).715 G(isa)-2.75 E=0A= (via Diotisalvi 2, 56126 Pisa, Italy)80.25 215 Q(Jon Cro)80.25 241 Q=0A= (wcroft)-.275 E(J.Cro)80.25 254 Q(wcroft@cs.ucl.ac.uk)-.275 E=0A= (Department of Computer Science)80.25 267 Q(Uni)80.25 280 Q -.165(ve)=0A= -.275 G(rsity Colle).165 E(ge London)-.165 E(Go)80.25 293 Q(wer Street,)=0A= -.275 E(London WC1E 6BT)80.25 306 Q 2.75(,U)-.814 G(K)-2.75 E=0A= (Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66 E 157.517=0A= (wcroft Section)-.275 F 2.75(8. [P)2.75 F(age 9])-.165 E EP=0A= %%Page: 10 10=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 71.587(-DRAFT Expires:)-1.012 F=0A= (January 2002)2.75 E(July 2001)123.726 E/F1 11/Times-Bold@0 SF(9.)72 85=0A= Q/F2 14/Times-Bold@0 SF(Full Copyright Statement)5.5 E F0(Cop)72 101.6 Q=0A= (yright \(C\) The Internet Society \(2000\).)-.11 E(All Rights Reserv)=0A= 5.5 E(ed.)-.165 E(This document and translations of it may be copied an\=0A= d furnished to others, and deri)72 118.2 Q -.275(va)-.275 G(ti).275 E=0A= .33 -.165(ve w)-.275 H(orks).055 E(that comment on or otherwise e)72=0A= 131.2 Q=0A= (xplain it or assist in its implementation may be prepared, copied,)=0A= -.165 E(published and distrib)72 144.2 Q=0A= (uted, in whole or in part, without restriction of an)-.22 E 2.75(yk)=0A= -.165 G(ind, pro)-2.75 E(vided that the)-.165 E(abo)72 157.2 Q .33 -.165=0A= (ve c)-.165 H(op).165 E(yright notice and this paragraph are included o\=0A= n all such copies and deri)-.11 E -.275(va)-.275 G(ti).275 E .33 -.165=0A= (ve w)-.275 H(orks.).055 E(Ho)72 170.2 Q(we)-.275 E -.165(ve)-.275 G .88=0A= -.44(r, t).165 H(his document itself may not be modi\214ed in an).44 E=0A= 2.75(yw)-.165 G(ay)-2.86 E 2.75(,s)-.715 G(uch as by remo)-2.75 E=0A= (ving the)-.165 E(cop)72 183.2 Q(yright notice or references to the Int\=0A= ernet Society or other Internet or)-.11 E -.055(ga)-.198 G(nizations, e)=0A= .055 E(xcept as)-.165 E(needed for the purpose of de)72 196.2 Q -.165=0A= (ve)-.275 G(loping Internet standards in which case the procedures for)=0A= .165 E(cop)72 209.2 Q=0A= (yrights de\214ned in the Internet languages other than English.)-.11 E=0A= (The limited permissions granted abo)72 225.8 Q .33 -.165(ve a)-.165 H=0A= (re perpetual and will not be re).165 E -.22(vo)-.275 G -.11(ke).22 G=0A= 2.75(db).11 G 2.75(yt)-2.75 G(he Internet)-2.75 E=0A= (Society or its successors or assigns.)72 238.8 Q=0A= (This document and the information contained herein is pro)72 255.4 Q=0A= (vided on an "AS IS" basis and THE)-.165 E=0A= (INTERNET SOCIETY AND THE INTERNET ENGINEERING T)72 268.4 Q=0A= (ASK FORCE DISCLAIMS)-1.023 E(ALL W)72 281.4 Q=0A= (ARRANTIES, EXPRESS OR IMPLIED, INCLUDING B)-1.32 E(UT NO)-.11 E 2.75=0A= (TL)-.44 G(IMITED T)-2.75 E 2.75(OA)-.198 G(NY)-2.75 E -1.32(WA)72 294.4=0A= S(RRANTY THA)1.32 E 2.75(TT)-1.221 G(HE USE OF THE INFORMA)-2.75 E=0A= (TION HEREIN WILL NO)-1.221 E 2.75(TI)-.44 G(NFRINGE)-2.75 E=0A= (ANY RIGHTS OR ANY IMPLIED W)72 307.4 Q(ARRANTIES OF MERCHANT)-1.32 E=0A= (ABILITY OR FITNESS)-1.023 E(FOR A P)72 320.4 Q(AR)-1.012 E=0A= (TICULAR PURPOSE.")-.66 E(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66=0A= E 152.017(wcroft Section)-.275 F 2.75(9. [P)2.75 F(age 10])-.165 E EP=0A= %%Page: 11 11=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 71.587(-DRAFT Expires:)-1.012 F=0A= (January 2002)2.75 E(July 2001)123.726 E(Luby/Gemmell/V)72 769 Q=0A= (icisano/Rizzo/Cro)-.66 E 152.017(wcroft Section)-.275 F 2.75(9. [P)2.75=0A= F(age 11])-.165 E EP=0A= %%Trailer=0A= end=0A= %%EOF=0A= ------=_NextPart_000_0002_01C11115.E3203A10-- >From owner-rmt@listserv.lbl.gov Fri Jul 20 13:49:49 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6KKnQ729323; Fri, 20 Jul 2001 13:49:26 -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.11.2/8.11.2) with ESMTP id f6KKnOR29319 for ; Fri, 20 Jul 2001 13:49:24 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6KKnOp21118 for ; Fri, 20 Jul 2001 13:49:24 -0700 (PDT) Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6KKnMA21110 for ; Fri, 20 Jul 2001 13:49:22 -0700 (PDT) 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 QAA05368; Fri, 20 Jul 2001 16:48:20 -0400 (EDT) Mime-Version: 1.0 X-Sender: adamson@pop.itd.nrl.navy.mil Message-Id: In-Reply-To: References: Date: Fri, 20 Jul 2001 16:48:21 -0400 To: From: Brian Adamson Subject: draft-ietf-rmt-bb-norm-02.txt Cc: "Lorenzo Vicisano" , "Roger Kermode" , Content-Type: multipart/mixed; boundary="============_-1216460392==_============" Sender: owner-rmt@lbl.gov Precedence: bulk --============_-1216460392==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Please post this draft on the IETF Internet Drafts archive. This is an update of an existing WG draft (RMT). best regards, --============_-1216460392==_============ Content-Id: Content-Type: text/plain; name="draft-ietf-rmt-bb-norm-02.txt"; charset="us-ascii" ; format="flowed" Content-Disposition: attachment; filename="draft-ietf-rmt-bb-norm-02.txt" ; modification-date="Fri, 20 Jul 2001 16:44:57 -0400" RMT Working Group B. Adamson/Newlink INTERNET-DRAFT C. Bormann/Tellique draft-ietf-rmt-bb-norm-02.txt M. Handley/ACIRI Expires: January 2002 J. Macker/NRL July 2001 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 (2001). All Rights Reserved. Abstract This memo describes issues related to the creation of negative- acknowledgment (NACK) oriented reliable multicast (NORM) protocols. The general goals and assumptions for NORM are defined. The tech- nical challenges related to NACK-oriented (and in some cases gen- eral) reliable multicast protocol design are identified. These challenges are resolved into a set of applicable "building blocks" which are described in further detail. It is anticipated that these building blocks (as they are further refined and defined in future revisions of this document) will be useful in generating different instantiations of reliable multicast protocols. Adamson, Bormann, et al. Expires January 2002 [Page 1] Internet Draft NORM Building Blocks July 2001 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 complexities of group communication paradigms neces- sitate 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) oriented reliable multicast (NORM) protocols offer scalability advantages for appli- cations and/or network topologies where, for various reasons, it is prohibitive to construct a higher order delivery infrastructure 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 Applicability Each potential protocol instantiation using the building blocks presented here (and other applicable building block documents) will have specific criteria which will influence individual protocol design. To support the development of applicable building blocks, it is useful to identify and summarize driving general protocol design goals and assumptions. These are areas which each protocol instantiation will need to address in detail. Each building block description in this document will include a discussion of the impact of these design criteria. The categories of design criteria considered here include: 1) Data content model 2) Group membership dynamics 3) Sender/receiver relationships 4) Group size 5) Data delivery performance 6) Network topology Adamson, Bormann, et al. Expires January 2002 [Page 2] Internet Draft NORM Building Blocks July 2001 3) Router/intermediate system assistance In some cases, a building block may be designed to address a wide range of assumptions while in other cases there will be trade-offs required to meet different application needs. Where necessary, building block features will designed to be parametric to meet dif- ferent requirements. Of course, an underlying goal will be to min- imize design complexity and to at least recommend default values for any such parameters which meet a general purpose "bulk data transfer" requirement in a typical Internet environment. 2.1 Data content model The implicit goal of a reliable multicast protocol is the reliable delivery of "data" among a group of members communicating through IP multicast datagram service. However, the nature of the data content and the service the application is attempting to provide can impact design decisions. The service model may range from 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 transmitted data (or state referencing it) for retransmission or repair. The needs for ordering and/or causality in the sequence of transmissions and receptions among members in the group may be dif- ferent depending upon data content. The group communication paradigm differs significantly from the point-to-point model in that, depending upon the data content type, some receivers may com- plete reception of a portion of data content and be able to act upon it before other members 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 protocol 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 Adamson, Bormann, et al. Expires January 2002 [Page 3] Internet Draft NORM Building Blocks July 2001 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 members 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. However, the potential for router assistance or other non-linear NACK suppression mechanisms may enable these protocols to scale to very large group sizes. In large scale cases, it may be pro- hibitive for members to maintain state on all other members (in particular, other receivers) in the group. The impact of group size needs to be considered in the development of generally appli- cable 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 Adamson, Bormann, et al. Expires January 2002 [Page 4] Internet Draft NORM Building Blocks July 2001 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. The bandwidth available on the links between the members of a single group today may vary between low numbers of kbit/s for wireless links and multiple Gbit/s for high speed LAN connections, with varying degrees of contention from other flows. Recently, a number of asymmetric network services including 56K/ADSL modems, CATV Internet service, satellite and other wire- less communication services have begun to proliferate. Many of these are inherently broadcast media with potentially large "fanouts" to which IP multicast service is highly applicable. 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 The previous section has presented in general what building blocks are intended to be and some of the criteria which may affect build- ing block identification/design. This section describes different building block areas applicable to NACK-oriented reliable multi- cast protocols. Some of these areas are specific to NACK-oriented Adamson, Bormann, et al. Expires January 2002 [Page 5] Internet Draft NORM Building Blocks July 2001 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 multi- cast. In those cases, the discussion below describes requirements placed on those other general building block areas from the stand- point of NACK-oriented reliable multicast. For the individual building blocks to be incorporated as part of a specific protocol instantiation, it is 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" provided 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: (NACK-Oriented Components) 1) Sender transmission 2) NACK-oriented Repair Process 3) "Late-joining" Receiver Policies and Mechanisms (Generally-applicable Components) 4) Node (member) 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 Figure 1 provides an pictoral overview of these building block areas and their relationships. For example, the content of the data messages that sender initially transmits depends upon the "Node Identification", Data Content Identification", "FEC" , and "Congestion Control components (Note that the rate of message transmission will generally depend upon the "Congestion Control" component). Subsequently, the receivers response to these trans- missions (e.g. NACKing for repair) will depend upon the content of these transmissions and inputs from other building block compo- nents. Then, the sender's processing of these responses will feed back into its transmission strategy. Application Data | Adamson, Bormann, et al. Expires January 2002 [Page 6] Internet Draft NORM Building Blocks July 2001 V .---------------------. .-----------------------. | Node Identification |----------->| Sender Transmission |<------. '---------------------' _.-' '-----------------------' | .---------------------. _.-' .' | | | Data Identification |--' .'' | ("Join" Policy) | '---------------------' .' ' V | .---------------------. .' ' .------------------------. | .->| Congestion Control |-' ' | Receiver NACK-oriented | | | '---------------------' .' | Repair Process | | | .---------------------. .' | .------------------. | | | | FEC |'. | | NACK Initiation | | | | '---------------------'. '._ | '------------------' | | | .---------------------. , '-._ | .------------------. | | '--| RTT Collection |._' '->| | NACK Content | | | '---------------------' .''. | '------------------' | | .---------------------. ' ''-._ | .------------------. | | | Group Size Est. |---'-'---'->| | NACK Suppression | | | '---------------------''. ' ' | '------------------' | | .---------------------. ' ' ' '------------------------' | | Other | ' ' ' | | '---------------------' ' ' ' | (Router Assistance) | '. ' ' V | '.'' .-------------------------. | '>| Sender NACK Processing |_____/ | and Repair Response | '-------------------------' ^ ^ | | .-----------------------------. | (Security) | '-----------------------------' Fig. 1 - NORM Building Block Framework The components on the left side of this figure represent the components which may be generally applicable beyond NORM and those on the right are specific to NORM protocols. Some components (e.g. "Security") will impact many aspects of the protocol and others such as "Router Assis- tance" may be more transparent to the core protocol processing. The sections below discuss issues with regards to these building block com- ponents and their relationships. Where applicable, specific technical recommendations are made for mechanisms which will properly satisfy the goals of reliable multicast bulk transport for the Internet. 3.1 Sender transmission Adamson, Bormann, et al. Expires January 2002 [Page 7] Internet Draft NORM Building Blocks July 2001 Senders will transmit data content to the multicast session. The data content will be application dependent. The sender will transmit data content at a rate and with packet sizes determined by application and/or network architecture requirements. When congestion control mechanisms are used (recommended), the transmission rate will be controlled by the congestion control mechanism. It is recommended that all data transmis- sions from senders be subject to rate limitations determined by the application or congestion control algorithm. The sender's transmissions should make good utlization of the available capacity (which may be lim- ited by the application and/or by congestion control). As a result, it is expected there will be overlap and multiplexing of new data content transmission with repair content. In addition to data content, other sender messages or commands may be employed as part of protocol operation. For NACK-oriented operation, the reliability of any such commands may depend upon redundant transmis- sion. Other factors related to NACK-oriented operation may determine sender transmission formats and methods. Some consideration needs to be given to the sender's behavior during intermittent idle periods when it has no data to transmit. While many aspects may be protocol-specific, there are techniques which may be generally applicable to NACK-oriented reliable multicast. For example, the periodicity of redundant transmis- sion 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 transmission. 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 sender should allow sufficient time between redundant transmissions to receive any NACK-oriented responses from the receiver set to this com- mand. Other protocol components may benefit from a similar approach. Inputs: 1) Data content 2) Segmentation size 3) Transmission rate 4) Application controls Outputs: 1) Rate-controlled stream of packets with headers uniquely identifying data or repair content within the context of the reliable multicast session. 2) Commands indicating sender's status or other transport con- trol actions to be taken. Adamson, Bormann, et al. Expires January 2002 [Page 8] Internet Draft NORM Building Blocks July 2001 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 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 receivers to aggregate NACK content into a smaller number of NACK messages. 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: Adamson, Bormann, et al. Expires January 2002 [Page 9] Internet Draft NORM Building Blocks July 2001 1) NACK Process Initiation Decision 3.2.2 NACK Content The content of NACK messages generated by reliable multicast receivers will include information detailing the current repair needs of each receiver. The specific information depends on the use and type of FEC in the NORM repair process. The identification of repair needs is dependent upon the data content identification (See Section 3.5 below). At the highest level the NACK content will identify the data transport object (or stream) within the mul- ticast session which needs repair. For the indicated transport entity, the NACK content will then identify the specific coding blocks and/or segments of coding blocks it needs to reconstruct the transmitted data. This content may consist FEC block erasure counts and/or explicit indication of missing blocks or segments of data and FEC content. 3.2.2 NACK Content Strategies Where FEC-based repair is used, the NACK message content will need to identify the coding block(s) for which repair is needed and the count of erasures (missing packets) in the coding block. Note that this assumes the FEC algorithm is capable of repairing _any_ loss combination within the coding block and that the quantity of unique FEC parity packets the server has available to transmit is essen- tially unlimited (i.e. the server will always be able to provide new parity packets in response to anysubsequent repair requests for the same coding block). In other cases, the NACK content will need to also _explicitly_ identify which packets (information and/or parity) the receiver needs to successfully reconstruct the content of the coding block. When FEC is not used as part of the repair process or the protocol instantiation is required to provide reliability even when the sender has transmitted all available parity for a given coding block (or the sender's ability to buffer transmission history is exceeded by the delay*bandwidth*loss characteristics of the network topology), the NACK content will need to contain _explicit_ coding block and/or packet loss information so that the sender can provide appropriate repair packets and/or data retransmissions. Explicit loss information in NACK content may also potentially serve other purposes. For example, it may be useful for decorrelating loss characteristics among a group of receivers to help differentiate candidate congestion control bottlenecks among the receiver set. For cases where the amount of loss is very small with respect to the coding block size, it may be efficient to simply provide a list Adamson, Bormann, et al. Expires January 2002 [Page 10] Internet Draft NORM Building Blocks July 2001 of coding block vector identifiers. However, in many cases, a bit mask marking the locations of missing packets may be significantly more efficient for communicating receiver repair needs. And since the data content is logically divided into coding blocks, a system of hierarchical bit masks can be used to encode missing content at the object/stream, FEC block, and individual packet levels. Hier- archical bit mask encoding can provide compact NACK messages even in high delay*bandwidth*loss conditions. Bit mask based NACK con- tent can also be efficiently processed with logical operations dur- ing protocol operation. When FEC is used and NACK content is designed to contain explicit repair requests, there is strategy where the receivers can NACK for specific content which will help facilitate NACK suppression and repair efficiency. The assumptions for this strategy are that sender may potentially exhaust its supply of new, unique parity packets available for a given coding block and be required to explicitly retransmit some data or parity segments to complete reliable transfer. Another assumption is that an FEC algorithm where any parity packet can fill any erasure within the coding block is used. The goal of this strategy is to make maximum use of the available parity and provide the minimal amount of data and repair transmissions during reliable transfer of a coding block to the group. In this approach, the sender transmits the data content of the cod- ing block (and optionally some quantity of parity packets) in its initial transmission. Note that a coding block is considered to be logically made up of the contiguous set of data vectors plus parity vectors for the given FEC algorithm used. The sender transmits parity vectors from the lowest ordinal part of the parity portion of the coding block. When the receivers construct explicit NACK content, they request transmission of only the _upper_ ordinal por- tion, corresponding to the number of _data_ vectors, of the logical coding block required to fill their packet erasures (Note this _may_ include data vectors if there is a smaller number of parity vectors than data vectors for the selected code, but generally will consist solely of parity vectors). The receivers can also provide a count of erasures as a convenience (saves processing time) to the sender. Upon receipt of the NACK message, the sender will schedule transmission of fresh, new parity vectors based on the erasure count _if_ it has a sufficient quantity of vectors which were _not_ previously transmitted and ignore the explicit content requested.. Otherwise, the sender will resort to transmitting the set of repair vectors requested. With this approach, the sender needs to main- tain very little state on requests it has received from the group without need for synchronization of repair requests from the group. Since all receivers use this same algorithm to express their Adamson, Bormann, et al. Expires January 2002 [Page 11] Internet Draft NORM Building Blocks July 2001 explict repair needs, NACK suppression among receivers is simpli- fied over the course of multiple repair cycles. The receivers can simply compare NACKs heard from other receivers against their own calculated repair needs to determine whether they should transmit or suppress their pending NACK messages. 3.2.3 General Purpose NACK Content Encapsulation Format This section describes a general format for encapsulating negative acknowledgement (NACK) feedback content for reliable data transmis- sion protocols. This includes protocols which may incorporate for- ward error correction (FEC) for repair packet generation as well as those which do not. This NACK format is structured according to a logical, hierarchical framework where the sender transmits data optionally in the form of one or more "streams" or "objects", with each optionally composed of a series of FEC coding "blocks" with each "block" composed of some number of data transmission segments with source data and/or FEC parity content. This allows any seg- ment of transmitted data (or FEC parity) to be hierarchically addressed, as applicable, by the concatenation of "stream/object", "block", and "segment" identifiers. Note that multiple levels of streams and substreams or objects can be instantiated within a hierarchy as required by protocol instan- tiations to meet protocol or application needs. Also note that the notional hierarchy of "streams" and/or "blocks" can be omitted for protocols which do not employ them and the appropriate subset of the message scheme described here can still be used for NACK repair requests. Thus a protocol with a single virtual "stream" would invoke only the message sets relevant to FEC "blocks" and transmis- sion "segments". Figure 2 illustrates this logical hierarchy of transmission content identification, denoting that the notion streams (or objects) and/or FEC blocking is optional at the protocol instantiation's discretion. Since the notion of session "streams" and "blocks" are optional, the framework degenerates to that of typical transport data segmentation and reassembly in its simplest form. Session_ \_ [Stream(s)]_ \_ [FEC Blocks]_ \_ Segments Adamson, Bormann, et al. Expires January 2002 [Page 12] Internet Draft NORM Building Blocks July 2001 Figure 2: Hierarchy of Reliable Data Transfer Content Besides providing a general purpose, standard format for encapsu- lating NACK content, the format presented here has other beneficial properties: 1) A variety of forms of repair requests are supported: individ- ual, ranges, and lists of repair symbols. Also, bitmask formats for repair needs which can lend themselves to effi- cient packing and processing are supported. 2) The format is independent of FEC type where FEC is applica- ble. 3) Intermediate systems can process this format and perform functions in support of feedback suppression or other proto- col assistance with minimal side information. In this specification, it is assumed that any "Streams" (or Objects) and "FEC Blocks" can be identified with 32-bit numeric fields. In some protocols, "Segments" may be identified by numeric fields whose size is dependent upon the FEC coding technique used. Thus, in this specification, feedback messages with "segment" repair content identified fall into message categories denoting the explicit size (in bytes) of segment identifier fields to allow mes- sage parsing independent of FEC-type knowledge. Currently, segment identification fields of 1, 2, and 4 bytes (8, 16, 32 bits) are supported, but additional field sizes could easily be supported. Additionally, it is understood that the use of "Streams" and/or "Blocks" may not be applicable to some protocols. In this case, the specification supports NACK content consisting soley of repair requests for sets of transmission segments. 3.2.3.1 NACK Content Common Header A simple common header allows NACK content to be efficiently encap- sulated by receivers and parsed by senders and intermediate sys- tems. This header is usually followed by content dependent upon the header content, including sub-encapsulation of lower-level NACKs. This header consists of NackType, NackForm, and NackLength fields as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NackType | NackForm | NackLength (bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ enum NackType = {STREAM, BLOCKS, SEGMT1, SEGMT2, SEGMT4, OOB_DATA} Adamson, Bormann, et al. Expires January 2002 [Page 13] Internet Draft NORM Building Blocks July 2001 enum NackForm = {SINGLE, RANGE, LIST, MASK, SUBSET, COUNT} The NackType field is of one of the values: STREAM, BLOCKS, SEGMT1, SEGMT2, SEGMT4, or OOB_DATA. For example, the "STREAM" type indicates the Nack is requesting repair transmission for one or more "stream(s)" (or object) which have been transmitted. The STREAM type and other NackTypes are described in detail in the sec- tions below. The NackForm field is used to describe the format of the content of the given NACK message. The form "SINGLE" indicates the NACK is a request for repair of a single unit of the given NackType (STREAM, BLOCK, SEGMT1, SEGMT2, SEGMT4, or OOB_DATA) identified with appro- priate fields (Note the "SINGLE" form can also be used for some "wildcard" requests as described below). The "RANGE" form indi- cates that repair is requested for a contiguous range of units of the NackType field and the "LIST" form is used for discrete lists of units of the NackType. The "MASK" form indicates that bitmask content to describe the repair needs follows. Bitmask encoding of repair needs can be efficient in terms of size and processing for much NACK content. The "SUBSET" form is used to indicate content comprised of NACKs for units below the level of the given NackType. The "SUBSET" form provides context for the content with an indenti- fier for the given NackType. For example, a NACK of {type=STREAM, form=SUBSET} might encapsulate a NACK of {type=BLOCKS, form=SINGLE} to denote a missing FEC coding block for the given stream or object. Note the "COUNT" NackForm is only used with the SEGMTx NackTypes and is used indicate the number of erasures (missing seg- ments) in a given FEC coding block. The format for different com- binations of NackType and NackForm are described in detail below. The NackLength field is the size of the content attached to the NACK encapsulation header. This includes the total length of "SUB- SET" NACK content as well as the fields associated with the given NACK (not including its own encapsulation header). The NackLength is in units of bytes. Note in some cases there may be zero content attached to a given NACK. The NackLength field assists in the parsing of NACK content. For example, when the NACK content con- sists of a concatenation of different NACK units (NACK messages, bit masks, etc), the parser can use the NackLength field to find the end of the given NACK content (or the beginning of the next set of content). 3.2.3.2 STREAM NackType The STREAM NackType is used by receivers to request repair for spe- cific stream(s) or object(s) in the context of the reliable data Adamson, Bormann, et al. Expires January 2002 [Page 14] Internet Draft NORM Building Blocks July 2001 transfer session. Streams (or objects) are indentified by 32-bit fields. The STREAM NackType may of NackForm SINGLE, RANGE, LIST, MASK, or SUBSET. The following formats are used for these differ- ent STREAM Nack forms: STREAM::SINGLE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = STREAM | form = SINGLE | NackLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | stream/object id* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: The "STREAM::SINGLE" NACK can be used as a "wildcard" NACK requesting transmission/repair of all content the sender is willing to send under it's transmission/repair policies for late-joining receivers. This is done by setting the NackLength value equal to zero and omitting the "stream/object id" field. STREAM::RANGE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = STREAM | form = RANGE | NackLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | start stream/object id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | end stream/object id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Adamson, Bormann, et al. Expires January 2002 [Page 15] Internet Draft NORM Building Blocks July 2001 STREAM::LIST 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = STREAM | form = LIST | NackLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | stream index 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | stream index 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | stream index N-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Notes on STREAM::LIST content: 1) The list length can be determined from the NackLength field by right shifting it 2 places (i.e. divide by 4). STREAM::MASK 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = STREAM | form = MASK | NackLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mask1 offset (stream/object id) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mask1 length (bytes) | mask1 data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mask2 offset (stream/object id) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mask2 length (bytes) | mask2 data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | maskN offset (stream/object id) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | maskN length (bytes) | maskN data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Adamson, Bormann, et al. Expires January 2002 [Page 16] Internet Draft NORM Building Blocks July 2001 Notes on STREAM::MASK content: 1) The offset is an index to the starting stream id of the sub- sequent bitmask. 2) The offset stream id shall be an even multiple of 32 for alignment. 3) The MASK NackForm content is a concatenation of one or more bitmasks. The NackLength field can be used by the parser to determine the number of individual bitmasks included. STREAM::SUBSET 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = STREAM | form = SUBSET | NackLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | stream/object id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SubsetType | SubsetForm | SubsetLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subset content ... | Notes on STREAM::SUBSET content: 1) Valid STREAM::SUBSET NackTypes (i.e. SubsetType) include STREAM, BLOCKS, SEGMENTS (SEGMT1, SEGMT2, SEGMT4), and OOB_DATA. (Note that the "STREAM" (stream/object) type can be a subset of the STREAM type so that protocol instantia- tions may build multi-level hierarchies of streams, sub- streams, and objects as needed. This allows the number of hierarchy levels to be different for different protocols and maintain protocol-independent parsing of NACK content). 2) The "stream/object id" field gives context for the attached "subset" NACK content. 3) Multiple "subset" NACKs may be concatenated for the given, identified stream. The NackLength can be used by the parser to determine the number of subset items included. 3.2.3.3 BLOCKS NackType The BLOCKS NackType is used by the receiver to request repair con- tent for one or more specific FEC coding blocks. The BLOCK Nack- Type may generally be enclosed as SUBSET content for a STREAM NACK, but can be a stand-alone NACK type for protocols with a single implicit transmission stream. FEC blocks are indentified by 32-bit fields. The BLOCKS NackType may of the forms SINGLE, RANGE, LIST, MASK, or SUBSET. The "non-SUBSET" forms implicity indicates the Adamson, Bormann, et al. Expires January 2002 [Page 17] Internet Draft NORM Building Blocks July 2001 specified FEC coding blocks are missing in entirety while the SUB- SET form indicates repair is needed only for a portion of the iden- tified coding block. The same formats as used for the STREAM Nack- Type are used for the BLOCK NackType except that identifier fields contain FEC block identifiers instead of stream/object identifiers. The following formats are used for these different BLOCKS Nack forms: BLOCKS::SINGLE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = BLOCKS | form = SINGLE | NackLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC block id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: The "BLOCKS::SINGLE" NACK can be used as a "wildcard" NACK requesting transmission/repair of all FEC blocks for an indicated stream/object (if applicable) the sender is willing to send under it's transmission/repair policies for late-joining receivers. This is done by setting the NackLength value equal to zero and omitting the "block id" field. This NACK method may be useful when a receiver has only received out-of-band data associated with a given stream or object and requires all of the associated content. BLOCKS::RANGE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = BLOCKS | form = RANGE | NackLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | start FEC block id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | end FEC block id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Adamson, Bormann, et al. Expires January 2002 [Page 18] Internet Draft NORM Building Blocks July 2001 BLOCKS::LIST 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = BLOCKS | form = LIST | NackLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC block index 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC block index 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC block index N-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Notes on STREAM::LIST content: 1) The list length can be determined from the NackLength field by right shifting it 2 places (i.e. divide by 4). BLOCKS::MASK 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = BLOCKS | form = MASK | NackLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mask1 offset (block id) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mask1 length (bytes) | mask1 data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mask2 offset (block id) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mask2 length (bytes) | mask2 data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | maskN offset (block id) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | maskN length (bytes) | maskN data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Adamson, Bormann, et al. Expires January 2002 [Page 19] Internet Draft NORM Building Blocks July 2001 Notes on BLOCKS::MASK content: 1) The offset is an index to the starting block id of the subse- quent bitmask. 2) The offset block id shall be an even multiple of 32 for alignment. 3) The MASK NackForm content is a concatenation of one or more bitmasks. The NackLength field can be used by the parser to determine the number of individual bitmasks included. BLOCKS::SUBSET 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = BLOCKS | form = SUBSET | NackLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | block id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SubsetType | SubsetForm | SubsetLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | subset content ... | Notes on BLOCKS::SUBSET content: 1) Valid BLOCKS::SUBSET NackTypes (i.e. SubsetType) include SEG- MENTS (SEGMT1, SEGMT2, SEGMT4) only. 2) The "block id" field gives context for the attached "subset" NACK content. 3) Multiple "subset" NACKs may be concatenated for the given, identified block. The NackLength can be used by the parser to determine the number of subset items included. 3.2.3.4 SEGMENTS (SEGMT1, SEGMT2, and SEGMT4) NackTypes The SEGMENTS NackTypes are used by the receiver to request repair content for a set of segments possible associated with a given stream and/or FEC coding block. For protocols employing FEC block- ing, the SEGMENTS NackTypes may generally be enclosed as SUBSET content for a BLOCK Nack (which in turn may be enclosed as part of a STREAM NackType if applicable), but can be a stand-alone NACK type for protocols with a single implicit transmission stream and no block-based encoding. Segments are indentified by numeric iden- tifiers. The appropriate size of segment identifier can be a func- tion of the FEC encoding technique. For example, segments that are part of FEC coding blocks up to 256 packets in length may use an 8-bit identifier while larger block codes may require a Adamson, Bormann, et al. Expires January 2002 [Page 20] Internet Draft NORM Building Blocks July 2001 correspondingly large segment identification field. For this rea- son, the SEGMENTS NackType is split into distinct types of SEGMT1, SEGMT2, and SEGMT4. As shown in the table below, the numeric por- tion of the NackType name (1, 2, or 4) corresponds to the number of bytes with which segment identifier fields occupy in the content of that NackType. These values correspond to 8, 16, or 32 bit indexes for fields related to segment identification, etc. Segment identi- fier fields use "Big Endian" ordering of most to least significant bytes. +---------+----------------------+ |NackType | Bytes per Segment-Id | +---------+----------------------+ | SEGMT1 | 1 | +---------+----------------------+ | SEGMT2 | 2 | +---------+----------------------+ | SEGMT4 | 4 | +---------+----------------------+ Note that the use of appropriately sized fields allow for proper computing alignment of associated message content while maintaining efficient packing of NACK payload content for small to large block sizes. If needed, this protocol specification could be easily extended to include other word sizes (e.g. SEGMT5 for 64-bit index- ing and alignment of segment identifiers). The SEGMENTS NackTypes (SEGMT1, SEGMT2, SEGMT4) may of NackForm SINGLE, RANGE, LIST, or MASK. Formats similar to those used for the STREAM and BLOCK NackTypes are used with the appropriate inter- pretation of segment identifier fields. The following formats are used for these resulting different SEGMENTS NackForms: SEGMENTS::SINGLE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = SEGMTx | form = SINGLE | NackLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...segment id... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: The "segment id" field is of length 1, 2, or 4 bytes directly corresponding to the type of SEGMT1, SEGMT2, or SEGMT4. Adamson, Bormann, et al. Expires January 2002 [Page 21] Internet Draft NORM Building Blocks July 2001 SEGMENTS::RANGE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = SEGMTx | form = RANGE | NackLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...start segment id... | ...end segment id... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: The "start segment id" and "end segment id" fields are of length 1, 2, or 4 bytes directly corresponding to the type of SEGMT1, SEGMT2, or SEGMT4. SEGMENTS::LIST 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = SEGMTx | form = LIST | NackLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...segment index 0... | ...segment index 1... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...segment index N-2... | ...segment index N-2... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Notes on SEGMENTS::LIST content: 1) The "segment index" fields are of length 1, 2, or 4 bytes directly corresponding to the type of SEGMT1, SEGMT2, or SEGMT4. 2) The LIST length can be determined from the NackLength field by right shifting it 0, 1, or 2 places as needed for the given SEGMTx type (i.e. divide by 1, 2, or 4). SEGMENTS::MASK An "erasure count" field is included for SEGMENT NackType content of NackForm MASK. The "erasure count" field allows the parser of the NACK message (generally a sender or repairer of data) to quickly determine FEC repair strategies without needing to count the "set" portion of the bitmask content. Note that the "erasure count" can easily be determined for the "RANGE" and "LIST" forms from the corresponding "end-start+1" or "NackLength" values. The MASK form can also be used to provide "erasure count only" feedback by omitting inclusion of bitmask content and setting the NackLength Adamson, Bormann, et al. Expires January 2002 [Page 22] Internet Draft NORM Building Blocks July 2001 appropriately small. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = SEGMTx | form = MASK | NackLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...erasure count... | ...mask1 offset (seg id)... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...mask1 length... | mask1 data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...mask2 offset (seg id)... | ...mask2 length... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mask2 data ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...maskN offset (seg id)... | ...maskN length... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | maskN data ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Notes on SEGMENTS::MASK content: 1) The "list length" and "segment index" fields are of length 1, 2, or 4 bytes directly corresponding to the type of SEGMT1, SEGMT2, or SEGMT4. 2) The "offset" (segment id) shall be an even multiple of 8, 16, or 32 corresponding to NackTypes of SEGMT1, SEGMT2, or SEGMT4 for computing alignment purposes. 3) The "mask length" field shall be an even multiple of 1, 2, or 4 corresponding to NackTypes of SEGMT1, SEGMT2, or SEGMT4 for computing alignment purposes. 4) The "offset" is an index to the starting block id of the sub- sequent bitmask. 5) The MASK NackForm content is a concatenation of one or more bitmasks. The NackLength field can be used by the parser to determine the number of individual bitmasks included. Adamson, Bormann, et al. Expires January 2002 [Page 23] Internet Draft NORM Building Blocks July 2001 SEGMENTS::COUNT 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = SEGMTx | form = COUNT | NackLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...erasure count... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: The "erasure count" field is of length 1, 2, or 4 bytes directly corresponding to the NackType of SEGMT1, SEGMT2, or SEGMT4. 3.2.3.5 OOB_DATA NackType The OOB_DATA NackType is used by receivers to request repair of out-of-band data content associated with a specific stream/object or with the general context of a reliable data transfer session. The nature of OOB_DATA is protocol specific, but the NACK format specified in this document provides a general approach for request- ing this type of repair. The only NackForm supported for the OOB_DATA NackType is SINGLE. The OOB_DATA NACK can be transmitted as a stand-alone NACK message where it is implicitly understood that the request is for any OOB_DATA content general to the reli- able data transfer session. Alternatively, the OOB_DATA NackType can be transmitted as "subset" content of a STREAM NACK when the receiver is requesting out-of-band data associated with a specific stream or object within the session. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = O_DATA | form = SINGLE | NackLength = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Adamson, Bormann, et al. Expires January 2002 [Page 24] Internet Draft NORM Building Blocks July 2001 3.2.3.6 Example NACK Messages: Request for OOB_DATA associated with a given stream/object: (stream:1) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = STREAM | form = SUBSET | NackLength = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | stream/object id = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = O_DATA | form = SINGLE | NackLength = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Request for a SINGLE segment: (stream:1 block:5 segment:10 seg- ment_id_length:2) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = STREAM | form = SUBSET | NackLength = 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | stream/object id = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = BLOCKS | form = SUBSET | NackLength = 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | block id = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = SEGMT2 | form = SINGLE | NackLength = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | segId = 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Adamson, Bormann, et al. Expires January 2002 [Page 25] Internet Draft NORM Building Blocks July 2001 Request for a LIST of segments: (stream:1 block:5 seg- ments:11,12,21,32 segment_id_length:1) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = STREAM | form = SUBSET | NackLength = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | stream/object id = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = BLOCKS | form = SUBSET | NackLength = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | block id = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = SEGMT2 | form = LIST | NackLength = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | segId = 11 | segId = 12 | segId = 21 | segId = 32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Request indicating erasure count for a specfic FEC coding block: (stream:1 block:5 erasures:4) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = STREAM | form = SUBSET | NackLength = 17 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | stream/object id = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = BLOCKS | form = SUBSET | NackLength = 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | block id = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = SEGMT1 | form = COUNT | NackLength = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | count = 4 | +-+-+-+-+-+-+-+-+ Adamson, Bormann, et al. Expires January 2002 [Page 26] Internet Draft NORM Building Blocks July 2001 Request with Bitmask indicating repair needs for a specific FEC block: (stream:1 block:5 segment_id_length:1): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = STREAM | form = SUBSET | NackLength = 27 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | stream/object id = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = BLOCKS | form = SUBSET | NackLength = 19 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | block id = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = SEGMT1 | form = MASK | NackLength = 11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | offset = 0 | erasures = 16 | maskLen = 8 | maskData[0] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | maskData[1] | maskData[2] | maskData[3] | maskData[4] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | maskData[5] | maskData[6] | maskData[7] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Request for range of segments for coding block (no stream/objects): (block:12 segments:239-283) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = BLOCKS | form = SUBSET | NackLength = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | block id = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = SEGMT2 | form = RANGE | NackLength = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | start = 239 | end = 283 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Adamson, Bormann, et al. Expires January 2002 [Page 27] Internet Draft NORM Building Blocks July 2001 Request for range of segments for coding block associated with an object (or stream) which is a subset of another stream: (stream: 1 object: 342 block:12 segments:143-212) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = STREAM | form = SUBSET | NackLength = 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | stream/object id = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = STREAM | form = SUBSET | NackLength = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | stream/object id = 342 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = BLOCKS | form = SUBSET | NackLength = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | block id = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type = SEGMT2 | form = RANGE | NackLength = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | start = 143 | end = 212 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 the 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 the repair information it will be subsequently trans- mitting). The backoff timeout periods used by receivers should be indepen- dently, randomly picked by receivers with an exponential distribu- tion [Nonnenmacher98]. This results in the bulk of the receiver set holding off transmission of NACK messages under the assumption that the smaller number of "early NACKers" will supersede the repair needs of the remainder of the group. The mean of the dis- tribution should be determined as a function of the current esti- mate of sender<->group greatest round trip time (GRTT) and a group size estimate which determined by other mechanisms within the pro- tocol (See section below) or preset by the multicast application. Adamson, Bormann, et al. Expires January 2002 [Page 28] Internet Draft NORM Building Blocks July 2001 A simple algorithm can be constructed to generate random backoff timeouts with the appropriate distribution. Additionally, the algorithm may be designed to optimize the backoff distribution given the number of receivers (R) potentially generating feedback. This "optimization" minimizes the number of feedback messages (e.g. NACK) in the worst-case situation where all receivers generate a NACK. The maximum backoff timeout (T) can also be controlled to allow the application or protocol tradeoff NACK latency versus vol- ume of feedback traffic. A larger value of T will result in a lower density of feedback traffic for a given repair cycle. A smaller value of T results in shorter latency which reduces the buffering requirements of senders and receivers for reliable trans- port. Given the receiver group size (R), and maximum allowed backoff timeout (T), a truncated exponential backoff timeout (t') can be picked with the following algorithm: 1) Establish an optimal mean (L) for the exponential backoff based on the group size: L = ln(R) + 1 2) Pick a random number (x) from a uniform distribution over a range of: L L L ---------------- to ---------------- + --- T * (exp(L) - 1) T * (exp(L) - 1) T 3) Transform this random variate to generate the desired random backoff time (t) with the following equation: t' = T/L * ln(x * (exp(L) - 1) * (T/L)) This is a C language function which can be used to perform this function: double RandomBackoff(double maxTime, double groupSize) { double lambda = log(groupSize) + 1; double x = UniformRand(lambda/maxTime) + lambda / (maxTime*(exp(lambda)-1)); return ((maxTime/lambda) * log(x*(exp(lambda)-1)*(maxTime/lambda))); } // end RandomBackoff() Adamson, Bormann, et al. Expires January 2002 [Page 29] Internet Draft NORM Building Blocks July 2001 where UniformRand(double max) returns random numbers with a uniform distribution from the range of 0..max. For example, based on the POSIX "rand()" function, the following code can be used: double UniformRand(double max) { return (max * ((double)rand()/(double)RAND_MAX)); } The number of expected NACKs generated (N) within the first round trip time for a single loss event can be approximately expected to be: N = exp(1.2 * L / (2*T/GRTT)) Thus the maximum backoff time (T) can be adjusted to tradeoff worst-case NACK feedback volume versus latency. This is derived from [Nonnenmacher98] and assumes T >= GRTT, and L is the mean of the distribution optimized for the given group size as shown in the algorithm above. Note that other mechanisms within protocol may work to reduce redundant NACK generation further. There are some secondary NACK suppression mechanisms which can also be considered. For example, the sender's transmissions may follow an ordinal sequence of transmission (observed through data/repair content 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 sender 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 Adamson, Bormann, et al. Expires January 2002 [Page 30] Internet Draft NORM Building Blocks July 2001 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 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 sequence 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 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 Adamson, Bormann, et al. Expires January 2002 [Page 31] Internet Draft NORM Building Blocks July 2001 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 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" Policies/ Procedures Consideration should be given to how new receivers join a group (perhaps where reliable transmission is already in progress) and beging NACKing for any repair needs. If this is unconstrained, the dynamics of group membership may impede the application's ability to meet it goals progressing the transmission of data. Policies limiting the opportunities at which receivers begin participating in the NACK process may be used to achieve the desired behavior. For example, it may be beneficial if receivers only attempt reli- able reception from a newly-heard sender when upon non-repair transmissions of data in the first FEC block of an object or logi- cal portion of a stream. The sender may also implement policies limiting which receivers from which it will accept NACK requests, but this may be prohibitive for scalability reasons in some situa- tions. In some types of bulk transfer applications (and for poten- tial interactive applications), it may alternatively desirable to have a looser transport synchronization policy and rely upon ses- sion management mechanisms to control group dynamics which may result in poor behavior. Inputs: 1) Current object/stream data/repair content and sequencing identifiers from sender transmissions. Outputs: Adamson, Bormann, et al. Expires January 2002 [Page 32] Internet Draft NORM Building Blocks July 2001 1) Receiver yes/no decision to begin receiving and NACKing for reliable reception of data 3.4 Reliable multicast member identification In a NORM protocol (or other multicast protocols) where there is the potential for multiple sources of data, it is necessary to pro- vide some mechanism to uniquely identify the sources (and possibly some or all receivers in some cases) within the group. Identity based on arriving packet source addresses is insufficient for sev- eral 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 ses- sion members. 3.5 Data Content identification The data and repair content transmitted by a NORM sender requires some form of identification in the protocol header fields. This identification is required to facilitate the reliable NACK-oriented repair process. These identifiers will be used in NACK messages generated. 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 Adamson, Bormann, et al. Expires January 2002 [Page 33] Internet Draft NORM Building Blocks July 2001 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 inter- val. Note that it is _not_ expected that this data content identi- fication 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 and during the time that sender is supporting a specific transport instance of that object or stream. Since the "bulk" object/stream content will generally require seg- mentation, some form of segment identification must also be provided. This segment identifier will be relative to any object or stream identifier which has been provided. Thus, in some cases, NORM protocol instantiations may be able to receive trans- missions and request repair for multiple streams and one or more sets of static objects in parallel. For protocol instantiations employing FEC the portion of the data content identi- fier may consist of a logical concatenation of a coding block iden- tifier and identifer for the specific data or parity seg- ment of the code block. The RMT FEC Building Block (currently "draft-ietf-rmt-bb-fec-02.txt") provides a standard message format for identifying FEC transmission content. The "General Purpose NACK Encapsulation Format" described herein (Section 3.2.2) is com- patible with the RMT FEC Building Block specification. 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 individ- ual protocol instantiations. In summary, the following data content identification fields may be required for NORM protocol data content messages: 1) Source node identifier () 2) Object/Stream identifier (), if applicable. 3) FEC Block identifier (), if applicable. 4) Segment identifier () 5) Flags to differentiate interpretation of identifier fields Adamson, Bormann, et al. Expires January 2002 [Page 34] Internet Draft NORM Building Blocks July 2001 or identifier structure which implicitly indicates usage. 6) Additional FEC transmission content fields per FEC Building Block These fields have been identified since any generated NACK messages will use these identifiers in requesting repair or retransmission of data. NORM 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 been iden- tified which can provide great performance enhancements to the repair process of NACK-oriented and other reliable multicast proto- cols [Metzner84, Macker97]. NORM protocols can reap additional benefits since FEC-based repair does not _generally_ require explicit knowledge of repair content within the bounds of its cod- ing 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 NORM, these sorts of requirements may dictate the types of algorithms and protocol approaches which are applica- ble. A specific issue related to the use of FEC with NORM is the mecha- nism used to identify which portion(s) of transmitted data content to which specific FEC packets are applicable. It is expected that FEC algorithms will be based on generating a set of parity repair packets for a corresponding block of transmitted data packets. Since data content packets are uniquely identified by the concate- nation of during transport, it is expected that FEC packets will be identified in a similar manner. The RMT FEC Building Block specification provides detailed recommendations concerning application of FEC and standard formats for related reliable multicast protocol messages. 3.7 Round-trip Timing Collection Adamson, Bormann, et al. Expires January 2002 [Page 35] Internet Draft NORM Building Blocks July 2001 The measurement of packet propagation round-trip time (RTT) among members of the group is required to support NACK suppression algo- rithms, timing of sender commands or certain repair functions, and congestion control operation. The nature of the round-trip infor- mation collected is dependent upon the type of interaction among the members of the group. In the case where only "one-to-many" transmission is required, it may be necessary that only the sender require RTT knowledge of the greatest RTT (GRTT) among the receiver set and/or RTT knowledge of only a portion of the group. Here, the GRTT information might be collected in a reasonably scalable man- ner. For congestion control operation, it is possible that RTT information may be required by each receiver in the group. In this case, an alternative RTT collection scheme may be utilized where receivers collect individual RTT measurements with respect to the sender and advertise them (or an competed subset) to the group or sender. Where it is likely that exchange of reliable multicast data will occur among the group on a "many-to-many" basis, there are alternative measurement techniques which might be employed for increased efficiency [Ozdemir99]. And in some cases, there might be absolute time synchronization among hosts which may simplify RTT measurement. There are trade-offs in multicast congestion control design which need further consideration before a universal recom- mendation on RTT (or GRTT) measurement can be specified. Regard- less of how the RTT information is collected (and more specifically GRTT) with respect to congestion control or other requirements, the sender will need to advertise its current GRTT estimate to the group for timing of the 3.7.1 One-to-Many Sender GRTT Measurement The goal of this form of RTT measurement is for the sender to learn the GRTT among the receivers who are actively participating in NORM operation. The set of receivers participating in this process may be the entire group or some subset of the group determined from another mechanism within the protocol instantiation. An approach to collect this GRTT information follows. The sender periodically polls the group with a message (independent or "piggy-backed" with other transmissions) containing a timestamp relative to an internal clock at the sender. Upon recep- tion of this message, the receivers will record this timestamp and the time (referenced to their own clocks) at which it was received . When the receiver provides feedback to the sender (either explicitly or as part of other feedback messages depending upon protocol instantion specification), it will con- struct a "response" using the formula: = + ( - ) Adamson, Bormann, et al. Expires January 2002 [Page 36] Internet Draft NORM Building Blocks July 2001 where the is the timestamp from the last probe message received from the source and the ( - ) is the amount of time differential since that request was received until the receiver generated the response. The sender processes each receiver response by calculating a cur- rent RTT measurement for the receiver from whom the response was received using the following formula: = - During the each periodic GRTT probing interval, the source keeps the peak round trip estimate from the set of responses it has received. The GRTT estimate should be filtered to be conservative towards maintaining an estimate biased towards the greatest receiver RTT measurements received. A conservative estimate of GRTT maximizes the efficiency redundant NACK suppression and repair aggregation. The update to the source's ongoing estimate of GRTT is done observing the following rules: 1) If a receiver's response round trip calculation is greater than the current GRTT estimate AND current peak, the response value is immediately fed into the GRTT update fil- ter given below. In any case, the source records the "peak" receiver RTT measurement for the current probe interval. 2) At the end of the response collection period (i.e. the GRTT probe interval), if the recorded "peak" response is less than the current GRTT estimate AND this is the third consec- utive collection period with a peak less than the current GRTT estimate the recorded peak is fed into the GRTT update. (Implicitly, Rule #1 was applied otherwise so no new update is required). 3) At the end of the response collection period, the peak tracking value is set to either ZERO if the "peak" is greater than or equal to the current GRTT estimate (i.e. Already incorporated into the filter under Rule #1) or kept the same if its value is less than the current GRTT estimate AND was not yet incorporated into the GRTT update filter according to Rule #2. Thus for decreases in the source's estimate of GRTT, the "peak" is tracked across three consec- utive probe intervals. The current MDP implementation uses the following GRTT update filter to incorporate new peak responses into the the GRTT estimate: if (peak > current_estimate) current_estimate = 0.25 * current_estimate + 0.75 * peak; Adamson, Bormann, et al. Expires January 2002 [Page 37] Internet Draft NORM Building Blocks July 2001 else current_estimate = 0.75 * current_estimate + 0.25 * peak; This update method is biased towards maintaining an estimate of the worst-case round trip delay. The reason the GRTT estimate is reduced only after 3 consecutive collection periods with smaller response peaks is to be conservative where packet loss may have resulted in lost response messages. And then the reduction is additionally conservatively weighted using the averaging filter from above. The GRTT collection period (i.e. period of probe transmission) could be fixed at a value on the order of that expected for group membership and/or network topology dynamics. For robustness, more rapid probing could be used at protocol startup before settling to a less frequent, steady-state interval. Optionally, an algorithm may be developed to adjust the GRTT collection period dynamically in response to the current GRTT estimate (or variations in it) and to an estimation of packet loss. The overhead of probing messages could then be reduced when the GRTT estimate is stable and unchang- ing, but be adjusted to track more dynamically during periods of variation with correspondingly shorter GRTT collection periods. In summary, although NORM repair cycle timeouts are based on GRTT, it should be noted that convergent operation of the protocol does not _strictly_ depend on accurate GRTT estimation. The current mechanism has proved sufficient in simulations and in the environ- ments in which NORM-like protocols have been deployed to date. The estimate provided by the algorithm tracks the peak envelope of actual GRTT (including operating system effect as well as network delays) even in relaitvely high loss connectivity. The steady- state probing/update interval may potentially be varied to accommo- date different levels of expected network dynamics in different environments. 3.7.2 One-to-Many Receiver RTT Measurement (TBD - Receivers "ping" sender for RTT measurement, and then receivers competitively (worst case RTT metric) advertise their measurements to the sender and optionally group so the sender can determine GRTT ... Sender should still robustly advertise its cur- rent GRTT knowledge to the group so group can use appropriate tim- ing) 3.7.3 Many-to-Many RTT Measurement (TBD - Describe approach based on Ozdemir99, if appropriate/appli- cable?) Adamson, Bormann, et al. Expires January 2002 [Page 38] Internet Draft NORM Building Blocks July 2001 3.7.4 Sender GRTT Advertisement To facilitate determistic NORM protocol operation, the sender should robustly advertise its current estimation of GRTT to the receiver set. Common, robust knowledge of the sender's current operating GRTT estimate among the group will allow the protocol to progress in its most efficient manner. The sender's GRTT estimate can be robustly advertised to the group by simply embedding the estimate into all pertinent messages transmitted by the sender. The overhead of this can be made quite small by quantizing (com- pressing) the GRTT estimate to a single byte of information. The following C-lanquage function algorithm allows this to be done over a wide range of GRTT values while maintaining a greater range of precision for small GRTT values and less precision for large val- ues: unsigned char QuantizeGrtt(double grtt) { if (grtt > 1.0e03) grtt = 1.0e03; else if (grtt < 1.0e-06) grtt = 1.0e-06; if (grtt < 3.3e-05) return ((unsigned char)(grtt * 1.0e06) - 1); else return ((unsigned char)(ceil(255.0.- (13.0 * log(1.0e03/grtt))))); } Note that this function is useful for quantizing GRTT times in the range of 1 microsecond to 1000 seconds. Of course, NORM protocol implementations may wish to further constrain advertised GRTT esti- mates (e.g. limit the maximum value) for practical reasons. 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 Adamson, Bormann, et al. Expires January 2002 [Page 39] Internet Draft NORM Building Blocks July 2001 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 statistics collection, session management, etc) 4.0 Security Considerations (TBD) 5.0 References [Mankin98] A. Mankin, A. Romanow, S. Bradner, V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Applica- tion 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. Interna- tional 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 multicast 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, Adamson, Bormann, et al. Expires January 2002 [Page 40] Internet Draft NORM Building Blocks July 2001 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, October 1997. [Ozdemir99] V. Ozdemir, S. Muthukrishnan, I. Rhee, "Scalable, Low- Overhead Network Delay Estimation", NCSU/AT&T White Paper, February 1999. 6.0 Authors' Addresses Brian Adamson adamson@itd.nrl.navy.mil Naval Research Laboratory Washington, DC, USA, 20375 Carsten Bormann cabo@tellique.de Tellique Kommunikationstechnik GmbH Gustav-Meyer-Allee 25 Geb ude 12 D-13355 Berlin, Germany 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, Bormann, et al. Expires January 2002 [Page 41] --============_-1216460392==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" -- Brian __________________________________ Brian Adamson --============_-1216460392==_============-- >From owner-rmt@listserv.lbl.gov Fri Jul 20 13:54:48 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6KKsih29351; Fri, 20 Jul 2001 13:54: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.11.2/8.11.2) with ESMTP id f6KKsgR29347 for ; Fri, 20 Jul 2001 13:54:42 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6KKsfT23137 for ; Fri, 20 Jul 2001 13:54:41 -0700 (PDT) Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6KKseA23132 for ; Fri, 20 Jul 2001 13:54:40 -0700 (PDT) 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 QAA05375; Fri, 20 Jul 2001 16:48:22 -0400 (EDT) Mime-Version: 1.0 X-Sender: adamson@pop.itd.nrl.navy.mil Message-Id: In-Reply-To: References: Date: Fri, 20 Jul 2001 16:48:23 -0400 To: From: Brian Adamson Subject: draft-ietf-rmt-pi-norm-02.txt Cc: "Lorenzo Vicisano" , "Roger Kermode" , Content-Type: multipart/mixed; boundary="============_-1216460390==_============" Sender: owner-rmt@lbl.gov Precedence: bulk --============_-1216460390==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Please post this draft on the IETF Internet Drafts archive. This is an update of an existing WG draft (RMT). --============_-1216460390==_============ Content-Id: Content-Type: text/plain; name="draft-ietf-rmt-pi-norm-02.txt"; charset="us-ascii" ; format="flowed" Content-Disposition: attachment; filename="draft-ietf-rmt-pi-norm-02.txt" ; modification-date="Fri, 20 Jul 2001 16:44:52 -0400" RMT Working Group B. Adamson/Newlink INTERNET-DRAFT C. Bormann/Tellique draft-ietf-rmt-pi-norm-02.txt M. Handley/ACIRI Expires: January 2002 J. Macker/NRL July 2001 NACK-Oriented Reliable Multicast Protocol (NORM) 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 document describes the messages and procedures of the Nega- tive-acknowledgement (NACK) oriented reliable multicast (NORM). This revision of the document represents an initial outline of the protocol description. The document requires refinement in a number of areas to be considered complete. At this time, the document describes the high level details of the reliable multicast bulk transfer service model this protocol hopes to fulfill and the gen- eral message types and mechanisms which will be used to accomplish those goals. Adamson, Borman, et al. Expires January 2002 [Page 1] Internet Draft NORM Protocol July 2001 1.0 Protocol Design Goals NORM is designed to provide end-to-end reliable transport of data from sender(s) to a group of receivers over a multicast-capable network. The primary design goal of NORM is to provide for effi- cient, scalable, and robust bulk data (e.g. computer files, trans- mission of persistent data) transfer adaptable (preferably in an automated fashion) across heterogeneous networks and topologies. The protocol is capable of operating in an end-to-end fashion with no assistance from intermediate systems beyond basic IP multicast group management and forwarding services. However, an additional design goal will be compatibility with other reliable multicast "building blocks" [REF RMT Building Block Guidelines] to take advantage of additional network capabilities when available. Thus, while the techniques utilized in NORM are principally applicable to "flat" network distribution, they might also be applied to a given level of a hierarchical (e.g. tree-based) multicast distribution system if so desired. NORM can make use of reciprocal (among senders and receivers) multicast routing when available but will also be capable of efficient operation in asymmetric multicast topologies [REF single source multicast, etc]. Group communication scalability requirements leads to adaptation of negative acknowledgement (NACK) based protocol schemes [REF.]. NORM is a protocol centered around the use of selective NACKs to request repairs of missing data. NORM also uses NACK suppression methods and dynamic event timers to reduce retransmission requests and avoid congestion within the network. When used in pure multi- cast session operation, both NACKs and repair transmissions are multicast to the group to aid in feedback and control message sup- pression. This feature and additional message aggregation func- tionality reduce the likelihood of multicast control message implo- sion. NORM also dynamically measures the greatest group roundtrip time (GRTT) between sources and the set of multicast receivers to further improve the efficiency of the protocol state timers and probabilistic backoff algorithms. This allows NORM to scale well while maintaining reliable data delivery transport with low latency relative to the network topology over which it is operating. NORM also provides for the use of packet-level forward error correction (FEC) techniques for efficient multicast repair and optional proac- tive transmission robustness. Another aspect of the NORM protocol design is providing support for distributed multicast session participation with minimal coordina- tion among sources and receivers. The protocol allows sources and receivers to dynamically join and leave multicast sessions at will with minimal overhead for control information and timing synchro- nization among participants. To accommodate this capability, NORM Adamson, Borman, et al. Expires January 2002 [Page 2] Internet Draft NORM Protocol July 2001 protocol message headers contain some common information allowing receivers to easily synchronize to sources throughout the lifetime of a defined session. These common headers also include support for collection of transmission timing information (e.g., round trip delays) that allows NORM to adapt itself to a wide range of dynamic network conditions with little or no pre-configuration. The proto- col is purposely designed to be tolerant of inaccurate timing esti- mations or lossy conditions which may occur many networks includin mobile and wireless. The protocol is also designed to exhibit con- vergence even under cases of heavy packet loss and large queueing or transmission delays. While the various features of NORM are designed to provide some measure of general purpose utility, it is important to emphasize the understanding that "no one size fits all" in the reliable mul- ticast transport arena. There are numerous engineering tradeoffs involved in reliable multicast transport design and this requires an increased awareness of application and network architecture con- siderations. Performance requirements affecting design can include: group size, heterogeneity (e.g., capacity and/or delay), asymmetric delivery, data ordering, delivery delay, group dynamics, mobility, congestion control, and transport across low capacity connections. NORM contains various protocol parameters to accommo- date many of these differing requirements, but there is an assumed model of bulk transfer transport service that drives the trade-offs resulting in the protocol described here. 1.1 NORM Transport Service Model An instance of the NORM protocol (NormSession) is defined within the context of one or more senders and receivers mutually communi- cating with prdefined IP addresses and host port(s). While point- to-point (unicast) NormSessions may be established between a pair of protocol participants (NormNodes), it is anticipated the proto- col will be used for multicast data distribution and that partici- pating nodes will communicate on a common IP multicast group address and port number which has been chosen via other means (e.g. MBONE session directory tools, administrative coordination, SIP signalling, etc). Note that the protocol provides for an optional mechanism for receiver nodes to use unicast addressing to provide feedback to senders in networks where this is required (e.g. Single Source Multicast Routing, asymmetric topologies, etc). The protocol design is principally driven with the assumption of a single sender transmitting bulk data content to a group of receivers. However, the protocol does provide for multiple senders to coexist within the context of a NormSession. In initial imple- mentations of this protocol, it is anticipated that multiple Adamson, Borman, et al. Expires January 2002 [Page 3] Internet Draft NORM Protocol July 2001 senders will transmit independently of one another and receivers will maintain state as necessary for each independent sender. In future iterations of this document, it is possible that some aspects of protocol operation (e.g. round-trip time collection) will provide for alternate modes allowing more efficient perfor- mance for applications requiring multiple senders. NORM provides for three types of bulk data content objects (NormOb- jects) to be reliably transported. These types include static com- puter memory data content (NORM_OBJECT_DATA), computer storage files (NORM_OBJECT_FILE), and non-finite streams of continuous data content (NORM_OBJECT_STREAM). The distinction between NORM_OBJECT_DATA and NORM_OBJECT_FILE is simply to provide a "hint" to receivers in NormSessions serving multiple types of content as to what type of storage should be allocated for received content (i.e. memory or file storage). Other than that distinction, the two are identical, providing for reliable transport of finite units of content. The use of the NORM_OBJECT_STREAM type is at the application's discretion and conceivably be used to carry static data or file content also. Reliable stream service also opens up other possibilities such as reliable messaging or other unbounded, perhaps dynamically produced content. The NORM_OBJECT_STREAM pro- vides for reliable transport analogous to that of the Transmission Control Protocol (TCP) although NORM receivers will be able to begin receiving stream content at any point in time (The applica- bility of this feature will depend upon the application). The static data and file services are anticpated to be useful for mul- ticast-based cache applications with the ability to reliably pro- vide transmission/repair of a large set of static data. Other types of static data/file "casting" services might make use of these transport object types, too. The NORM protocol allows for a small amount of "out-of-band" data (NORM_INFO) to be attached to the data content objects transmitted by the sender. This readily- available "out-of-band" data allows multicast receivers to quickly and efficiently determine the nature of the bulk content (data, file, or stream) being transmitted to allow application-level con- trol of the receiver node's participation in the current transport activity. This allows the protocol to be flexible with minimal pre-coordination among senders and receivers. NORM does _not_ provide for global or application-level identifica- tion of data content within in its message headers (It should be noted that the NORM_INFO out-of-band data mechanism can be lever- aged by the application for this purpose if desired, or identifica- tion could alternatively be embedded within the data content). NORM identifies data content objects (NormObjects) with transport identifiers which are applicable while the sender is transmitting and/or repairing the given object. These transport data content Adamson, Borman, et al. Expires January 2002 [Page 4] Internet Draft NORM Protocol July 2001 identifiers are assigned in a montonically increasing fashion by each NORM sender during the course of a NormSession. Each sender maintains its transport identifier assignments independently so NormObjects are uniquely identified during transport by the con- catenation of the sender's session-unique identifier (NormNodeId) and the assigned NormObject transport identifier (NormTransportId). The NormTransportIds are assigned from a large (32 bit?) numeric space in increasing order and may be reassigned for long-lived ses- sions. The NORM protocol provides mechanisms so that the sender application may terminate transmission of data content and inform the group of this in an efficient manner. Other similar protocol control mechanisms (e.g. session termination, receiver synchroniza- tion, etc) are specified so that reliable multicast application variants may construct different, complete bulk transfer communica- tion models to meet their goals. In summary, the NORM protocol's goal is to provide reliable trans- port of data content objects (including a potentially mixed set of types) to the receiver set from one or more senders. The senders will queue and transmit content in the form of static data or files and/or non-finite, ongoing stream types. The sender will provide for repair transmission of this content in response to NACK mes- sages received from the receiver group. Mechanisms for "out-of- band" information and other session management mechanisms are also specified for use by applications to form a complete reliable mul- ticast transport solutions for a range different purposes. 2.0 Protocol Definition 2.1 Assumptions A NORM protocol instantiation (NormSession) is defined by the con- text of participants communicating connectionless (e.g. User Data- gram Protocol (UDP)) packets over an Internet Protocol (IP) network on a common, pre-determined network address and host port number. Generally, the participants exchange packets on an IP multicast group address, but unicast transport may also be established or applied as an adjunct to multicast delivery. Currently the protocol uses a single multicast address for transmissions associated with a given NORM session. However, in the future, it is possible that multiple multicast addresses might be employed to segregate sepa- rate degrees of repair information to different groups of receivers experiencing different packet loss characteristics with respect to a given sender. This capability is under ongoing investigation in the research community [REF]. For multicast operation, the NORM protocol assumes basic IP multicast forwarding service is available at least from the sender(s) to the receiver set. However, the Adamson, Borman, et al. Expires January 2002 [Page 5] Internet Draft NORM Protocol July 2001 protocol also supports asymmetry where receiver participants may transmit back to sender participants via unicast routing instead of broadcasting to the session multicast address. Each participant (NormNode) within an NormSession is assumed to have an preselected unique XX-bit (TBD) identifier (NormNodeId). NormNodes MUST have uniquely assigned identifiers within a single NormSession to distinquish between possible multiple senders and to distinguish feedback information from different receivers. The protocol does not preclude multiple sender nodes actively transmit- ting within the context of a single NORM session (i.e. many- to- many operation), but any type of interactive coordination among these senders is assumed to be controlled by a higher protocol layer (perhaps using some of the optional NORM mechanisms later specified to perform this coordination). Unique data content transmitted within a NormSession uses sender- assigned identifiers (NormObjectTransportIds) which are valid and applicable only during the actual _transport_ of the particular portion of data content (i.e. for as long as the sender is trans- mitting and providing repair of the indicated data content). Any globally unique identification of transported data content must be assigned and processed by the higher level application using the NORM transport service. 2.2 General Protocol Operation A NORM sender primarily generates messages of type NORM_DATA which carry the data content and related FEC parity-based repair informa- tion for the bulk data/file or stream objects being transferred. Parity content is by default sent only on in response to receiver repair requests (NACKs) and thus normally imposes no additional protocol overhead. However, the transport of an object can be optionally configured to proactively transmit some amount of parity packets along with the original data content to potentially enhance performance (e.g., improved delay) at the cost of additional over- head with initial data transmission. This configuration may be sensible for certain network conditions and can allow for robust, asymmetric multicast (e.g., unidirectional routing, satellite, cable) [REF] with minimal receiver feedback, or, in some cases, none. A sender message of type NORM_INFO is also defined and is used to carry any optional "out-of-band" context information for a given transport object. Because of its simple, nature content of NORM_INFO messages can be NACKed and repaired with a slightly lower delay process than NORM's general FEC-encoded data content. NORM_INFO may serve special purposes for some buld transfer, Adamson, Borman, et al. Expires January 2002 [Page 6] Internet Draft NORM Protocol July 2001 reliable multicast applications where receivers join the group mid- stream and need to ascertain contextual information on the current content being transmitted. The NACK process for NORM_INFO will be described later. The sender also generates messages of type NORM_CMD to perform cer- tain protocol operations such as congestion control, end-of-trans- mission flushing, round trip time estimation, receiver synchroniza- tion, and optional positive acknowledgement requests or application defined commands. The transmission of NORM_CMD messages from the sender is accomplished by one of three different processes. These include single, best effort unreliable transmission of the command, repeated redundant transmission of the command, and positively acknowledged commands. The transmission technique used for a given command depends upon the function of the command. Several core commands are defined for basic protocol operation. Additionally, implementations may wish to consider providing the option of appli- cation-defined commands which can take advantage of these transmis- sion methodologies available for command. These transmission methodologies make use of information available to the protocol engine (e.g. round-trip timing, transmission rate, etc) to perform efficiently. An NORM receiver generates messages of type NORM_NACK or NORM_ACK in response to transmissions of data and commands from a sender. The NORM_NACK messages are generated to request repair of detected data transmission losses. Receivers generally detect losses by tracking the sequence of transmission from a sender. Sequencing information is embedded in the transmitted data packets and end-of- transmission commands from the sender. NORM_ACK messages are gen- erated in response to certain commands transmitted by the sender. In the general (and most scalable) protocol mode, receivers do not transmit any NORM_ACK messages. However, in order to meet poten- tial user requirements for positive data acknowledgement, and to collect more detailed information for potential multicast conges- tion control algorithms, NORM_ACK messages are defined and poten- tially used. NORM_ACK messages are also generated by a small sub- set of receivers when NORM dynamic end-to-end congestion control is in operation. NORM allows for reliable transfer of three different types of data content. These include the type NORM_OBJECT_DATA which are static, persistent blocks of data content maintained in the sender's appli- cation memory storage and the type NORM_OBJECT_FILE which corre- sponds to data stored in the sender's non-volatile file system. Both of these types represent "NormObjects" of finite size which are encapsulated for transmission and are temporarily yet uniquely identified with the given sender's NormNodeId and a temporarily Adamson, Borman, et al. Expires January 2002 [Page 7] Internet Draft NORM Protocol July 2001 unique NormObjectTransportId. The third type of All transmissions by individual senders and receivers are subject to rate control governed by a peak transmission rate set for each participant by the application. This can be used to limit the quantity of multicast data transmitted by the group. When NORM's congestion control algorithm is enabled the rate for senders is automatically adjusted. And even when congestion control is enabled, it may be desirable in some cases to establish minimum and maximum bounds for the rate adjustment depending upon the applica- tion. 2.3 Message Type and Header Definitions As mentioned previously, there are two primary classes of NORM mes- sages: messages generated by the sender of reliable multicast traf- fic and messages generated by receivers. 2.3.1 NORM Common Message Header There are some common message fields contained in all NORM message types. All NORM protocol messages begin with a common header with information fields as follows: NORM Common Packet Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | version | type | sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The "version" field is a (TBD)-bit value indicating the protocol version number. Currently, NORM implementations SHOULD ignore received messages with a different protocol version number. This number is intended to indicate and distinguish upgrades of the pro- tocol which may be non-interoperable. The message "type" field is a (TBD)-bit value indicating the NORM protocol message type. These types are defined as follows: Adamson, Borman, et al. Expires January 2002 [Page 8] Internet Draft NORM Protocol July 2001 Message Value NORM_INFO 1 NORM_DATA 2 NORM_CMD 3 NORM_NACK 4 NORM_ACK 5 NORM_REPORT 6 The "sequence" field is a 16-bit value which is set by the message originator as a monotonically increasing number incremented with each NORM message transmitted. This value can be monitored by receiving nodes to detect packet losses in the transmission. Note that this value is NOT used to detect missing reliable data con- tent, but is intended for use in an algorithm estimating raw packet loss for congestion control purposes. The size of this field is intended to be sufficient to allow detection of a reasonable range of packet loss within the expected delay-bandwidth product of expected network connections. The "source_id" field is a 32-bit value identifying the node which sent the message. A participant's NORM node identifier (NormNodeId) can be set according to the application needs but unique identifiers must be assigned within a single NormSession. In some cases, use of the host IP address or a hash of it can suf- fice, but alternative methodologies for assignment and potential collision resolution of node identifiers within a multicast session need to be considered. For example, the "source identifier" mecha- nism defined in the RTPv2 specification [REF RTP] may be applicable to use for NORM node identifiers. At this point in time, the pro- tocol makes no assumptions about how these unique identifiers are actually assigned. NORM Message Types Sender Messages: NORM_DATA This is expected to be the predominant message type transmitted by NORM senders. These messages will contain data content for objects of type NORM_OBJECT_DATA, NORM_OBJECT_FILE, and NORM_OBJECT_STREAM. A goal of the protocol design is to provide for parallel transmis- sion of different streams and data/file sets. NORM_DATA messages will generally consist of original data content of the application data being transmitted. The content size of these messages will a Adamson, Borman, et al. Expires January 2002 [Page 9] Internet Draft NORM Protocol July 2001 maximum of NormSegmentSize which is constant for the duration of a given sender's term of participation in the session. Senders advertise their NormSegmentSize in applicable messages which they transmit. This allows receivers to allocate appropriate buffering resources and to determine other information in order to properly process received data messaging. Note this message type will also be used to convey FEC parity repair content for NormObjects sent. NORM_DATA Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | grtt | segment_size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | object_transport_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | object_size_lsb | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | object_size_msb | reserved | fec_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fec_encoding_name | fec_num_parity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fec_block_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fec_symbol_id | fec_num_data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | offset_lsb* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | offset_msb* | payload_len* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | payload_data* | * Note the "offset" and "payload_len" fields for NORM_DATA messages containing parity information are actually values computed from FEC encoding of the "offset" and "payload_len" fields of the data seg- ments of the applicable coding block. Thus, for parity packets, these do _not_ represent these values directly. The "flags" field contains a number of different binary flags pro- viding information and hints regarding how the receiver should han- dle the identified object. Defined flags in this field include: Adamson, Borman, et al. Expires January 2002 [Page 10] Internet Draft NORM Protocol July 2001 +---------------------+-------+------------------------------------------+ | Flag | Value | Purpose | +---------------------+-------+------------------------------------------+ |NORM_FLAG_REPAIR | 0x01 | Indicates message is a repair transmis- | | | | sion | +---------------------+-------+------------------------------------------+ |NORM_FLAG_INFO | 0x02 | Indicates availability of NORM_INFO for | | | | object, | +---------------------+-------+------------------------------------------+ |NORM_FLAG_UNRELIABLE | 0x04 | Indicates that repair transmissions for | | | | the specified object will be unavail- | | | | able. (One-shot, best effort transmis- | | | | sion) | +---------------------+-------+------------------------------------------+ |NORM_FLAG_FILE | 0x08 | Indicates object is "file-based" data | | | | (hint to use disk storage for reception) | +---------------------+-------+------------------------------------------+ |NORM_FLAG_STREAM | 0x10 | Indicates object is of type | | | | NORM_OBJECT_STREAM. | +---------------------+-------+------------------------------------------+ The NORM_FLAG_REPAIR flag is set when the associated transmission is a repair transmission. This information can be used by receivers to facilitate a join policy where it is desired that newly joining receivers only begin participating in the NACK pro- cess upon receipt of new "fresh" data. The NORM_FLAG_INFO flag is se only when there optional NORM_INFO content is available for the associated object. Thus, receivers will NACK for retransmission of NORM_INFO only when it is available. The NORM_FLAG_UNRELIABLE flag is set when the sender wishes to transmit and object with "best effort" delivery only and will not supply repair transmissions for the object. The NORM_FLAG_FILE flag can be set as a "hint" from the sender that the associated object should be stored in non- volatile storage. The NORM_FLAG_STREAM flag is set when the iden- tified object is of type NORM_OBJECT_STREAM. Note that the "object_size" field is no longer applicable (Another use for this field for "stream" objects may be determined as this capability is designed). The "grtt" field contains a non-linear quantized representation of the sender's current estimate of group round-trip time (GRTT). This value is used to control timing of the NACK repair process and other aspects of protocol operation as described in this document. The "segment_size" field indicates the sender's current setting for maximum message payload content (in bytes). The "fec_type" field describes the error correction coding technique and parameters the sender is using to calculate parity repair segments. Knowledge of Adamson, Borman, et al. Expires January 2002 [Page 11] Internet Draft NORM Protocol July 2001 these fiels allows a NORM receiver to allocate appropriate buffer- ing and FEC decoding resources. The "object_transport_id" field is a monotonically and incremen- tally increasing value assigned by a sender to the object being transmitted. Transmissions and repair requests related to that object use the same "object_id" value. For sessions of very long or indefinite duration, the "object_id" field may be repeated, but it is presumed that the 32-bit field size provides an adequate enough sequence space to prevent temporary object confusion amongst receivers and sources (i.e. receivers SHOULD re-synchronize with a server when receiving object sequence identifiers sufficiently out- of-range with the current state kept for a given source). During the course of its transmission within a NORM session, an object is uniquely identified by the concatenation of the sender "node_id" and the given "object_transport_id". Note that NORM_INFO messages associated with the identified object carry the same "object_trans- port_id" value. The "object_size" fields indicate the total size of the object (in bytes). This information is used by receivers to determine storage requirements and/or allocate storage for the received object. Receivers with insufficient storage capability may wish to forego reception (i.e. not NACK for) of the indicated object. The "object_size" fields are not applicable for objects of type NORM_OBJECT_STREAM. (Note: The "object_size" fields _may_ be defined to serve an alternative use in this case). The "fec_id" field corresponds to the FEC Encoding Identifier described in the FEC Building Block document (currently "draft- ietf-rmt-bb-fec-03.txt"). The packet format illustrated above assumes "Small Block Systematic Codes" which correspond to an FEC Encoding Identifier equal to 129. The "fec_encoding_name" and "fec_num_parity" fields correspond to the "FEC Encoding Name" and "Number of redundant symbols" fields of the FEC Object Transmission Information format given by the FEC Building Block document. The "fec_encoding_name" shall be a value corresponding to the particular type of Small Block Systematic Code being used (e.g. Reed-Solomon GF(2^8), Reed-Solomon GF(2^16), etc). The standardized assignment these values are TBD. The "fec_num_parity" field corresponds to a parameter for generating specific FEC encoding/decoding algorithms for the named code. For example, Reed-Solomon codes may be arbitrarily shortened to create different code variations for a given block length. In this case, the "fec_num_parity" value indicates the maximum number of avail- able parity segments for the coding block from the sender. This Adamson, Borman, et al. Expires January 2002 [Page 12] Internet Draft NORM Protocol July 2001 field _may_ be interpreted differently for other systematic codes as they are defined. The "fec_block_id", "fec_symbol_id", "fec_num_data" fields directly correspond to the "encoding block number", "encoding symbol id", and "Source block length" fields of the FEC Payload ID format given by the FEC Building Block document. The "fec_block_id" identifies the coding block while the "fec_symbol_id" identifies which spe- cific symbol (segment) within the coding block the attached packet conveys. Given the "fec_num_data" (Source block length) informa- tion of how many symbols of application data is contained in the block, the receiver can determine whether the attached symbol is data or parity content and treat it appropriately. (For systematic codes, symbols numbered 0 through (fec_num_data-1) contain applica- tion data while symbols numbered (fec_num_data) through (fec_num_data+fec_numparity-1) contain the parity content calcu- lated for the block). The "offset" and "payload_len" fields are used to identify the position and quantity of the content of the packet payload. For senders employing systematic FEC encoding, these fields will corre- spond to the actual values for NORM_DATA messages which contain original data content. For NORM_DATA messages containing calcu- lated parity content, these fields will actually contain the values computed by FEC encoding of the "offset" and "length" values of the data segments of the corresponding FEC coding block. This allows the "offset" and "length" values of missing data content to be determined when decoding an FEC coding block. The "payload_data" field contains original data or computed parity content for the identified segment. The maximum length of this field corresponds to the sender's NormSegmentSize. The length of this field for messages containing parity content will always be of the length NormSegmentSize. When encoding a block of data segments of varying sizes, the FEC encoder SHALL assume zero value padding for data segments less than the NormSegmentSize. The receiver will use the "length" information to properly retrieve receive data con- tent and deliver it to the application. NORM_INFO The NORM_INFO message is used to convey _optional_ "out-of-band" context information for objects transmitted. An example may be MIME type information for the associated file, data, or stream object. Receivers might use this information to make a decision as whether to participate in reliable reception of the associated Adamson, Borman, et al. Expires January 2002 [Page 13] Internet Draft NORM Protocol July 2001 object. Each NormObject may have an independent unit of NORM_INFO associated with it. NORM_DATA messages contain a flag to indicate the availability of NORM_INFO for a given NormObject. NORM receivers may NACK for retransmission of NORM_INFO when they have not received it for a given NormObject. The size of the NORM_INFO content is limited to that of a single NormSegmentSize for the given sender. This atomic nature allows the NORM_INFO to be rapidly and efficiently repaired within the NORM transmission pro- cess. NORM_INFO Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | grtt | segment_size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | object_transport_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | object_size_lsb | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | object_size_msb | reserved | fec_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fec_encoding_name | fec_num_parity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | payload_data | The "flags", "grtt", "segment_size", "object_transport_id", "object_size", "fec_id", "fec_encoding_name", and "fec_num_parity" fields carry the same information and serve the same purpose as with NORM_DATA messages. The "payload_data" field contains the application-defined content which can be used by the receiver application for various purposes. NORM_CMD NORM_CMD messages are transmitted by senders to perform a number of different protocol functions. This includes round-trip timing col- lection, potential congestion control functions, synchronization of receiver NACKing "windows", notification of sender status and other core protocol functions. A core set of NORM_CMD messages will be enumerated. A range of command types will remain undefined for potential application-specific usage. Some NORM_CMD types (possi- bly including application-defined commands) may have some dynamic content attached. This content will be limited to a single Norm- SegmentSize to retain the atomic nature of commands. The NORM_CMD message begins with a common header, following the usual NORM Adamson, Borman, et al. Expires January 2002 [Page 14] Internet Draft NORM Protocol July 2001 message common header. The header format is defined as: NORM_CMD Common Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | grtt | flavor | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The "grtt" field provides the same information and serves the same purpose as with NORM_DATA and NORM_INFO messages. The "flavor" field indicates the type of command to follow. The command flavors (types) include: +------------------+--------------+----------------------------------+ | Command | Flavor Value | Purpose | +------------------+--------------+----------------------------------+ |NORM_CMD_FLUSH | 1 | Indicates sender temporary or | | | | permanent end-of-transmission. | | | | (Assists in robustly initiating | | | | outstanding repair requests from | | | | receivers). | +------------------+--------------+----------------------------------+ |NORM_CMD_SQUELCH | 2 | Advertisement of current repair | | | | window in response to out-of- | | | | range NACKs. | +------------------+--------------+----------------------------------+ |NORM_CMD_ACK_REQ | 3 | Requests positive acknowledge- | | | | ment of a watermark point from a | | | | specific list of receivers. | +------------------+--------------+----------------------------------+ |NORM_CMD_GRTT_REQ | 4 | Probe used in collection of | | | | sender's group GRTT estimate and | | | | possibly congestion control | | | | feedback. | +------------------+--------------+----------------------------------+ NORM_CMD(FLUSH) The NORM_CMD_FLUSH command is sent when the sender reaches the end of any data content and pending repairs it has queued for transmis- sion. This command is repeated once per 2*GRTT to excite the receiver set for any outstanding repair requests for data up to and including the point indicated by the FLUSH message. The number of repeats is equal to ROBUST_FACTOR. The greater this number, the higher the probability that all applicable receivers will be Adamson, Borman, et al. Expires January 2002 [Page 15] Internet Draft NORM Protocol July 2001 excited for repair requests (NACKs) _and_ the corresponding NACKs are delivered to the sender. If a NACK message interrupts the flush process, the sender will re-initiate the flush process when repair transmissions are completed. Note that receivers also employ a timeout mechanism to self-initiate NACKing when a sender is determined to have gone "idle". This inactivity timeout is related to 2*GRTT*ROBUST_FACTOR and will be discussed more later. With a sufficient ROBUST_FACTOR value, data content is delivered with a high assurance of reliability. The penalty of a large ROBUST_FACTOR value is potentially excess sender NORM_CMD_FLUSH transmissions and a longer timeout for receivers to self-initiate a terminal NACK process. The format of the NORM_CMD_FLUSH message (in addition to the NORM message common header) is: NORM_CMD(FLUSH) Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | grtt | flavor = 1 | fec_symbol_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fec_block_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | object_transport_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In addition to the common NORM_CMD "grtt" and "flavor" fields, the NORM_CMD(FLUSH) message contains fields to identify the current logical transmit position of the sender. These fields consist of "fec_symbol_id", "fec_block_id", and "object_transport_id". These fields are interpreted in the same manner as the fields of the same names in the NORM_DATA message type. Receivers are expected to check their completion state and initiate the NACK repair process if they have outstanding repair needs up to this transmission point. If the receivers have no outstanding repair needs, no response is generated. NORM_CMD(SQUELCH) The NORM_CMD_SQUELCH command is multicast to the receiver set in response to invalid NACKs received by the sender. The NORM_CMD_SQUELCH command is limited to be sent at once per 2*GRTT at the most. The NORM_CMD_SQUELCH advertises the "repair window" of the sender by identifying the earliest (lowest) transmission point for which it will provide repair, along with an encoded list of objects from that point forward which are still valid for repair. This mechanism allows the sender application to abort Adamson, Borman, et al. Expires January 2002 [Page 16] Internet Draft NORM Protocol July 2001 intermediate objects still in repair transmission. For example, an object pending transmission/repair may for some reason may have become obsolete. The receiver set learns from the NORM_CMD_SQUELCH the set of data for which it is valid to request repair. In normal conditions, it is expected the NORM_CMD_SQUELCH will be used infre- quently, and is generally anticipated to provide a reference for receivers who have fallen "out-of-sync" with the sender. The NORM_CMD_SQUELCH contains the identity of the earliest transmission point and includes a set of NormTransportIds which are valid. The starting point of the included set begins at the greatest (latest) of the sender's earliest transmission point or the lowest invalid NormTransportId in the invalid NACK(s) which prompted the genera- tion of the NORM_CMD_SQUELCH. The length of the list in the NORM_CMD_SQUELCH is limited by the sender's NormSegmentSize. This allows the receivers to learn the status of the sender's applicable object repair window with minimal transmission of NORM_CMD_SQUELCH commands. The format of the NORM_CMD_SQUELCH message (in addition to the NORM message common header) is: NORM_CMD(SQUELCH) Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | grtt | flavor = 2 | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fec_block_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | object_transport_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | invalid_object_list ... | In addition to the common NORM_CMD "grtt" and "flavor" fields, the NORM_CMD(SQUELCH) message contains fields to identify the earliest logical transmit position of the sender's current repair window and a "repair window description" beginning with the index of the logi- cally earliest invalid repair request from the offending NACK mes- sage which initiated the SQUELCH response. The "fec_block_id", and "object_transport_id" fields are concate- nated to indicate the beginning of the sender's current repair win- dow (i.e. the logically earliest point in its transmission history for which the sender can provide repair). This serves as an adver- tisement of a "synchronization point" for receivers to request repair. The "invalid_object_list" is a list of 32-bit object_transport_ids which, although they are within the sender's current repair window, Adamson, Borman, et al. Expires January 2002 [Page 17] Internet Draft NORM Protocol July 2001 are no longer available for repair from the sender. The total size of the "invalid_object_list" content is limited by the NormSegment- Size of the sender. Thus, it is possible that in some cases a sin- gle SQUELCH message may not be capable of completely listing the entire set. In these cases, the sender should ensure that the list begins with a "object_transport_id" (providing it is greater than the "synchronization point" from a NACK message for which the SQUELCH is being generated. This insures convergence of the SQUELCH process, even if multiple invalid NACK/ SQUELCH response iterations are required. This explicit description of invalid con- tent within the sender's current window, allows the sender applica- tion (most notably for discrete "object" based transport) to arbi- trarily invalidate (i.e. dequeue) portions of enqueued content (e.g. certain objects) for which it no longer wishes to provide reliable transport. (TBD) Provide example SQUELCH messages. NORM_CMD_ACK_REQ The NORM_CMD_ACK_REQ message is used by the sender to request acknowledgement from a specified list of receivers. This message serves in a lightweight positive acknowledgement mechanism which can be optionally employed by the reliable multicast application to deterministically determine that watermark points in the reliable transmission have been achieved by specific receivers. er's appli- cable object repair window with minimal transmission of NORM_CMD_SQUELCH commands. The format of the NORM_CMD_ACK_REQ mes- sage (in addition to the NORM message common header and the NORM_CMD common header) is: +-------------+---------------+----------------------------------+ | Field | Length (bits) | Purpose | +-------------+---------------+----------------------------------+ | object_id | 32 | NormObjectTransportId of water- | | | | mark NormObject for which the | | | | sender supports acknowledgement. | +-------------+---------------+----------------------------------+ | segment_id | (TBD) | Segment identifier of watermark | | | | point within the identified | | | | object. | +-------------+---------------+----------------------------------+ | data | -- | List of NormNodeIds to which the | | | | request applies. | +-------------+---------------+----------------------------------+ Adamson, Borman, et al. Expires January 2002 [Page 18] Internet Draft NORM Protocol July 2001 NORM_CMD(ACK_REQ) Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | grtt | flavor = 1 | fec_symbol_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fec_block_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | object_transport_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | acking_node_list ... | The "fec_symbol_id", "fec_block_id", and "object_transport_id" are used to identify the watermark point for which the positive acknowledgement request applies. This watermark point is similar to that used in MDP_CMD(FLUSH) message. It should be noted that all receivers are expected to treat the ACK_REQ command equiva- lently to a FLUSH command and appropriately initiate NACK repair cycles in response to any detected missing data up to the watermark point. The "acking_node_list" field contains the current list of receiver NormNodeIds which should reply with postive acknowledgement to this request. The NormNodeIds are listed in network (Big Endian) order. The indicated receivers SHALL send a NORM_ACK message in response to this request IF they have no outstanding repair needs up to and including the watermark point. Note this does _not_ necessarily mean the receivers actually received all of the data, but simply that, for whatever reason (including the fact they may have already received the data or if the receiving application simply chose _not_ to receive the indicated data), they have no outstanding repair needs prior to the watermark point. Verification of actual received data content must be accomplished by another means outside of this transport layer protocol. Receivers SHALL randomly spread their response to this request using a uniform distribution over 1 GRTT of time. Note the size of the included list is limited to the sender's NormSegmentSize setting. Thus, multiple NORM_CMD_ACK_REQ cycles may be required to achieve responses from all receivers specified. Also, the number of attempts to excite a response from a given receive SHALL be limited to ROBUST_FACTOR. The NORM_CMD_ACK_REQ is repeated at a rate of once per 2*GRTT. Note that the content of the attached NormNodeId list will be dynami- cally updated as this process progresses and ACKs are received from the specified receiver set. The process SHALL terminate when all desired receivers have responded or the maximum number of attempts has been achieved. Note that repair requests can interrupt the positive acknowledgement process and the positive acknowledgment Adamson, Borman, et al. Expires January 2002 [Page 19] Internet Draft NORM Protocol July 2001 process will resume only when there are no pending repair transmis- sions up to the specified watermark point. NORM_CMD_RTT_REQ The NORM_CMD_RTT_REQ is periodically transmitted by the sender to provide a reference point (a timestamp) so that receivers can cal- culate appropriate response content in NORM_NACK and NORM_NACK mes- sages from which the sender can monitor and estimate the current GRTT. Currently, this reference is sent separately from other sender message and not included in every message because of the excessive overhead it may impose on data transmission. Generally, the GRTT is not expected to be so dynamic as to require rapid update. However, a technique is being investigated by the author to provide a low overhead reference which could be attached to every sender transmission and used for the receiver response gener- ation [REF]. This command may also potentially be leveraged serve as part of NORM congestion control to periodically provide updated congestion control information and/or probing to the group. There is expected to be sufficient content in this message that it merits a separate message rather than be periodically included in the overhead of other sender transmissions. This command may also be extended to assume some responsibility in initializing and updating a group size estimator used to appropri- ately scale NACK suppression back-off timing, etc. For now, a min- imal format is defined as a placeholder for this message. The for- mat of the NORM_CMD_RTT_REQ message (in addition to the NORM mes- sage common header and the NORM_CMD common header) is: +----------+---------------+----------------------------------+ | Field | Length (bits) | Purpose | +----------+---------------+----------------------------------+ | req_seq | 8 | NORM_CMD_RTT_REQ sequence number | | | | T} send_time 64 T{ Timestamp | | | | referenced to sender clock for | | | | when the command was generated. | +----------+---------------+----------------------------------+ The "req_seq" field is an 8-bit, monotonically increasing sequence number which is incremented with each NORM_CMD_RTT_REQ command gen- erated by the sender. Responses to the NORM_CMD_RTT_REQ embedded in receiver NORM_NACK and NORM_ACK messages will identify the sequence number of the NORM_CMD_RTT_REQ which they have most recently received. The "send_time" field is a precision timestamp indicating the time Adamson, Borman, et al. Expires January 2002 [Page 20] Internet Draft NORM Protocol July 2001 that the NORM_CMD_GRTT_REQ message was transmitted. This consists of a 64-bit field containing 32-bits with the time in seconds and 32-bits with the time in microseconds since some reference time the source maintains (usually 00:00:00, 1 January 1970). The ordering of the fields in Big Endian network order. Other candidate fields for this message include: "flags" to mark different forms/purposes of the request. (e.g. a WILDCARD flag to prompt an explicit response from the entire group) "hold_time" field to provide a random back-off scaling factor when an entire group response is expected. Congestion control parameters such as "tx_rate", "rtt", "loss", etc for assisting a congestion control mechanism appropiate for NORM. Techniques are under investigation. Receiver Messages: NORM_NACK The principal purpose of NORM_NACK messages will be for receivers to request repair of content via negative acknowledgement upon detection of incomplete data. NORM_NACKs will be transmitted according to the rules of NACK generation and suppression of the NORM NACK process. A goal for the content of these messages is to use a format which can be potentially used by compatible intermedi- ate systems [REF Generic Router Assist Building Block] to provide assistance in promoting protocol scalability and efficiency when available. NORM_NACK messages generated will also contain addi- tional content to provide feedback to sender(s) for purposes of round-trip timing collection, congestion control, etc. NORM_NACK messages are transmitted by NORM receivers in response to the detection of missing data in the sequence of transmissions received from a particular source. The specific times and condi- tions under which receivers will generate and transmit these NORM_NACK messages are governed by the processes described in detail later in this document. The payload of NORM_NACK messages contains a list of "ObjectNACKs" for different objects and portions of a those objects. In addition to the common message header the NORM_NACK messages contain the following fields: Adamson, Borman, et al. Expires January 2002 [Page 21] Internet Draft NORM Protocol July 2001 NORM_NACK Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | server_id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | grtt_response_msb | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | grtt_response_lsb | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | loss_estimate |grtt_req_sequence| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data ... | The "server_id" field identifies the source to which the NORM_NACK message is destined. Other sources should ignore this message. (Note that this another reason why multiple potential sources within an NORM session MUST have unique NormNodeIds). The "grtt_response" field contains a timestamp indicating the time at which the NORM_NACK was transmitted. The format of this times- tamp is the same as the "send_time" field of the NORM_CMD_GRTT_REQ. However, note that the "grtt_response" timestamp is _relative_ to the "send_time" the source provided with the corresponding NORM_CMD_GRTT_REQ command. The receiver adjusts the source's NORM_CMD_GRTT_REQ "send_time" timestamp by the time differential from when the receiver received the NORM_CMD_GRTT_REQ to when the NORM_NACK was transmitted to calculate the value in the "grtt_response" field. The following formula applies: "grtt_response" = request "send_time" + request_to_response_differential If the "grtt_response" has ZERO value, that is an indication that the receiver has not yet received a NORM_CMD_GRTT_REQ command from the source and the source should ignore this portion of the response. The "loss_estimate" field is the receiver's current packet loss fraction estimate for the indicated source. The loss fraction is a value from 0.0 to 1.0 corresponding to a range of zero to 100 per- cent packet loss. The 16-bit "loss_estimate" value is calculated by the following formula: "loss_estimate" = decimal_loss_fraction * 65535.0 The "grtt_req_sequence" field contains the sequence number identi- fier of the received NORM_CMD_GRTT_REQ to which the response Adamson, Borman, et al. Expires January 2002 [Page 22] Internet Draft NORM Protocol July 2001 information in this NORM_NACK applies. The "data" field of the NORM_NACK message specifies the repair needs of this client pertaining to the indicated "server_id". These repair needs are in the format described by the "General Pur- pose NACK Content Encapsulation Format" in Section 3.2.3 of the NORM Building Block specification (currently "draft-ietf-rmt-bb- norm-02.txt". Note that the NACK content for multiple objects or ranges of stream data may be present in one NORM_NACK message and that each ObjectNACK consists of a hierarchical set of indicators and bit masks depending upon what data the receiver has detected is missing. (TBD) Example NACK messages. (See NORM Building Block document for now) NORM_ACK The basic operation of NORM transport will _not_ rely on the use NORM_ACK (positive acknowledgement) messages. However, some appli- cations may benefit from some limited form of positive acknowledge- ment for certain functions. A simple, scalable positive acknowl- edgement scheme is defined which can be leveraged by protocol implementations when appropriate. (TBD) Detailed description. General Messages: NORM_REPORT This is an optional message generated by NORM participants. This message may include periodic performance reports from receivers. Additionally, this message type may be potentially used by applica- tions to perform other session management functions such as period- ically advertising the full identity of a participant or the gen- eral context (more general than NORM_INFO messages which are asso- ciated with specific data content objects) of the content being transmitted to the group by a sender. 3.0 Detailed Protocol Operation (TBD) This section describes the detailed interactions of senders and receivers participating in a NORM session. Candidate subsec- tions: 3.1 Sender Initialization and Transmission Adamson, Borman, et al. Expires January 2002 [Page 23] Internet Draft NORM Protocol July 2001 (TBD) Describes how a sender becomes active within the group, transmits data content and how it may potentially go inactive or leave the group. 3.2 Receiver Initialization and Reception (TBD) Describes how a receiver joins the group, begins receiving data content and any requirements on dynamically leaving and poten- tially rejoining the group. 3.3 Receiver NACK Process (TBD) Describes receiver criteria by which/when it chooses to transmit NACK-based repair requests and the content of the these messages. 3.3.1 NACK initiation 3.3.2 NACK content 3.4 Sender NACK Processing and Repair Transmission (TBD) Describes how the sender accumulates NACK repair requests and transmits repair information in response to these requests. 3.5 Additional Protocol Mechanisms (TBD) Describes any other protocol mechanisms running periperally or embedded as part of other protocol messaging. 3.5.1 Round-trip time collection 3.5.2 Congestion control operation 3.5.3 Other (e.g. optional scalable, positive acknowledgements, asymmet- ric feedback, performance reporting, etc) 4.0 Security Considerations (TBD) 5.0 Suggested Use (TBD) Adamson, Borman, et al. Expires January 2002 [Page 24] Internet Draft NORM Protocol July 2001 6.0 References (TBD) 7.0 Authors' Addresses Brian Adamson adamson@itd.nrl.navy.mil Newlink Global Engineering Corporation 8580 Cinder Bed Road, Suite 1000 Newington, VA, USA, 22122 Carsten Bormann cabo@tellique.de Tellique Kommunikationstechnik GmbH Gustav-Meyer-Allee 25 Geb ude 12 D-13355 Berlin, Germany 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 January 2002 [Page 25] --============_-1216460390==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" -- Brian __________________________________ Brian Adamson --============_-1216460390==_============-- >From owner-rmt@listserv.lbl.gov Fri Jul 20 14:06:14 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6KL64101812; Fri, 20 Jul 2001 14:06:04 -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.11.2/8.11.2) with ESMTP id f6KL63R01808 for ; Fri, 20 Jul 2001 14:06:03 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6KL62E26983 for ; Fri, 20 Jul 2001 14:06:02 -0700 (PDT) Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f6KL61A26969 for ; Fri, 20 Jul 2001 14:06:01 -0700 (PDT) Received: (qmail 24637 invoked from network); 20 Jul 2001 21:05:56 -0000 Received: from mail.intranet (10.1.1.37) by mx.digitalfountain.com with SMTP; 20 Jul 2001 21:05:56 -0000 Received: from leningrad (leningrad.intranet [10.1.3.72]) by mail.intranet (8.9.3/8.9.3) with SMTP id OAA03976; Fri, 20 Jul 2001 14:05:30 -0700 X-Authentication-Warning: mail.intranet: Host leningrad.intranet [10.1.3.72] claimed to be leningrad From: "Mike Luby" To: Cc: "Jim Gemmell" , "Luigi Rizzo" , "Lorenzo Vicisano" , "Mark Handley" , "Jon Crowcroft" , "Roger Kermode" , , "Mike Luby" Subject: RE: Date: Fri, 20 Jul 2001 14:07:10 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000B_01C11125.44940CE0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C11125.44940CE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please replace the previous draft I sent earlier with this draft on the IETF Internet Drafts archive. (The only difference is that this one is formatted better and a bit more readable.) This is an update of an existing WG draft (RMT). Michael Luby Chief Technical Officer Digital Fountain, Inc. 39141 Civic Center Drive Suite 300 Fremont, CA 94538 www.digitalfountain.com luby@digitalfountain.com (510) 284-1420 (phone) (510) 284-1499 (fax) (510) 284-1400 (main) -----Original Message----- From: Mike Luby [mailto:luby@digitalfountain.com] Sent: Friday, July 20, 2001 12:17 PM To: internet-drafts@ietf.org Cc: Michael Luby; Jim Gemmell; Luigi Rizzo; Lorenzo Vicisano; Mark Handley; Jon Crowcroft; Roger Kermode; rmt@lbl.gov Subject: Please post this draft on the IETF Internet Drafts archive. This is an update of an existing WG draft (RMT). Michael Luby Chief Technical Officer Digital Fountain, Inc. 39141 Civic Center Drive Suite 300 Fremont, CA 94538 www.digitalfountain.com luby@digitalfountain.com (510) 284-1420 (phone) (510) 284-1499 (fax) (510) 284-1400 (main) ------=_NextPart_000_000B_01C11125.44940CE0 Content-Type: text/plain; name="draft-ietf-rmt-bb-alc-02.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-rmt-bb-alc-02.txt" Internet Engineering Task Force RMT WG=0A= INTERNET-DRAFT M.Luby/Digital Fountain=0A= draft-ietf-rmt-pi-alc-02.txt J.Gemmell/Microsoft=0A= L.Vicisano/Cisco=0A= L.Rizzo/ACIRI and Univ. Pisa=0A= J. Crowcroft/UCL=0A= 20 July 2001=0A= Expires: January 2002=0A= =0A= =0A= Asynchronous Layered Coding:=0A= A massively scalable reliably content delivery protocol=0A= =0A= =0A= =0A= Status of this Document=0A= =0A= This document is an Internet-Draft and is in full conformance with all=0A= provisions of Section 10 of RFC2026.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering Task=0A= Force (IETF), its areas, and its working groups. Note that other groups=0A= may also distribute working documents as Internet-Drafts.=0A= =0A= Internet-Drafts are valid for a maximum of six months and MAY be=0A= updated, replaced, or obsoleted by other documents at any time. It is=0A= inappropriate to use Internet-Drafts as reference material or to cite=0A= them other than as a "work in progress".=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt=0A= =0A= To view the list Internet-Draft Shadow Directories, see=0A= http://www.ietf.org/shadow.html.=0A= =0A= This document is a product of the IETF RMT WG. Comments should be=0A= addressed to the authors, or the WG's mailing list at rmt@lbl.gov.=0A= =0A= =0A= Abstract=0A= =0A= =0A= This document describes the Asynchronous Layered Coding=0A= protocol, a massively scalable reliable content delivery=0A= protocol, hereafter referred to as ALC. ALC can be used for=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft [Page 1]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= multi-rate reliable delivery of content to large sets of=0A= receivers. ALC uses the LCT transport described in [3]=0A= augmented with a congestion control protocol that is compliant=0A= with RFC2387 such as one of the layered congestion control=0A= protocols described [4]. ALC achieves reliability based on FEC=0A= codecs as generally described in [1], and in particular based=0A= on the details provided in the FEC building block described in=0A= [2].=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft [Page 2]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= Table of Contents=0A= =0A= =0A= 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4=0A= 1.1. Related Documents. . . . . . . . . . . . . . . . . . 5=0A= 1.2. Environmental Requirements and Considerations. . . . 5=0A= 2. General Architecture. . . . . . . . . . . . . . . . . . 6=0A= 2.1. Delivery service models. . . . . . . . . . . . . . . 6=0A= 2.2. Congestion Control . . . . . . . . . . . . . . . . . 7=0A= 3. Type of packets used by the ALC protocol. . . . . . . . 7=0A= 3.1. Packet format for the ALC protocol . . . . . . . . . 8=0A= 3.2. Packet header fields for the ALC protocol. . . . . . 8=0A= 4. Procedures. . . . . . . . . . . . . . . . . . . . . . . 9=0A= 4.1. Sender Operation . . . . . . . . . . . . . . . . . . 9=0A= 4.2. Receiver Operation . . . . . . . . . . . . . . . . . 10=0A= 5. Security Considerations . . . . . . . . . . . . . . . . 10=0A= 6. IANA Considerations . . . . . . . . . . . . . . . . . . 10=0A= 7. Intellectual Property Issues. . . . . . . . . . . . . . 10=0A= 8. Authors' Addresses. . . . . . . . . . . . . . . . . . . 11=0A= 9. Full Copyright Statement. . . . . . . . . . . . . . . . 13=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft [Page 3]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= 1. Introduction=0A= =0A= This document describes a massively scalable reliable content delivery=0A= protocol, Asynchronous Layered Coding (ALC), for multi-rate reliable=0A= content delivery. ALC is a protocol instantiation as defined in=0A= RFC3048. ALC uses the LCT transport [3]. Thus, like the LCT transport,=0A= the ALC protocol is primarily designed to be used with the IP multicast=0A= network service, but MAY also be used with other basic underlying=0A= network or transport services such as unicast UDP. ALC uses FEC codes=0A= to provide reliability as generally described in [1], i.e. all packets=0A= in a session contain FEC coded information in formats that are compliant=0A= with the FEC building block described in [2]. A crucial point is that=0A= ALC strongly relies on FEC codecs in the sense that there is no request=0A= for retransmission of individual packets from receivers that miss=0A= packets in order to assure reliable reception of an object, and the=0A= packets and their rate of transmission out of the sender can be=0A= independent of the number and the individual reception experiences of=0A= the receivers. In some delivery service models it is appropriate that=0A= receivers send out of band messages to the sender to provide guaranteed=0A= delivery of content. For example, in a push reliable delivery model=0A= receivers may send messages to a sender to continue the session if=0A= receivers have not yet received enough packets to recover the content or=0A= to terminate the session when receivers have received enough packets to=0A= recover the content. To be able to track usage of the system, receivers=0A= may also send messages out of band to the sender that contain statistics=0A= on their reception experience. ALC, however, does not require nor=0A= specify such messages, with the aim of avoiding unnecessary limitation=0A= to the scalability of the basic ALC protocol.=0A= =0A= The LCT transport provides support for congestion control, and the ALC=0A= protocol uses this support. The congestion control protocol must=0A= conform with RFC 2357. It is recommended that the congestion control=0A= protocol used for ALC be a multi-rate protocol, as described in [4]. In=0A= this case, a sender sends packets in the session to several LCT channels=0A= at potentially different rates. Then, individual receivers can adjust=0A= their reception rate within a session by adjusting which set of LCT=0A= channels they are joined to at each point in time depending on the=0A= available bandwidth between the receiver and the sender, but independent=0A= of other receivers. A single rate congestion control protocol can also=0A= be used, but this may limit the scalability of the session in terms of=0A= the number of receivers that can concurrently participate.=0A= =0A= Receiver may join and leave a session asynchronously at their=0A= discretion.=0A= =0A= An ALC packet thus consists of an LCT packet header, an FEC packet=0A= header, optional by additional parameters and packet payload.=0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 1. [Page 4]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= ALC has the following properties when the LCT transport uses multicast=0A= to deliver packets:=0A= =0A= =0A= o To each receiver, it appears as if though there is a dedicated session=0A= from the sender to the receiver, where the reception rate adjusts to=0A= congestion along the path from sender to receiver.=0A= =0A= o To the sender, there is no difference in load or outgoing rate if one=0A= receiver is joined to the session or a million (or any number of)=0A= receivers are joined to the session, independent of when the receivers=0A= join and leave.=0A= =0A= o On each link in the network, the packet traffic from the session and=0A= its reaction to competing traffic is the same whether there is one=0A= receiver or a million receivers beyond the link.=0A= =0A= Thus, ALC provides a massively scalable content delivery system that=0A= is network friendly.=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in RFC2119.=0A= =0A= =0A= 1.1. Related Documents=0A= =0A= The LCT transport that ALC MUST use is described in [3]. A more in-=0A= depth description of the use of FEC codecs in reliable content delivery=0A= protocols is given in [1]. All packets in a session MUST contain FEC=0A= coded information in formats that are compliant with the FEC building=0A= block described in [2]. Implementors of ALC MUST also implement a=0A= congestion control protocol in accordance to RFC2357, where the=0A= congestion control is over the entire session. Some possible schemes=0A= are specified in [4]. Congestion control MUST be integrated into ALC=0A= through the support provided in the LCT transport.=0A= =0A= It is RECOMMENDED that ALC implementors use some authentication scheme=0A= to protect the protocol from attacks. An example of a possibly suitable=0A= scheme is described in [5]. Authentication in ALC, if used, is to be=0A= integrated through the support provided in the LCT transport.=0A= =0A= =0A= 1.2. Environmental Requirements and Considerations=0A= =0A= ALC is intended for congestion controlled, multi-rate delivery of=0A= objects, i.e., reliable content delivery.=0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 1.2. [Page 5]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= All of the environmental requirements and considerations that apply to=0A= the LCT transport and to the FEC building block also apply to ALC.=0A= =0A= =0A= 2. General Architecture=0A= =0A= ALC protocol consists basically of using FEC codecs in the form=0A= described in [2] with the LCT transport as described in [3]. Thus, the=0A= terminology used in the description of the LCT transport and the FEC=0A= building block are inherited by the ALC protocol and this terminology is=0A= used below. In particular, the definition of a session for the ALC=0A= protocol is the same as it is for the LCT transport.=0A= =0A= Packets used within the ALC protocol are specialized versions of LCT=0A= packets. In particular, a packet consists of an LCT packet header, an=0A= FEC payload ID, optional additional parameters as appropriate, and the=0A= packet payload. From the point of view of the LCT transport, the FEC=0A= payload ID, the additional parameters if present, and the packet payload=0A= are all part of the LCT packet payload.=0A= =0A= The out of band information used by the ALC protocol consists of the out=0A= of band all information required for both the LCT transport and for the=0A= FEC building block. The possible means for acquiring this out of band=0A= information is the same as for the LCT transport and the FEC building=0A= block, and in particular is outside the scope of the ALC protocol.=0A= =0A= Congestion control for the ALC protocol MUST conform to RFC 2387, and=0A= MUST be provided through the mechanisms provided by the LCT transport.=0A= Although it is not mandatory, ALC is most scalable when multi-rate=0A= congestion control is used that does not require feedback from receivers=0A= to the sender, and thus use of a mult-rate congestion control as=0A= described in [4] is RECOMMENDED.=0A= =0A= =0A= 2.1. Delivery service models=0A= =0A= ALC can support several different delivery service models. Two examples=0A= are briefly described here.=0A= =0A= =0A= Push service model.=0A= =0A= One way a push service model can be used for reliable content delivery=0A= is to deliver a series of objects. For example, a receiver could join=0A= the session and dynamically adapt the number of LCT channels the=0A= receiver is joined to until enough packets have been received to=0A= reconstruct an object. After reconstructing the object the receiver may=0A= stay in the session and wait for the transmission of the next object.=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 2.1. [Page 6]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= The push model is particularly attractive in satellite networks and=0A= wireless networks. In these cases, a session may consist of one fixed=0A= rate LCT channel.=0A= =0A= =0A= On-demand content delivery model.=0A= =0A= For an on-demand content delivery service model, senders typically=0A= transmit for some given time period selected to be long enough to allow=0A= all the intended receivers to join the session and recover a single=0A= object. For example a popular software update might be transmitted=0A= using ALC for several days, even though a receiver may be able to=0A= complete the download in one hour total of connection time, perhaps=0A= spread over several intervals of time.=0A= =0A= In this case the receivers join the session at any point in time when it=0A= is active and dynamically adapt the number of LCT channels they=0A= subscribe to according to the available bandwidth using a multi-rate=0A= congestion control protocol. Receivers leave the session when they have=0A= received enough packets to recover the object.=0A= =0A= =0A= Other service models.=0A= =0A= =0A= There may be other delivery service models that can be supported by ALC.=0A= The description of the potential applications, the appropriate delivery=0A= service model, and the additional mechanisms to support such=0A= functionalities when combined with ALC is beyond the scope of this=0A= document.=0A= =0A= =0A= 2.2. Congestion Control=0A= =0A= The specific congestion control protocol to be used for ALC sessions=0A= should be suitable for reliable content delivery. While the general=0A= behavior of the congestion control protocol is to reduce the throughput=0A= in presence of congestion and gradually increase it in the absence of=0A= congestion, the actual dynamic behavior (e.g. response to single losses)=0A= can vary.=0A= =0A= Some possible multi-rate congestion control protocols for reliable=0A= content delivery using LCT are described in [4].=0A= =0A= 3. Type of packets used by the ALC protocol=0A= =0A= The type of packet used by the ALC protocol is a specialized version of=0A= an LCT packet. LCT packets are sent by senders to LCT channels.=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 3. [Page 7]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= Some instances of sessions MAY require the generation of feedback from=0A= the receivers to the sender. However, the mechanism for doing this is=0A= outside the scope of ALC.=0A= =0A= =0A= 3.1. Packet format for the ALC protocol=0A= =0A= The packet format used for ALC protocol is depicted in Figure 1.=0A= =0A= =0A= 0 1 2 3=0A= 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | LCT packet header |=0A= | |=0A= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=0A= | FEC Payload ID |=0A= | |=0A= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=0A= | Additional parameters |=0A= | (optional) |=0A= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=0A= | Payload |=0A= | |=0A= | |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= =0A= =0A= Figure 1 - Packet format for ALC protocol=0A= =0A= =0A= 3.2. Packet header fields for the ALC protocol=0A= =0A= The description of the fields and their functions within the LCT packet=0A= header can be found in [3]. The information that needs to be=0A= communicated out of band for the LCT transport and the possible=0A= mechanisms for achieving this are described in [3].=0A= =0A= The description of the fields and their functions within the FEC payload=0A= ID can be found in [2], with the exception that the FEC Encoding Flag=0A= value, if applicable, MAY be communicated via the value of the Codepoint=0A= field within LCT packet header. The information that needs to be=0A= communicated out of band for the FEC codecs and the possible mechanisms=0A= for achieving this are described in [2]. The mechanisms for=0A= communicating the out of band information needed for the LCT transport,=0A= including the mapping between the Codepoint field values in the LCT=0A= packet header and the interpretations of the values, MAY be the same as=0A= those used for communicating the out of band information needed for the=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 3.2. [Page 8]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= FEC building block, with the exception that portions of the information=0A= needed for FEC building blocks may be communicated either through the=0A= use of the Codepoint field in the LCT packet header, or through the=0A= Additional Parameters fields that follow the FEC payload ID.=0A= =0A= The fields and formats of the optional Additional Parameters fields MUST=0A= be communicated to the receivers out of band. The particular Additional=0A= Parameters fields that may appear in packets MUST be communicated out of=0A= band. The specification of which Additional Parameters fields that=0A= appear in a packet MUST be communicated via the value of the Codepoint=0A= field in the LCT packet header, and the mapping between Codepoint field=0A= values and the Additional Parameters fields that appear in a packet MUST=0A= be communicated out of band. It is RECOMMENDED that the format of any=0A= Additonal Parameters fields adhere to the format of Header-Extension=0A= Fields defined for the LCT transport in [3].=0A= =0A= 4. Procedures=0A= =0A= =0A= 4.1. Sender Operation=0A= =0A= The sender operation when using the ALC protocol includes all the points=0A= made about the sender operation when using the LCT transport as=0A= described in [3], and the FEC building block as described in [2]. The=0A= following description highlights some of the additional considerations=0A= to be taken into account with respect to the ALC protocol.=0A= =0A= Before a session starts, a sender using the ALC protocol MUST make=0A= available all applicable information regarding the session. This=0A= information includes:=0A= =0A= o Any information needed by the LCT transport;=0A= =0A= o The congestion control protocol being used within the LCT transport;=0A= =0A= o The mapping between values of the Codepoint field in the LCT packet=0A= header and interpretations of these values;=0A= =0A= o Any information needed for the FEC building block;=0A= =0A= o If used, the authentication scheme being used within the LCT=0A= transport, and all relevant information which is necessary for=0A= sender authentication purposes;=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 4.1. [Page 9]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= 4.2. Receiver Operation=0A= =0A= The receiver operation when using the ALC protocol includes all the=0A= points made about the receiver operation that pertain to reliable=0A= content delivery when using the LCT transport as described in [3], and=0A= that pertain to using the FEC building block as described in [2]. The=0A= following description highlights some of the additional considerations=0A= to be taken into account with respect to the ALC protocol.=0A= =0A= When a receiver receives a packet, the receiver MUST process the LCT=0A= packet header (excluding the Codepoint field) as described in [3]=0A= before processing any other fields of the packet.=0A= =0A= =0A= 5. Security Considerations=0A= =0A= The same security consideration that apply to the LCT transport and to=0A= the FEC building block also apply to the ALC protocol. In addition, any=0A= security considerations that apply to the congestion control protocol=0A= used by the ALC protocol within the LCT transport also apply.=0A= =0A= =0A= 6. IANA Considerations=0A= =0A= No information in this specification is directly subject to IANA=0A= registration. However, building blocks components used by the ALC=0A= protcol may introduce additional IANA considerations. In particular,=0A= the FEC building block used by the ALC protocol does require IANA=0A= registration of the FEC codecs used.=0A= =0A= =0A= 7. Intellectual Property Issues=0A= =0A= =0A= No specific reliability protocol or congestion control protocol is=0A= specified or referenced as mandatory in this document.=0A= =0A= ALC MAY be used with congestion control protocols and other protocols=0A= which are proprietary, or have pending or granted patents.=0A= =0A= =0A= =0A= [1] Luby, M., Gemmell, Vicisano, L., J., Rizzo, L., Handley, M.,=0A= Crowcroft, J., "The use of Forward Error Correction in Reliable=0A= Multicast", Internet Draft draft-ietf-rmt-info-fec-00.txt, November=0A= 2000, a work in progress.=0A= =0A= [2] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M.,=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 7. [Page 10]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= Crowcroft, J., "RMT BB Forward Error Correction Codes", Internet Draft=0A= draft-ietf-rmt-bb-fec-03.txt, July 2001.=0A= =0A= [3] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M.,=0A= Crowcroft, J., "Layered Coding Transport: A massively scalable content=0A= delivery transport", Internet Draft draft-ietf-rmt-bb-lct-01.txt, July=0A= 2001.=0A= =0A= [4] Luby, M., Vicisano, L., Haken, A., "RMT BB Layered congestion=0A= control", draft-ietf-rmt-bb-lcc-00.txt, November 2000, a work in=0A= progress.=0A= =0A= [5] Perrig, A., Canetti, R., Briscoe, B., Tygar, D., Song, D., "TESLA:=0A= Multicast Source Authentication Transform", draft-irtf-smug-=0A= tesla-00.txt, November, 2000, a work in progress.=0A= =0A= =0A= =0A= 8. Authors' Addresses=0A= =0A= Michael Luby=0A= luby@digitalfountain.com=0A= Digital Fountain=0A= 39141 Civic Center Drive=0A= Suite 300=0A= Fremont, CA, USA, 94538=0A= =0A= Jim Gemmell=0A= jgemmell@microsoft.com=0A= Microsoft Research=0A= 301 Howard St., #830=0A= San Francisco, CA, USA, 94105=0A= =0A= Lorenzo Vicisano=0A= lorenzo@cisco.com=0A= cisco Systems, Inc.=0A= 170 West Tasman Dr.,=0A= San Jose, CA, USA, 95134=0A= =0A= Luigi Rizzo=0A= luigi@iet.unipi.it=0A= Dip. Ing. dell'Informazione,=0A= Univ. di Pisa=0A= via Diotisalvi 2, 56126 Pisa, Italy=0A= =0A= Jon Crowcroft=0A= J.Crowcroft@cs.ucl.ac.uk=0A= Department of Computer Science=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 8. [Page 11]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= University College London=0A= Gower Street,=0A= London WC1E 6BT, UK=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 8. [Page 12]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= 9. Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2000). All Rights Reserved.=0A= =0A= This document and translations of it may be copied and furnished to=0A= others, and derivative works that comment on or otherwise explain it or=0A= assist in its implementation may be prepared, copied, published and=0A= distributed, in whole or in part, without restriction of any kind,=0A= provided that the above copyright notice and this paragraph are included=0A= on all such copies and derivative works. However, this document itself=0A= may not be modified in any way, such as by removing the copyright notice=0A= or references to the Internet Society or other Internet organizations,=0A= except as needed for the purpose of developing Internet standards in=0A= which case the procedures for copyrights defined in the Internet=0A= languages other than English.=0A= =0A= The limited permissions granted above are perpetual and will not be=0A= revoked by the Internet Society or its successors or assigns.=0A= =0A= This document and the information contained herein is provided on an "AS=0A= IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK=0A= FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT=0A= LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT=0A= INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR=0A= FITNESS FOR A PARTICULAR PURPOSE."=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 9. [Page 13]=0A= =0C=0A= INTERNET-DRAFT Expires: January 2002 July 2001=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 9. [Page 14]=0A= ------=_NextPart_000_000B_01C11125.44940CE0-- >From owner-rmt@listserv.lbl.gov Sun Jul 22 03:02:03 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6MA09829262; Sun, 22 Jul 2001 03:00: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.11.2/8.11.2) with ESMTP id f6MA08R29258 for ; Sun, 22 Jul 2001 03:00:08 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6MA08S10373 for ; Sun, 22 Jul 2001 03:00:08 -0700 (PDT) Received: from mail.greatbasin.net (mail.greatbasin.net [207.228.35.39]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6MA07A10368 for ; Sun, 22 Jul 2001 03:00:07 -0700 (PDT) Received: from rogue (sugarpinellc.com [216.82.147.171]) by mail.greatbasin.net (8.9.3-MySQL-0.2.3b/8.9.3) with SMTP id DAA13984 for ; Sun, 22 Jul 2001 03:00:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Sugarpine.Sierra.West@greatbasin.net, LLC To: rmt@lbl.gov Subject: Press Release Message-ID: <200172210791rmt@lbl.gov> Date: Sun, 22 Jul 2001 02:59:51 -0600 Sender: owner-rmt@lbl.gov Precedence: bulk For Immediate Release Incline Village, Nevada Contact Corporate Communications www.sugarpinellc.com Sugarpine Sierra West, LLC is proud to announce 4 additional services, Sports Memorabilia, Hair Raisers, Financial Services and Worlds-Best-4 the worlds largest virtual shopping mall featuring over 2.2 million products! Save time! Save money! Make money!!! These services and products are now available to everyone. To view these tremendous opportunities, please visit our website. Sports Memorabilia may be viewed simply by clicking on its front-page banner. Hair Raisers may be viewed by visiting our web site, www.sugarpinellc.com, and select our associates^Ò link. Our Financial Services is linked and bannered on our home page. As you all may already know, Sugarpine Sierra West, LLC is at its heart an asset hosting company. Please don^Òt forget to look at our Asset Gallery to see some outstanding business and investment opportunities, as well as collectables and real estate. Sugarpine Sierra West, LLC would like to extend its sincere thanks and appreciation to all! Please visit us at our web site at: www.sugarpinellc.com. Corporate Communications: Sugarpine Sierra West, LLC Mr. Charles J. Armstrong II or Ms. Denise Pavlo Phone: 775-832-2552 E-Mail: info@sugarpinellc.com To be removed from our e-mail list, reply to this e-mail with "REMOVE" in the subject line of your reply. >From owner-rmt@listserv.lbl.gov Mon Jul 23 09:40:26 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6NGUoE13202; Mon, 23 Jul 2001 09:30: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.11.2/8.11.2) with ESMTP id f6NGUnR13198 for ; Mon, 23 Jul 2001 09:30:49 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6NGUmg02105 for ; Mon, 23 Jul 2001 09:30:48 -0700 (PDT) Received: from cs.utexas.edu (root@cs.utexas.edu [128.83.139.9]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6NGUlA02092 for ; Mon, 23 Jul 2001 09:30:47 -0700 (PDT) Received: from toulon.cs.utexas.edu (zxc@toulon.cs.utexas.edu [128.83.120.39]) by cs.utexas.edu (8.11.2/8.11.2) with ESMTP id f6NGUkQ20073; Mon, 23 Jul 2001 11:30:46 -0500 (CDT) Received: (from zxc@localhost) by toulon.cs.utexas.edu (8.11.2/8.11.2) id f6NGUjK00797; Mon, 23 Jul 2001 11:30:45 -0500 (CDT) Date: Mon, 23 Jul 2001 11:30:45 -0500 (CDT) From: Xincheng Zhang To: , LLC cc: Subject: REMOVE In-Reply-To: <200172210791rmt@lbl.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by SpamWall.lbl.gov id f6NGUnR13199 Sender: owner-rmt@lbl.gov Precedence: bulk xincheng On Sun, 22 Jul 2001 Sugarpine.Sierra.West@greatbasin.net wrote: > For Immediate Release > Incline Village, Nevada > Contact Corporate Communications > www.sugarpinellc.com > > Sugarpine Sierra West, LLC is proud to announce 4 additional services, Sports Memorabilia, Hair Raisers, Financial Services and Worlds-Best-4 the worlds largest virtual shopping mall featuring over 2.2 million products! Save time! Save money! Make money!!! > > These services and products are now available to everyone. To view these tremendous opportunities, please visit our website. Sports Memorabilia may be viewed simply by clicking on its front-page banner. Hair Raisers may be viewed by visiting our web site, www.sugarpinellc.com, and select our associates^Ò link. Our Financial Services is linked and bannered on our home page. > > As you all may already know, Sugarpine Sierra West, LLC is at its heart an asset hosting company. Please don^Òt forget to look at our Asset Gallery to see some outstanding business and investment opportunities, as well as collectables and real estate. > > Sugarpine Sierra West, LLC would like to extend its sincere thanks and appreciation to all! > > Please visit us at our web site at: www.sugarpinellc.com. > > Corporate Communications: > Sugarpine Sierra West, LLC > Mr. Charles J. Armstrong II or Ms. Denise Pavlo > Phone: 775-832-2552 > E-Mail: info@sugarpinellc.com > > To be removed from our e-mail list, reply to this e-mail with "REMOVE" in the subject line of your reply. > > > >From owner-rmt@listserv.lbl.gov Tue Jul 24 03:35:16 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6OAYSE17681; Tue, 24 Jul 2001 03:34:28 -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.11.2/8.11.2) with ESMTP id f6OAYRw17677 for ; Tue, 24 Jul 2001 03:34:27 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6OAYQc13841 for ; Tue, 24 Jul 2001 03:34:26 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6OAYPA13837 for ; Tue, 24 Jul 2001 03:34:25 -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 GAA06648; Tue, 24 Jul 2001 06:33:26 -0400 (EDT) Message-Id: <200107241033.GAA06648@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-lct-01.txt,.ps Date: Tue, 24 Jul 2001 06:33:26 -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 : Layered Coding Transport: A massively scalable content delivery transport Author(s) : L. Vicisano et al. Filename : draft-ietf-rmt-bb-lct-01.txt,.ps Pages : 27 Date : 23-Jul-01 This document describes Layered Coding Transport, a massively scalable reliable content delivery and stream delivery transport, hereafter referred to as LCT. LCT can be used for multi-rate delivery to large sets of receivers. In LCT, scalability and congestion control are supported through the use of layered coding techniques. Coding techniques can be combined with LCT to provide support for reliability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-lct-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-bb-lct-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-bb-lct-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: <20010723141119.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-lct-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-lct-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723141119.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Tue Jul 24 03:35:16 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6OAYWV17687; Tue, 24 Jul 2001 03:34:32 -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.11.2/8.11.2) with ESMTP id f6OAYVw17683 for ; Tue, 24 Jul 2001 03:34:31 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6OAYUG13848 for ; Tue, 24 Jul 2001 03:34:30 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6OAYTA13845 for ; Tue, 24 Jul 2001 03:34:29 -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 GAA06660; Tue, 24 Jul 2001 06:33:31 -0400 (EDT) Message-Id: <200107241033.GAA06660@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-03.txt,.ps Date: Tue, 24 Jul 2001 06:33:30 -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 : RMT BB Forward Error Correction Codes Author(s) : L. Vicisano et al. Filename : draft-ietf-rmt-bb-fec-03.txt,.ps Pages : 11 Date : 23-Jul-01 This memo describes the abstract packet formats and IANA registration procedures for use of Forward Error Correction (FEC) codes within the context of reliable IP multicast transport. This memo should be read in conjunction with and uses the terminology of the companion memo [1], which 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-03.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-03.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-03.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: <20010723141128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-fec-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-fec-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723141128.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Tue Jul 24 03:35:19 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6OAYNA17675; Tue, 24 Jul 2001 03:34:23 -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.11.2/8.11.2) with ESMTP id f6OAYMw17671 for ; Tue, 24 Jul 2001 03:34:22 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6OAYLG13833 for ; Tue, 24 Jul 2001 03:34:21 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6OAYKA13829 for ; Tue, 24 Jul 2001 03:34:20 -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 GAA06631; Tue, 24 Jul 2001 06:33:21 -0400 (EDT) Message-Id: <200107241033.GAA06631@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-02.txt Date: Tue, 24 Jul 2001 06:33:21 -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 : Asynchronous Layered Coding A scalable reliable multicast protocol Author(s) : L. Vicisano et al. Filename : draft-ietf-rmt-pi-alc-02.txt Pages : 14 Date : 23-Jul-01 This document describes the Asynchronous Layered Coding protocol, a massively scalable reliable content delivery protocol, hereafter referred to as ALC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-alc-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-pi-alc-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-pi-alc-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: <20010723141110.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-pi-alc-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-pi-alc-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723141110.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Tue Jul 24 12:39:03 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6OJc3G11527; Tue, 24 Jul 2001 12: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.11.2/8.11.2) with ESMTP id f6OJc1w11523 for ; Tue, 24 Jul 2001 12:38:01 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6OJbuG15573 for ; Tue, 24 Jul 2001 12:37:56 -0700 (PDT) Received: from acm.cs.umn.edu (acm.cs.umn.edu [128.101.32.12]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6OJbuA15570 for ; Tue, 24 Jul 2001 12:37:56 -0700 (PDT) Received: from sorry.cs.umn.edu (sorry.cs.umn.edu [128.101.32.10]) by acm.cs.umn.edu (8.11.3/8.11.3) with ESMTP id f6OJbok69365; Tue, 24 Jul 2001 14:37:50 -0500 (CDT) (envelope-from orasis@acm.cs.umn.edu) Received: (from orasis@localhost) by sorry.cs.umn.edu (8.11.2/8.11.0) id f6OJbnq10521; Tue, 24 Jul 2001 14:37:49 -0500 (CDT) (envelope-from orasis) Date: Tue, 24 Jul 2001 14:37:49 -0500 From: Justin Chapweske To: rm@mash.berkeley.edu Cc: rmt@lbl.gov, justin@opencola.com, swarmcast-devel@lists.sourceforge.net Subject: Java FEC Library 1.0 Released Message-ID: <20010724143749.K7774@sorry.cs.umn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-rmt@lbl.gov Precedence: bulk The 1.0 (bourbon-12) release of the Swarmcast FEC Library is available at http://www.sourceforge.net/projects/swarmcast/ This software is based on Luigi Rizzo's wonderful C FEC library but has been significantly expanded to include multi-threaded IO routines for encoding and decoding files. Just as with Luigi's library, this is released under a BSD-style license. I would highly recommend that anyone implementing a reliable multicast solution in Java look at these libraries. We have been actively developing them for over a year and believe you will find them to be quite useful. The features for this release include: o Very efficient multi-threaded FEC I/O routines for easily encoding and decoding files. o Pure Java, native linux, and native win32 implementations of the Vandermonde FEC codes. o Platform specific libraries are automatically detected and deployed and pure java codes are used for fallback in case platform specific libraries cannot be found. o An FEC codec plugin interface. o Cryptographic hashes can be used to verify the integrity of the file being decoded. If a block is found to be corrupt then the software can attempt to repair it. Thanks Luigi for the C code, Lorenzo for the JNI beginnings, and Jim Gemmel for his papers on FEC IO. -- Justin Chapweske, Lead Swarmcast Developer, OpenCola Inc. http://www.swarmcast.com/ >From owner-rmt@listserv.lbl.gov Wed Jul 25 03:42:13 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6PAfNK07786; Wed, 25 Jul 2001 03:41:23 -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.11.2/8.11.2) with ESMTP id f6PAfLK07782 for ; Wed, 25 Jul 2001 03:41:21 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6PAfK013229 for ; Wed, 25 Jul 2001 03:41:21 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6PAfIS13222 for ; Wed, 25 Jul 2001 03:41:19 -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 GAA08324; Wed, 25 Jul 2001 06:40:18 -0400 (EDT) Message-Id: <200107251040.GAA08324@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-02.txt Date: Wed, 25 Jul 2001 06:40:18 -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-02.txt Pages : 24 Date : 24-Jul-01 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-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-gra-arch-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-gra-arch-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: <20010724132800.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-gra-arch-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-gra-arch-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132800.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Thu Jul 26 12:01:27 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6QIxLZ01957; Thu, 26 Jul 2001 11:59:21 -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.11.2/8.11.2) with ESMTP id f6QIxKK01953 for ; Thu, 26 Jul 2001 11:59:20 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6QIxJ824222 for ; Thu, 26 Jul 2001 11:59:19 -0700 (PDT) Received: from cecom6.monmouth.army.mil (cecom6.monmouth.army.mil [134.80.0.9]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6QIxIS24218 for ; Thu, 26 Jul 2001 11:59:18 -0700 (PDT) Received: from [134.80.0.139] (mailsw2.monmouth.army.mil [134.80.0.139]) by cecom6.monmouth.army.mil (8.9.3/8.9.3) with ESMTP id OAA11185 for ; Thu, 26 Jul 2001 14:59:11 -0400 (EDT) X-IMPORTANT-Address-Change: All doim6 addresses have changed to mail1. Example: mailbox@doim6.monmouth.army.mil is now mailbox@mail1.monmouth.army.mil Received: from swgm6.monmouth.army.mil (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 26 Jul 2001 14:59:07 -0400 Received: by SWGM6 with Internet Mail Service (5.5.2653.19) id <3VADS1KW>; Thu, 26 Jul 2001 14:59:07 -0400 Message-ID: From: "Lovuola, James J CECOM RDEC CSC" To: "'macker@itd.nrl.navy.mil'" , "'rmt@lbl.gov'" Cc: "Langan, Russell J CECOM RDEC HQ" Subject: Use of the Multicast Disemmination Protocol (MDP) for Unicast Date: Thu, 26 Jul 2001 14:59:06 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-rmt@lbl.gov Precedence: bulk Joe: I'm currently supporting the Army Systems Engineering Office (ASEO) in investigating which Multicast and Reliable Multicast protocols would be suitable for inclusion into the Joint Technical Architecture-Army (JTA-A). One of the candidates we are looking at is MDP which is being supported within the Army by FBCB2 for use over Combat Net Radio (CNR) and other networks within the lower and upper Tactical Internet (TI). At the CNR Implementation WG held last week, the issue surfaced as to whether Segmentation/Reassembly (a CNR WG developed Application Framing Prptocol to support Unicast) should be mandated over UDP for all large messages (those larger than the maximum segment size of 496 octets). At the meeting, I pointed out that S/R was never designed to support multicast and other protocols (e.g., MDP) are much more suited to provide a reliable transport service for multcast applications. My question is; Is it possible that MDP could also provide a reliable transport service for Unicast (e.g., be used by different applications for both Multicast and Unicast)? The problem with using TCP is that it imposes to much overhead for use over CNR networks. S/R can also be used for Unicast but is not an open standard and has not gained wide acceptance even within the CNR community (i.e., is only being supported by Fire Support and a handful of synchronous users). S/R is also not well documented ands does not contain any guidance on use of timers, etc. Also I know that there are real-time protocols such a RTP that could be used to ensure sequencing of packets for Unicast but they don't provide a reliable transport service. For MDP to support Unicast, it appears that addressing would be an obvious issues; Could MDP support for instance both Class D addresses as well as Unicast addresses? Would all Unicast receivers have to be considered as a separate groups? Again, it may be more than just addressing, as I would guess that for Unicast you would want to shut off some of the mechanisms such as NACK supression, NAK aggregation for sending repair information, etc. Would this be easy to do or would it require a major SW modification effort? Has MDP ever been tested for Unicast? Any insight you could give me on this subject would be greatly appreciated. Regards Jim L >From owner-rmt@listserv.lbl.gov Fri Jul 27 04:35:50 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6RBPpM29727; Fri, 27 Jul 2001 04:25:51 -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.11.2/8.11.2) with ESMTP id f6RBPnK29723 for ; Fri, 27 Jul 2001 04:25:49 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6RBPnu21589 for ; Fri, 27 Jul 2001 04:25:49 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6RBPmS21584 for ; Fri, 27 Jul 2001 04:25:48 -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 HAA07795; Fri, 27 Jul 2001 07:24:47 -0400 (EDT) Message-Id: <200107271124.HAA07795@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-norm-02.txt Date: Fri, 27 Jul 2001 07:24:47 -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 : NACK-Oriented Reliable Multicast Protocol (NORM) Author(s) : B. Adamson, C. Bormann, M. Handley, J. Macker Filename : draft-ietf-rmt-pi-norm-02.txt Pages : 25 Date : 26-Jul-01 This document describes the messages and procedures of the Nega- tive-acknowledgement (NACK) oriented reliable multicast (NORM). This revision of the document represents an initial outline of the protocol description. The document requires refinement in a number of areas to be considered complete. At this time, the document describes the high level details of the reliable multicast bulk transfer service model this protocol hopes to fulfill and the gen- eral message types and mechanisms which will be used to accomplish those goals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-norm-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-pi-norm-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-pi-norm-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: <20010726171135.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-pi-norm-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-pi-norm-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726171135.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Fri Jul 27 04:35:51 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6RBNxv29721; Fri, 27 Jul 2001 04:23:59 -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.11.2/8.11.2) with ESMTP id f6RBNvK29717 for ; Fri, 27 Jul 2001 04:23:57 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6RBNvi21475 for ; Fri, 27 Jul 2001 04:23:57 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6RBNtS21472 for ; Fri, 27 Jul 2001 04:23: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 HAA07713; Fri, 27 Jul 2001 07:22:55 -0400 (EDT) Message-Id: <200107271122.HAA07713@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-norm-bb-02.txt Date: Fri, 27 Jul 2001 07:22: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 : NACK-Oriented Reliable Multicast (NORM) Protocol Building Blocks Author(s) : B. Adamson, C. Bormann, M. Handley, J. Macker Filename : draft-ietf-rmt-norm-bb-02.txt Pages : 41 Date : 26-Jul-01 This memo describes issues related to the creation of negative- acknowledgment (NACK) oriented reliable multicast (NORM) protocols. The general goals and assumptions for NORM are defined. The tech- nical challenges related to NACK-oriented (and in some cases gen- eral) reliable multicast protocol design are identified. These challenges are resolved into a set of applicable 'building blocks' which are described in further detail. It is anticipated that these building blocks (as they are further refined and defined in future revisions of this document) will be useful in generating different instantiations of reliable multicast protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-norm-bb-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-norm-bb-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-norm-bb-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: <20010726171121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-norm-bb-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-norm-bb-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726171121.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Fri Jul 27 15:13:28 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6RMBJT22268; Fri, 27 Jul 2001 15:11:19 -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.11.2/8.11.2) with ESMTP id f6RMBIK22264 for ; Fri, 27 Jul 2001 15:11:18 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6RMBFj19808 for ; Fri, 27 Jul 2001 15:11:16 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6RMBDS19766 for ; Fri, 27 Jul 2001 15:11:13 -0700 (PDT) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6RMAUg10650; Fri, 27 Jul 2001 15:10:30 -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 PAA05383; Fri, 27 Jul 2001 15:10:30 -0700 (PDT) Message-Id: <200107272210.PAA05383@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI] To: rmt@lbl.gov cc: roger.kermode@motorola.com, mankin@ISI.EDU, sob@harvard.edu Subject: RMT meeting -- draft agenda Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Jul 2001 15:10:30 -0700 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk This the list of items, in a random order, based on the requests received so far. Please send us addition and modification requests. You have time until Monday, when we are planning to submit this to the IETF. thank you, the RMT chairs. - updates on GRA work Tony Speakman 20 mins - updates on LCT BB Mike Luby 10 mins - updates on ALC PI Mike Luby 10 mins - discussion on RCCP PI Mike Luby 15 mins (a) Present draft outline (b) Is this type of document within the scope of RMT? (c) Feedback on the draft if it is. - discussion on FEC BBs Mike Luby 15 mins (a) Are we moving this towards experimental now instead of standards? (b) What are the processes for getting approval, i.e., what experiements - updates on FEC BB Lorenzo Vicisano 10 mins (a) General updates (b) Issue on "Object Length" packet field - NORM BB and PI updates Brian Adamson 10 mins - general purpose NACK format Brian Adamson 20 mins >From owner-rmt@listserv.lbl.gov Mon Jul 30 03:15:56 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6UADqE00941; Mon, 30 Jul 2001 03:13: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.11.2/8.11.2) with ESMTP id f6UADoK00937 for ; Mon, 30 Jul 2001 03:13:50 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6UADlh05554 for ; Mon, 30 Jul 2001 03:13:48 -0700 (PDT) Received: from unicorn.saver.ne.jp ([61.115.196.10]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f6UADGn05230 for ; Mon, 30 Jul 2001 03:13:17 -0700 (PDT) Date: Mon, 30 Jul 2001 03:13:17 -0700 (PDT) Message-Id: <200107301013.f6UADGn05230@SpamWall.lbl.gov> Received: (qmail 15752 invoked from network); 30 Jul 2001 10:19:55 -0000 Received: from unknown (HELO mc3.law13.hotmail.com) (61.115.196.131) by 61.115.196.132 with SMTP; 30 Jul 2001 10:19:55 -0000 Reply-To: From: "gfyt563@hotmail.com" To: "0411@yahoo.com" <0411@yahoo.com> Subject: WE PAY CASH NOW! Content-Type: text/plain; charset="us-ascii";format=flowed Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk WE PAY CASH, NOW! We will pay you a lump sum of cash for Eight years of your Military and Government pensions, or your VA diusability. We pay top dollar! Go to: www.tfund2000.com and click on Military/Government pensions. www.tfund2000.com To be removed, please send a blank email with the word remove in the subject line. >From owner-rmt@listserv.lbl.gov Mon Jul 30 12:44:47 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6UJf1P15981; Mon, 30 Jul 2001 12:41:01 -0700 (PDT) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal2.lbl.gov (postal2.lbl.gov [131.243.248.26]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6UJf0K15977 for ; Mon, 30 Jul 2001 12:41:00 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal2.lbl.gov (8.11.2/8.11.2) with ESMTP id f6UJex703697 for ; Mon, 30 Jul 2001 12:40:59 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6UHvsx23811 for ; Mon, 30 Jul 2001 10:57:54 -0700 (PDT) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6UHvxY22661 for ; Mon, 30 Jul 2001 10:58:00 -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 KAA17537 for ; Mon, 30 Jul 2001 10:57:46 -0700 (PDT) Message-Id: <200107301757.KAA17537@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI] To: rmt@lbl.gov Subject: 51st IETF -- agenda update Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 Jul 2001 10:57:46 -0700 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk This is the new agenda. We'll be submitting this shortly, please ask for changes now, if any. thanks the RMT chairs - updates on GRA work Tony Speakman 20 mins - LCT BB update Mike Luby 10 mins - ALC PI update Mike Luby 10 mins - discussion on RCCP PI Mike Luby 15 mins (a) Present draft outline (b) Is this type of document within the scope of RMT? (c) Feedback on the draft if it is. - discussion on CC BBs Mike Luby 15 mins (a) Are we moving this towards experimental now instead of standards? (b) What are the processes for getting approval, i.e., what experiements - FEC BB update Lorenzo Vicisano 10 mins (a) General updates (b) Issue on "Object Length" packet field - NORM BB and PI updates Brian Adamson 10 mins - general purpose NACK format Brian Adamson 20 mins - TRACK PI update Brian Whetten 10 mins >From owner-rmt@listserv.lbl.gov Mon Jul 30 14:25:36 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6ULNlE21793; Mon, 30 Jul 2001 14:23: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.11.2/8.11.2) with ESMTP id f6ULNjK21789 for ; Mon, 30 Jul 2001 14:23:45 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6ULNid22179 for ; Mon, 30 Jul 2001 14:23:44 -0700 (PDT) Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6ULNf522153 for ; Mon, 30 Jul 2001 14:23:41 -0700 (PDT) Received: from reception ([12.80.24.110]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20010730181736.CBE8490.mtiwmhc23.worldnet.att.net@reception> for ; Mon, 30 Jul 2001 18:17:36 +0000 From: "Richard Leathers" To: rmt@lbl.gov Subject: bills date: Mon, 30 Jul 2001 11:16:33 -0500 MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-Type: multipart/mixed; boundary="----212C14E2_Outlook_Express_message_boundary" Content-Disposition: Multipart message Message-Id: <20010730181736.CBE8490.mtiwmhc23.worldnet.att.net@reception> Sender: owner-rmt@lbl.gov Precedence: bulk ------212C14E2_Outlook_Express_message_boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) Found virus TROJ_SIRCAM.A in file bills.doc.pif The file e/iscan/virus/virTHBhLayrL is moved to the configured virus directory. ********************************************************* ------212C14E2_Outlook_Express_message_boundary Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: message text Hi! How are you=3F I send you this file in order to have your advice See you later=2E Thanks ------212C14E2_Outlook_Express_message_boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) bills.doc.pif is removed from here because it contains a virus. ********************************************************* ------212C14E2_Outlook_Express_message_boundary ------212C14E2_Outlook_Express_message_boundary-- >From owner-rmt@listserv.lbl.gov Mon Jul 30 14:25:35 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6ULNoR21799; Mon, 30 Jul 2001 14:23: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.11.2/8.11.2) with ESMTP id f6ULNnK21795 for ; Mon, 30 Jul 2001 14:23:49 -0700 (PDT) Received: from localhost (root@localhost) by postal1.lbl.gov (8.11.2/8.11.2) with SMTP id f6ULNm722228 for ; Mon, 30 Jul 2001 14:23:48 -0700 (PDT) Date: Mon, 30 Jul 2001 14:23:48 -0700 (PDT) Message-Id: <200107302123.f6ULNm722228@postal1.lbl.gov> From: VirusWall@lbl.gov To: rmt@listserv.lbl.gov Subject: Virus Alert Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk This is an automated message from the LBNL VirusWall. The mail message you recently received from: leathersnb@worldnet.att.net which included the file: bills.doc.pif contained the virus: TROJ_SIRCAM.A. PLEASE NOTE: 1. The virus has been REMOVED from the email message by the LBNL VirusWall and will NOT INFECT your computer. 2. It is SAFE to read the message and open the attachment, though you should always use caution when opening attachments from people you do not know. 3. You do not need to notify anyone that you received this message. For more information take a look at our virus protection web page: http://www.lbl.gov/ITSD/Security/resources/ If you have any questions, please contact the LBNL Help Desk at http://www.lbl.gov/help/, or 510-486-4357. Thanks, The VirusWall Lawrence Berkeley National Laboratory >From owner-rmt@listserv.lbl.gov Tue Jul 31 13:29:00 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f6VKPVA29256; Tue, 31 Jul 2001 13:25:31 -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.11.2/8.11.2) with ESMTP id f6VKPTK29252 for ; Tue, 31 Jul 2001 13:25:29 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6VKPTT08048 for ; Tue, 31 Jul 2001 13:25:29 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6VKPS508043 for ; Tue, 31 Jul 2001 13:25:28 -0700 (PDT) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6VKPMg21809; Tue, 31 Jul 2001 13:25:22 -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 NAA22223; Tue, 31 Jul 2001 13:25:22 -0700 (PDT) Message-Id: <200107312025.NAA22223@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI] To: agenda@ietf.org cc: rmt@lbl.gov Subject: RMT agenda Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 31 Jul 2001 13:25:22 -0700 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk Please find attached the proposed agenda for the two RMT meetings. thank you, the RMT chairs - updates on GRA work Tony Speakman 20 mins - LCT BB update Mike Luby 10 mins - ALC PI update Mike Luby 10 mins - discussion on RCCP PI Mike Luby 15 mins (a) Present draft outline (b) Is this type of document within the scope of RMT? (c) Feedback on the draft if it is. - discussion on CC BBs Mike Luby 15 mins (a) Are we moving this towards experimental now instead of standards? (b) What are the processes for getting approval, i.e., what experiements - FEC BB update Lorenzo Vicisano 10 mins (a) General updates (b) Issue on "Object Length" packet field - NORM BB and PI updates Brian Adamson 10 mins - general purpose NACK format Brian Adamson 20 mins - TRACK PI update Brian Whetten 10 mins >From owner-rmt@listserv.lbl.gov Thu Aug 2 15:59:49 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f72Mvu826149; Thu, 2 Aug 2001 15:57: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.11.2/8.11.2) with ESMTP id f72MvsK26145 for ; Thu, 2 Aug 2001 15:57:54 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f72MvrG12879 for ; Thu, 2 Aug 2001 15:57:53 -0700 (PDT) Received: from ns2.webfountain.com (mx2.webfountain.com [216.136.183.167]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f72Mvq512866 for ; Thu, 2 Aug 2001 15:57:52 -0700 (PDT) Received: (qmail 7930 invoked from network); 2 Aug 2001 22:57:47 -0000 Received: from mail.intranet (10.1.1.37) by ns2.webfountain.com with SMTP; 2 Aug 2001 22:57:47 -0000 Received: from leningrad (leningrad.intranet [10.1.3.72]) by mail.intranet (8.9.3/8.9.3) with SMTP id PAA12655; Thu, 2 Aug 2001 15:57:47 -0700 X-Authentication-Warning: mail.intranet: Host leningrad.intranet [10.1.3.72] claimed to be leningrad From: "Mike Luby" To: "Rmt@Lbl. Gov" Cc: "Michael Luby" , "Lorenzo Vicisano" , "Allison Mankin" , "Roger Kermode" Subject: Date: Thu, 2 Aug 2001 15:59:16 -0700 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 Sender: owner-rmt@lbl.gov Precedence: bulk In the upcoming RMT working group meeting at the IETF there will be a discussion about whether or not a session control protocol instantiation is: (1) within the mandate of the RMT working group (2) valuable assuming that the answer to (1) is "yes" The following draft is a description of a possible session control protocol. Note that this draft is not an official submission to the IETF, and its content will not be reviewed at the IETF meeting. This draft is available at: http://www.digitalfountain.com/getDocument.htm/technology/library/draft-ietf -rmt-mgl-pi-rccp-00-7-11-2001.txt This document describes the Rich Content Control Protocol (RCCP), a session control protocol for client initiated content delivery. The content in question may be a file, a stream or some other form of content. The RCCP protocol itself, however, is independent of the type of the content. RCCP offers support for both multicast and unicast delivery. Some of the key properties and goals of RCCP are: (1) Initiation of the session including communication of the session description to clients. (2) Session monitoring to facilitate server side accounting. (3) Session teardown, facilitating server side accounting and collection of client statistics. (4) Initiation and high level control of data packet reception. (5) Prevention of some types of DoS attacks on servers. (3) The ability to either directly or after configuration allow delivery of content through firewalls. This document is in a high state of flux, will be greatly modified in the near future, and is not an official document within the IETF. Michael Luby Chief Technical Officer Digital Fountain, Inc. 39141 Civic Center Drive Suite 300 Fremont, CA 94538 www.digitalfountain.com luby@digitalfountain.com (510) 284-1420 (phone) (510) 284-1499 (fax) (510) 284-1400 (main) >From owner-rmt@listserv.lbl.gov Thu Aug 2 16:02:13 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f72N2A428582; Thu, 2 Aug 2001 16:02: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.11.2/8.11.2) with ESMTP id f72N28K28578 for ; Thu, 2 Aug 2001 16:02:08 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f72N27Z14265 for ; Thu, 2 Aug 2001 16:02:07 -0700 (PDT) Received: from ns2.webfountain.com (mx2.webfountain.com [216.136.183.167]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f72N26514254 for ; Thu, 2 Aug 2001 16:02:06 -0700 (PDT) Received: (qmail 7947 invoked from network); 2 Aug 2001 23:02:01 -0000 Received: from mail.intranet (10.1.1.37) by ns2.webfountain.com with SMTP; 2 Aug 2001 23:02:01 -0000 Received: from leningrad (leningrad.intranet [10.1.3.72]) by mail.intranet (8.9.3/8.9.3) with SMTP id QAA12934; Thu, 2 Aug 2001 16:02:01 -0700 X-Authentication-Warning: mail.intranet: Host leningrad.intranet [10.1.3.72] claimed to be leningrad From: "Mike Luby" To: "Rmt@Lbl. Gov" Cc: "Michael Luby" , "Lorenzo Vicisano" , "Roger Kermode" Subject: Session control protocol instantiation discussion within the IETF Date: Thu, 2 Aug 2001 16:03:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C11B6C.AC037450" 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 Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C11B6C.AC037450 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit (This is a resend of a recent message, but with a title and with the link properly displayed (at least in some email programs)). In the upcoming RMT working group meeting at the IETF there will be a discussion about whether or not a session control protocol instantiation is: (1) within the mandate of the RMT working group (2) valuable assuming that the answer to (1) is "yes" The following draft is a description of a possible session control protocol. Note that this draft is not an official submission to the IETF, and its content will not be reviewed at the IETF meeting. This draft is available at: http://www.digitalfountain.com/getDocument.htm/technology/library/draft-ietf -rmt-mgl-pi-rccp-00-7-11-2001.txt This document describes the Rich Content Control Protocol (RCCP), a session control protocol for client initiated content delivery. The content in question may be a file, a stream or some other form of content. The RCCP protocol itself, however, is independent of the type of the content. RCCP offers support for both multicast and unicast delivery. Some of the key properties and goals of RCCP are: (1) Initiation of the session including communication of the session description to clients. (2) Session monitoring to facilitate server side accounting. (3) Session teardown, facilitating server side accounting and collection of client statistics. (4) Initiation and high level control of data packet reception. (5) Prevention of some types of DoS attacks on servers. (3) The ability to either directly or after configuration allow delivery of content through firewalls. This document is in a high state of flux, will be greatly modified in the near future, and is not an official document within the IETF. Michael Luby Chief Technical Officer Digital Fountain, Inc. 39141 Civic Center Drive Suite 300 Fremont, CA 94538 www.digitalfountain.com luby@digitalfountain.com (510) 284-1420 (phone) (510) 284-1499 (fax) (510) 284-1400 (main) ------=_NextPart_000_0000_01C11B6C.AC037450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    (This is a resend of a recent message, = but with a=20 title and with the link properly displayed (at least in some email=20 programs)).

    In the upcoming RMT working group meeting at the IETF = there will=20 be a
    discussion about whether or not a session control protocol = instantiation=20 is:

    (1) within the mandate of the RMT working group

    (2) = valuable=20 assuming that the answer to (1) is "yes"

    The following draft is a = description of a possible session control protocol.
    Note that this = draft is=20 not an official submission to the IETF, and its
    content will not be = reviewed=20 at the IETF meeting.  This draft is available
    at:

    http://www.digitalfountain.com/getDocument.htm/technology= /library/draft-ietf-rmt-mgl-pi-rccp-00-7-11-2001.txt

    This=20 document describes the Rich Content Control Protocol (RCCP), a=20 session
    control protocol for client initiated  content = delivery. =20 The content in
    question may be a file, a stream or some other form of = content.  The RCCP
    protocol  itself, however, is = independent of the=20 type of the content.  RCCP
    offers support for both multicast and = unicast  delivery.

    Some of the key properties and goals of = RCCP=20 are:

    (1) Initiation of the session including communication of the = session
    description to clients.
    (2) Session monitoring to = facilitate=20 server side accounting.
    (3) Session teardown, facilitating server = side=20 accounting and collection of
    client statistics.
    (4) Initiation and = high=20 level control of data packet reception.
    (5) Prevention of some types = of DoS=20 attacks on servers.
    (3) The ability to either directly or after = configuration=20 allow delivery of
    content through firewalls.

    This document is = in a=20 high state of flux, will be greatly modified in the
    near future, and = is not=20 an official  document within the IETF.

    Michael Luby
    Chief = Technical Officer
    Digital Fountain, Inc.
    39141 Civic Center = Drive
    Suite=20 300
    Fremont, CA =20 94538


    www.digitalfountain.com
    luby@digitalfountain.com
    (= 510)=20 284-1420 (phone)
    (510) 284-1499 (fax)
    (510) 284-1400 (main)     =

    ------=_NextPart_000_0000_01C11B6C.AC037450-- >From owner-rmt@listserv.lbl.gov Thu Aug 2 18:16:13 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f731Fio03865; Thu, 2 Aug 2001 18:15: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.11.2/8.11.2) with ESMTP id f731FhK03861 for ; Thu, 2 Aug 2001 18:15:43 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f731Fhq18511 for ; Thu, 2 Aug 2001 18:15:43 -0700 (PDT) Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.164.217]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f731FZ518487 for ; Thu, 2 Aug 2001 18:15:36 -0700 (PDT) Received: from escape (sjkoh3.etri.re.kr [129.254.164.124]) by pec.etri.re.kr (8.10.0/8.10.0) with SMTP id f7316NV16774; Fri, 3 Aug 2001 10:06:24 +0900 (KST) Message-ID: <001801c11bb9$14c10ba0$7ca4fe81@escape> From: "Eunsook Kim" To: "Mike Luby" , "Rmt@Lbl. Gov" Cc: "Michael Luby" , "Lorenzo Vicisano" , "Roger Kermode" References: Subject: Re: Session control protocol instantiation discussion within the IETF Date: Fri, 3 Aug 2001 10:09:55 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C11C04.71C446A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C11C04.71C446A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIHN1Y2ggZGlzY3Vzc2lvbiBpcyB2ZXJ5IGNydWNpYWwgYW5kIHZhbHVhYmxlIGZv ciB0aGUgZnVydGhlciBwcm9ncmVzcyBvZiBSTVQgV0cuDQoNCldlIG5vdGUgdGhhdCBpbiB0aGUg cmVhbCBmaWVsZHMgaW5jbHVkaW5nIHRoZSBtdWx0aWNhc3QtYmFzZWQgY29udGVudHMgZGVsaXZl cnkgYW5kIHRoZSByZWxhdGVkIG1hcmtldHMsDQp0aGVyZSBoYXMgYmVlbiBhIHVyZ2VudCBuZWVk IGZyb20gc28gbWFueSBjb250ZW50cyBwcm92aWRlcnMgYW5kIENETiBzZXJ2aWNlIHByb3ZpZGVy cw0KdG8gcHJvdmlkZSB0aGUgbXVsdGljYXN0IHNlc3Npb24gY29udHJvbCBvciBtYW5hZ2VtZW50 IA0KZm9yIHJlYWxpemluZyBwcm92aXNpb2luaW5nIG9mIG11bHRpY2FzdCBzZXJ2aWNlcy4NCg0K SSB0aGluayB0aGlzIGlzc3VlIG11c3QgYmUgcHJvZ3Jlc3NpdmVseSBkaXNjdXNzZWQgaW4gdGhl IFJNVCBXRywgYWxvbmcgd2l0aCBvcmlnaW5hbCBlcnJvci9jb25nZXN0aW9uIGNvbnRyb2xzLg0K DQpJbiBhZGRpdGlvbiB0byBMdWJ5J3MgZHJhZnQsIGhlcmUgaXMgYW5vdGhlciBpbmZvcm1hdGl2 ZSBtYXRlcmlhbCBmb3IgdGhpcyBkaXNjdXNzaW9uOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQta29oLXRzbS0wMC50eHQNCihzb21lIHBhcnRzIG9mIHRob3NlIGhh dmUgYWxyZWFkeSBiZWVuIGRpc2N1c3NlZCBpbiB0aGUgbGFzdCBSTVQgbWVldGluZykNCg0KDQpC ZXN0IFJlZ2FyZHMsDQoNCg0KDQpFdW5zb29rIEtpbQ0KDQpldW5haEBldHJpLnJlLmtyDQorODIt Mi04NjAtNjEyNA0KUHJvdG9jb2wgRW5naW5lZXJpbmcgQ2VudGVyDQpFbGVjdHJvbmljcyBhbmQg VGVsZWNvbW11bmljYXRpb25zIFJlc2VhcmNoIEluc3RpdHV0ZSAoRVRSSSkNCg0KDQogIC0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IE1pa2UgTHVieSANCiAgVG86IFJtdEBM YmwuIEdvdiANCiAgQ2M6IE1pY2hhZWwgTHVieSA7IExvcmVuem8gVmljaXNhbm8gOyBSb2dlciBL ZXJtb2RlIA0KICBTZW50OiBGcmlkYXksIEF1Z3VzdCAwMywgMjAwMSA4OjAzIEFNDQogIFN1Ympl Y3Q6IFNlc3Npb24gY29udHJvbCBwcm90b2NvbCBpbnN0YW50aWF0aW9uIGRpc2N1c3Npb24gd2l0 aGluIHRoZSBJRVRGDQoNCg0KICAoVGhpcyBpcyBhIHJlc2VuZCBvZiBhIHJlY2VudCBtZXNzYWdl LCBidXQgd2l0aCBhIHRpdGxlIGFuZCB3aXRoIHRoZSBsaW5rIHByb3Blcmx5IGRpc3BsYXllZCAo YXQgbGVhc3QgaW4gc29tZSBlbWFpbCBwcm9ncmFtcykpLg0KDQogIEluIHRoZSB1cGNvbWluZyBS TVQgd29ya2luZyBncm91cCBtZWV0aW5nIGF0IHRoZSBJRVRGIHRoZXJlIHdpbGwgYmUgYQ0KICBk aXNjdXNzaW9uIGFib3V0IHdoZXRoZXIgb3Igbm90IGEgc2Vzc2lvbiBjb250cm9sIHByb3RvY29s IGluc3RhbnRpYXRpb24gaXM6DQoNCiAgKDEpIHdpdGhpbiB0aGUgbWFuZGF0ZSBvZiB0aGUgUk1U IHdvcmtpbmcgZ3JvdXANCg0KICAoMikgdmFsdWFibGUgYXNzdW1pbmcgdGhhdCB0aGUgYW5zd2Vy IHRvICgxKSBpcyAieWVzIg0KDQogIFRoZSBmb2xsb3dpbmcgZHJhZnQgaXMgYSBkZXNjcmlwdGlv biBvZiBhIHBvc3NpYmxlIHNlc3Npb24gY29udHJvbCBwcm90b2NvbC4NCiAgTm90ZSB0aGF0IHRo aXMgZHJhZnQgaXMgbm90IGFuIG9mZmljaWFsIHN1Ym1pc3Npb24gdG8gdGhlIElFVEYsIGFuZCBp dHMNCiAgY29udGVudCB3aWxsIG5vdCBiZSByZXZpZXdlZCBhdCB0aGUgSUVURiBtZWV0aW5nLiAg VGhpcyBkcmFmdCBpcyBhdmFpbGFibGUNCiAgYXQ6DQoNCiAgaHR0cDovL3d3dy5kaWdpdGFsZm91 bnRhaW4uY29tL2dldERvY3VtZW50Lmh0bS90ZWNobm9sb2d5L2xpYnJhcnkvZHJhZnQtaWV0Zi1y bXQtbWdsLXBpLXJjY3AtMDAtNy0xMS0yMDAxLnR4dA0KDQogIFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIHRoZSBSaWNoIENvbnRlbnQgQ29udHJvbCBQcm90b2NvbCAoUkNDUCksIGEgc2Vzc2lvbg0K ICBjb250cm9sIHByb3RvY29sIGZvciBjbGllbnQgaW5pdGlhdGVkICBjb250ZW50IGRlbGl2ZXJ5 LiAgVGhlIGNvbnRlbnQgaW4NCiAgcXVlc3Rpb24gbWF5IGJlIGEgZmlsZSwgYSBzdHJlYW0gb3Ig c29tZSBvdGhlciBmb3JtIG9mIGNvbnRlbnQuICBUaGUgUkNDUA0KICBwcm90b2NvbCAgaXRzZWxm LCBob3dldmVyLCBpcyBpbmRlcGVuZGVudCBvZiB0aGUgdHlwZSBvZiB0aGUgY29udGVudC4gIFJD Q1ANCiAgb2ZmZXJzIHN1cHBvcnQgZm9yIGJvdGggbXVsdGljYXN0IGFuZCB1bmljYXN0ICBkZWxp dmVyeS4NCg0KICBTb21lIG9mIHRoZSBrZXkgcHJvcGVydGllcyBhbmQgZ29hbHMgb2YgUkNDUCBh cmU6DQoNCiAgKDEpIEluaXRpYXRpb24gb2YgdGhlIHNlc3Npb24gaW5jbHVkaW5nIGNvbW11bmlj YXRpb24gb2YgdGhlIHNlc3Npb24NCiAgZGVzY3JpcHRpb24gdG8gY2xpZW50cy4NCiAgKDIpIFNl c3Npb24gbW9uaXRvcmluZyB0byBmYWNpbGl0YXRlIHNlcnZlciBzaWRlIGFjY291bnRpbmcuDQog ICgzKSBTZXNzaW9uIHRlYXJkb3duLCBmYWNpbGl0YXRpbmcgc2VydmVyIHNpZGUgYWNjb3VudGlu ZyBhbmQgY29sbGVjdGlvbiBvZg0KICBjbGllbnQgc3RhdGlzdGljcy4NCiAgKDQpIEluaXRpYXRp b24gYW5kIGhpZ2ggbGV2ZWwgY29udHJvbCBvZiBkYXRhIHBhY2tldCByZWNlcHRpb24uDQogICg1 KSBQcmV2ZW50aW9uIG9mIHNvbWUgdHlwZXMgb2YgRG9TIGF0dGFja3Mgb24gc2VydmVycy4NCiAg KDMpIFRoZSBhYmlsaXR5IHRvIGVpdGhlciBkaXJlY3RseSBvciBhZnRlciBjb25maWd1cmF0aW9u IGFsbG93IGRlbGl2ZXJ5IG9mDQogIGNvbnRlbnQgdGhyb3VnaCBmaXJld2FsbHMuDQoNCiAgVGhp cyBkb2N1bWVudCBpcyBpbiBhIGhpZ2ggc3RhdGUgb2YgZmx1eCwgd2lsbCBiZSBncmVhdGx5IG1v ZGlmaWVkIGluIHRoZQ0KICBuZWFyIGZ1dHVyZSwgYW5kIGlzIG5vdCBhbiBvZmZpY2lhbCAgZG9j dW1lbnQgd2l0aGluIHRoZSBJRVRGLg0KDQogIE1pY2hhZWwgTHVieQ0KICBDaGllZiBUZWNobmlj YWwgT2ZmaWNlcg0KICBEaWdpdGFsIEZvdW50YWluLCBJbmMuDQogIDM5MTQxIENpdmljIENlbnRl ciBEcml2ZQ0KICBTdWl0ZSAzMDANCiAgRnJlbW9udCwgQ0EgIDk0NTM4DQoNCg0KICB3d3cuZGln aXRhbGZvdW50YWluLmNvbQ0KICBsdWJ5QGRpZ2l0YWxmb3VudGFpbi5jb20NCiAgKDUxMCkgMjg0 LTE0MjAgKHBob25lKQ0KICAoNTEwKSAyODQtMTQ5OSAoZmF4KQ0KICAoNTEwKSAyODQtMTQwMCAo bWFpbikgDQoNCg== ------=_NextPart_000_0015_01C11C04.71C446A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250 ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEg Y29udGVudD0iTVNIVE1MIDUuNTAuNDYxNi4yMDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwv U1RZTEU+DQo8L0hFQUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9 JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+DQo8RElWPjxGT05UIHNpemU9Mj5JIGJlbGlldmUmbmJz cDtzdWNoIGRpc2N1c3Npb24gaXMgdmVyeSBjcnVjaWFsIGFuZCB2YWx1YWJsZSANCmZvciB0aGUg ZnVydGhlciBwcm9ncmVzcyBvZiBSTVQgV0cuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+V2Ugbm90ZSB0aGF0IGlu IHRoZSByZWFsIGZpZWxkcyZuYnNwO2luY2x1ZGluZyZuYnNwO3RoZSANCm11bHRpY2FzdC1iYXNl ZCBjb250ZW50cyBkZWxpdmVyeSBhbmQgdGhlIHJlbGF0ZWQgbWFya2V0cyw8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj50aGVyZSBoYXMgYmVlbiZuYnNwO2EgdXJnZW50IG5lZWQgZnJv bSBzbyBtYW55IGNvbnRlbnRzIA0KcHJvdmlkZXJzIGFuZCBDRE4gc2VydmljZSBwcm92aWRlcnM8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj50byBwcm92aWRlIHRoZSBtdWx0aWNhc3Qg c2Vzc2k8L0ZPTlQ+PEZPTlQgc2l6ZT0yPm9uIGNvbnRyb2wgDQpvciBtYW5hZ2VtZW50IDwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPmZvciByZWFsaXppbmcmbmJzcDtwcm92aXNpb2lu aW5nIG9mIG11bHRpY2FzdCANCnNlcnZpY2VzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkgdGhpbmsgdGhpcyBp c3N1ZSBtdXN0IGJlIHByb2dyZXNzaXZlbHkgZGlzY3Vzc2VkIGluIHRoZSBSTVQgDQpXRywgYWxv bmcgd2l0aCBvcmlnaW5hbCBlcnJvci9jb25nZXN0aW9uIGNvbnRyb2xzLjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PkluIGFkZGl0aW9uIHRvIEx1YnkncyZuYnNwO2RyYWZ0LCBoZXJlIGlzIGFub3RoZXIgaW5mb3Jt YXRpdmUgDQptYXRlcmlhbCBmb3IgdGhpcyBkaXNjdXNzaW9uOjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPjxBIA0KaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQta29oLXRzbS0wMC50eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWtvaC10c20tMDAudHh0PC9BPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPihzb21lIHBhcnRzIG9mIHRob3NlIGhhdmUgYWxyZWFkeSBiZWVuIGRpc2N1c3NlZCBpbiB0 aGUgbGFzdCANClJNVCBtZWV0aW5nKTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5C ZXN0IFJlZ2FyZHMsPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5FdW5zb29rIEtpbTwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+PEEgaHJlZj0ibWFpbHRvOmV1bmFoQGV0cmkucmUua3IiPmV1bmFo QGV0cmkucmUua3I8L0E+PC9ESVY+DQo8RElWPis4Mi0yLTg2MC02MTI0PC9ESVY+DQo8RElWPlBy b3RvY29sIEVuZ2luZWVyaW5nIENlbnRlcjwvRElWPg0KPERJVj5FbGVjdHJvbmljcyBhbmQgVGVs ZWNvbW11bmljYXRpb25zIFJlc2VhcmNoIEluc3RpdHV0ZSAoRVRSSSk8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+PC9GT05UPjwv RElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBB RERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAwMCAy cHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCAm IzQ0NDA0OyYjNDc1NDg7Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8 RElWIA0KICBzdHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogMTBwdCAmIzQ0NDA0OyYj NDc1NDg7OyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IDxBIA0KICB0aXRsZT1sdWJ5 QGRpZ2l0YWxmb3VudGFpbi5jb20gaHJlZj0ibWFpbHRvOmx1YnlAZGlnaXRhbGZvdW50YWluLmNv bSI+TWlrZSANCiAgTHVieTwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgJiM0 NDQwNDsmIzQ3NTQ4OyI+PEI+VG86PC9CPiA8QSB0aXRsZT1ybXRAbGJsLmdvdiANCiAgaHJlZj0i bWFpbHRvOlJtdEBMYmwuIEdvdiI+Um10QExibC4gR292PC9BPiA8L0RJVj4NCiAgPERJViBzdHls ZT0iRk9OVDogMTBwdCAmIzQ0NDA0OyYjNDc1NDg7Ij48Qj5DYzo8L0I+IDxBIHRpdGxlPWx1YnlA ZGlnaXRhbGZvdW50YWluLmNvbSANCiAgaHJlZj0ibWFpbHRvOmx1YnlAZGlnaXRhbGZvdW50YWlu LmNvbSI+TWljaGFlbCBMdWJ5PC9BPiA7IDxBIA0KICB0aXRsZT1sb3JlbnpvQGNpc2NvLmNvbSBo cmVmPSJtYWlsdG86bG9yZW56b0BjaXNjby5jb20iPkxvcmVuem8gVmljaXNhbm88L0E+IDsgDQog IDxBIHRpdGxlPVJvZ2VyLktlcm1vZGVAbW90b3JvbGEuY29tIA0KICBocmVmPSJtYWlsdG86Um9n ZXIuS2VybW9kZUBtb3Rvcm9sYS5jb20iPlJvZ2VyIEtlcm1vZGU8L0E+IDwvRElWPg0KICA8RElW IHN0eWxlPSJGT05UOiAxMHB0ICYjNDQ0MDQ7JiM0NzU0ODsiPjxCPlNlbnQ6PC9CPiBGcmlkYXks IEF1Z3VzdCAwMywgMjAwMSA4OjAzIEFNPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQg JiM0NDQwNDsmIzQ3NTQ4OyI+PEI+U3ViamVjdDo8L0I+IFNlc3Npb24gY29udHJvbCBwcm90b2Nv bCANCiAgaW5zdGFudGlhdGlvbiBkaXNjdXNzaW9uIHdpdGhpbiB0aGUgSUVURjwvRElWPg0KICA8 RElWPjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+PC9GT05UPjxCUj48L0RJVj4N CiAgPFA+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+KFRoaXMgaXMgYSByZXNlbmQgb2YgYSByZWNl bnQgbWVzc2FnZSwgYnV0IHdpdGggYSANCiAgdGl0bGUgYW5kIHdpdGggdGhlIGxpbmsgcHJvcGVy bHkgZGlzcGxheWVkIChhdCBsZWFzdCBpbiBzb21lIGVtYWlsIA0KICBwcm9ncmFtcykpLjwvRk9O VD48L1A+DQogIDxQPjxGT05UIHNpemU9Mj5JbiB0aGUgdXBjb21pbmcgUk1UIHdvcmtpbmcgZ3Jv dXAgbWVldGluZyBhdCB0aGUgSUVURiB0aGVyZSANCiAgd2lsbCBiZSBhPEJSPmRpc2N1c3Npb24g YWJvdXQgd2hldGhlciBvciBub3QgYSBzZXNzaW9uIGNvbnRyb2wgcHJvdG9jb2wgDQogIGluc3Rh bnRpYXRpb24gaXM6PEJSPjxCUj4oMSkgd2l0aGluIHRoZSBtYW5kYXRlIG9mIHRoZSBSTVQgd29y a2luZyANCiAgZ3JvdXA8QlI+PEJSPigyKSB2YWx1YWJsZSBhc3N1bWluZyB0aGF0IHRoZSBhbnN3 ZXIgdG8gKDEpIGlzICJ5ZXMiPEJSPjxCUj5UaGUgDQogIGZvbGxvd2luZyBkcmFmdCBpcyBhIGRl c2NyaXB0aW9uIG9mIGEgcG9zc2libGUgc2Vzc2lvbiBjb250cm9sIA0KICBwcm90b2NvbC48QlI+ Tm90ZSB0aGF0IHRoaXMgZHJhZnQgaXMgbm90IGFuIG9mZmljaWFsIHN1Ym1pc3Npb24gdG8gdGhl IElFVEYsIA0KICBhbmQgaXRzPEJSPmNvbnRlbnQgd2lsbCBub3QgYmUgcmV2aWV3ZWQgYXQgdGhl IElFVEYgbWVldGluZy4mbmJzcDsgVGhpcyBkcmFmdCANCiAgaXMgYXZhaWxhYmxlPEJSPmF0OjxC Uj48QlI+PEEgdGFyZ2V0PV9ibGFuayANCiAgaHJlZj0iaHR0cDovL3d3dy5kaWdpdGFsZm91bnRh aW4uY29tL2dldERvY3VtZW50Lmh0bS90ZWNobm9sb2d5L2xpYnJhcnkvZHJhZnQtaWV0Zi1ybXQt bWdsLXBpLXJjY3AtMDAtNy0xMS0yMDAxLnR4dCI+aHR0cDovL3d3dy5kaWdpdGFsZm91bnRhaW4u Y29tL2dldERvY3VtZW50Lmh0bS90ZWNobm9sb2d5L2xpYnJhcnkvZHJhZnQtaWV0Zi1ybXQtbWds LXBpLXJjY3AtMDAtNy0xMS0yMDAxLnR4dDwvQT48QlI+PEJSPlRoaXMgDQogIGRvY3VtZW50IGRl c2NyaWJlcyB0aGUgUmljaCBDb250ZW50IENvbnRyb2wgUHJvdG9jb2wgKFJDQ1ApLCBhIA0KICBz ZXNzaW9uPEJSPmNvbnRyb2wgcHJvdG9jb2wgZm9yIGNsaWVudCBpbml0aWF0ZWQmbmJzcDsgY29u dGVudCBkZWxpdmVyeS4mbmJzcDsgDQogIFRoZSBjb250ZW50IGluPEJSPnF1ZXN0aW9uIG1heSBi ZSBhIGZpbGUsIGEgc3RyZWFtIG9yIHNvbWUgb3RoZXIgZm9ybSBvZiANCiAgY29udGVudC4mbmJz cDsgVGhlIFJDQ1A8QlI+cHJvdG9jb2wmbmJzcDsgaXRzZWxmLCBob3dldmVyLCBpcyBpbmRlcGVu ZGVudCBvZiANCiAgdGhlIHR5cGUgb2YgdGhlIGNvbnRlbnQuJm5ic3A7IFJDQ1A8QlI+b2ZmZXJz IHN1cHBvcnQgZm9yIGJvdGggbXVsdGljYXN0IGFuZCANCiAgdW5pY2FzdCZuYnNwOyBkZWxpdmVy eS48QlI+PEJSPlNvbWUgb2YgdGhlIGtleSBwcm9wZXJ0aWVzIGFuZCBnb2FscyBvZiBSQ0NQIA0K ICBhcmU6PEJSPjxCUj4oMSkgSW5pdGlhdGlvbiBvZiB0aGUgc2Vzc2lvbiBpbmNsdWRpbmcgY29t bXVuaWNhdGlvbiBvZiB0aGUgDQogIHNlc3Npb248QlI+ZGVzY3JpcHRpb24gdG8gY2xpZW50cy48 QlI+KDIpIFNlc3Npb24gbW9uaXRvcmluZyB0byBmYWNpbGl0YXRlIA0KICBzZXJ2ZXIgc2lkZSBh Y2NvdW50aW5nLjxCUj4oMykgU2Vzc2lvbiB0ZWFyZG93biwgZmFjaWxpdGF0aW5nIHNlcnZlciBz aWRlIA0KICBhY2NvdW50aW5nIGFuZCBjb2xsZWN0aW9uIG9mPEJSPmNsaWVudCBzdGF0aXN0aWNz LjxCUj4oNCkgSW5pdGlhdGlvbiBhbmQgaGlnaCANCiAgbGV2ZWwgY29udHJvbCBvZiBkYXRhIHBh Y2tldCByZWNlcHRpb24uPEJSPig1KSBQcmV2ZW50aW9uIG9mIHNvbWUgdHlwZXMgb2YgRG9TIA0K ICBhdHRhY2tzIG9uIHNlcnZlcnMuPEJSPigzKSBUaGUgYWJpbGl0eSB0byBlaXRoZXIgZGlyZWN0 bHkgb3IgYWZ0ZXIgDQogIGNvbmZpZ3VyYXRpb24gYWxsb3cgZGVsaXZlcnkgb2Y8QlI+Y29udGVu dCB0aHJvdWdoIGZpcmV3YWxscy48QlI+PEJSPlRoaXMgDQogIGRvY3VtZW50IGlzIGluIGEgaGln aCBzdGF0ZSBvZiBmbHV4LCB3aWxsIGJlIGdyZWF0bHkgbW9kaWZpZWQgaW4gdGhlPEJSPm5lYXIg DQogIGZ1dHVyZSwgYW5kIGlzIG5vdCBhbiBvZmZpY2lhbCZuYnNwOyBkb2N1bWVudCB3aXRoaW4g dGhlIElFVEYuPEJSPjxCUj5NaWNoYWVsIA0KICBMdWJ5PEJSPkNoaWVmIFRlY2huaWNhbCBPZmZp Y2VyPEJSPkRpZ2l0YWwgRm91bnRhaW4sIEluYy48QlI+MzkxNDEgQ2l2aWMgDQogIENlbnRlciBE cml2ZTxCUj5TdWl0ZSAzMDA8QlI+RnJlbW9udCwgQ0EmbmJzcDsgDQogIDk0NTM4PEJSPjxCUj48 QlI+d3d3LmRpZ2l0YWxmb3VudGFpbi5jb208QlI+bHVieUBkaWdpdGFsZm91bnRhaW4uY29tPEJS Pig1MTApIA0KICAyODQtMTQyMCAocGhvbmUpPEJSPig1MTApIDI4NC0xNDk5IChmYXgpPEJSPig1 MTApIDI4NC0xNDAwIChtYWluKTwvRk9OVD4gDQo8L1A+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hU TUw+DQo= ------=_NextPart_000_0015_01C11C04.71C446A0-- >From owner-rmt@listserv.lbl.gov Thu Aug 2 19:07:55 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7327dZ06398; Thu, 2 Aug 2001 19:07: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 (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327YK06369 for ; Thu, 2 Aug 2001 19:07:35 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327XI25870 for ; Thu, 2 Aug 2001 19:07:33 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327X525865 for ; Thu, 2 Aug 2001 19:07:33 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGYEO00.KCJ for ; Thu, 2 Aug 2001 21:49:36 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5C8000.A08; Fri, 27 Jul 2001 15:16:48 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id OAA10726; Fri, 27 Jul 2001 14:29:51 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA19518 for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 14:15:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13161 for ; Fri, 27 Jul 2001 07:24:51 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07795; Fri, 27 Jul 2001 07:24:47 -0400 (EDT) Message-Id: <200107271124.HAA07795@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-norm-02.txt Date: Fri, 27 Jul 2001 07:24:47 -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 : NACK-Oriented Reliable Multicast Protocol (NORM) Author(s) : B. Adamson, C. Bormann, M. Handley, J. Macker Filename : draft-ietf-rmt-pi-norm-02.txt Pages : 25 Date : 26-Jul-01 This document describes the messages and procedures of the Nega- tive-acknowledgement (NACK) oriented reliable multicast (NORM). This revision of the document represents an initial outline of the protocol description. The document requires refinement in a number of areas to be considered complete. At this time, the document describes the high level details of the reliable multicast bulk transfer service model this protocol hopes to fulfill and the gen- eral message types and mechanisms which will be used to accomplish those goals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-norm-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-pi-norm-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-pi-norm-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: <20010726171135.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-pi-norm-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-pi-norm-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726171135.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Thu Aug 2 19:07:56 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7327gQ06402; Thu, 2 Aug 2001 19:07:42 -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.11.2/8.11.2) with ESMTP id f7327bK06389 for ; Thu, 2 Aug 2001 19:07:37 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327aW25897 for ; Thu, 2 Aug 2001 19:07:36 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327Z525884 for ; Thu, 2 Aug 2001 19:07:35 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGZ3I00.CD5 for ; Thu, 2 Aug 2001 22:04:30 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5SW400.PHN; Fri, 27 Jul 2001 21:16:52 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA25124; Tue, 24 Jul 2001 15:30:17 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA21111 for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 15:15:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12949 for ; Tue, 24 Jul 2001 06:33:28 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06648; Tue, 24 Jul 2001 06:33:26 -0400 (EDT) Message-Id: <200107241033.GAA06648@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-lct-01.txt,.ps Date: Tue, 24 Jul 2001 06:33:26 -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 : Layered Coding Transport: A massively scalable content delivery transport Author(s) : L. Vicisano et al. Filename : draft-ietf-rmt-bb-lct-01.txt,.ps Pages : 27 Date : 23-Jul-01 This document describes Layered Coding Transport, a massively scalable reliable content delivery and stream delivery transport, hereafter referred to as LCT. LCT can be used for multi-rate delivery to large sets of receivers. In LCT, scalability and congestion control are supported through the use of layered coding techniques. Coding techniques can be combined with LCT to provide support for reliability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-lct-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-bb-lct-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-bb-lct-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: <20010723141119.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-lct-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-lct-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723141119.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Thu Aug 2 19:07:56 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7327ff06400; Thu, 2 Aug 2001 19:07: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.11.2/8.11.2) with ESMTP id f7327ZK06372 for ; Thu, 2 Aug 2001 19:07:35 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327YS25877 for ; Thu, 2 Aug 2001 19:07:34 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327X525868 for ; Thu, 2 Aug 2001 19:07:33 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGYYR00.ODF for ; Thu, 2 Aug 2001 22:01:39 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5PS400.DDI; Fri, 27 Jul 2001 20:09:40 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA12374; Wed, 25 Jul 2001 15:19:28 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA03283 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 14:55:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25758 for ; Wed, 25 Jul 2001 06:40:22 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08324; Wed, 25 Jul 2001 06:40:18 -0400 (EDT) Message-Id: <200107251040.GAA08324@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-02.txt Date: Wed, 25 Jul 2001 06:40:18 -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-02.txt Pages : 24 Date : 24-Jul-01 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-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-gra-arch-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-gra-arch-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: <20010724132800.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-gra-arch-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-gra-arch-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132800.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Thu Aug 2 19:07:56 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7327fo06401; Thu, 2 Aug 2001 19:07: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.11.2/8.11.2) with ESMTP id f7327aK06380 for ; Thu, 2 Aug 2001 19:07:36 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327Zo25891 for ; Thu, 2 Aug 2001 19:07:36 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327Y525873 for ; Thu, 2 Aug 2001 19:07:34 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGZ2B00.EE3 for ; Thu, 2 Aug 2001 22:03:47 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5SLG00.LGK; Fri, 27 Jul 2001 21:10:28 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA25580; Tue, 24 Jul 2001 15:42:48 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA21295 for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 15:25:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12956 for ; Tue, 24 Jul 2001 06:33:32 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06660; Tue, 24 Jul 2001 06:33:31 -0400 (EDT) Message-Id: <200107241033.GAA06660@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-03.txt,.ps Date: Tue, 24 Jul 2001 06:33:30 -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 : RMT BB Forward Error Correction Codes Author(s) : L. Vicisano et al. Filename : draft-ietf-rmt-bb-fec-03.txt,.ps Pages : 11 Date : 23-Jul-01 This memo describes the abstract packet formats and IANA registration procedures for use of Forward Error Correction (FEC) codes within the context of reliable IP multicast transport. This memo should be read in conjunction with and uses the terminology of the companion memo [1], which 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-03.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-03.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-03.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: <20010723141128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-fec-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-fec-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723141128.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Thu Aug 2 19:08:05 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7327pm06403; Thu, 2 Aug 2001 19:07:51 -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.11.2/8.11.2) with ESMTP id f7327aK06382 for ; Thu, 2 Aug 2001 19:07:36 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327a225894 for ; Thu, 2 Aug 2001 19:07:36 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327Y525875 for ; Thu, 2 Aug 2001 19:07:34 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGZ3I00.5CQ for ; Thu, 2 Aug 2001 22:04:30 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5SW400.EGI; Fri, 27 Jul 2001 21:16:52 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA24869; Tue, 24 Jul 2001 15:23:52 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA20968 for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 15:05:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12941 for ; Tue, 24 Jul 2001 06:33:23 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06631; Tue, 24 Jul 2001 06:33:21 -0400 (EDT) Message-Id: <200107241033.GAA06631@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-02.txt Date: Tue, 24 Jul 2001 06:33:21 -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 : Asynchronous Layered Coding A scalable reliable multicast protocol Author(s) : L. Vicisano et al. Filename : draft-ietf-rmt-pi-alc-02.txt Pages : 14 Date : 23-Jul-01 This document describes the Asynchronous Layered Coding protocol, a massively scalable reliable content delivery protocol, hereafter referred to as ALC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-alc-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-pi-alc-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-pi-alc-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: <20010723141110.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-pi-alc-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-pi-alc-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723141110.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Thu Aug 2 19:07:55 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7327ex06399; Thu, 2 Aug 2001 19:07:40 -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.11.2/8.11.2) with ESMTP id f7327ZK06376 for ; Thu, 2 Aug 2001 19:07:35 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327YM25880 for ; Thu, 2 Aug 2001 19:07:35 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327X525869 for ; Thu, 2 Aug 2001 19:07:34 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGYEP00.VCT for ; Thu, 2 Aug 2001 21:49:37 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5C8100.V0H; Fri, 27 Jul 2001 15:16:49 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id OAA10507; Fri, 27 Jul 2001 14:24:06 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA19296 for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 14:05:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13151 for ; Fri, 27 Jul 2001 07:22:58 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07713; Fri, 27 Jul 2001 07:22:55 -0400 (EDT) Message-Id: <200107271122.HAA07713@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-norm-bb-02.txt Date: Fri, 27 Jul 2001 07:22: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 : NACK-Oriented Reliable Multicast (NORM) Protocol Building Blocks Author(s) : B. Adamson, C. Bormann, M. Handley, J. Macker Filename : draft-ietf-rmt-norm-bb-02.txt Pages : 41 Date : 26-Jul-01 This memo describes issues related to the creation of negative- acknowledgment (NACK) oriented reliable multicast (NORM) protocols. The general goals and assumptions for NORM are defined. The tech- nical challenges related to NACK-oriented (and in some cases gen- eral) reliable multicast protocol design are identified. These challenges are resolved into a set of applicable 'building blocks' which are described in further detail. It is anticipated that these building blocks (as they are further refined and defined in future revisions of this document) will be useful in generating different instantiations of reliable multicast protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-norm-bb-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-norm-bb-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-norm-bb-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: <20010726171121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-norm-bb-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-norm-bb-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726171121.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Fri Aug 3 01:55:51 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f738tOR14159; Fri, 3 Aug 2001 01:55: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 (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tLK14145 for ; Fri, 3 Aug 2001 01:55:21 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tKV12831 for ; Fri, 3 Aug 2001 01:55:20 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tJ512823 for ; Fri, 3 Aug 2001 01:55:19 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHFDD00.SPI for ; Fri, 3 Aug 2001 03:56:01 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5SLG00.LGK; Fri, 27 Jul 2001 21:10:28 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA25580; Tue, 24 Jul 2001 15:42:48 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA21295 for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 15:25:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12956 for ; Tue, 24 Jul 2001 06:33:32 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06660; Tue, 24 Jul 2001 06:33:31 -0400 (EDT) Message-Id: <200107241033.GAA06660@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-03.txt,.ps Date: Tue, 24 Jul 2001 06:33:30 -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 : RMT BB Forward Error Correction Codes Author(s) : L. Vicisano et al. Filename : draft-ietf-rmt-bb-fec-03.txt,.ps Pages : 11 Date : 23-Jul-01 This memo describes the abstract packet formats and IANA registration procedures for use of Forward Error Correction (FEC) codes within the context of reliable IP multicast transport. This memo should be read in conjunction with and uses the terminology of the companion memo [1], which 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-03.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-03.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-03.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: <20010723141128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-fec-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-fec-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723141128.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Fri Aug 3 01:55:51 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f738tVX14163; Fri, 3 Aug 2001 01:55:31 -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.11.2/8.11.2) with ESMTP id f738tMK14155 for ; Fri, 3 Aug 2001 01:55:29 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tMI12842 for ; Fri, 3 Aug 2001 01:55:22 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tK512833 for ; Fri, 3 Aug 2001 01:55:21 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHFDV00.BRW for ; Fri, 3 Aug 2001 03:56:19 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5SW400.PHN; Fri, 27 Jul 2001 21:16:52 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA25124; Tue, 24 Jul 2001 15:30:17 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA21111 for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 15:15:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12949 for ; Tue, 24 Jul 2001 06:33:28 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06648; Tue, 24 Jul 2001 06:33:26 -0400 (EDT) Message-Id: <200107241033.GAA06648@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-lct-01.txt,.ps Date: Tue, 24 Jul 2001 06:33:26 -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 : Layered Coding Transport: A massively scalable content delivery transport Author(s) : L. Vicisano et al. Filename : draft-ietf-rmt-bb-lct-01.txt,.ps Pages : 27 Date : 23-Jul-01 This document describes Layered Coding Transport, a massively scalable reliable content delivery and stream delivery transport, hereafter referred to as LCT. LCT can be used for multi-rate delivery to large sets of receivers. In LCT, scalability and congestion control are supported through the use of layered coding techniques. Coding techniques can be combined with LCT to provide support for reliability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-lct-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-bb-lct-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-bb-lct-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: <20010723141119.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-lct-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-lct-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723141119.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Fri Aug 3 01:55:52 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f738tK314141; Fri, 3 Aug 2001 01:55:21 -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.11.2/8.11.2) with ESMTP id f738tIK14129 for ; Fri, 3 Aug 2001 01:55:18 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tIs12813 for ; Fri, 3 Aug 2001 01:55:18 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tG512809 for ; Fri, 3 Aug 2001 01:55:17 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHF5200.0QA for ; Fri, 3 Aug 2001 03:51:02 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5C8000.A08; Fri, 27 Jul 2001 15:16:48 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id OAA10726; Fri, 27 Jul 2001 14:29:51 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA19518 for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 14:15:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13161 for ; Fri, 27 Jul 2001 07:24:51 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07795; Fri, 27 Jul 2001 07:24:47 -0400 (EDT) Message-Id: <200107271124.HAA07795@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-norm-02.txt Date: Fri, 27 Jul 2001 07:24:47 -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 : NACK-Oriented Reliable Multicast Protocol (NORM) Author(s) : B. Adamson, C. Bormann, M. Handley, J. Macker Filename : draft-ietf-rmt-pi-norm-02.txt Pages : 25 Date : 26-Jul-01 This document describes the messages and procedures of the Nega- tive-acknowledgement (NACK) oriented reliable multicast (NORM). This revision of the document represents an initial outline of the protocol description. The document requires refinement in a number of areas to be considered complete. At this time, the document describes the high level details of the reliable multicast bulk transfer service model this protocol hopes to fulfill and the gen- eral message types and mechanisms which will be used to accomplish those goals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-norm-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-pi-norm-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-pi-norm-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: <20010726171135.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-pi-norm-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-pi-norm-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726171135.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Fri Aug 3 01:55:52 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f738tO814158; Fri, 3 Aug 2001 01:55: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 (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tLK14148 for ; Fri, 3 Aug 2001 01:55:21 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tLb12837 for ; Fri, 3 Aug 2001 01:55:21 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tK512827 for ; Fri, 3 Aug 2001 01:55:20 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHFDU00.0QF for ; Fri, 3 Aug 2001 03:56:18 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5SW400.EGI; Fri, 27 Jul 2001 21:16:52 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA24869; Tue, 24 Jul 2001 15:23:52 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA20968 for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 15:05:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12941 for ; Tue, 24 Jul 2001 06:33:23 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06631; Tue, 24 Jul 2001 06:33:21 -0400 (EDT) Message-Id: <200107241033.GAA06631@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-02.txt Date: Tue, 24 Jul 2001 06:33:21 -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 : Asynchronous Layered Coding A scalable reliable multicast protocol Author(s) : L. Vicisano et al. Filename : draft-ietf-rmt-pi-alc-02.txt Pages : 14 Date : 23-Jul-01 This document describes the Asynchronous Layered Coding protocol, a massively scalable reliable content delivery protocol, hereafter referred to as ALC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-alc-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-pi-alc-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-pi-alc-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: <20010723141110.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-pi-alc-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-pi-alc-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723141110.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Fri Aug 3 01:55:51 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f738tNQ14157; Fri, 3 Aug 2001 01:55:23 -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.11.2/8.11.2) with ESMTP id f738tKK14139 for ; Fri, 3 Aug 2001 01:55:20 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tJq12825 for ; Fri, 3 Aug 2001 01:55:19 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tI512816 for ; Fri, 3 Aug 2001 01:55:18 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHFCG00.PQL for ; Fri, 3 Aug 2001 03:55:28 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5PS400.DDI; Fri, 27 Jul 2001 20:09:40 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA12374; Wed, 25 Jul 2001 15:19:28 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA03283 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 14:55:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25758 for ; Wed, 25 Jul 2001 06:40:22 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08324; Wed, 25 Jul 2001 06:40:18 -0400 (EDT) Message-Id: <200107251040.GAA08324@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-02.txt Date: Wed, 25 Jul 2001 06:40:18 -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-02.txt Pages : 24 Date : 24-Jul-01 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-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-gra-arch-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-gra-arch-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: <20010724132800.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-gra-arch-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-gra-arch-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132800.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Fri Aug 3 01:55:52 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f738tNW14156; Fri, 3 Aug 2001 01:55:23 -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.11.2/8.11.2) with ESMTP id f738tJK14134 for ; Fri, 3 Aug 2001 01:55:19 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tIW12819 for ; Fri, 3 Aug 2001 01:55:18 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tH512812 for ; Fri, 3 Aug 2001 01:55:17 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHF5U00.AQL for ; Fri, 3 Aug 2001 03:51:30 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5C8100.V0H; Fri, 27 Jul 2001 15:16:49 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id OAA10507; Fri, 27 Jul 2001 14:24:06 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA19296 for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 14:05:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13151 for ; Fri, 27 Jul 2001 07:22:58 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07713; Fri, 27 Jul 2001 07:22:55 -0400 (EDT) Message-Id: <200107271122.HAA07713@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-norm-bb-02.txt Date: Fri, 27 Jul 2001 07:22: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 : NACK-Oriented Reliable Multicast (NORM) Protocol Building Blocks Author(s) : B. Adamson, C. Bormann, M. Handley, J. Macker Filename : draft-ietf-rmt-norm-bb-02.txt Pages : 41 Date : 26-Jul-01 This memo describes issues related to the creation of negative- acknowledgment (NACK) oriented reliable multicast (NORM) protocols. The general goals and assumptions for NORM are defined. The tech- nical challenges related to NACK-oriented (and in some cases gen- eral) reliable multicast protocol design are identified. These challenges are resolved into a set of applicable 'building blocks' which are described in further detail. It is anticipated that these building blocks (as they are further refined and defined in future revisions of this document) will be useful in generating different instantiations of reliable multicast protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-norm-bb-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-norm-bb-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-norm-bb-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: <20010726171121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-norm-bb-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-norm-bb-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726171121.I-D@ietf.org> --OtherAccess-- --NextPart-- >From owner-rmt@listserv.lbl.gov Sun Aug 5 21:41:49 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f764Yli04669; Sun, 5 Aug 2001 21:34: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.11.2/8.11.2) with ESMTP id f764YjK04665 for ; Sun, 5 Aug 2001 21:34:45 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f764YWB23174 for ; Sun, 5 Aug 2001 21:34:32 -0700 (PDT) Received: from ns.live.com (ns.live.com [66.80.62.34]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f764YW523168 for ; Sun, 5 Aug 2001 21:34:32 -0700 (PDT) Received: (from rsf@localhost) by ns.live.com (8.9.3/8.9.3) id VAA86250; Sun, 5 Aug 2001 21:34:22 -0700 (PDT) (envelope-from rsf) Message-Id: <4.3.1.1.20010804234205.00b66990@localhost> X-Sender: rsf@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 05 Aug 2001 00:25:54 -0700 To: "Mike Luby" From: Ross Finlayson Subject: Re: Session control protocol instantiation discussion within the IETF Cc: "Rmt@Lbl. Gov" , confctrl@ISI.EDU In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-rmt@lbl.gov Precedence: bulk At 04:03 PM 8/2/01, Mike Luby wrote: >In the upcoming RMT working group meeting at the IETF there will be a >discussion about whether or not a session control protocol instantiation is: > >(1) within the mandate of the RMT working group > >(2) valuable assuming that the answer to (1) is "yes" > >The following draft is a description of a possible session control protocol. >Note that this draft is not an official submission to the IETF, and its >content will not be reviewed at the IETF meeting. This draft is available >at: > >http://www.digitalfountain.com/getDocument.htm/technology/library/draft-ietf-rmt-mgl-pi-rccp-00-7-11-2001.txt > >This document describes the Rich Content Control Protocol (RCCP), a session >control protocol for client initiated content delivery. The content in >question may be a file, a stream or some other form of content. The RCCP >protocol itself, however, is independent of the type of the content. RCCP >offers support for both multicast and unicast delivery. > >Some of the key properties and goals of RCCP are: > >(1) Initiation of the session including communication of the session >description to clients. >(2) Session monitoring to facilitate server side accounting. >(3) Session teardown, facilitating server side accounting and collection of >client statistics. >(4) Initiation and high level control of data packet reception. >(5) Prevention of some types of DoS attacks on servers. >(3) The ability to either directly or after configuration allow delivery of >content through firewalls. Mike & RMT (cc. MMUSIC), I think such a protocol is needed, but at this point I'm not convinced that it should be a completely new protocol. Instead, we should consider whether such a protocol could be built upon the existing RTSP protocol - the IETF standard control protocol for multimedia (AVT) sessions. RTSP already addresses many of the issues that you outline for your control protocol. While RTSP currently uses SDP - which is probably not rich enough to describe reliable transport sessions - the 'next generation' of SDP (nicknamed "SDPng") will be flexible enough to describe such sessions. Presumably there can also be a "RTSPng" which can make use of "SDPng", as well as having sufficient flexiblity to describe reliable transport sessions. Using RTSP (or "RTSPng") as the control protocol for reliable transport sessions has several benefits over using a completely new protocol: - Some multimedia sessions might include both streaming media (audio and/or video) and reliable data delivery. It would be beneficial to use the same control protocol for all parts of such a session. - Some future RTP payload formats may include reliable (or semi-reliable) delivery for part of its data. (E.g., a RTP payload format for Vorbis audio will likely need to include a reliable delivery mechanism for transporting 'codebooks' to receivers.) Ideally, all of the parameters/attributes for such a session should be described in SDP (or SDPng). - Some client tools may end up being used to receive/display both A/V streams, and reliably-delivered files. It would simplify the implementation of such clients if they could use a single control protocol, rather than using one for A/V streams, and another for reliable data transport. - Ditto for servers - if the same server implementation ends up being used to serve both A/V streams and RMT data. Ross. >From owner-rmt@listserv.lbl.gov Mon Aug 6 15:37:18 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f76MacA04574; Mon, 6 Aug 2001 15:36: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 (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f76MabK04570 for ; Mon, 6 Aug 2001 15:36:37 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f76Maal21082 for ; Mon, 6 Aug 2001 15:36:36 -0700 (PDT) Received: from real.com (prognet.com [205.219.198.1]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f76MaZ521075 for ; Mon, 6 Aug 2001 15:36:35 -0700 (PDT) Received: from goobox.prognet.com ([172.23.105.191]) by real.com (8.9.2/8.9.0) with ESMTP id PAA31755; Mon, 6 Aug 2001 15:36:32 -0700 (PDT) Date: Mon, 6 Aug 2001 15:35:52 -0700 (PDT) From: Rob Lanphier X-Sender: To: Ross Finlayson cc: Mike Luby , "Rmt@Lbl. Gov" , Subject: Re: Session control protocol instantiation discussion within the IETF In-Reply-To: <4.3.1.1.20010804234205.00b66990@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rmt@lbl.gov Precedence: bulk Yeah, what Ross said. It seems like we should be able to sit down this week and figure out how to reformulate this as a proposal to extend RTSP. This is roughly equivalent to the "Backchannel Multicast" feature we use in RealServer (as distinguished from "Scalable Multicast" which doesn't use the RTSP connection, but just serves an SDP file off of the HTTP port) I'm here at the London meeting....let's try to catch up and sketch out an RTSP version that meets your needs. Rob On Sun, 5 Aug 2001, Ross Finlayson wrote: > At 04:03 PM 8/2/01, Mike Luby wrote: > >In the upcoming RMT working group meeting at the IETF there will be a > >discussion about whether or not a session control protocol instantiation is: > > > >(1) within the mandate of the RMT working group > > > >(2) valuable assuming that the answer to (1) is "yes" > > > >The following draft is a description of a possible session control protocol. > >Note that this draft is not an official submission to the IETF, and its > >content will not be reviewed at the IETF meeting. This draft is available > >at: > > > >http://www.digitalfountain.com/getDocument.htm/technology/library/draft-ietf-rmt-mgl-pi-rccp-00-7-11-2001.txt > > > >This document describes the Rich Content Control Protocol (RCCP), a session > >control protocol for client initiated content delivery. The content in > >question may be a file, a stream or some other form of content. The RCCP > >protocol itself, however, is independent of the type of the content. RCCP > >offers support for both multicast and unicast delivery. > > > >Some of the key properties and goals of RCCP are: > > > >(1) Initiation of the session including communication of the session > >description to clients. > >(2) Session monitoring to facilitate server side accounting. > >(3) Session teardown, facilitating server side accounting and collection of > >client statistics. > >(4) Initiation and high level control of data packet reception. > >(5) Prevention of some types of DoS attacks on servers. > >(3) The ability to either directly or after configuration allow delivery of > >content through firewalls. > > Mike & RMT (cc. MMUSIC), > > I think such a protocol is needed, but at this point I'm not convinced that > it should be a completely new protocol. Instead, we should consider > whether such a protocol could be built upon the existing RTSP protocol - > the IETF standard control protocol for multimedia (AVT) sessions. RTSP > already addresses many of the issues that you outline for your control > protocol. While RTSP currently uses SDP - which is probably not rich > enough to describe reliable transport sessions - the 'next generation' of > SDP (nicknamed "SDPng") will be flexible enough to describe such > sessions. Presumably there can also be a "RTSPng" which can make use of > "SDPng", as well as having sufficient flexiblity to describe reliable > transport sessions. > > Using RTSP (or "RTSPng") as the control protocol for reliable transport > sessions has several benefits over using a completely new protocol: > - Some multimedia sessions might include both streaming media (audio and/or > video) and reliable data delivery. It would be beneficial to use the same > control protocol for all parts of such a session. > - Some future RTP payload formats may include reliable (or semi-reliable) > delivery for part of its data. (E.g., a RTP payload format for Vorbis > audio will likely need to include a reliable delivery mechanism for > transporting 'codebooks' to receivers.) Ideally, all of the > parameters/attributes for such a session should be described in SDP (or SDPng). > - Some client tools may end up being used to receive/display both A/V > streams, and reliably-delivered files. It would simplify the > implementation of such clients if they could use a single control protocol, > rather than using one for A/V streams, and another for reliable data transport. > - Ditto for servers - if the same server implementation ends up being used > to serve both A/V streams and RMT data. > > Ross. > >From owner-rmt@listserv.lbl.gov Wed Aug 8 20:46:23 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f793Xs511769; Wed, 8 Aug 2001 20:33:54 -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.11.2/8.11.2) with ESMTP id f793Xq911765 for ; Wed, 8 Aug 2001 20:33:52 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f793Xpg15371 for ; Wed, 8 Aug 2001 20:33:51 -0700 (PDT) Received: from ns2.webfountain.com (mx2.webfountain.com [216.136.183.167]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f793Xn515368 for ; Wed, 8 Aug 2001 20:33:51 -0700 (PDT) Received: (qmail 24362 invoked from network); 9 Aug 2001 03:33:43 -0000 Received: from mail.intranet (10.1.1.37) by ns2.webfountain.com with SMTP; 9 Aug 2001 03:33:43 -0000 Received: from mikedell (pptp-10-1-129-56.intranet [10.1.129.56]) by mail.intranet (8.9.3/8.9.3) with SMTP id UAA27005; Wed, 8 Aug 2001 20:33:37 -0700 X-Authentication-Warning: mail.intranet: Host pptp-10-1-129-56.intranet [10.1.129.56] claimed to be mikedell From: "Michael Luby" To: "Rob Lanphier" , "Ross Finlayson" Cc: "Rmt@Lbl. Gov" , , "Michael Luby" , "Allison Mankin" , Subject: RE: Session control protocol instantiation discussion within the IETF Date: Wed, 8 Aug 2001 20:37:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Sender: owner-rmt@lbl.gov Precedence: bulk All, I unfortunately was only at the IETF for a couple of days, and am back in the Bay Area now. I would first like to talk with the transport area directorate (Scott and Allison) to get some advice on this, and then probably followup with a conference call with whoever is interested. Would a conference call be ok with you Rob, Ross (and whoever else is interested?). Mike -----Original Message----- From: Rob Lanphier [mailto:robla@real.com] Sent: Monday, August 06, 2001 3:36 PM To: Ross Finlayson Cc: Mike Luby; Rmt@Lbl. Gov; confctrl@ISI.EDU Subject: Re: Session control protocol instantiation discussion within the IETF Yeah, what Ross said. It seems like we should be able to sit down this week and figure out how to reformulate this as a proposal to extend RTSP. This is roughly equivalent to the "Backchannel Multicast" feature we use in RealServer (as distinguished from "Scalable Multicast" which doesn't use the RTSP connection, but just serves an SDP file off of the HTTP port) I'm here at the London meeting....let's try to catch up and sketch out an RTSP version that meets your needs. Rob On Sun, 5 Aug 2001, Ross Finlayson wrote: > At 04:03 PM 8/2/01, Mike Luby wrote: > >In the upcoming RMT working group meeting at the IETF there will be a > >discussion about whether or not a session control protocol instantiation is: > > > >(1) within the mandate of the RMT working group > > > >(2) valuable assuming that the answer to (1) is "yes" > > > >The following draft is a description of a possible session control protocol. > >Note that this draft is not an official submission to the IETF, and its > >content will not be reviewed at the IETF meeting. This draft is available > >at: > > > >http://www.digitalfountain.com/getDocume nt.htm/technology/library/draft-ietf-rmt-mgl-pi-rccp-00-7-11-2001.txt > > > >This document describes the Rich Content Control Protocol (RCCP), a session > >control protocol for client initiated content delivery. The content in > >question may be a file, a stream or some other form of content. The RCCP > >protocol itself, however, is independent of the type of the content. RCCP > >offers support for both multicast and unicast delivery. > > > >Some of the key properties and goals of RCCP are: > > > >(1) Initiation of the session including communication of the session > >description to clients. > >(2) Session monitoring to facilitate server side accounting. > >(3) Session teardown, facilitating server side accounting and collection of > >client statistics. > >(4) Initiation and high level control of data packet reception. > >(5) Prevention of some types of DoS attacks on servers. > >(3) The ability to either directly or after configuration allow delivery of > >content through firewalls. > > Mike & RMT (cc. MMUSIC), > > I think such a protocol is needed, but at this point I'm not convinced that > it should be a completely new protocol. Instead, we should consider > whether such a protocol could be built upon the existing RTSP protocol - > the IETF standard control protocol for multimedia (AVT) sessions. RTSP > already addresses many of the issues that you outline for your control > protocol. While RTSP currently uses SDP - which is probably not rich > enough to describe reliable transport sessions - the 'next generation' of > SDP (nicknamed "SDPng") will be flexible enough to describe such > sessions. Presumably there can also be a "RTSPng" which can make use of > "SDPng", as well as having sufficient flexiblity to describe reliable > transport sessions. > > Using RTSP (or "RTSPng") as the control protocol for reliable transport > sessions has several benefits over using a completely new protocol: > - Some multimedia sessions might include both streaming media (audio and/or > video) and reliable data delivery. It would be beneficial to use the same > control protocol for all parts of such a session. > - Some future RTP payload formats may include reliable (or semi-reliable) > delivery for part of its data. (E.g., a RTP payload format for Vorbis > audio will likely need to include a reliable delivery mechanism for > transporting 'codebooks' to receivers.) Ideally, all of the > parameters/attributes for such a session should be described in SDP (or SDPng). > - Some client tools may end up being used to receive/display both A/V > streams, and reliably-delivered files. It would simplify the > implementation of such clients if they could use a single control protocol, > rather than using one for A/V streams, and another for reliable data transport. > - Ditto for servers - if the same server implementation ends up being used > to serve both A/V streams and RMT data. > > Ross. > >From owner-rmt@listserv.lbl.gov Wed Aug 8 20:59:08 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f793nSR11785; Wed, 8 Aug 2001 20:49:28 -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.11.2/8.11.2) with ESMTP id f793nQ911781 for ; Wed, 8 Aug 2001 20:49:26 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f793nPO16821 for ; Wed, 8 Aug 2001 20:49:26 -0700 (PDT) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f793nP516818 for ; Wed, 8 Aug 2001 20:49:25 -0700 (PDT) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.2/8.11.2) with ESMTP id f793nHI04291; Wed, 8 Aug 2001 23:49:18 -0400 Message-Id: <200108090349.f793nHI04291@minotaur.nge.isi.edu> To: "Michael Luby" cc: "Rob Lanphier" , "Ross Finlayson" , "Rmt@Lbl. Gov" , confctrl@ISI.EDU, "Allison Mankin" , sob@harvard.edu Reply-To: mankin@ISI.EDU Subject: Re: Session control protocol instantiation discussion within the IETF In-reply-to: Your message of Wed, 08 Aug 2001 20:37:44 -0700. Date: Wed, 08 Aug 2001 23:49:17 -0400 From: Allison Mankin Sender: owner-rmt@lbl.gov Precedence: bulk Mike, We ADs would be happy to talk with you about this sometime (but after we all recover from IETF). Having had one hallway talk with you while you were in London, I think there is some value to discussing session work (without prejudging if it would extend an existing charter or start up in a new situation of some sort). Mike Luby wrote: > All, > I unfortunately was only at the IETF for a couple of days, and am back in > the Bay Area now. I would first like to talk with the transport area > directorate (Scott and Allison) to get some advice on this, and then > probably followup with a conference call with whoever is interested. Would > a conference call be ok with you Rob, Ross (and whoever else is > interested?). > Mike > >From owner-rmt@listserv.lbl.gov Wed Aug 15 08:39:00 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7FFXbD28811; Wed, 15 Aug 2001 08:33:37 -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.11.2/8.11.2) with ESMTP id f7FFXZZ28807 for ; Wed, 15 Aug 2001 08:33:36 -0700 (PDT) Received: from localhost (root@localhost) by postal1.lbl.gov (8.11.2/8.11.2) with SMTP id f7FFXZM09335 for ; Wed, 15 Aug 2001 08:33:35 -0700 (PDT) Date: Wed, 15 Aug 2001 08:33:35 -0700 (PDT) Message-Id: <200108151533.f7FFXZM09335@postal1.lbl.gov> From: VirusWall@lbl.gov To: rmt@listserv.lbl.gov Subject: Virus Alert Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk This is an automated message from the LBNL VirusWall. The mail message you recently received from: autow@wshlab2.ee.kuas.edu.tw which included the file: javacomm20-win32.zip.lnk contained the virus: TROJ_SIRCAM.A. PLEASE NOTE: 1. The virus has been REMOVED from the email message by the LBNL VirusWall and will NOT INFECT your computer. 2. It is SAFE to read the message and open the attachment, though you should always use caution when opening attachments from people you do not know. 3. You do not need to notify anyone that you received this message. For more information take a look at our virus protection web page: http://www.lbl.gov/ITSD/Security/resources/ If you have any questions, please contact the LBNL Help Desk at http://www.lbl.gov/help/, or 510-486-4357. Thanks, The VirusWall Lawrence Berkeley National Laboratory >From owner-rmt@listserv.lbl.gov Wed Aug 15 08:39:00 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7FFXXX28805; Wed, 15 Aug 2001 08:33:33 -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.11.2/8.11.2) with ESMTP id f7FFXWZ28801 for ; Wed, 15 Aug 2001 08:33:32 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7FFXUN09281 for ; Wed, 15 Aug 2001 08:33:30 -0700 (PDT) Received: from wshlab2.ee.kuas.edu.tw (wshlab2.ee.nkit.edu.tw [140.127.114.233]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7FFUR508077 for ; Wed, 15 Aug 2001 08:30:28 -0700 (PDT) Received: from wshstd.ee.kuas.edu.tw (unknown [140.127.114.234]) by wshlab2.ee.kuas.edu.tw (Postfix) with SMTP id 9B0D223686 for ; Wed, 15 Aug 2001 23:32:33 +0800 (CST) From: "=?ISO-8859-1?Q?=C4=A3=B0=F3?=" To: rmt@lbl.gov Subject: javacomm20-win32 date: Wed, 15 Aug 2001 23:47:53 +0800 MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-Type: multipart/mixed; boundary="----5E983576_Outlook_Express_message_boundary" Content-Disposition: Multipart message Message-Id: <20010815153233.9B0D223686@wshlab2.ee.kuas.edu.tw> Sender: owner-rmt@lbl.gov Precedence: bulk ------5E983576_Outlook_Express_message_boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) Found virus TROJ_SIRCAM.A in file javacomm20-win32.zip.lnk The file e/iscan/virus/virACBn6aaYn is moved to the configured virus directory. ********************************************************* ------5E983576_Outlook_Express_message_boundary Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: message text Hi! How are you=3F I send you this file in order to have your advice See you later=2E Thanks ------5E983576_Outlook_Express_message_boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) javacomm20-win32.zip.lnk is removed from here because it contains a virus. ********************************************************* ------5E983576_Outlook_Express_message_boundary ------5E983576_Outlook_Express_message_boundary-- >From owner-rmt@listserv.lbl.gov Wed Aug 15 18:03:27 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7G0xbV02594; Wed, 15 Aug 2001 17:59:37 -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.11.2/8.11.2) with ESMTP id f7G0xaZ02590 for ; Wed, 15 Aug 2001 17:59:36 -0700 (PDT) Received: from localhost (root@localhost) by postal1.lbl.gov (8.11.2/8.11.2) with SMTP id f7G0xaw10901 for ; Wed, 15 Aug 2001 17:59:36 -0700 (PDT) Date: Wed, 15 Aug 2001 17:59:36 -0700 (PDT) Message-Id: <200108160059.f7G0xaw10901@postal1.lbl.gov> From: VirusWall@lbl.gov To: rmt@listserv.lbl.gov Subject: Virus Alert Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk This is an automated message from the LBNL VirusWall. The mail message you recently received from: autow@wshlab2.ee.kuas.edu.tw which included the file: javacomm20-win32.zip.pif contained the virus: TROJ_SIRCAM.A. PLEASE NOTE: 1. The virus has been REMOVED from the email message by the LBNL VirusWall and will NOT INFECT your computer. 2. It is SAFE to read the message and open the attachment, though you should always use caution when opening attachments from people you do not know. 3. You do not need to notify anyone that you received this message. For more information take a look at our virus protection web page: http://www.lbl.gov/ITSD/Security/resources/ If you have any questions, please contact the LBNL Help Desk at http://www.lbl.gov/help/, or 510-486-4357. Thanks, The VirusWall Lawrence Berkeley National Laboratory >From owner-rmt@listserv.lbl.gov Wed Aug 15 18:03:27 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7G0xUq02588; Wed, 15 Aug 2001 17:59: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.11.2/8.11.2) with ESMTP id f7G0xTZ02584 for ; Wed, 15 Aug 2001 17:59:29 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7G0xRn10875 for ; Wed, 15 Aug 2001 17:59:27 -0700 (PDT) Received: from wshlab2.ee.kuas.edu.tw ([140.127.114.233]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7G0wO510565 for ; Wed, 15 Aug 2001 17:58:27 -0700 (PDT) Received: from wshstd.ee.kuas.edu.tw (unknown [140.127.114.234]) by wshlab2.ee.kuas.edu.tw (Postfix) with SMTP id 5B16C236A1 for ; Thu, 16 Aug 2001 09:00:43 +0800 (CST) From: "=?ISO-8859-1?Q?=C4=A3=B0=F3?=" To: rmt@lbl.gov Subject: javacomm20-win32 date: Thu, 16 Aug 2001 09:16:02 +0800 MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-Type: multipart/mixed; boundary="----2C762821_Outlook_Express_message_boundary" Content-Disposition: Multipart message Message-Id: <20010816010043.5B16C236A1@wshlab2.ee.kuas.edu.tw> Sender: owner-rmt@lbl.gov Precedence: bulk ------2C762821_Outlook_Express_message_boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) Found virus TROJ_SIRCAM.A in file javacomm20-win32.zip.pif The file e/iscan/virus/virPUB.pbWjr is moved to the configured virus directory. ********************************************************* ------2C762821_Outlook_Express_message_boundary Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: message text Hi! How are you=3F I send you this file in order to have your advice See you later=2E Thanks ------2C762821_Outlook_Express_message_boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) javacomm20-win32.zip.pif is removed from here because it contains a virus. ********************************************************* ------2C762821_Outlook_Express_message_boundary ------2C762821_Outlook_Express_message_boundary-- >From owner-rmt@listserv.lbl.gov Fri Aug 17 10:56:09 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7HHqax22587; Fri, 17 Aug 2001 10:52: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 (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7HHqZV22583 for ; Fri, 17 Aug 2001 10:52:35 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7HHqYT03412 for ; Fri, 17 Aug 2001 10:52:34 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7HHqY503408 for ; Fri, 17 Aug 2001 10:52:34 -0700 (PDT) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7HHqiT22598 for ; Fri, 17 Aug 2001 10:52:44 -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 KAA19204 for ; Fri, 17 Aug 2001 10:52:28 -0700 (PDT) Message-Id: <200108171752.KAA19204@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI] To: rmt@lbl.gov Subject: Presentations and Minutes submissions for the 51st IETF (fwd) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Aug 2001 10:52:28 -0700 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk For all presenters at the last RMT meeting in London, please submit you presentation material to minutes@ietf.org, if you have not already done so. thank you, Lorenzo Vicisano ------- Forwarded Message Message-ID: <3B7D3CB8.576A3196@ietf.org> Date: Fri, 17 Aug 2001 11:48:09 -0400 From: IETF Proceedings Coordinator MIME-Version: 1.0 To: wgchairs@ietf.org, bofchairs@ietf.org CC: scoya@ietf.org Subject: Presentations and Minutes submissions for the 51st IETF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, This is a reminder to all group chairs and presenters to submit your visual materials and meeting minutes. Any materials from interim meetings should be noted as such. No intermediate drafts of meeting minutes should be submitted, only final drafts. Slide presentations must be provided in one of the following formats: .html / .htm HTML .pdf Adobe Portable Document Format .ps Postscript 1, 2 .ppt Microsoft PowerPoint (95-2000) .txt Dos/Mac/Unix Text Meeting minutes must be provided as plain text (Dos/Mac/or Unix) Meeting agendas may be provided within a presentation or in the minutes. All submitted material is now available at the following location: http://www.ietf.org/proceedings/01aug/index.html To submit materials, please email them to minutes@ietf.org. It will take approximately 2-3 days for newly submitted materials to post. Thank you, Proceedings Coordinator ------- End of Forwarded Message >From owner-rmt@listserv.lbl.gov Sat Aug 18 14:06:51 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7IL0FL10039; Sat, 18 Aug 2001 14:00:15 -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.11.2/8.11.2) with ESMTP id f7IL0EV10006 for ; Sat, 18 Aug 2001 14:00:14 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7IL0DK23277 for ; Sat, 18 Aug 2001 14:00:13 -0700 (PDT) Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1.email.verio.net [129.250.36.41]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7IL0C523274 for ; Sat, 18 Aug 2001 14:00:12 -0700 (PDT) Received: from [129.250.38.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout1.email.verio.net with esmtp id 15YDCQ-0006xq-00; Sat, 18 Aug 2001 21:00:06 +0000 Received: from [63.184.75.187] (helo=localhost) by dfw-mmp3.email.verio.net with esmtp id 15YDCG-0002bW-00; Sat, 18 Aug 2001 20:59:56 +0000 X-Sender: robertlong@veriomail.com From: Bob Long To: "Mortgage Rate Info" Date: Sat, 18 Aug 2001 14:06:04 -0700 Subject: Need a Home Loan? We Can Help!! Reply-To: robertlong@veriomail.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__28034840_50764.44" Message-Id: Sender: owner-rmt@lbl.gov Precedence: bulk This is a Multipart MIME message. ------=_NextPart_000_001__28034840_50764.44 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_000_001__28034840_50764.44 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 DQoNCjxIVE1MPg0KDQo8aGVhZD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIg Q09OVEVOVD0idGV4dC9odG1sO2NoYXJzZXQ9aXNvLTg4NTktMSI+DQo8IURPQ1RZUEUgSFRN TCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgNC4wIFRyYW5zaXRpb25hbC8vRU4iPg0KPFRJ VExFPkZyZWUgUmF0ZSBRdW90ZTwvVElUTEU+DQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7 IGNoYXJzZXQ9aXNvLTg4NTktMSIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+PFhNRVRBIA0K Y29udGVudD0iTW96aWxsYS80LjcgW2VuXSAoV2luOTg7IEkpIFtOZXRzY2FwZV0iIG5hbWU9 IkdFTkVSQVRPUiI+DQo8TUVUQSBjb250ZW50PSJNaWNyb3NvZnQgRnJvbnRQYWdlIDQuMCIg bmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIGJhY2tn cm91bmQ9aHR0cDovLzIxNy42Ny4yMzAuMTUvbW9uZXlfZ3IuanBnIGJnQ29sb3I9I2ZmZmZm ZiBiZ3Byb3BlcnRpZXM9ImZpeGVkIj4NCjxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwi Pg0KPERJVj4mbmJzcDs8L0RJVj48L0RJVj4NCjxESVY+PEJSPjwvRElWPg0KPFAgYWxpZ249 Y2VudGVyPjxlbT48Yj48Zm9udCBjb2xvcj0iI2ZmMDAwMCIgc2l6ZT0iNiI+JnF1b3Q7UmVm aW5hbmNpbmcgWW91cg0KQ3VycmVudCBNb3J0Z2FnZSBNYWtlcyAkZW5zZSEmcXVvdDs8L2Zv bnQ+PC9iPjwvZW0+PC9QPg0KPHAgYWxpZ249ImNlbnRlciI+PGI+PGZvbnQgc2l6ZT0iNCI+ TW9ydGdhZ2UgUmF0ZXMgQXJlIFNvIExvdyEmbmJzcDs8L2ZvbnQ+PC9iPjwvcD4NCjxwIGFs aWduPSJjZW50ZXIiPjxiPjxmb250IHNpemU9IjQiPllvdSBDYW4gU2F2ZSBUaG91c2FuZHMg T2YgRG9sbGFycyBCeSBUYWtpbmcNCkFkdmFudGFnZSBOb3chPC9mb250PjwvYj48L3A+DQo8 UCBhbGlnbj1jZW50ZXI+PEVNPjxCPjxGT05UIGNvbG9yPSNmZjAwMDAgc2l6ZT01PiZxdW90 O1dFIEFSRSBBTiBBU1NPQ0lBVElPTiBPRg0KTU9SVEdBR0UgQlJPS0VSUyBBTkQgTEVOREVS UyA8L0ZPTlQ+PC9CPjwvRU0+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxFTT48Qj48Rk9OVCBj b2xvcj0jZmYwMDAwIHNpemU9NT5XSVRIIFRIRSBCRVNUIFJBVEVTIEFORCBUSEUgTE9XRVNU DQpDT1NUUyEmcXVvdDwvRk9OVD48L0I+PC9FTT48L1A+DQo8cCBhbGlnbj0iY2VudGVyIj4m bmJzcDs8L3A+DQo8UCBhbGlnbj1jZW50ZXI+PEZPTlQgY29sb3I9IzAwMDBmZiBzaXplPTQ+ PEI+V2UmbmJzcDtoYXZlIHRob3VzYW5kcyBvZiBsb2FuIA0KcHJvZ3JhbXMgdGhyb3VnaCBo dW5kcmVkcyBvZiBsZW5kZXJzITxCUj48L0I+PC9GT05UPjxGT05UIHNpemU9Mz48L0ZPTlQ+ PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxTVFJPTkc+PEZPTlQgc2l6ZT01PllvdSBjYW4gY2hv b3NlIGZyb20mbmJzcDsiQWRqdXN0YWJsZSBSYXRlDQpNb3J0Z2FnZXMgDQphcyBsb3cgYXMg My45NSUmcXVvdDs8L0ZPTlQ+PC9TVFJPTkc+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxTVFJP Tkc+PEZPTlQgc2l6ZT01PmFuZCZuYnNwOyJGaXhlZCBSYXRlIE1vcnRnYWdlcyBhcyBsb3cg YXMNCjYuNTAlJm5ic3A7PC9GT05UPjwvU1RST05HPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48 U1RST05HPjxGT05UIHNpemU9NT5hbGwgd2l0aCB0aGUgbG93ZXN0IGNvc3RzIGluIHRoZQ0K TmF0aW9uISZxdW90OzwvRk9OVD48L1NUUk9ORz48QklHPjxCSUc+PEZPTlQgY29sb3I9I2Zm MDAwMD4qPC9GT05UPjwvQklHPjwvQklHPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48Rk9OVCAN CnNpemU9NT48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+JnF1b3Q7PGI+PGk+WU9VIENBTiA8dT5C VVkgRE9XTiBZT1VSIElOVEVSRVNUIFJBVEU8L3U+DQpUTzwvaT48L2I+PC9mb250PjwvRk9O VD48L1A+DQo8UCBhbGlnbj1jZW50ZXI+PGZvbnQgY29sb3I9IiNGRjAwMDAiIHNpemU9IjUi PjxiPjxpPkFTIExPVyBBUyBZT1UgQ0FODQpBRkZPUkQhJnF1b3Q7PC9pPjwvYj48L2ZvbnQ+ PEZPTlQgDQpzaXplPTU+PEJSPjwvRk9OVD48Rk9OVCBzaXplPTM+PC9GT05UPjwvUD4NCjxQ IGFsaWduPWNlbnRlcj48Rk9OVCBzaXplPSswPjxGT05UIGNvbG9yPSMwMDAwZmYgc2l6ZT0y PjxCSUc+PEJJRz48Rk9OVCANCmNvbG9yPSNmZjAwMDAgc2l6ZT01Pio8L0ZPTlQ+PC9CSUc+ PFNUUk9ORz5BbGwgcmF0ZXMgYXJlIGJhc2VkIG9uIA0KcXVhbGlmaWNhdGlvbjwvU1RST05H PiE8L0JJRz48L0ZPTlQ+PC9GT05UPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48Rk9OVCBzaXpl PSswPjxGT05UIHNpemU9Mj48QklHPjwvQklHPjwvRk9OVD48Rk9OVCANCmNvbG9yPSMwMDAw ZmY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PEEgaHJlZj0iaHR0cDovLzIxNy42 Ny4yMzAuMTUiIA0KdGFyZ2V0PV9ibGFuaz48Rk9OVCBzaXplPTU+PFNUUk9ORz48Rk9OVCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPkNsaWNrIGhlcmUgZm9yIA0KeW91ciA8L0ZPTlQ+PEZP TlQgc2l6ZT02PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PEVNPiJGUkVFIFJBVEUg DQpRVU9URSIhPC9FTT48L0ZPTlQ+PC9GT05UPjwvU1RST05HPjwvRk9OVD48L0E+PC9GT05U PjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvUD4NCjxQIGFsaWduPWxlZnQ+Jm5ic3A7PC9QPg0K PFAgYWxpZ249bGVmdD48aT48Yj48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iKzAiPkNMSUNL IE9OIExPQU5TIEJFTE9XIEZPUiBZT1VSDQpGUkVFIEFQUExJQ0FUSU9OITwvZm9udD48L2I+ PC9pPjxGT05UIGZhY2U9QXJpYWw+PEJSPjwvRk9OVD48L1A+DQo8UCBhbGlnbj1sZWZ0PjxT VFJPTkc+PEVNPjxBIGhyZWY9Imh0dHA6Ly8yMTcuNjcuMjMwLjE1IiANCnRhcmdldD1fYmxh bms+PGZvbnQgc2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPlB1cmNoYXNlIExvYW5zPC9mb250 PjwvQT4gPEZPTlQgc2l6ZT01Pg0KPC9GT05UPiA8L0VNPjxGT05UIA0Kc2l6ZT00Pi0gPEVN PlRob3VzYW5kcyBvZiBwcm9ncmFtcyANCmZvciBGaXJzdCBNb3J0Z2FnZXMhPC9FTT48L0ZP TlQ+PEk+PC9JPjwvU1RST05HPjxJPjxGT05UIA0KY29sb3I9IzAwMDAwMD48QlI+PEJSPjwv Rk9OVD48L0k+PEEgaHJlZj0iaHR0cDovLzIxNy42Ny4yMzAuMTUiIF9ibGFuaz8+PEVNPjxT VFJPTkc+PGZvbnQgc2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPlJlZmluYW5jZSBMb2Fuczwv Zm9udD48L1NUUk9ORz48L0VNPjxJPjxGT05UIA0KY29sb3I9IzAwMDAwMCBzaXplPTI+IDwv Rk9OVD48L0k+PC9BPjxJPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT00Pi0gPEI+UmVkdWNl IHlvdXIgDQptb250aGx5IHBheW1lbnRzIGFuZDwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMDAw IHNpemU9Mj4gPC9GT05UPjxGT05UIA0KY29sb3I9I2ZmMDAwMCBzaXplPTU+R2V0IENhc2gg QmFjayE8L0ZPTlQ+PC9CPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT00PiANCjwvRk9OVD48 Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mz48QlI+PEJSPjwvRk9OVD48L0k+PEEgDQpocmVm PSJodHRwOi8vMjE3LjY3LjIzMC4xNSIgdGFyZ2V0PV9ibGFuaz48Zm9udCBjb2xvcj0iIzgw MDA4MCI+PEVNPjxCPjxGT05UIHNpemU9NT5TZWNvbmQgDQpNb3J0Z2FnZXM8L0ZPTlQ+PC9C PjwvRU0+PEk+PEZPTlQgc2l6ZT0zPiA8L0ZPTlQ+PC9JPg0KPC9mb250PiA8L0E+PEk+PEZP TlQgY29sb3I9IzAwMDAwMCBzaXplPTM+IC0gPC9GT05UPjxCPjxGT05UIA0KY29sb3I9IzAw MDAwMCBzaXplPTQ+V2UgY2FuIGhlbHAgeW91IGdldCBmcm9tIDwvRk9OVD48Rk9OVCBjb2xv cj0jZmYwMDAwIA0Kc2l6ZT01PjkwJTwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9 ND4gdXAgdG8gPC9GT05UPjxGT05UIGNvbG9yPSNmZjAwMDAgDQpzaXplPTU+MTI1JTwvRk9O VD48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9ND4gb2YgeW91ciBob21lcyB2YWx1ZSEgKHJh dGlvcyB2YXJ5IA0KYnkgc3RhdGUpPC9GT05UPjwvQj48L1A+DQo8UCBhbGlnbj1sZWZ0PjxB IGhyZWY9Imh0dHA6Ly8yMTcuNjcuMjMwLjE1IiANCnRhcmdldD1fYmxhbms+PEI+PGZvbnQg c2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPkRlYnQgQ29uc29saWRhdGlvbjwvZm9udD48L0I+ PC9BPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0zPiA8Rk9OVCBjb2xvcj0jMDAwMDAwIHNp emU9ND4tIA0KPEI+Q29tYmluZSA8L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmMDAwMCBzaXplPTU+ YWxsPC9GT05UPjxGT05UIGNvbG9yPSMwMDAwMDAgDQpzaXplPTQ+IHlvdXIgYmlsbHMgaW50 byA8L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmMDAwMCBzaXplPTU+T25lIExvdyBNb250aGx5IA0K UGF5bWVudCE8L0ZPTlQ+PC9CPjxCUj48QlI+PC9GT05UPjxCPjxBIA0KaHJlZj0iaHR0cDov LzIxNy42Ny4yMzAuMTUiIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0iNSIgY29sb3I9IiM4 MDAwODAiPkZpcnN0IFRpbWUgSG9tZSBCdXllcnM8L2ZvbnQ+PC9BPjxGT05UIGNvbG9yPSMw MDAwMDAgc2l6ZT0zPiAtIA0KPEZPTlQgY29sb3I9IzAwMDAwMCBzaXplPTQ+V2UgY2FuIGhl bHAgeW91IGJ1eSB3aXRoIDxGT05UIGNvbG9yPSNmZjAwMDAgDQpzaXplPTU+TG93PC9GT05U PjwvRk9OVD48Rk9OVCBjb2xvcj0jZmYwMDAwIHNpemU9NT4gTW9uZXkgRG93bjwvRk9OVD48 Rk9OVCANCmNvbG9yPSMwMDAwMDAgc2l6ZT00PiwgYW5kIGV2ZW4gPC9GT05UPjxGT05UIGNv bG9yPSNmZjAwMDAgc2l6ZT01PkdldCBDYXNoIA0KQmFjayE8L0ZPTlQ+PC9GT05UPjwvQj48 L1A+PC9JPg0KPFAgYWxpZ249Y2VudGVyPjxCSUc+PEJJRz48Rk9OVCBjb2xvcj0jZmYwMDAw Pio8L0ZPTlQ+PC9CSUc+QWxsIHJhdGVzIGFyZSBiYXNlZCANCm9uIHF1YWxpZmljYXRpb24h PC9CSUc+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxCPjxJPjxGT05UIGNvbG9yPSMwMDAwMDAg c2l6ZT02PldlIGhhdmUgcHJvZ3JhbXMgZm9yIA0KPC9GT05UPjxGT05UIGNvbG9yPSNmZjAw MDAgc2l6ZT02PjxVPkVWRVJZPC9VPjwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9 Nj4gDQpjcmVkaXQgc2l0dWF0aW9uITwvRk9OVD48QlI+PEJSPjxBIGhyZWY9Imh0dHA6Ly8y MTcuNjcuMjMwLjE1IiB0YXJnZXQ9X2JsYW5rPjxGT05UIA0KY29sb3I9IzAwMDBmZiBzaXpl PTU+Q2xpY2sgaGVyZSBmb3IgeW91ciBGUkVFIFJBVEUgUVVPVEUhPC9GT05UPjwvQT48L0k+ PC9CPjwvUD4NCjxQIGFsaWduPWxlZnQ+PEZPTlQgY29sb3I9IzAwODAwMD48U1RST05HPiAN CklmIHlvdSBmZWVsIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVy cm9yLCBwbGVhc2UgZm9sbG93IHRoZSBiZWxvdyANCmluc3RydWN0aW9ucyBhbmQgeW91IHdp bGwgYmUgcmVtb3ZlZCBpbW1lZGlhdGVseS4gIFdlIGltbWVkaWF0ZWx5IGhvbm9yIGFsbCBy ZXF1ZXN0cyANCnRvIGJlIHJlbW92ZWQgZnJvbSB0aGlzIGxpc3QuIFRoaXMgbWVzc2FnZSBp cyBiZWluZyBzZW50IHRvIHlvdSBpbiBjb21wbGlhbmNlIHdpdGggDQp0aGUgRmVkZXJhbCBs ZWdpc2xhdGlvbiBmb3IgY29tbWVyY2lhbCBlLW1haWwgKEguUi40MTc2IC0gU2VjdGlvbiAx MDEsICBQYXJhZ3JhcGggDQooZSkoMSkoYSkpIGFuZCBCaWxsIHMuMTYxOCBUaXRsZSBJSUkg cGFzc2VkIGJ5IHRoZSAxMDV0aCBVUyBDb25ncmVzcy4sIGZ1cnRoZXIgDQp0cmFuc21pc3Np b25zIHRvIHlvdSBieSB0aGUgc2VuZGVyIG9mIHRoaXMgZS1tYWlsIG1heSBiZSBzdG9wcGVk IGF0IG5vIGNvc3QgdG8geW91IA0KYnkgc3VibWl0dGluZyBhIHJlcXVlc3QgdG8gYmUgcmVt b3ZlZC4gPGEgaHJlZj0ibWFpbHRvOmdyZWF0cmF0ZXMxMDhAZXhjaXRlLmNvbT9zdWJqZWN0 PVBMRUFTRV9SRU1PVkVfTUUhX1ZSTzEiPkNsaWNrIEhlcmUgdG8gU2VuZCBhIFJlbW92ZSBS ZXF1ZXN0PC9hPi4NCk5vIG5lZWQgdG8gdHlwZSBhbnkgbWVzc2FnZS48L1NUUk9ORz48L0ZP TlQ+PC9QPjwvQk9EWT48L0hUTUw+ ------=_NextPart_000_001__28034840_50764.44-- >From owner-rmt@listserv.lbl.gov Tue Aug 21 04:16:00 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7LBCat23526; Tue, 21 Aug 2001 04:12: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 (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LBCZV23522 for ; Tue, 21 Aug 2001 04:12:35 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LBCZ929506 for ; Tue, 21 Aug 2001 04:12:35 -0700 (PDT) Received: from rafi ([213.8.76.34]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LBCW529495 for ; Tue, 21 Aug 2001 04:12:33 -0700 (PDT) Received: from mail pickup service by rafi with Microsoft SMTPSVC; Tue, 21 Aug 2001 14:12:31 +0200 From: To: Subject: Instant Messaging platform at your Web site is now a few clicks away Date: Tue, 21 Aug 2001 14:12:31 +0200 Message-ID: <125701c12a3a$8dacb3e0$0200a8c0@rafi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft CDO for Windows 2000 Thread-Index: AcEqOo2srhYARx8QRVKpv6ZqyPGCRg== Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 21 Aug 2001 12:12:31.0706 (UTC) FILETIME=[8DB5DBA0:01C12A3A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by SpamWall.lbl.gov id f7LBCZV23523 Sender: owner-rmt@lbl.gov Precedence: bulk Instant Messaging platform at your Web site is now a few clicks away ---------------------------------------------------------------------- Install a FREE Instant Messaging server at your Web site. Use it as is or customize to meet your specific branding. Cross platform servers line support 25 and up to 1000 concurrent users All servers offered can be secured with RSA 512Bit (and higher) encryption!! Download free 10 concurrent users server at: http://www.seebex.com/download/get_server.asp It is easier, faster and affordable than ever!! For further information please check seebex Web site at: http://www.seebex.com or contact our Marketing & Sales department at sales@seebex.com First 50 Web sites to download and embed the free 10 concurrent users server are entitled to a free 100 concurrent users server and will be listed on Seebex Web site. >From owner-rmt@listserv.lbl.gov Tue Aug 21 12:47:42 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7LJdOP07751; Tue, 21 Aug 2001 12:39: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 (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LJdMV07747 for ; Tue, 21 Aug 2001 12:39:22 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LJdKo24089 for ; Tue, 21 Aug 2001 12:39:20 -0700 (PDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LJdA524036 for ; Tue, 21 Aug 2001 12:39:10 -0700 (PDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7LJdCi13190 for ; Tue, 21 Aug 2001 14:39:13 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Aug 2001 14:39:07 -0500 content-class: urn:content-classes:message Subject: RE: Session control protocol instantiation discussion within the IETF Date: Tue, 21 Aug 2001 14:38:31 -0500 Message-ID: X-MS-Has-Attach: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C12A78.DBC2BFA0" X-MS-TNEF-Correlator: Thread-Topic: Session control protocol instantiation discussion within the IETF Thread-Index: AcEghmN7vo7KnYxsEdWrxAAIx6S5QwJ763Vg X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 From: "Trossen Dirk (NRC/Boston)" To: , "Michael Luby" Cc: "Rob Lanphier" , "Ross Finlayson" , "Rmt@Lbl. Gov" , , , "ietf-floor control" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C12A78.DBC2BFA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, as announced on the MMUSIC mailing list, a couple of people being interested in conference course control met on Wednesday August 8th (10-11pm) during the London IETF meeting to discuss=20 further steps in this direction. The following persons were present during this informal meeting: Jun-Won Lee, Shin-Gak Kang, Jonathan Rosenberg, Eunsook Kim, Colin Perkins, Joerg Ott, Dirk Kutscher, Dirk Trossen During the meeting, a general interest in this topic was expressed by the attendents. However, the concern was raised (by Jonathan, Joerg, and Colin) that the scope of the work has to be defined very carefully. Especially Jonathan expressed interest in 'doable' solutions, i.e., covering rather simple centralized conferencing scenarios first rather than defining a wide scope of the work. The following steps have been proposed to be undertaken in this direction: - provision of a problem statement document - submission to mailing list(s) - creation of own discussion list for this topic The problem statement document should be created by a circle of people being interested in this topic and willing to contribute to this work.=20 The discussion of the problem statement should end in a decision how to bring this topic to the IETF within the therein defined scope, either within the charter of existing WGs or by organizing a BOF. Since similar discussions about future session control efforts=20 have been undertaken within the RMT WG, I'm sending this mail=20 also to this list to invite interested people to join the discussion. Enclosed you find the current document which was meant as a=20 problem statement for conference course control. This document is far from being completed (it was not submitted as a draft although it is written in Internet draft style) but it is intended as a basis for discussion to reach final document status. Any comments are welcome. Best Regards, Dirk Trossen ----------------------- Dirk Trossen Nokia Research Center 5 Wayside Road Burlington, MA 01803 Tel: +1 (781) 993 3605 Fax: +1 (781) 993 1907 mob: +1 (617) 794 7041 ----------------------- > -----Original Message----- > From: ext Allison Mankin [mailto:mankin@ISI.EDU] > Sent: Wednesday, August 08, 2001 11:49 PM > To: Michael Luby > Cc: Rob Lanphier; Ross Finlayson; Rmt@Lbl. Gov; confctrl@ISI.EDU; > Allison Mankin; sob@harvard.edu > Subject: Re: Session control protocol instantiation discussion within > the IETF=20 >=20 >=20 > Mike, >=20 > We ADs would be happy to talk with you about this sometime (but after=20 > we all recover from IETF). =20 >=20 > Having had one hallway talk with you while you were in London, > I think there is some value to discussing session work (without > prejudging if it would extend an existing charter or start up in > a new situation of some sort). >=20 > Mike Luby wrote: > > All, > > I unfortunately was only at the IETF for a couple of days,=20 > and am back in > > the Bay Area now. I would first like to talk with the=20 > transport area > > directorate (Scott and Allison) to get some advice on this, and then > > probably followup with a conference call with whoever is=20 > interested. Would > > a conference call be ok with you Rob, Ross (and whoever else is > > interested?). > > Mike > >=20 >=20 ------_=_NextPart_001_01C12A78.DBC2BFA0 Content-Type: text/plain; name="draft-trossen-problem-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-trossen-problem-00.txt Content-Disposition: attachment; filename="draft-trossen-problem-00.txt" DQpJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlICAgICAgICAgICAgICAgICAgRC4gVHJv c3NlbiAoRWRpdG9yKSANCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIE5va2lhIFJlc2VhcmNoIA0KZHJhZnQtdHJvc3Nlbi1wcm9ibGVtLTAwLnR4 dCAgICAgICAgICAgICAgICAgICAgICAgICAgICAxMS4gTWF5IDIwMDEgDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlczogTm92ZW1iZXIgMjAwMSAN CiANCiANCiAgICAgICAgICAgICAgICBDb25mZXJlbmNlIENvdXJzZSBDb250cm9sIFByb2JsZW0g U3RhdGVtZW50IA0KIA0KIA0KU3RhdHVzIG9mIHRoaXMgTWVtbyANCiANCiAgIFRoaXMgZG9jdW1l bnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2UgDQogICB3 aXRoIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4gDQogICAgDQogICAg DQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5l dCBFbmdpbmVlcmluZyANCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMg d29ya2luZyBncm91cHMuICBOb3RlIHRoYXQgICAgICANCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxz byBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLiAN CiAgICANCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBh IG1heGltdW0gb2Ygc2l4IA0KICAgbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQs IG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgDQogICBhdCBhbnkgdGltZS4gIEl0IGlz IGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyANCiAgIHJlZmVyZW5jZSBt YXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4i IA0KICAgIA0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFj Y2Vzc2VkIGF0IA0KICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0 cy50eHQgDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMg Y2FuIGJlIGFjY2Vzc2VkIGF0IA0KICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5o dG1sLiANCiAgICANCkNvcHlyaWdodCBOb3RpY2UgDQogICAgDQogICBDb3B5cmlnaHQgKGMpIFRo ZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAxKS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4gDQogICAgDQpB YnN0cmFjdCANCiAgICANCiAgIEFzIHBhcnQgb2YgdGhlIEludGVybmV0IE11bHRpbWVkaWEgQ29u ZmVyZW5jaW5nIEFyY2hpdGVjdHVyZSBbM10sIA0KICAgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJv bCBkZWFscyB3aXRoIHRoZSBjb250cm9sIG9mIHJ1bm5pbmcgDQogICBjb25mZXJlbmNlcyBhZnRl ciB0aGUgY3JlYXRpb24gb2YgdGhlIGluaXRpYWwgY29uZmVyZW5jZSBzdGF0ZSB3aXRoIA0KICAg cmVzcGVjdCB0byB0aGUgbWVtYmVyc2hpcCBhbmQgYWNjZXNzIGNvbnRyb2wgZHVyaW5nIHJ1bnRp bWUgb2YgdGhlIA0KICAgc2Vzc2lvbi4gVGhlIHNwZWN0cnVtIG9mIHNjZW5hcmlvcyByZWFjaGVz IGZyb20gc21hbGwgbXVsdGlwYXJ0eSANCiAgIGdhdGhlcmluZ3MgdXAgdG8gbGFyZ2Ugc2NhbGVk IG1lZXRpbmdzIHdpdGggYSBoaWdoIGZsdWN0dWF0aW9uIG9mIA0KICAgdXNlcpJzIG1lbWJlcnNo aXAgYW5kIGFjdGl2aXR5LiANCiAgICANCiAgIFRoaXMgZG9jdW1lbnQgaWRlbnRpZmllcyB0aGUg cHJvYmxlbSBhcmVhIHRvIGRlZmluZSB0aGUgc2NvcGUgb2YgYSANCiAgIGNvbmZlcmVuY2UgY291 cnNlIGNvbnRyb2wgd29ya2luZyBncm91cCBpbiB0aGUgSUVURi4gDQogDQogICAgIA0KVHJvc3Nl biAgICAgICAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAg ICAgWzFdIA0MDQpJbnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0 ZW1lbnQgICAgICAgICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KVGFibGUgb2YgQ29udGVudHMg DQogICAgDQogICAxLiBJbnRyb2R1Y3Rpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4yIA0KICAgMi4gRGVmaW5pdGlvbiBvZiBUZXJtcy4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMyANCiAgIDMuIFNjb3BlLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQgDQog ICA0LiBQcm9ibGVtIFN0YXRlbWVudC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi40IA0KICAgNS4gQ29uZmVyZW5jaW5nIFNjZW5hcmlvcy4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNSANCiAgIDUuMS4gIFNpbXBsZSBDb25mZXJlbmNp bmcuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUgDQogICA1LjEuMS4g IEV4YW1wbGVzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li42IA0KICAgNS4yLiAgRmxvb3IgQ29udHJvbGxlZCBDb25mZXJlbmNpbmcuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uNiANCiAgIDUuMi4xLiAgRXhhbXBsZXMuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYgDQogICA1LjMuICBSaWNoIENvbmZl cmVuY2luZy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42IA0KICAg NS4zLjEuICBFeGFtcGxlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uNyANCiAgIDUuNC4gIFN1bW1hcnkgb2YgQ2hhcmFjdGVyaXN0aWNzLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcgDQogICA2LiBDb25mZXJlbmNlIENvdXJzZSBDb250 cm9sIE1vZGVscy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45IA0KICAgNi4xLiAgTG9v c2UgQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJvbC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u OSANCiAgIDYuMi4gIFRpZ2h0IENvbmZlcmVuY2UgQ291cnNlIENvbnRyb2wuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjkgDQogICA2LjMuICAnSmVsbHktbGlrZScgQ29uZmVyZW5jZSBDb3Vy c2UgQ29udHJvbC4uLi4uLi4uLi4uLi4uLi4uLi4uLi45IA0KICAgNy4gRXhpc3RpbmcgU29sdXRp b25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOSANCiAgIDcu MS4gIEguMzJ4IFByb3RvY29sIFN1aXRlLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uMTAgDQogICA3LjIuICBTSVAtYmFzZWQgU29sdXRpb25zLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwIA0KICAgOC4gTmV4dCBTdGVwcy4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMSANCiAgIDkuIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTEg DQogICAxMC4gIEFja25vd2xlZGdlbWVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjExIA0KICAgMTEuICBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMSANCiAgICANCiAgICANCjEuICAgICBJbnRy b2R1Y3Rpb24gDQogICAgDQogICBJbnRlcmFjdGl2ZSBjb2xsYWJvcmF0aXZlIHNjZW5hcmlvcyBs aWtlIHJlbW90ZSBtZWV0aW5ncywgdmlydHVhbCANCiAgIGNsYXNzcm9vbXMsIG9yIHNoYXJpbmcg YXBwbGljYXRpb25zIHZpYSB0aGUgSW50ZXJuZXQgaGF2ZSBiZWNvbWUgDQogICBtb3JlIGFuZCBt b3JlIHBvcHVsYXIgaW4gdGhlIHBhc3QgdGVuIHllYXJzLiANCiAgICANCiAgIEFjY29yZGluZyB0 byBbM10sIHRoZSB0ZXJtICdjb25mZXJlbmNpbmcnIGlzIGNvbnNpZGVyZWQgaW4gdGhlIA0KICAg cmVtYWluZGVyIG9mIHRoaXMgZG9jdW1lbnQgYXMgc3luY2hyb25vdXMsIHJlYWwtdGltZSBjb21t dW5pY2F0aW9uLCANCiAgIHNwZWNpZmljYWxseSBpbmNsdWRpbmcgYXVkaW8gYW5kIHZpZGVvIG1l ZGlhIGJ1dCBhbHNvIHNoYXJlZCBkYXRhIA0KICAgbWVkaWEgc3VjaCBhcyB3aGl0ZWJvYXJkcywg YW1vbmcgYSBzZXQgb2YgbWVtYmVycy4gU2V2ZXJhbCwgcHJvYmFibHkgDQogICBpbmRlcGVuZGVu dGx5IGltcGxlbWVudGVkLCBhZ2VudHMgZm9yIG1lZGlhIGhhbmRsaW5nIGFuZCBjb250cm9sIA0K ICAgcHVycG9zZXMgaGF2ZSB0byBiZSBjb29yZGluYXRlZCBhbmQgc3luY2hyb25pemVkIGR1cmlu ZyBydW50aW1lIG9mIA0KICAgdGhlIGNvbmZlcmVuY2UsIHJlZmVycmVkIHRvIGFzICdjb25mZXJl bmNlIGNvdXJzZSBjb250cm9sJyBpbiB0aGUgDQogICBmb2xsb3dpbmcsIGFmdGVyIGNyZWF0aW5n IHRoZSBpbml0aWFsIGNvbmZlcmVuY2Ugc3RhdGUgYXMgcGFydCBvZiANCiAgIHRoZSBjb25mZXJl bmNpbmcgc2V0dXAgZnVuY3Rpb25hbGl0eS4gVGhlIHByb3ZpZGVkIGZ1bmN0aW9uYWxpdHkgDQog ICB3aXRoIHJlc3BlY3QgdG8gY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCB1c3VhbGx5IGRlcGVu ZHMgb24gdGhlIA0KICAgY29uc2lkZXJlZCBzY2VuYXJpbyBpbiB3aGljaCBpdCBpcyBuZWVkZWQu ICANCiAgICANCiAgIEluIHRoZSBmb2xsb3dpbmcsIHRoZSBzY29wZSBvZiBjb25mZXJlbmNpbmcg Y291cnNlIGNvbnRyb2wgYXMgd2VsbCANCiAgIGFzIGEgcHJvYmxlbSBzdGF0ZW1lbnQgd2lsbCBi ZSBwaW5wb2ludGVkLiBGdXJ0aGVybW9yZSwgc2NlbmFyaW9zIA0KICAgZm9yIG11bHRpbWVkaWEg Y29uZmVyZW5jaW5nIGluIHRoZSBJbnRlcm5ldCBhcmUgY2F0ZWdvcml6ZWQsIA0KICAgcmVhY2hp bmcgZnJvbSBzbWFsbCBjbG9zZWQgbWVldGluZ3MgdG8gbGFyZ2UgcGxlbmFyeSBzZXNzaW9ucyB3 aXRoIA0KICAgICANClRyb3NzZW4gICAgICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAw MSAgICAgICAgICAgICAgICAgICAgIFsyXSANDA0KSW50ZXJuZXQgRHJhZnQgICAgIENvdXJzZSBD b250cm9sIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAgICBNYXkgMjAwMSANCiAgICANCiAgICAN CiAgIGhpZ2ggZmx1Y3R1YXRpb25zIHJlZ2FyZGluZyB0aGUgcGFydGljaXBhbnSScyBhY3Rpdml0 eSBhbmQgDQogICBpbnRlcmVzdHMuIFNpbmNlIHRoZSBmb2N1cyBvZiB0aGUgZG9jdW1lbnQgaXMg b24gY29udHJvbCBpc3N1ZXMgaW4gDQogICBjb25mZXJlbmNpbmcsIGRhdGEgZGVsaXZlcnkgYXNw ZWN0cyBhcmUgbGVmdCBvdXQgb2YgY29uc2lkZXJhdGlvbi4gDQogICAgDQogICBUaGUgc2NlbmFy aW8gZmluZGluZ3MgYXJlIHRoZW4gdXNlZCB0byBkZWZpbmUgbW9kZWxzIGZvciBjb25mZXJlbmNl IA0KICAgY291cnNlIGNvbnRyb2wgcHJvdmlzaW9uLiANCiAgICANCiAgIE1vcmVvdmVyLCBjdXJy ZW50IGNvbmZlcmVuY2luZyBzb2x1dGlvbnMgYXJlIGJyaWVmbHkgZXZhbHVhdGVkIA0KICAgY29u Y2VybmluZyB0aGVpciBzaG9ydGNvbWluZ3MgaW4gY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCAN CiAgIGZ1bmN0aW9uYWxpdHkuIEZpbmFsbHksIG5leHQgc3RlcHMgZm9yIGNvbmZlcmVuY2UgY291 cnNlIGNvbnRyb2wgDQogICBlZmZvcnRzIHdpbGwgYmUgcHJlc2VudGVkLiANCiAgICANCjIuICAg ICBEZWZpbml0aW9uIG9mIFRlcm1zIA0KICAgIA0KICAgbyBBcHBsaWNhdGlvbiBzZXNzaW9uIChB UyksIFNlc3Npb24gDQogICAgIFRoZSBzZXQgb2YgbWVkaWEgYWdlbnRzL2FwcGxpY2F0aW9ucyB0 aGF0IGFjdCBhcyBwZWVycyB0byBlYWNoICANCiAgICAgb3RoZXIgd2l0aGluIGEgY29uZmVyZW5j ZS4gIEZvciByZWFsLXRpbWUgZGF0YSwgdGhpcyBnZW5lcmFsbHkgIA0KICAgICB3aWxsIGJlIGFu IFJUUCBzZXNzaW9uOyBmb3Igb3RoZXIgYXBwbGljYXRpb24gcHJvdG9jb2xzLCBvdGhlciAgDQog ICAgIGhvcml6b250YWwgcHJvdG9jb2xzIG1heSBkZWZpbmUgdGhlaXIgb3duIHR5cGUgb2Ygc2Vz c2lvbiBjb25jZXB0LiAgDQogICAgDQogICBvIFBhcnRpY2lwYW50IA0KICAgICBBIGh1bWFuIGJl aW5nIHRoYXQgdGFrZXMgcGFydCBpbiBhIGNvbmZlcmVuY2UsIGVpdGhlciBhY3RpdmVseSBvciAg DQogICAgIHBhc3NpdmVseSBsaXN0ZW5pbmcuIA0KICAgIA0KICAgbyBBY3RpdmUgUGFydGljaXBh bnQgDQogICAgIEEgcGFydGljaXBhbnQgb2YgYSBjb25mZXJlbmNlIGJlY29taW5nIHNlbmRlciBv ZiBtZWRpYSBpbmZvcm1hdGlvbiAgDQogICAgIGR1cmluZyBsaWZldGltZSBvZiB0aGUgY29uZmVy ZW5jZS4gDQogICAgDQogICBvIFBhc3NpdmUgUGFydGljaXBhbnQgDQogICAgIEEgcGFydGljaXBh bnQgb2YgYSBjb25mZXJlbmNlIHBhc3NpdmVseSByZWNlaXZpbmcgdGhlIG1lZGlhICANCiAgICAg aW5mb3JtYXRpb24gd2l0aG91dCBiZWNvbWluZyBzZW5kZXIgb2YgbWVkaWEgaW5mb3JtYXRpb24g IA0KICAgICBkdXJpbmcgbGlmZXRpbWUgb2YgdGhlIGNvbmZlcmVuY2UuIA0KICAgIA0KICAgbyBN ZW1iZXIgDQogICAgIFRoZSBzeXN0ZW0sIGluY2x1ZGluZyBzb2Z0d2FyZSBhbmQgaGFyZHdhcmUs IHRoYXQgdGFrZXMgcGFydCBpbiBhICAgIA0KICAgICBjb21wdXRlciBjb25mZXJlbmNlLCByZXBy ZXNlbnRpbmcgYSBzaW5nbGUgcGFydGljaXBhbnQuIA0KICAgIA0KICAgbyBQcm9maWxlIA0KICAg ICBBbiBpbml0aWFsIGRlc2NyaXB0aW9uIG9mIHRoZSBjb25mZXJlbmNlLCBpbmNsdWRpbmcgYXNz aWdubWVudCBvZiAgDQogICAgIHJvbGVzIHRvIHBhcnRpY3VsYXIgbWVtYmVycywgdGltZSBsaW1p dHMgZm9yIHNwZWFrZXJzLCBhdHRyaWJ1dGVzICANCiAgICAgb2YgdGhlIGNvbmZlcmVuY2UgKG9w ZW4vY2xvc2UsIGNvbmR1Y3RlZC9hbmFyY2hpYywgZXRjKS4gDQogICAgDQogICBvIENvbmZlcmVu Y2UgU2V0dXAgYW5kIERpc2NvdmVyeSANCiAgICAgQWNjb3JkaW5nIHRvIFszXSwgYXNwZWN0cyBm b3Igc2V0dGluZyB1cCBhbiBpbml0aWFsIGNvbmZlcmVuY2UgIA0KICAgICBTdGF0ZSBpbiBwYXJ0 aWNpcGF0aW5nIG1lbWJlcnMsIGluY2x1ZGluZyB0aGUgZXhjaGFuZ2Ugb2YgbWVkaWEgIA0KICAg ICBhbmQgY2FwYWJpbGl0aWVzIGluZm9ybWF0aW9uIGFtb25nIHRoZSBzZXQgb2YgcGFydGljaXBh bnRzLCBhcmUgIA0KICAgICBiZWluZyBhZGRyZXNzZWQgYnkgc2V0dXAgYW5kIGRpc2NvdmVyeSBm dW5jdGlvbmFsaXR5LiANCiAgICANCiAgIG8gQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJvbCANCiAg ICAgQWNjb3JkaW5nIHRvIFszXSwgYXNwZWN0cyB0byBjb250cm9sIHRoZSBjb25mZXJlbmNlIGR1 cmluZyBydW50aW1lICANCiAgICAgb2YgdGhlIGV2ZW50IGFyZSBiZWluZyBhZGRyZXNzZWQgYnkg Y29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbC4gDQogICAgDQogICAgIA0KVHJvc3NlbiAgICAgICAg ICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAgICAgWzNdIA0M DQpJbnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAg ICAgICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KMy4gICAgIFNjb3BlIA0KICAgIA0KICAgVGhl IHNjb3BlIG9mIGNvbmZlcmVuY2UgY291cnNlIGNvbnRyb2wgZnVuY3Rpb25hbGl0eSB3aWxsIGJl IA0KICAgZGV2ZWxvcGVkIGFzIHBhcnQgb2YgdGhlIHNvbHV0aW9uIHNwYWNlLiBQb3NzaWJsZSBm dW5jdGlvbmFsaXR5IA0KICAgaW5jbHVkZXM6IA0KICAgIA0KICAgbyAnY29uZmVyZW5jZSBjb250 ZXh0IGFkbWluaXN0cmF0aW9uJywgcHJvdmlkaW5nIG1lbWJlcnNoaXAgIA0KICAgICBhbmQgYXBw bGljYXRpb24vc2Vzc2lvbiBpbmZvcm1hdGlvbiBhZG1pbmlzdHJhdGlvbiANCiAgIG8gJ21lbWJl cnNoaXAgZW5mb3JjZW1lbnQnLCBwcm92aWRpbmcgbWVhbnMgdG8gZW5mb3JjZSBzcGVjaWZpYyAg DQogICAgIGNvbmZlcmVuY2UgbWVtYmVyc2hpcCANCiAgIG8gJ2Zsb29yIGNvbnRyb2wnLCBwcm92 aWRpbmcgbWVhbnMgdG8gbWFwIHNvY2lhbCBwcm90b2NvbHMgb250byAgDQogICAgIGRpc3RyaWJ1 dGVkIGVudmlyb25tZW50cy4gSG93ZXZlciwgdGhlIHNlbWFudGljcyBvZiBzcGVjaWZpYyAgDQog ICAgIHNvY2lhbCBwcm90b2NvbHMgaXMgbm90IHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIHBvc3Np YmxlICANCiAgICAgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBzb2x1dGlvbi4gDQogICBvICdh Y3RpdmUvcGFzc2l2ZSBtZW1iZXIgc3VwcG9ydCcsIGFsbG93aW5nIGZvciBkaWZmZXJlbnQgcG9s aWNpZXMgIA0KICAgICB3aXRoIHJlc3BlY3QgdG8gbWVtYmVyc2hpcCBhbmQgZmxvb3IgY29udHJv bC4gVGhpcyBpbmNsdWRlcyAgDQogICAgIGNoYW5nZXMgZnJvbSBhY3RpdmUgdG8gcGFzc2l2ZSBh bmQgdmljZSB2ZXJzYSwgZWl0aGVyIGltcGxpY2l0bHkgIA0KICAgICBvciBleHBsaWNpdGx5LiAN CiAgIG8gJ2NhcGFiaWxpdGllcyByZS1uZWdvdGlhdGlvbicsIGFsbG93aW5nIGZvciBjaGFuZ2Vz IGluICANCiAgICAgdGhlIGluaXRpYWwgY2FwYWJpbGl0aWVzIHNldCBvZiBwYXJ0aWNpcGFudHMg ZHVyaW5nIHJ1bnRpbWUgb2YgdGhlICANCiAgICAgY29uZmVyZW5jZS4gDQogICAgDQogICBUaGlz IGxpc3QgZG9lcyBub3QgY2xhaW0gdG8gYmUgZXhoYXVzdGl2ZS4gSG93ZXZlciwgaXQgcG9pbnRz IGluIHRoZSANCiAgIGRpcmVjdGlvbiBvZiBwcm92aWRlZCBmdW5jdGlvbmFsaXR5IGZvciBjb25m ZXJlbmNlIGNvdXJzZSBjb250cm9sIA0KICAgc29sdXRpb25zLiANCiAgICANCjQuICAgICBQcm9i bGVtIFN0YXRlbWVudCANCiAgICANCiAgIFRoZXJlIGFyZSBtYW55IGFwcHJvYWNoZXMgaW4gdGhl IHJlc2VhcmNoIGNvbW11bml0eSB0byByZWFsaXplIA0KICAgY29uZmVyZW5jZSBjb3Vyc2UgY29u dHJvbCBhcyBwYXJ0IG9mIGEgY29uZmVyZW5jaW5nIGFyY2hpdGVjdHVyZS4gDQogICBBbHNvIGlu IHN0YW5kYXJkaXphdGlvbiBib2RpZXMgKHN1Y2ggYXMgSC4zMjMgWzddIG9yIFNDQ1AgWzFdKSwg DQogICBjb25mZXJlbmNlIGNvdXJzZSBjb250cm9sIGhhcyBiZWVuIGFkZHJlc3NlZC4gSG93ZXZl ciwgbm9uZSBvZiB0aGVzZSANCiAgIGFwcHJvYWNoZXMgb2ZmZXJzIGEgdW5pZmllZCBhbmQgZmxl eGlibGUgc29sdXRpb24gZm9yIGNvbmZlcmVuY2UgDQogICBjb3Vyc2UgY29udHJvbCB0byBjb3Zl ciB0aGUgc3BlY3RydW0gb2Ygc2NlbmFyaW9zIG91dGxpbmVkIGluIA0KICAgU2VjdGlvbiA1LiAN CiAgICANCiAgIFNwZWNpZmljYWxseSwgYSBjb25mZXJlbmNlIGNvdXJzZSBjb250cm9sIHNvbHV0 aW9uIHNob3VsZCANCiAgICANCiAgIG8gZml0IGludG8gdGhlIGFscmVhZHkgZGVmaW5lZCBjb25m ZXJlbmNlIGNvbnRyb2wgYXJjaGl0ZWN0dXJlIGFuZCAgDQogICAgIGxldmVyYWdlIHRoZSBleGlz dGluZyBzdWl0ZSBvZiBtZWNoYW5pc21zIGFuZCBwcm90b2NvbHMsIHN1Y2ggYXMgIA0KICAgICAq IGNvbmZlcmVuY2UgZGVzY3JpcHRpb24sIGkuZS4sIFNEUCBbNF0gb3IgZnV0dXJlIHZlcnNpb25z IChTREctbmcgIA0KICAgICAgIFs5XSksIGFuZCBpbml0aWF0aW9uLCBpLmUuLCBTSVAgWzVdIA0K ICAgICAqIGxvY2FsIGNvb3JkaW5hdGlvbiwgaS5lLiwgTUJVUyBbMTBdIA0KICAgICAqIHRyYW5z cG9ydCBsYXllciBwcm90b2NvbHMsIHN1Y2ggYXMgZm9yIHJlbGlhYmxlIG11bHRpY2FzdCwgcmVh bC0gDQogICAgICAgdGltZSB0cmFuc2Zlciwgb3Igc2ltcGxlIHVuaWNhc3QgdHJhbnNtaXNzaW9u IA0KICAgICAqIHNlY3VyaXR5IGNvbXBvbmVudHMsIHN1Y2ggYXMgZ3JvdXAga2V5IHNvbHV0aW9u cyANCiAgIG8gcHJvdmlkZSBhIGZsZXhpYmxlIHNvbHV0aW9uLCBhbGxvd2luZyBmb3IgYSB2YXJp ZXR5IG9mIHNjZW5hcmlvcyAgDQogICAgIChzZWUgU2VjdGlvbiA1KSBhbmQgY2hhcmFjdGVyaXN0 aWNzIHRvIGJlIHBsdWdnZWQgaW4gdGhlIHN5c3RlbS4gIA0KICAgIA0KICAgRm9yIHRoYXQsIGEg YnVpbGRpbmcgYmxvY2sgYXBwcm9hY2ggd291bGQgYWxsb3cgdGhlIHByb3Zpc2lvbiBvZiANCiAg IHN0YW5kYXJkaXplZCBpbnRlcmZhY2VzIHRvIHRoZSBkZXNpcmVkIGNvbW1vbiBmdW5jdGlvbmFs aXR5LiBXaXRoIA0KICAgdGhhdCwgc3BlY2lmaWMgc2NlbmFyaW8tdGFpbG9yZWQgaW5zdGFudGlh dGlvbnMgZm9yIGNlcnRhaW4gDQogICBmdW5jdGlvbmFsaXR5LCByZXByZXNlbnRlZCBieSBhIGJ1 aWxkaW5nIGJsb2NrLCBhcmUgZW5hYmxlZCANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAg ICBFeHBpcmVzIE5vdmVtYmVyIDIwMDEgICAgICAgICAgICAgICAgICAgICBbNF0gDQwNCkludGVy bmV0IERyYWZ0ICAgICBDb3Vyc2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAg TWF5IDIwMDEgDQogICAgDQogICAgDQogICBwcmVzZXJ2aW5nIHRoZSBjb21tb24gdmlldyBvZiB0 aGUgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCANCiAgIGZ1bmN0aW9uYWxpdHkuIA0KICAgIA0K ICAgIA0KNS4gICAgIENvbmZlcmVuY2luZyBTY2VuYXJpb3MgDQogICAgDQogICBUaGlzIHNlY3Rp b24gaW5mb3JtYWxseSBvdXRsaW5lcyBzY2VuYXJpbyBjYXRlZ29yaWVzIGZvciBtdWx0aW1lZGlh IA0KICAgY29uZmVyZW5jaW5nIGluIHRoZSBJbnRlcm5ldC4gIA0KICAgIA0KICAgVGhlIGNvbmZl cmVuY2luZyBzY2VuYXJpb3MgYXJlIGNhdGVnb3JpemVkIGluIHRocmVlIHNlY3Rpb25zLiBGb3Ig DQogICBlYWNoIGNhdGVnb3J5LCB0eXBpY2FsIGNoYXJhY3RlcmlzdGljcyBhcmUgb3V0bGluZWQs IGFuZCBleGFtcGxlcyANCiAgIGFyZSBnaXZlbi4gRmluYWxseSwgYSB0YWJsZS13aXNlIG92ZXJ2 aWV3IGlzIGRlcml2ZWQgZnJvbSB0aGUgbW9yZSANCiAgIGluZm9ybWFsIGRlc2NyaXB0aW9uIHBp bnBvaW50aW5nIHRoZSB2ZXJ5IGZ1bmN0aW9uYWxpdHkgcmVxdWlyZWQgZm9yIA0KICAgdGhlIHNw ZWNpZmljIHNjZW5hcmlvcy4gVGhpcyB0YWJsZS13aXNlIGRlc2NyaXB0aW9uIHdpbGwgYmUgdXNl ZCBpbiANCiAgIFNlY3Rpb24gNSB0byBkaXNjdXNzIGNvbmZlcmVuY2UgY291cnNlIGNvbnRyb2wg bW9kZWxzLiANCiAgICANCiAgIEl0IGlzIHdvcnRoIG1lbnRpb25pbmcgdGhhdCBzaW1wbGUgc3Ry ZWFtaW5nIGlzIG5vdCBjb25zaWRlcmVkIGluIA0KICAgdGhlIGZvbGxvd2luZyBkdWUgdG8gaXRz IGxhY2sgb2YgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCANCiAgIGZ1bmN0aW9uYWxpdHkuIEhv d2V2ZXIsIGl0IG1pZ2h0IGJlIHVzZWQgdG8gcmVhbGl6ZSB2ZXJ5IHNpbXBsZSANCiAgIGNvbmZl cmVuY2luZyBzY2VuYXJpb3Mgc3VjaCBhcyBJbnRlcm5ldCBsZWN0dXJlcywgd2hlcmUgZGF0YSBp cyANCiAgIHNpbXBseSBzZW50IHRvIGEgc2V0IG9mIHJlY2VpdmVycyB3aXRob3V0IGZlZWRiYWNr IG9yIGludGVyYWN0aW9uLiAgDQogICAgDQo1LjEuICAgU2ltcGxlIENvbmZlcmVuY2luZyANCiAg ICANCiAgICdTaW1wbGUgQ29uZmVyZW5jaW5nJyByZWZsZWN0cyB0aGUgc2ltcGxlc3QgZm9ybSBv ZiBjb25mZXJlbmNpbmcgDQogICB3aXRoIGEgY2hhbmdlIG9mIHRoZSBzZW5kZXIvcmVjZWl2ZXIg cmVsYXRpb24gYmFzZWQgb24gY2VydGFpbiANCiAgICdzb2NpYWwgcnVsZXMnIGR1cmluZyB0aGUg bGlmZXRpbWUgb2YgdGhlIGNvbmZlcmVuY2UuIA0KICAgIA0KICAgQ29uZmVyZW5jZXMgb2YgdGhp cyB0eXBlIG1pZ2h0IGJlIGFubm91bmNlZCBiZWZvcmVoYW5kLCBpbmNsdWRpbmcgDQogICB0aGUg Y29uZmVyZW5jZZJzIHByb2ZpbGUgaW5mb3JtYXRpb24sIG9yIHRoZXkgdGFrZSBwbGFjZSBhcyBh ZC1ob2MgDQogICBtZWV0aW5ncy4gIA0KICAgIA0KICAgVGhlIGdyb3VwIG9mIHBhcnRpY2lwYW50 cyBtaWdodCBiZSB3ZWxsLWtub3duLCBpZiBhbm5vdW5jZWQsIG9yIGJlIA0KICAgYnVpbHQgYnkg aW52aXRhdGlvbiBvciByZXF1ZXN0LiBGb3IgdGhhdCwgc2V2ZXJhbCBpbml0aWF0aW9uIG1vZGVs cyANCiAgIG1pZ2h0IGJlIHJlYWxpemVkIChzZWUgYWxzbyBbMTFdKSwgd2hpY2ggcmVxdWlyZXMg YXBwcm9wcmlhdGUgDQogICBpbml0aWF0aW9uIGZ1bmN0aW9uYWxpdHkgaW5jbHVkaW5nIGF1dGhl bnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIA0KICAgbWVhbnMgZm9yIHJlc3RyaWN0ZWQgYWNj ZXNzIHRvIHRoZSBjb25mZXJlbmNlLiAgDQogICAgDQogICBGbG9vciBjb250cm9sIGZ1bmN0aW9u YWxpdHksIGUuZy4sIHRvIHJlYWxpemUgY29uZHVjdGVkIG1lZXRpbmcgDQogICBmdW5jdGlvbmFs aXR5LCBpcyBub3QgcHJvdmlkZWQgaW4gdGhpcyBjYXRlZ29yeS4gRHVlIHRvIHRoaXMgbGFjayBv ZiANCiAgIG1lZGlhdGlvbiBjb25jZXJuaW5nIHRoZSBhY2Nlc3Mgb24gdGhlIGNvbW1vbiBtZWRp YSByZXNvdXJjZSwgdGhlIA0KICAgbGV2ZWwgb2YgaW50ZXJhY3Rpdml0eSBpcyB1c3VhbGx5IGxp bWl0ZWQsIGV2ZW4gaWYgc2NhbGFibGUgDQogICBtdWx0aWNhc3QgdHJhbnNmZXIgaXMgdXNlZC4g IA0KICAgIA0KICAgVXN1YWxseSwgdGhlIGluaXRpYWwgc2V0IG9mIGNhcGFiaWxpdGllcyBpcyBu b3QgY2hhbmdlZCwgaS5lLiwgcmUtDQogICBuZWdvdGlhdGVkLCBkdXJpbmcgcnVudGltZSBvZiB0 aGUgY29uZmVyZW5jZS4gSG93ZXZlciwgc29tZSBzaW1wbGUgDQogICBmb3JtIG9mIHJlLW5lZ290 aWF0aW9uIGNvdWxkIGJlIHByb3ZpZGVkLiANCiAgICANCiAgIEFsdGhvdWdoIHRoZSBudW1iZXIg b2YgcGFydGljaXBhbnRzIGNhbiBlYXNpbHkgcmVhY2ggc2V2ZXJhbCANCiAgIHRob3VzYW5kcyBv ciBldmVuIG1vcmUsIHdoZW4gdXNpbmcgbXVsdGljYXN0IHRyYW5zZmVyIGNhcGFiaWxpdGllcywg DQogICBpdCBpcyBleHBlY3RlZCB0aGF0IHRoZSByZXF1aXJlbWVudHMgZm9yIHByZWNpc2UgbWVt YmVyc2hpcCANCiAgIGluZm9ybWF0aW9uIGFyZSBsZXNzIHN0cmluZ2VudCBpbiBsYXJnZXIgc2Nh bGVkIGNvbmZlcmVuY2VzLiANCiAgICANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAgICBF eHBpcmVzIE5vdmVtYmVyIDIwMDEgICAgICAgICAgICAgICAgICAgICBbNV0gDQwNCkludGVybmV0 IERyYWZ0ICAgICBDb3Vyc2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgTWF5 IDIwMDEgDQogICAgDQogICAgDQo1LjEuMS4gRXhhbXBsZXMgDQogICAgDQogICBFeGFtcGxlcyBm b3Igc2ltcGxlIGNvbmZlcmVuY2luZyBpbmNsdWRlIGFkLWhvYyBvciBwcmUtcGxhbm5lZCBzbWFs bCANCiAgIGdyb3VwIG1lZXRpbmdzLCByaWNoIGNhbGxzLCBJbnRlcm5ldCBsZWN0dXJlcywgdGVs ZS13b3JraW5nIGluIGEgDQogICB0ZWFtLiBNb3N0IG9mIHRoZSBjdXJyZW50IE1Cb25lIFsyXSBz ZXNzaW9ucyBhcmUgdHlwaWNhbCBleGFtcGxlcyANCiAgIGZvciBzaW1wbGUgY29uZmVyZW5jaW5n LiANCiAgICANCjUuMi4gICBGbG9vciBDb250cm9sbGVkIENvbmZlcmVuY2luZyANCiAgICANCiAg IFNjZW5hcmlvcyBvZiB0aGlzIGNhdGVnb3J5IGVucmljaCB0aGUgc2ltcGxlIGNvbmZlcmVuY2lu ZyANCiAgIGZ1bmN0aW9uYWxpdHkgb2Ygc2VjdGlvbiA1LjEuIGJ5IHByb3ZpZGluZyBmbG9vciBj b250cm9sIGZhY2lsaXRpZXMgDQogICB0byBjb250cm9sIHRoZSBhY2Nlc3Mgb24gZGlzdHJpYnV0 ZWQgcmVzb3VyY2VzLiBBbW9uZyBvdGhlcnMsIHRoZXNlIA0KICAgZGlzdHJpYnV0ZWQgcmVzb3Vy Y2VzIG1pZ2h0IHJlZmxlY3QgdGhlIGNvbW1vbmx5IHVzZWQgYXVkaW92aXN1YWwgDQogICBjaGFu bmVsIHdpdGhpbiB0aGUgY29uZmVyZW5jZSBidXQgYWxzbyB0aGUgY29udGVudCBvZiBhIHNoYXJl ZCANCiAgIHdoaXRlYm9hcmQsIG9yIGEgc2hhcmVkLCBsb2NhbGx5IGhvc3RlZCBhcHBsaWNhdGlv bi4gVGhlIGZsb29yIA0KICAgY29udHJvbCBzZW1hbnRpY3MgYXJlIHVzdWFsbHkga25vd24gYmVm b3JlaGFuZCwgb3IgdGhleSBtaWdodCBiZSANCiAgIGRpc3RyaWJ1dGVkIHVzaW5nIHRoZSBjb25m ZXJlbmNlIHByb2ZpbGUgaW5mb3JtYXRpb24uIFRoZSANCiAgIHJlYWxpemF0aW9uIG9mIHRoZSBm bG9vciBjb250cm9sIHNlbWFudGljcyBpcyB1c3VhbGx5IGhpZ2hseSANCiAgIGFwcGxpY2F0aW9u LXNwZWNpZmljLiANCiAgICANCiAgIEZvciBpbnN0YW5jZSwgZmxvb3IgY29udHJvbGxlZCBjb25m ZXJlbmNpbmcgbWlnaHQgYWxsb3cgJ2NvbmR1Y3RlZCANCiAgIG1lZXRpbmdzJywgZW5hYmxpbmcg dGhlIGNvbmR1Y3RvciBvZiBhIGNvbmZlcmVuY2UgZm9yIGluc3RhbmNlIHRvIA0KICAgZWplY3Qg cGFydGljaXBhbnRzIGZyb20gYSBjb25mZXJlbmNlIG9yIHRvIGRlbnkgYWNjZXNzIHRvIHRoZSAN CiAgIGNvbmZlcmVuY2UuIEhvd2V2ZXIsIGluIGFkZGl0aW9uIHRvIHRoZSByZWFsaXphdGlvbiBv ZiB0aGUgc29jaWFsIA0KICAgcnVsZXMgYnkgbWVhbnMgb2YgZmxvb3IgY29udHJvbCwgYXBwcm9w cmlhdGUgZnVuY3Rpb25hbGl0eSB0byANCiAgIGVuZm9yY2UgdGhlbSBvbiBkYXRhIGxldmVsIGlz IHJlcXVpcmVkIGJ5IG1lYW5zIG9mIGV4Y2x1ZGluZyANCiAgIHJlY2VpdmVyIHNldHMgZnJvbSBy ZWNlcHRpb24uIA0KICAgIA0KICAgQ2FwYWJpbGl0aWVzIHJlLW5lZ290aWF0aW9uIGlzIHVzdWFs bHkgcHJvdmlkZWQgaW4gdGhlc2Ugc2NlbmFyaW9zLCANCiAgIHdoaWNoIG1pZ2h0IGFsc28gYmUg dGllZCB0byB0aGUgaW1wbGVtZW50ZWQgZmxvb3IgY29udHJvbCBwb2xpY3kgb2YgDQogICB0aGUg c3BlY2lmaWMgc2NlbmFyaW8uIA0KICAgIA0KICAgSW4gZmxvb3IgY29udHJvbGxlZCBjb25mZXJl bmNlcywgdGhlcmUgaXMgYW4gZXhhY3Qga25vd2xlZGdlIG9mIHRoZSANCiAgIGN1cnJlbnQgbWVt YmVyc2hpcCBpbmZvcm1hdGlvbiBvZiB0aGUgcGFydGljaXBhbnRzLiBVc3VhbGx5LCB0aGUgDQog ICBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgZmxvb3IgY29udHJvbCByZXN0cmljdHMgdGhlIHNjYWxh YmlsaXR5IG9mIA0KICAgdGhpcyB0eXBlIG9mIGNvbmZlcmVuY2VzIHRvIGEgZmV3IHRlbnMuIEhv d2V2ZXIsIGFwcHJvYWNoZXMgYXMgDQogICBwcm9wb3NlZCBpbiBbMTNdLCBtaWdodCBiZSB1c2Vk IGluIHNwZWNpZmljIHNjZW5hcmlvcyB0byBpbXByb3ZlIHRoZSANCiAgIHNjYWxhYmlsaXR5LiAN CiAgICANCjUuMi4xLiBFeGFtcGxlcyANCiAgICANCiAgIEV4YW1wbGVzIGZvciBmbG9vciBjb250 cm9sbGVkIGNvbmZlcmVuY2VzIGluY2x1ZGUgc2NlbmFyaW9zIHdpdGggdGhlIA0KICAgbmVlZCB0 byByZWFsaXplIHNvY2lhbCBydWxlcyBvciBhY2Nlc3MgY29udHJvbCBvbiBzaGFyZWQgcmVzb3Vy Y2VzLCANCiAgIHN1Y2ggYXMgY29uZHVjdGVkIG1lZXRpbmdzLCBhcHBsaWNhdGlvbiBzaGFyaW5n IHNlc3Npb25zLCBkaXN0YW5jZSANCiAgIGxlYXJuaW5nIGluY2x1ZGluZyBkZW1vbnN0cmF0aW9u IG9mIHNoYXJlZCBpbmZvcm1hdGlvbiwgdGVsZS13b3JraW5nIA0KICAgd2l0aCBjb21tb24gcmVz b3VyY2VzIHRvIHNoYXJlLiANCiAgICANCjUuMy4gICBSaWNoIENvbmZlcmVuY2luZyANCiAgICAN CiAgIEEgJ3JpY2ggY29uZmVyZW5jaW5nJyBldmVudCwgd2hpY2ggaXMgZ29pbmcgdG8gaGFwcGVu LCBtaWdodCBiZSANCiAgIGFubm91bmNlZCBiZWZvcmVoYW5kIGJ1dCBhbiBhZC1ob2MgZXN0YWJs aXNobWVudCBtaWdodCBhbHNvIGJlIA0KICAgY29uc2lkZXJlZCwgc3VjaCBhcyBhICdyYW5kb21s eSBnYXRoZXJpbmcgYSBjcm93ZCBhcm91bmQgYW4gDQogICAgIA0KVHJvc3NlbiAgICAgICAgICAg ICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAgICAgWzZdIA0MDQpJ bnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAg ICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KICAgYXR0cmFjdGlvbicuIEF1dGhlbnRpY2F0aW9u IGFuZCBhdXRob3JpemF0aW9uIG1lYW5zIG1pZ2h0IGJlIHVzZWQgDQogICBmb3IgcmVzdHJpY3Rl ZCBhY2Nlc3MgdG8gdGhlIGV2ZW50LiANCiAgICANCiAgIFVzdWFsbHksIHRoZXJlIGlzIGEgKHNt YWxsKSB3ZWxsLWtub3duIGdyb3VwIG9mIGFjdGl2ZSBwYXJ0aWNpcGFudHMsIA0KICAgaS5lLiwg ZXhhY3QgbWVtYmVyc2hpcCBpbmZvcm1hdGlvbiBpcyByZXF1aXJlZCwgYW5kIGEgbGFyZ2VyIGdy b3VwIA0KICAgb2YgcGFzc2l2ZSBwYXJ0aWNpcGFudHMuIE1lbWJlcnNoaXAgaW5mb3JtYXRpb24g Zm9yIHRoaXMgbGFyZ2VyIA0KICAgZ3JvdXAgaXMgbGVzcyBzdHJpY3RseSBwcm92aWRlZCwgY29t cGFyYWJsZSB3aXRoICdibHVlIHNoZWV0cycgDQogICBhdHRlbmRlZXMgbGlzdHMuICANCiAgICAN CiAgIFRoZSBhY2Nlc3MgY29udHJvbCB3aXRoaW4gdGhlIGdyb3VwIG9mIGFjdGl2ZSBwYXJ0aWNp cGFudHMgaXMgDQogICByZWFsaXplZCBieSBtZWFucyBvZiBmbG9vciBjb250cm9sIHJlYWxpemlu ZyBzcGVjaWZpYyBzb2NpYWwgDQogICBpbnRlcmFjdGlvbnMgKGNvbmR1Y3RlZCBzZXNzaW9uLCBw YW5lbCBncm91cCkgc2ltaWxhciB0byBmbG9vciANCiAgIGNvbnRyb2xsZWQgY29uZmVyZW5jaW5n LiANCiAgICANCiAgIEFzIGEgc3BlY2lmaWMgY2hhcmFjdGVyaXN0aWMgb2YgdGhpcyBjYXRlZ29y eSwgZnJlcXVlbnQgY2hhbmdlcyANCiAgIGJldHdlZW4gYWN0aXZlIGFuZCBwYXNzaXZlIHBhcnRp Y2lwYXRpb24gaW4gdGhlIGNvbmZlcmVuY2UgYXJlIA0KICAgaGFwcGVuaW5nLCBlLmcuLCBhIHBh c3NpdmUgb2JzZXJ2ZXIgKHBhcnRpY2lwYW50KSBvZiB0aGUgZXZlbnQgbWlnaHQgDQogICByYWlz ZSBpdHMgaW50ZXJlc3QgaW4gYmVjb21pbmcgYWN0aXZlIGluIHRoZSBkaXNjdXNzaW9uLCBlaXRo ZXIgYnkgDQogICBvd24gcmVxdWVzdCBvciBieSBpbnZpdGF0aW9uLCBmb2xsb3dpbmcgdGhlIHNw ZWNpZmljIGFjY2VzcyBydWxlcyBvZiANCiAgIHRoZSBhY3RpdmUgcGFydGljaXBhbnQgZ3JvdXAg aW1wbGVtZW50ZWQgYnkgYXBwcm9wcmlhdGUgZmxvb3IgDQogICBjb250cm9sIG1lYW5zLiBUaGUg bW9kZSBjaGFuZ2UgY291bGQgaGFwcGVuICdleHBsaWNpdGx5JywgaS5lLiwgYnkgDQogICBqb2lu aW5nIHRoZSBhY3RpdmUgbWVtYmVyIGdyb3VwLCBvciAnaW1wbGljaXRseScsIGkuZS4sIGJ5IA0K ICAgcmVxdWVzdGluZyBmbG9vciBjb250cm9sIHNlcnZpY2VzLiANCiAgICANCiAgIFRoaXMgbW9k ZSBjaGFuZ2Ugc2hvdWxkIGJlIHBvc3NpYmxlIGluIHRoZSByZXZlcnNlIGRpcmVjdGlvbiwgdG9v LCANCiAgIGkuZS4sIHdoZW4gYW4gYWN0aXZlIHBhcnRpY2lwYW50IGxvb3NlcyBpbnRlcmVzdCBp biBhY3RpdmUgDQogICBwYXJ0aWNpcGF0aW9uLiANCiAgICANCjUuMy4xLiBFeGFtcGxlcyANCiAg ICANCiAgIEV4YW1wbGVzIGZvciBsYXJnZSBzY2FsZSByaWNoIGNvbmZlcmVuY2luZyBzY2VuYXJp b3MgYXJlIHRvd24gaGFsbCANCiAgIG1lZXRpbmdzLCBJRVRGIHdvcmtpbmcgZ3JvdXAgbWVldGlu Z3MsIHZpcnR1YWwgbGVjdHVyZXMgd2l0aCANCiAgIGZlZWRiYWNrLCB2aXJ0dWFsIG5ld3Nncm91 cHMuIEhvd2V2ZXIsIGV4YW1wbGVzIGZvciBzaW1wbGUgYW5kIGZsb29yIA0KICAgY29udHJvbGxl ZCBjb25mZXJlbmNpbmcgYXJlIGFsc28gYXBwbGljYWJsZSBmb3IgdGhpcyBjYXRlZ29yeSBkdWUg dG8gDQogICB0aGUgc3VwZXJzZXQgY2hhcmFjdGVyIG9mIHRoZSByaWNoIGNvbmZlcmVuY2luZyBj YXRlZ29yeSBjb21wYXJlZCB0byANCiAgIHRoZSBvdGhlciBvbmVzLiANCiAgICANCjUuNC4gICBT dW1tYXJ5IG9mIENoYXJhY3RlcmlzdGljcyANCiAgICANCiAgIFRoZSBmb2xsb3dpbmcgdGFibGUg c3VtbWFyaXplcyB0aGUgbWFpbiBjaGFyYWN0ZXJpc3RpY3MgZm9yIHRoZSANCiAgIGRpZmZlcmVu dCBzY2VuYXJpbyBjYXRlZ29yaWVzIHByZXNlbnRlZCBpbiBzZWN0aW9uIDUuMS4gdG8gNS4zLiAN CiAgICcoKyknIGluZGljYXRlcyBvcHRpb25hbCBmdW5jdGlvbmFsaXR5LiAgDQogICAgDQogICBU aGUgZmlyc3QgYmxvY2sgb2YgY2hhcmFjdGVyaXN0aWNzIGlzIHJlZmVycmVkIHRvIGFzIGNvbmZl cmVuY2UgDQogICBpbml0aWF0aW9uIGFuZCBzZXR1cCAoc2VlIFszXSksIHdoaWxlIHRoZSBzZWNv bmQgYmxvY2sgaXMgZGVkaWNhdGVkIA0KICAgdG8gY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBm dW5jdGlvbmFsaXR5LiANCiAgICANCiAgICANCiAgICANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgfCBGdW5jdGlv bmFsaXR5ICAgIHwgIFNpbXBsZSAgICAgfCAgICBGLkMuICAgICB8ICAgUmljaCAgICAgIHwgDQog ICB8ICAgICAgICAgICAgICAgICAgfCAgIENvbmYuICAgICB8ICAgQ29uZi4gICAgIHwgICBDb25m LiAgICAgfCANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgICANClRyb3NzZW4gICAgICAgICAgICAgICAgIEV4cGly ZXMgTm92ZW1iZXIgMjAwMSAgICAgICAgICAgICAgICAgICAgIFs3XSANDA0KSW50ZXJuZXQgRHJh ZnQgICAgIENvdXJzZSBDb250cm9sIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAgICBNYXkgMjAw MSANCiAgICANCiAgICANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgfCBQcm9maWxlIEluZi4gICAgIHwgICAgICAr ICAgICAgfCAgICAgICsgICAgICB8ICAgICAgKyAgICAgIHwgDQogICB8ICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICB8ICAgIGluY2wuICAgIHwgICAgaW5jbC4gICAgfCANCiAgIHwgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgIGZsb29yIGluZi4gfCAgZmxvb3IgaW5mLiB8 IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0gDQogICB8IEluaXRpYXRpb24gICAgICAgfCAgYW5ub3VuY2VkICB8ICBhbm5v dW5jZWQgIHwgIGFubm91bmNlZCAgfCANCiAgIHwgICAgICAgICAgICAgICAgICB8ICAgaW52aXRl ZCAgIHwgICBpbnZpdGVkICAgfCAgIGludml0ZWQgICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IENhcGFi aWxpdGllcyAgICAgfCAgICAgKCspICAgICB8ICAgICAgKyAgICAgIHwgICAgICArICAgICAgfCAN CiAgIHwgUmUtbmVnb3RpYXRpb24gICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAg ICAgICAgICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IEF1dGhlbnRpY2F0aW9uICsgfCAgICAgKCspICAg ICB8ICAgICAoKykgICAgIHwgICAgICgrKSAgICAgfCANCiAgIHwgQXV0aG9yaXphdGlvbiAgICB8 ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICB8IA0KICAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQog ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSANCiAgIHwgTWVtYmVyc2hpcCBJbmZvICB8ICAgICAgKyAgICAgIHwgICAgICArICAg ICAgfCAgICAgICsgICAgICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IEZsb29yIENvbnRyb2wgICAgfCAg ICAgIC0gICAgICB8ICAgICAgKyAgICAgIHwgICAgKyAoZm9yICAgfCANCiAgIHwgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICBhY3RpdmUpICB8IA0KICAg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0gDQogICB8IE1lbWJlcnNoaXAgICAgICAgfCAgYXQgc3RhcnR1cCB8IGJhc2VkIG9uICAg IHwgYmFzZWQgb24gICAgfCANCiAgIHwgRW5mb3JjZW1lbnQgICAgICB8ICAgICBvbmx5ICAgIHwg Zmxvb3IgY3RybCAgfCBmbG9vciBjdHJsICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IEFjdGl2ZS9QYXNz aXZlICAgfCAgICAgIC0gICAgICB8ICAgICAgLSAgICAgIHwgICAgICArICAgICAgfCANCiAgIHwg TW9kZSBDaGFuZ2UgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAg ICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0gDQogICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCiAgIHwgU2NhbGUgICAgICAgICAgICB8IHNtYWxs IGR1ZSB0b3wgZGVwZW5kcyBvbiAgfCAgIGxhcmdlICAgICB8IA0KICAgfCAgICAgICAgICAgICAg ICAgIHwgbGFjayBvZiAgICAgfCBmbG9vciAgY3RybC58ICAgICAgICAgICAgIHwgDQogICB8ICAg ICAgICAgICAgICAgICAgfCBtZWRpYXRpb24gICB8IHNjYWxlICAgICAgIHwgICAgICAgICAgICAg fCANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tIA0KICAgICAgICAgICAgICBUYWJsZSAxIDogU3VtbWFyeSBvZiBDaGFyYWN0 ZXJpc3RpY3MgDQogICAgDQogICBUaGUgZm9sbG93aW5nIEZpZ3VyZSAxIHRyaWVzIHRvIG91dGxp bmUgdGhlIGNhdGVnb3JpZXMgb2YgdGhpcyANCiAgIHNlY3Rpb24gaW4gYSBzY2FsZS1mdW5jdGlv bmFsaXR5IHNwYWNlLCBlbXBoYXNpemluZyB0aGUgc3VwZXJzZXQgDQogICBjaGFyYWN0ZXIgb2Yg dGhlICdyaWNoIGNvbmZlcmVuY2luZycgY2F0ZWdvcnkuIA0KICAgIA0KICAgU2NhbGUgL3xcIA0K ICAgICAgICAgIHx8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS18IA0KICAgICAgICAgIHx8ICAgICAgICAgICAgICAgIFJpY2ggQ29uZmVyZW5jaW5nICAg ICAgICAgICAgICAgICB8IA0KICAgICAgICAgIHx8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgIHx8ICAgICAgICBUb3duIEhhbGwg TWVldGluZ3MsIElFVEYgTWVldGluZ3MgICAgICAgICB8IA0KICAgICAgICAgIHx8fC0tLS0tLS0t LS0tLS0tLS0tLS0tLS18fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXx8IA0KICAgICAgICAgIHx8 fCBTaW1wbGUgQ29uZmVyZW5jaW5nICB8fCBGbG9vciBDb250cm9sbGVkIENvbmYuIHx8IA0KICAg ICAgICAgIHx8fCAgICAgICAgICAgICAgICAgICAgICB8fCAgICAgICAgICAgICAgICAgICAgICAg IHx8IA0KICAgICAgICAgIHx8fCBMZWN0dXJlcywgTWVldGluZ3MgICB8fCBjb25kdWN0ZWQgbWVl dGluZ3MgICAgIHx8IA0KICAgICAgICAgIHx8fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS18fC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLXx8IA0KICAgICAgICAgIHx8LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgICAgICAgIHwtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPiANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGdW5jdGlvbmFsaXR5IA0KICAgIA0K ICAgICAgICAgICAgICBGaWd1cmUgMSA6IENhdGVnb3JpZXMgaW4gU2NhbGUtRnVuY3Rpb25hbGl0 eSBTcGFjZSANCiAgICANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAgICBFeHBpcmVzIE5v dmVtYmVyIDIwMDEgICAgICAgICAgICAgICAgICAgICBbOF0gDQwNCkludGVybmV0IERyYWZ0ICAg ICBDb3Vyc2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgTWF5IDIwMDEgDQog ICAgDQogICAgDQo2LiAgICAgQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJvbCBNb2RlbHMgDQogICAg DQogICBUaGUgY29uZmVyZW5jaW5nIHNjZW5hcmlvcyBpbiBTZWN0aW9uIDUgY2FuIGVhc2lseSBi ZSBtYXBwZWQgb250byANCiAgIG1vZGVscyBmb3IgcmVhbGl6ZSBjb25mZXJlbmNlIGNvdXJzZSBj b250cm9sIHJlYWxpemF0aW9uIHdpdGggDQogICByZXNwZWN0IHRvIHRoZSBmdW5jdGlvbmFsaXRp ZXMgcHJlc2VudGVkIGluIFNlY3Rpb24gMi4gDQogICAgDQo2LjEuICAgTG9vc2UgQ29uZmVyZW5j ZSBDb3Vyc2UgQ29udHJvbCANCiAgICANCiAgICdMb29zZScgY29uZmVyZW5jZSBjb3Vyc2UgY29u dHJvbCAoYWxzbyByZWZlcnJlZCB0byBhcyAnbGlnaHQtd2VpZ2h0IA0KICAgc2Vzc2lvbiBjb250 cm9sJyBbM10pIGlzIHRoZSBtb2RlbCBhcHBsaWNhYmxlIGZvciB0aGUgc2ltcGxlIA0KICAgY29u ZmVyZW5jaW5nIHNjZW5hcmlvIGNhdGVnb3J5IG9mIFNlY3Rpb24gNS4xLiAgDQogICAgDQogICBI ZW5jZSwgdGhpcyBjb250cm9sIG1vZGVsIGxhY2tzIG9mIGV4cGxpY2l0IG1lbWJlcnNoaXAgYW5k IA0KICAgYXBwbGljYXRpb24gc2Vzc2lvbiBjb250cm9sLiBGdXJ0aGVybW9yZSwgZmxvb3IgY29u dHJvbCBmYWNpbGl0aWVzIA0KICAgYXJlIG5vdCBwcm92aWRlZC4gSG93ZXZlciwgbWVtYmVyc2hp cCBpbmZvcm1hdGlvbiBtaWdodCBiZSBnYXRoZXJlZCANCiAgIGR1cmluZyBydW50aW1lIG9mIHRo ZSBzZXNzaW9uLCBjb21wYXJhYmxlIHdpdGggdGhlIGJsdWUgc2hlZXRzIG9mIA0KICAgYXR0ZW5k ZWVzLiANCiAgICANCiAgIFVzdWFsbHksIGdyb3VwIGtleSBtZWNoYW5pc21zIGFyZSBhbHNvIG1p c3NpbmcgZm9yIG1lbWJlcnNoaXAgDQogICBlbmZvcmNlbWVudCBhZnRlciBzdGFydGluZyB0aGUg Y29uZmVyZW5jZS4gDQogICAgDQo2LjIuICAgVGlnaHQgQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJv bCANCiAgICANCiAgICdUaWdodCcgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBbM10gaXMgdGhl IG1vZGVsIGFwcGxpY2FibGUgZm9yIA0KICAgdGhlIGZsb29yIGNvbnRyb2wgY29uZmVyZW5jaW5n IHNjZW5hcmlvIGNhdGVnb3JpZXMgb2YgU2VjdGlvbiA1LjIuIA0KICAgIA0KICAgSGVuY2UsIGFk ZGl0aW9uYWwgZmxvb3IgY29udHJvbCBpbmZvcm1hdGlvbiBvZiB0aGUgY29uZmVyZW5jZSANCiAg IHByb2ZpbGUgb3Igc3RhdGljYWxseSBpbXBsZW1lbnRlZCBhcHBsaWNhdGlvbiBzZW1hbnRpYyBh cmUgdXNlZCBmb3IgDQogICBpbXBsZW1lbnRpbmcgZmxvb3IgY29udHJvbCB0byBtYXAgJ3NvY2lh bCBwcm90b2NvbCcgc2VtYW50aWNzIG9udG8gDQogICB0aGUgZGlzdHJpYnV0ZWQgc2NlbmFyaW8u IEV4YWN0IG1lbWJlcnNoaXAgYW5kIGFwcGxpY2F0aW9uIHNlc3Npb24gDQogICBpbmZvcm1hdGlv biBpcyB1c3VhbGx5IHByb3ZpZGVkIHRvZ2V0aGVyIHdpdGggbWVtYmVyc2hpcCBlbmZvcmNlbWVu dCANCiAgIGJhc2VkIG9uIGZsb29yIGNvbnRyb2wgcG9saWNpZXMgZHVyaW5nIHJ1bnRpbWUgb2Yg dGhlIGNvbmZlcmVuY2UuIA0KICAgIA0KNi4zLiAgICdKZWxseS1saWtlJyBDb25mZXJlbmNlIENv dXJzZSBDb250cm9sIA0KICAgIA0KICAgQXMgYSBjb21iaW5hdGlvbiBvZiB0aGUgbG9vc2UgYW5k IHRpZ2h0IGNvbnRyb2wgbW9kZWwgb2YgU2VjdGlvbiANCiAgIDYuMS4gYW5kIDYuMi4sICdqZWxs eS1saWtlJyBjb3Vyc2UgY29udHJvbCBpcyBjb25zaWRlcmVkIGZvciByaWNoIA0KICAgY29uZmVy ZW5jaW5nIChzZWUgU2VjdGlvbiA1LjMuKSByZWFsaXphdGlvbi4gDQogICAgDQogICBUaGUgdGln aHQgY29udHJvbCBtb2RlbCBpcyBhcHBsaWVkIGZvciB0aGUgYWN0aXZlIHBhcnRpY2lwYW50cyBp biANCiAgIHRoZSBjb25mZXJlbmNlLCB3aGlsZSBhIGxvb3NlIGNvbnRyb2wgbW9kZWwgaXMgdXNl ZCBmb3IgdGhlIHBhc3NpdmUgDQogICBvbmVzLiBJbiBhZGRpdGlvbiB0byB0aGUgZnVuY3Rpb25h bGl0eSBmb3IgdGhlIHNwZWNpZmljIHVzZXIgZ3JvdXAsIA0KICAgaS5lLiwgYWN0aXZlIG9yIHBh c3NpdmUsIG1lY2hhbmlzbXMgdG8gc3VwcG9ydCBtb2RlIGNoYW5nZXMgZnJvbSANCiAgIGFjdGl2 ZSB0byBwYXNzaXZlIGFuZCB2aWNlIHZlcnNhIG1pZ2h0IGJlIHJlcXVpcmVkIHdpdGhvdXQgDQog ICBkaXN0dXJiYW5jZSwgaS5lLiwgaW50ZXJydXB0aW9uLCBvZiB0aGUgcnVubmluZyBjb25mZXJl bmNlLiANCiAgICANCiAgIERpZmZlcmVudCBwb2xpY2llcyBmb3IgdGhpcyBtb2RlIGNoYW5nZSBz aG91bGQgYmUgZmVhc2libGUsIHN1Y2ggYXMgDQogICB1cG9uIGludml0YXRpb24gYnkgaW5kaXZp ZHVhbCBhY3RpdmUgcGFydGljaXBhbnRzIG9yIHVwb24gcmVxdWVzdCBvZiANCiAgIHRoZSBwYXNz aXZlIHBhcnRpY2lwYW50LiANCiAgICANCjcuICAgICBFeGlzdGluZyBTb2x1dGlvbnMgDQogICAg DQogICAgIA0KVHJvc3NlbiAgICAgICAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAg ICAgICAgICAgICAgICAgICAgWzldIA0MDQpJbnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRy b2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KICAg VGhlIGZvbGxvd2luZyBzZWN0aW9uIGlzIGJyaWVmbHkgZXZhbHVhdGluZyBleGlzdGluZyBjb25m ZXJlbmNpbmcgDQogICBzb2x1dGlvbnMgd2l0aCByZXNwZWN0IHRvIHRoZWlyIGNvbmZlcmVuY2Ug Y291cnNlIGNvbnRyb2wgDQogICBmdW5jdGlvbmFsaXR5LiBOb3RlIHRoYXQgdGhpcyBwcmVzZW50 YXRpb24gaXMgcmVzdHJpY3RlZCB0byBzeXN0ZW1zIA0KICAgYmFzZWQgb24gY2VydGFpbiBzdGFu ZGFyZHMsIGhlbmNlIHRoaXMgbGlzdCBkb2VzIG5vdCBjbGFpbSB0byBiZSBhbiANCiAgIGV4aGF1 c3RpdmUgcmV2aWV3IG9mIGV4aXN0aW5nIGNvbmZlcmVuY2luZyBzeXN0ZW1zLiANCiAgICANCiAg IFRoZSBmb2xsb3dpbmcsIGludGVydHdpbmVkLCBjcml0ZXJpYSBhcmUgdXNlZCB0byBldmFsdWF0 ZSB0aGVzZSANCiAgIHNvbHV0aW9uczogDQogICBvIFByb3ZpZGVkIEZ1bmN0aW9uYWxpdHk6IFdo YXQgZnVuY3Rpb25hbGl0eSBpcyBwcm92aWRlZCB3aXRoICANCiAgICAgcmVzcGVjdCB0byBUYWJs ZSAxPyANCiAgIG8gRmxleGliaWxpdHk6IFdoYXQgc2NlbmFyaW9zIGFyZSBjb3ZlcmVkPyBXaGF0 IHBvbGljaWVzIGFyZSAgDQogICAgIHByb3ZpZGVkPyBIb3cgZmxleGlibGUgaXMgdGhlIHByb3Zp ZGVkIGZ1bmN0aW9uYWxpdHk/IA0KICAgbyBFeHRlbmRpYmlsaXR5OiBUbyB3aGF0IGV4dGVudCBj YW4gdGhlIHNvbHV0aW9uIGJlIGV4dGVuZGVkIHRvICANCiAgICAgaW50ZWdyYXRlIG5ldyBmdW5j dGlvbmFsaXR5PyANCiAgIG8gU2NhbGFiaWxpdHk6IFdoYXQgcmVzdHJpY3Rpb25zIGR1ZSB0byBh cmNoaXRlY3R1cmU/IA0KICAgIA0KNy4xLiAgIEguMzJ4IFByb3RvY29sIFN1aXRlIA0KICAgIA0K ICAgbyBGdW5jdGlvbmFsaXR5OiAgDQogICAgIC0gY2VudHJhbGl6ZWQvZGVjZW50cmFsaXplZCBj b25mZXJlbmNpbmcgDQogICAgIC0gcHJldHR5IG11Y2ggYWltaW5nIGF0IGZsb29yIGNvbnRyb2xs ZWQgY29uZmVyZW5jaW5nLCBhbHRob3VnaCAgDQogICAgICAgb25seSBjb25kdWN0ZWQvbm9uLWNv bmR1Y3RlZCBtb2RlcyBzdXBwb3J0ZWQgDQogICAgIC0gTm8gcGFzc2l2ZS9hY3RpdmUgbm90aW9u IGluIHRoZSBvcmlnaW5hbCBILjMyeCwgSC4zMzIgZXh0ZW5zaW9uICANCiAgICAgICBkb2VzbpJ0 IHN1cHBvcnQgY2hhbmdlcyBvZiBsaXN0ZW5lcnMgdG8gYWN0aXZlIHVzZXJzLiANCiAgICAgIA0K ICAgbyBGbGV4aWJpbGl0eTogIA0KICAgICAtIEZsb29yIGNvbnRyb2xsZWQgY29uZmVyZW5jaW5n IGlzIHBvb3JseSBzdXBwb3J0ZWQsIGFsdGhvdWdoIHRoZSAgDQogICAgICAgZGF0YSBjb25mZXJl bmNpbmcgcGFydCBzdXBwb3J0cyB0b2tlbnMuICANCiAgICAgLSBQcmUtZGVmaW5lZCByb2xlIG1v ZGVscywgaS5lLiwgY29uZHVjdGVkIHZlcnN1cyBub24tY29uZHVjdGVkLCAgDQogICAgICAgZm9y IGF1ZGlvdmlzdWFsIHBhcnQuICANCiAgICAgLSBObyBwb2xpY3kgZGVmaW5pdGlvbiwgZS5nLiwg dXNpbmcgYXBwcm9wcmlhdGUgcHJvZmlsZSAgDQogICAgICAgaW5mb3JtYXRpb24uIA0KICAgICAt IHJlY29uZmlndXJhdGlvbiBvZiBydW5uaW5nIGNvbmZlcmVuY2VzIHBvb3JseSBzdXBwb3J0ZWQu IA0KICAgIA0KICAgbyBFeHRlbmRpYmlsaXR5OiANCiAgICAgLSBwcmV0dHkgY2xvc2VkIHN5c3Rl bSBvZiBhIHdob2xlIHNldCBvZiBzdGFuZGFyZHMgDQogICAgDQogICBvIFNjYWxhYmlsaXR5OiB2 ZXJ5IHJlc3RyaWN0ZWQgZHVlIHRvIHRpZ2h0IGNlbnRyYWxpemVkIGNvbnRyb2wgIA0KICAgICBz dHJ1Y3R1cmUgDQogICAgDQogICBbVEJEXSBhZGQgb3RoZXIgcG9pbnRzLCBlaXRoZXIgaXRlbXMg b3Igc3ViaXRlbXMgDQogICAgDQo3LjIuICAgU0lQLWJhc2VkIFNvbHV0aW9ucyANCiAgICANCiAg IG8gRnVuY3Rpb25hbGl0eTogIA0KICAgICAtIGZsZXhpYmxlIGluaXRpYXRpb24gbW9kZWxzIFsx MV0gIA0KICAgICAtIG1lbWJlcnNoaXAgaW5mb3JtYXRpb24gdXNpbmcgUlRDUCBpbmZvcm1hdGlv biAobG9vc2UgY29udHJvbCkgb3IgICAgICANCiAgICAgICBhLXByaW9yaSBpbmZvcm1hdGlvbiAN CiAgICAgLSBubyBtZW1iZXJzaGlwIGVuZm9yY2VtZW50IA0KICAgICAtIG5vIGZsb29yIGNvbnRy b2wgDQogICAgIC0gbm8gY2FwYWJpbGl0eSByZS1uZWdvdGlhdGlvbiANCiAgICANCiAgIG8gRmxl eGliaWxpdHkvRXh0ZW5kaWJpbGl0eTogDQogICAgIA0KVHJvc3NlbiAgICAgICAgICAgICAgICAg RXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAgICBbMTBdIA0MDQpJbnRlcm5l dCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgICAgIE1h eSAyMDAxIA0KICAgIA0KICAgIA0KICAgICAtIGV4dGVuc2lvbiBwb3NzaWJsZSBieSBhZGRpbmcg Y29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCAgDQogICAgICAgZnVuY3Rpb25hbGl0eSBhcyBzZXBh cmF0ZWQgY29tcG9uZW50IGR1ZSB0byBvcGVuIHN5c3RlbSAgDQogICAgICAgY2hhcmFjdGVyIA0K ICAgICAtIG90aGVyIHNjZW5hcmlvcyBwb3NzaWJsZSBieSBhZGRpbmcgZnVuY3Rpb25hbGl0eSAN CiAgICANCiAgIG8gU2NhbGFiaWxpdHk6IGRlcGVuZHMgb24gdGhlIGluaXRpYXRpb24gbW9kZWws IGJ1dCBtb3N0IGxpa2VseSAgDQogICAgIHNpbWlsYXIgdG8gdGhlIHNpbXBsZSBjb25mZXJlbmNp bmcgY2F0ZWdvcnkgKHNlZSBTZWN0aW9uIDUuMSkgDQogICAgDQogICBbVEJEXSBhZGQgb3RoZXIg cG9pbnRzLCBlaXRoZXIgaXRlbXMgb3Igc3ViaXRlbXMgDQogICAgDQogICAgDQo4LiAgICAgTmV4 dCBTdGVwcyANCiAgICANCiAgIFRoZSBmb2xsb3dpbmcgaXRlbXMgYXJlIHByb3Bvc2VkIGFzIG5l eHQgc3RlcHM6IA0KICAgIA0KICAgbyBEZWZpbml0aW9uIG9mIHJlcXVpcmVtZW50cyANCiAgIG8g UHJvcG9zYWwgZm9yIHByb3ZpZGVkIHNlcnZpY2VzIA0KICAgbyBQcm9wb3NhbCBvZiBwcm90b2Nv bCBzb2x1dGlvbnMgDQogICBvIEFuYWx5c2lzIG9mIHByb3RvY29sIHNvbHV0aW9ucyANCiAgIG8g UmVjb21tZW5kYXRpb24gb2YgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBzZXJ2aWNlIGFuZCBw cm90b2NvbCANCiAgICANCiAgIEEgY3J1Y2lhbCBwYXJ0IG9mIHRoZSBhbmFseXNpcyB3b3JrIGlz IHRvIHN0dWR5IGV4aXN0aW5nIHNvbHV0aW9ucyANCiAgIHdpdGggcmVzcGVjdCB0byB0aGVpciBh cHBsaWNhYmlsaXR5IGFuZCB0aGVpciBhbGlnbm1lbnQgd2l0aCB0aGUgDQogICBkZWZpbmVkIHNj b3BlIG9mIFNlY3Rpb24gMiBhbmQgdGhlIHByb2JsZW0gc3RhdGVtZW50IGluIFNlY3Rpb24gMy4g DQogICAgDQogICAgDQo5LiAgICAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgDQogDQogICBUaGlz IGRvY3VtZW50IG1lcmVseSBkaXNjdXNzZXMgcHJvYmxlbSBzdGF0ZW1lbnRzIG1vdGl2YXRpbmcg dGhlIA0KICAgbmVlZCBmb3IgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBtZWNoYW5pc21zLiBT ZWN1cml0eSBpcyBhbiBpc3N1ZSANCiAgIGZvciBjb25mZXJlbmNlIGNvdXJzZSBjb250cm9sIGJ1 dCBpcyBjb25zaWRlcmVkIGluIHN1YnNlcXVlbnQgDQogICBzb2x1dGlvbi1zcGFjZSBkb2N1bWVu dHMuIA0KICAgIA0KICAgIA0KMTAuICAgIEFja25vd2xlZGdlbWVudHMgDQogICAgDQogICBJIHdv dWxkIGxpa2UgdG8gYWNrbm93bGVkZ2UgdGhlIHBhcnRpY2lwYW50cyBvZiB0aGUgbWFpbGluZyBs aXN0IA0KICAgdGhhdCB3YXMgc2V0IHVwIHRvIGRpc2N1c3MgdGhlIHRoaXMgZG9jdW1lbnQuIFRo ZWlyIGNvbnRyaWJ1dGlvbnMgDQogICBhbmQgYWN0aXZlIHBhcnRpY2lwYXRpb24gaW4gdGhlIGRp c2N1c3Npb24gb24gdGhlIG1haWxpbmcgbGlzdCB3ZXJlIA0KICAgdmVyeSB1c2VmdWwgaW4gdGhl IHByZXBhcmF0aW9uIG9mIHRoaXMgZG9jdW1lbnQuIA0KICAgIA0KICAgIA0KMTEuICAgIFJlZmVy ZW5jZXMgDQogICAgDQogICBbMV0gIEMuIEJvcm1hbm4sIEouIE90dCwgRC4gS3V0c2NoZXIsIEQu IFRyb3NzZW4sICJTaW1wbGUgQ29uZmVyZW5jZSANCiAgICAgICAgQ29udHJvbCBQcm90b2NvbCCW IFNlcnZpY2UgU3BlY2lmaWNhdGlvbiIsIGRyYWZ0LWlldGYtbW11c2ljLQ0KICAgICAgICBzY2Nw LTAxLnR4dCwgV29yayBpbiBQcm9ncmVzcywgRmVicnVhcnkgMjAwMSANCiAgICANCiAgIFsyXSAg SC4gRXJpa3Nzb24sICJNQk9ORTogVGhlIE11bHRpY2FzdCBCYWNrYm9uZSIsIENvbW11bmljYXRp b25zIG9mIA0KICAgICAgICB0aGUgQUNNLCBWb2wuMzcgTm8uOCwgcHAuNTQtNjAsIEF1Z3VzdCAx OTk0IA0KIA0KICAgICANClRyb3NzZW4gICAgICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIg MjAwMSAgICAgICAgICAgICAgICAgICAgWzExXSANDA0KSW50ZXJuZXQgRHJhZnQgICAgIENvdXJz ZSBDb250cm9sIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAgICBNYXkgMjAwMSANCiAgICANCiAg ICANCiAgIFszXSAgTS4gSGFuZGxleSwgSi4gQ3Jvd2Nyb2Z0LCBDLiBCb3JtYW5uLCAiVGhlIElu dGVybmV0IE11bHRpbWVkaWEgDQogICAgICAgIENvbmZlcmVuY2luZyBBcmNoaXRlY3R1cmUiLCBk cmFmdC1pZXRmLW1tdXNpYy1jb25mYXJjaC0wMy50eHQsIA0KICAgICAgICBXb3JrIEluIFByb2dy ZXNzLCBKdWx5IDIwMDAgIA0KICAgIA0KICAgWzRdICBNLiBIYW5kbGV5LCBWLiBKYWNvYnNvbiwg IlNEUDogU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCIsIA0KICAgICAgICBSRkMgMjMyNywg QXByaWwgMTk5OCANCiAgICANCiAgIFs1XSAgTS4gSGFuZGxleSwgSC4gU2NodWx6cmlubmUsIEUu IFNjaG9vbGVyLCBKLiBSb3NlbmJlcmcsICJTSVA6IA0KICAgICAgICBTZXNzaW9uIEluaXRpYXRp b24gUHJvdG9jb2wiLCBSRkMgMjU0MywgTWFyY2ggMTk5OSANCiAgICANCiAgIFs2XSAgTS4gSGFu ZGxleSwgQy4gUGVya2lucywgRS4gV2hlbGFuLCAiU2Vzc2lvbiBhbm5vdW5jZW1lbnQgDQogICAg ICAgIHByb3RvY29sIiwgUkZDIDI5NzQsIE9jdG9iZXIgMjAwMCANCiAgICANCiAgIFs3XSAgSVRV LVQsICJWaXN1YWwgVGVsZXBob25lIFN5c3RlbXMgYW5kIEVxdWlwbWVudCBmb3IgTG9jYWwgQXJl YSANCiAgICAgICAgTmV0d29ya3Mgd2l0aCBOb24tR3VhcmFudGVlZCBRdWFsaXR5IG9mIFNlcnZp Y2UiLCBJVFUtVCANCiAgICAgICAgUmVjb21tZW5kYXRpb24gSC4zMjMsIDIwMDAgDQogICAgDQog ICBbOF0gIElUVS1ULCAiSC4zMjMgZXh0ZW5kZWQgZm9yIGxvb3NlbHkgY291cGxlZCBjb25mZXJl bmNlcyIsIElUVS1UIA0KICAgICAgICBSZWNvbW1lbmRhdGlvbiBILjMzMiwgU2VwdGVtYmVyIDE5 OTggDQogICAgDQogICBbOV0gIEQuIEt1dHNjaGVyLCBKLiBPdHQsIEMuIEJvcm1hbm4sICJSZXF1 aXJlbWVudHMgZm9yIFNlc3Npb24gDQogICAgICAgIERlc2NyaXB0aW9uIGFuZCBDYXBhYmlsaXR5 IE5lZ290aWF0aW9uIiwgZHJhZnQtaWV0Zi1tbXVzaWMtDQogICAgICAgIHNkcG5nLXJlcS0wMC50 eHQsIFdvcmsgSW4gUHJvZ3Jlc3MsIEZlYnJ1YXJ5IDIwMDEgDQogDQogICBbMTBdIEouIE90dCwg Qy4gUGVya2lucywgRC4gS3V0c2NoZXIsICJBIE1lc3NhZ2UgQnVzIGZvciBMb2NhbCANCiAgICAg ICAgQ29vcmRpbmF0aW9uIiwgZHJhZnQtaWV0Zi1tbXVzaWMtbWJ1cy10cmFuc3BvcnQtMDQudHh0 LCBXb3JrIEluIA0KICAgICAgICBQcm9ncmVzcywgRmVicnVhcnkgMjAwMSANCiANCiAgIFsxMV0g Si4gUm9zZW5iZXJnLCBILiBTY2h1bHpyaW5uZSwgIk1vZGVscyBmb3IgTXVsdGkgUGFydHkgDQog ICAgICAgIENvbmZlcmVuY2luZyBpbiBTSVAiLCBkcmFmdC1yb3NlbmJlcmctc2lwLWNvbmZlcmVu Y2luZy1tb2RlbHMtDQogICAgICAgIDAwLnR4dCwgV29yayBJbiBQcm9ncmVzcywgTm92ZW1iZXIg MjAwMCANCiANCiAgIFsxMl0gSC4gU2NodWx6cmlubmUsIFMuIENhc25lciwgUi4gRnJlZGVyaWNr LCBWLiBKYWNvYnNvbiwgIlJUUDogQSANCiAgICAgICAgVHJhbnNwb3J0IFByb3RvY29sIGZvciBS ZWFsLVRpbWUgQXBwbGljYXRpb25zIiwgUkZDIDE4ODksIA0KICAgICAgICBKYW51YXJ5IDE5OTYg DQogDQogICBbMTNdIEQuIFRyb3NzZW4sICJTY2FsYWJsZSBGbG9vciBDb250cm9sIGluIENvbmZl cmVuY2luZyANCiAgICAgICAgRW52aXJvbm1lbnRzOiBUaGUgUkJvbmUgQXBwcm9hY2giLCAybmQg SVAgVGVsZXBob255IFdvcmtzaG9wLCANCiAgICAgICAgTmV3IFlvcmssIEFwcmlsIDIwMDEgDQog ICAgDQogICAgDQogICAgDQpBdXRob3IncyBBZGRyZXNzIA0KICAgIA0KICAgRGlyayBUcm9zc2Vu IA0KICAgTm9raWEgUmVzZWFyY2ggDQogICA1IFdheXNpZGUgUm9hZCANCiAgIEJ1cmxpbmd0b24s IE1BIDAyNDc0IFVTQSAgICAgIA0KICAgUGhvbmU6ICAxLTc4MS05OTMtMzYwNSANCiAgIEVtYWls OiAgZGlyay50cm9zc2VuQG5va2lhLmNvbSANCiAgICANCiAgICANCkZ1bGwgQ29weXJpZ2h0IFN0 YXRlbWVudCANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAgICBFeHBpcmVzIE5vdmVtYmVy IDIwMDEgICAgICAgICAgICAgICAgICAgIFsxMl0gDQwNCkludGVybmV0IERyYWZ0ICAgICBDb3Vy c2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgTWF5IDIwMDEgDQogICAgDQog ICAgDQogICAgDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAxKS4g QWxsIFJpZ2h0cyBSZXNlcnZlZC4gDQogICAgDQogICBUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xh dGlvbnMgb2YgaXQgbWF5IGJlIGNvcGllZCBhbmQgZnVybmlzaGVkIHRvIA0KICAgb3RoZXJzLCBh bmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0IGNvbW1lbnQgb24gb3Igb3RoZXJ3aXNlIGV4cGxhaW4g aXQgDQogICBvciBhc3Npc3QgaW4gaXRzIGltcGxlbWVudGF0aW9uIG1heSBiZSBwcmVwYXJlZCwg Y29waWVkLCBwdWJsaXNoZWQgDQogICBhbmQgZGlzdHJpYnV0ZWQsIGluIHdob2xlIG9yIGluIHBh cnQsIHdpdGhvdXQgcmVzdHJpY3Rpb24gb2YgYW55IA0KICAga2luZCwgcHJvdmlkZWQgdGhhdCB0 aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwYXJhZ3JhcGggDQogICBhcmUgaW5j bHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLiBIb3dldmVyLCB0 aGlzIA0KICAgZG9jdW1lbnQgaXRzZWxmIG1heSBub3QgYmUgbW9kaWZpZWQgaW4gYW55IHdheSwg c3VjaCBhcyBieSByZW1vdmluZyANCiAgIHRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5j ZXMgdG8gdGhlIEludGVybmV0IFNvY2lldHkgb3Igb3RoZXIgDQogICBJbnRlcm5ldCBvcmdhbml6 YXRpb25zLCBleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUgcHVycG9zZSBvZiANCiAgIGRldmVsb3Bp bmcgSW50ZXJuZXQgc3RhbmRhcmRzIGluIHdoaWNoIGNhc2UgdGhlIHByb2NlZHVyZXMgZm9yIA0K ICAgY29weXJpZ2h0cyBkZWZpbmVkIGluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgcHJvY2VzcyBt dXN0IGJlIA0KICAgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBpdCBpbnRv IGxhbmd1YWdlcyBvdGhlciB0aGFuIA0KICAgRW5nbGlzaC4gDQogICAgDQogICBUaGUgbGltaXRl ZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3ZlIGFyZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90IGJl IA0KICAgcmV2b2tlZCBieSB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBpdHMgc3VjY2Vzc29ycyBv ciBhc3NpZ25zLiANCiAgICANCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaGVyZWluIGlzIHByb3ZpZGVkIG9uIGFuIA0KICAgIkFTIElTIiBiYXNpcyBhbmQg VEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyANCiAgIFRB U0sgRk9SQ0UgRElTQ0xBSU1TIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIElO Q0xVRElORyANCiAgIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNF IE9GIFRIRSBJTkZPUk1BVElPTiANCiAgIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklH SFRTIE9SIEFOWSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgDQogICBNRVJDSEFOVEFCSUxJVFkgT1Ig RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIA0KICAgIA0KQWNrbm93bGVkZ2VtZW50 IA0KICAgIA0KICAgRnVuZGluZyBmb3IgdGhlIFJGQyBlZGl0b3IgZnVuY3Rpb24gaXMgY3VycmVu dGx5IHByb3ZpZGVkIGJ5IHRoZSANCiAgIEludGVybmV0IFNvY2lldHkuIA0KICAgICANClRyb3Nz ZW4gICAgICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAwMSAgICAgICAgICAgICAgICAg ICAgWzEzXSANDA== ------_=_NextPart_001_01C12A78.DBC2BFA0-- >From owner-rmt@listserv.lbl.gov Tue Aug 21 12:57:00 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7LJuhC07820; Tue, 21 Aug 2001 12:56: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.11.2/8.11.2) with ESMTP id f7LJufV07816 for ; Tue, 21 Aug 2001 12:56:41 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LJuem00277 for ; Tue, 21 Aug 2001 12:56:41 -0700 (PDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LJud500271 for ; Tue, 21 Aug 2001 12:56:40 -0700 (PDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7LJvkI27485 for ; Tue, 21 Aug 2001 14:57:46 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Aug 2001 14:56:38 -0500 content-class: urn:content-classes:message Subject: RE: Session control protocol instantiation discussion within the IETF Date: Tue, 21 Aug 2001 14:55:58 -0500 Message-ID: X-MS-Has-Attach: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-TNEF-Correlator: Thread-Topic: RE: Session control protocol instantiation discussion within the IETF Thread-Index: AcEqe0stkykBmLE2SC+HdMALGd5lmQ== X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 From: "Trossen Dirk (NRC/Boston)" To: , "'Michael Luby'" Cc: "'Rob Lanphier'" , "'Ross Finlayson'" , "'Rmt@Lbl. Gov'" , , , "'ietf-floor control'" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by SpamWall.lbl.gov id f7LJugV07817 Sender: owner-rmt@lbl.gov Precedence: bulk Sorry if you received multiple copies. I'm resending this due to mailing problems. ------------------------------------------------------------------------ Hi all, as announced on the MMUSIC mailing list, a couple of people being interested in conference course control met on Wednesday August 8th (10-11pm) during the London IETF meeting to discuss further steps in this direction. The following persons were present during this informal meeting: Jun-Won Lee, Shin-Gak Kang, Jonathan Rosenberg, Eunsook Kim, Colin Perkins, Joerg Ott, Dirk Kutscher, Dirk Trossen During the meeting, a general interest in this topic was expressed by the attendents. However, the concern was raised (by Jonathan, Joerg, and Colin) that the scope of the work has to be defined very carefully. Especially Jonathan expressed interest in 'doable' solutions, i.e., covering rather simple centralized conferencing scenarios first rather than defining a wide scope of the work. The following steps have been proposed to be undertaken in this direction: - provision of a problem statement document - submission to mailing list(s) - creation of own discussion list for this topic The problem statement document should be created by a circle of people being interested in this topic and willing to contribute to this work. The discussion of the problem statement should end in a decision how to bring this topic to the IETF within the therein defined scope, either within the charter of existing WGs or by organizing a BOF. Since similar discussions about future session control efforts have been undertaken within the RMT WG, I'm sending this mail also to this list to invite interested people to join the discussion. Enclosed you find the current document which was meant as a problem statement for conference course control. This document is far from being completed (it was not submitted as a draft although it is written in Internet draft style) but it is intended as a basis for discussion to reach final document status. Any comments are welcome. Best Regards, Dirk Trossen ----------------------- Dirk Trossen Nokia Research Center 5 Wayside Road Burlington, MA 01803 Tel: +1 (781) 993 3605 Fax: +1 (781) 993 1907 mob: +1 (617) 794 7041 ----------------------- > -----Original Message----- > From: ext Allison Mankin [mailto:mankin@ISI.EDU] > Sent: Wednesday, August 08, 2001 11:49 PM > To: Michael Luby > Cc: Rob Lanphier; Ross Finlayson; Rmt@Lbl. Gov; confctrl@ISI.EDU; > Allison Mankin; sob@harvard.edu > Subject: Re: Session control protocol instantiation discussion within > the IETF > > > Mike, > > We ADs would be happy to talk with you about this sometime (but after > we all recover from IETF). > > Having had one hallway talk with you while you were in London, > I think there is some value to discussing session work (without > prejudging if it would extend an existing charter or start up in > a new situation of some sort). > > Mike Luby wrote: > > All, > > I unfortunately was only at the IETF for a couple of days, > and am back in > > the Bay Area now. I would first like to talk with the > transport area > > directorate (Scott and Allison) to get some advice on this, and then > > probably followup with a conference call with whoever is > interested. Would > > a conference call be ok with you Rob, Ross (and whoever else is > > interested?). > > Mike > > > >From owner-rmt@listserv.lbl.gov Tue Aug 21 12:59:09 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7LJx1207840; Tue, 21 Aug 2001 12:59: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.11.2/8.11.2) with ESMTP id f7LJx0V07836 for ; Tue, 21 Aug 2001 12:59:00 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LJwxl00897 for ; Tue, 21 Aug 2001 12:58:59 -0700 (PDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LJww500891 for ; Tue, 21 Aug 2001 12:58:58 -0700 (PDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7LJx2i15424 for ; Tue, 21 Aug 2001 14:59:02 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Aug 2001 14:58:56 -0500 content-class: urn:content-classes:message Subject: RE: Session control protocol instantiation discussion within the IETF Date: Tue, 21 Aug 2001 14:57:46 -0500 Message-ID: X-MS-Has-Attach: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C12A7B.8C236B40" X-MS-TNEF-Correlator: Thread-Topic: RE: Session control protocol instantiation discussion within the IETF Thread-Index: AcEqe4uEShQMW6crRN2OATPOjXiPhA== X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 From: "Trossen Dirk (NRC/Boston)" To: , "'Michael Luby'" Cc: "'Rob Lanphier'" , "'Ross Finlayson'" , "'Rmt@Lbl. Gov'" , , , "'ietf-floor control'" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C12A7B.8C236B40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry, here's the document I was talking about in the previous mail. ------_=_NextPart_001_01C12A7B.8C236B40 Content-Type: text/plain; name="draft-trossen-problem-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-trossen-problem-00.txt Content-Disposition: attachment; filename="draft-trossen-problem-00.txt" DQpJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlICAgICAgICAgICAgICAgICAgRC4gVHJv c3NlbiAoRWRpdG9yKSANCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIE5va2lhIFJlc2VhcmNoIA0KZHJhZnQtdHJvc3Nlbi1wcm9ibGVtLTAwLnR4 dCAgICAgICAgICAgICAgICAgICAgICAgICAgICAxMS4gTWF5IDIwMDEgDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlczogTm92ZW1iZXIgMjAwMSAN CiANCiANCiAgICAgICAgICAgICAgICBDb25mZXJlbmNlIENvdXJzZSBDb250cm9sIFByb2JsZW0g U3RhdGVtZW50IA0KIA0KIA0KU3RhdHVzIG9mIHRoaXMgTWVtbyANCiANCiAgIFRoaXMgZG9jdW1l bnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2UgDQogICB3 aXRoIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4gDQogICAgDQogICAg DQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5l dCBFbmdpbmVlcmluZyANCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMg d29ya2luZyBncm91cHMuICBOb3RlIHRoYXQgICAgICANCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxz byBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLiAN CiAgICANCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBh IG1heGltdW0gb2Ygc2l4IA0KICAgbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQs IG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgDQogICBhdCBhbnkgdGltZS4gIEl0IGlz IGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyANCiAgIHJlZmVyZW5jZSBt YXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4i IA0KICAgIA0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFj Y2Vzc2VkIGF0IA0KICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0 cy50eHQgDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMg Y2FuIGJlIGFjY2Vzc2VkIGF0IA0KICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5o dG1sLiANCiAgICANCkNvcHlyaWdodCBOb3RpY2UgDQogICAgDQogICBDb3B5cmlnaHQgKGMpIFRo ZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAxKS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4gDQogICAgDQpB YnN0cmFjdCANCiAgICANCiAgIEFzIHBhcnQgb2YgdGhlIEludGVybmV0IE11bHRpbWVkaWEgQ29u ZmVyZW5jaW5nIEFyY2hpdGVjdHVyZSBbM10sIA0KICAgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJv bCBkZWFscyB3aXRoIHRoZSBjb250cm9sIG9mIHJ1bm5pbmcgDQogICBjb25mZXJlbmNlcyBhZnRl ciB0aGUgY3JlYXRpb24gb2YgdGhlIGluaXRpYWwgY29uZmVyZW5jZSBzdGF0ZSB3aXRoIA0KICAg cmVzcGVjdCB0byB0aGUgbWVtYmVyc2hpcCBhbmQgYWNjZXNzIGNvbnRyb2wgZHVyaW5nIHJ1bnRp bWUgb2YgdGhlIA0KICAgc2Vzc2lvbi4gVGhlIHNwZWN0cnVtIG9mIHNjZW5hcmlvcyByZWFjaGVz IGZyb20gc21hbGwgbXVsdGlwYXJ0eSANCiAgIGdhdGhlcmluZ3MgdXAgdG8gbGFyZ2Ugc2NhbGVk IG1lZXRpbmdzIHdpdGggYSBoaWdoIGZsdWN0dWF0aW9uIG9mIA0KICAgdXNlcpJzIG1lbWJlcnNo aXAgYW5kIGFjdGl2aXR5LiANCiAgICANCiAgIFRoaXMgZG9jdW1lbnQgaWRlbnRpZmllcyB0aGUg cHJvYmxlbSBhcmVhIHRvIGRlZmluZSB0aGUgc2NvcGUgb2YgYSANCiAgIGNvbmZlcmVuY2UgY291 cnNlIGNvbnRyb2wgd29ya2luZyBncm91cCBpbiB0aGUgSUVURi4gDQogDQogICAgIA0KVHJvc3Nl biAgICAgICAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAg ICAgWzFdIA0MDQpJbnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0 ZW1lbnQgICAgICAgICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KVGFibGUgb2YgQ29udGVudHMg DQogICAgDQogICAxLiBJbnRyb2R1Y3Rpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4yIA0KICAgMi4gRGVmaW5pdGlvbiBvZiBUZXJtcy4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMyANCiAgIDMuIFNjb3BlLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQgDQog ICA0LiBQcm9ibGVtIFN0YXRlbWVudC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi40IA0KICAgNS4gQ29uZmVyZW5jaW5nIFNjZW5hcmlvcy4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNSANCiAgIDUuMS4gIFNpbXBsZSBDb25mZXJlbmNp bmcuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUgDQogICA1LjEuMS4g IEV4YW1wbGVzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li42IA0KICAgNS4yLiAgRmxvb3IgQ29udHJvbGxlZCBDb25mZXJlbmNpbmcuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uNiANCiAgIDUuMi4xLiAgRXhhbXBsZXMuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYgDQogICA1LjMuICBSaWNoIENvbmZl cmVuY2luZy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42IA0KICAg NS4zLjEuICBFeGFtcGxlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uNyANCiAgIDUuNC4gIFN1bW1hcnkgb2YgQ2hhcmFjdGVyaXN0aWNzLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcgDQogICA2LiBDb25mZXJlbmNlIENvdXJzZSBDb250 cm9sIE1vZGVscy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45IA0KICAgNi4xLiAgTG9v c2UgQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJvbC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u OSANCiAgIDYuMi4gIFRpZ2h0IENvbmZlcmVuY2UgQ291cnNlIENvbnRyb2wuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjkgDQogICA2LjMuICAnSmVsbHktbGlrZScgQ29uZmVyZW5jZSBDb3Vy c2UgQ29udHJvbC4uLi4uLi4uLi4uLi4uLi4uLi4uLi45IA0KICAgNy4gRXhpc3RpbmcgU29sdXRp b25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOSANCiAgIDcu MS4gIEguMzJ4IFByb3RvY29sIFN1aXRlLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uMTAgDQogICA3LjIuICBTSVAtYmFzZWQgU29sdXRpb25zLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwIA0KICAgOC4gTmV4dCBTdGVwcy4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMSANCiAgIDkuIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTEg DQogICAxMC4gIEFja25vd2xlZGdlbWVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjExIA0KICAgMTEuICBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMSANCiAgICANCiAgICANCjEuICAgICBJbnRy b2R1Y3Rpb24gDQogICAgDQogICBJbnRlcmFjdGl2ZSBjb2xsYWJvcmF0aXZlIHNjZW5hcmlvcyBs aWtlIHJlbW90ZSBtZWV0aW5ncywgdmlydHVhbCANCiAgIGNsYXNzcm9vbXMsIG9yIHNoYXJpbmcg YXBwbGljYXRpb25zIHZpYSB0aGUgSW50ZXJuZXQgaGF2ZSBiZWNvbWUgDQogICBtb3JlIGFuZCBt b3JlIHBvcHVsYXIgaW4gdGhlIHBhc3QgdGVuIHllYXJzLiANCiAgICANCiAgIEFjY29yZGluZyB0 byBbM10sIHRoZSB0ZXJtICdjb25mZXJlbmNpbmcnIGlzIGNvbnNpZGVyZWQgaW4gdGhlIA0KICAg cmVtYWluZGVyIG9mIHRoaXMgZG9jdW1lbnQgYXMgc3luY2hyb25vdXMsIHJlYWwtdGltZSBjb21t dW5pY2F0aW9uLCANCiAgIHNwZWNpZmljYWxseSBpbmNsdWRpbmcgYXVkaW8gYW5kIHZpZGVvIG1l ZGlhIGJ1dCBhbHNvIHNoYXJlZCBkYXRhIA0KICAgbWVkaWEgc3VjaCBhcyB3aGl0ZWJvYXJkcywg YW1vbmcgYSBzZXQgb2YgbWVtYmVycy4gU2V2ZXJhbCwgcHJvYmFibHkgDQogICBpbmRlcGVuZGVu dGx5IGltcGxlbWVudGVkLCBhZ2VudHMgZm9yIG1lZGlhIGhhbmRsaW5nIGFuZCBjb250cm9sIA0K ICAgcHVycG9zZXMgaGF2ZSB0byBiZSBjb29yZGluYXRlZCBhbmQgc3luY2hyb25pemVkIGR1cmlu ZyBydW50aW1lIG9mIA0KICAgdGhlIGNvbmZlcmVuY2UsIHJlZmVycmVkIHRvIGFzICdjb25mZXJl bmNlIGNvdXJzZSBjb250cm9sJyBpbiB0aGUgDQogICBmb2xsb3dpbmcsIGFmdGVyIGNyZWF0aW5n IHRoZSBpbml0aWFsIGNvbmZlcmVuY2Ugc3RhdGUgYXMgcGFydCBvZiANCiAgIHRoZSBjb25mZXJl bmNpbmcgc2V0dXAgZnVuY3Rpb25hbGl0eS4gVGhlIHByb3ZpZGVkIGZ1bmN0aW9uYWxpdHkgDQog ICB3aXRoIHJlc3BlY3QgdG8gY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCB1c3VhbGx5IGRlcGVu ZHMgb24gdGhlIA0KICAgY29uc2lkZXJlZCBzY2VuYXJpbyBpbiB3aGljaCBpdCBpcyBuZWVkZWQu ICANCiAgICANCiAgIEluIHRoZSBmb2xsb3dpbmcsIHRoZSBzY29wZSBvZiBjb25mZXJlbmNpbmcg Y291cnNlIGNvbnRyb2wgYXMgd2VsbCANCiAgIGFzIGEgcHJvYmxlbSBzdGF0ZW1lbnQgd2lsbCBi ZSBwaW5wb2ludGVkLiBGdXJ0aGVybW9yZSwgc2NlbmFyaW9zIA0KICAgZm9yIG11bHRpbWVkaWEg Y29uZmVyZW5jaW5nIGluIHRoZSBJbnRlcm5ldCBhcmUgY2F0ZWdvcml6ZWQsIA0KICAgcmVhY2hp bmcgZnJvbSBzbWFsbCBjbG9zZWQgbWVldGluZ3MgdG8gbGFyZ2UgcGxlbmFyeSBzZXNzaW9ucyB3 aXRoIA0KICAgICANClRyb3NzZW4gICAgICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAw MSAgICAgICAgICAgICAgICAgICAgIFsyXSANDA0KSW50ZXJuZXQgRHJhZnQgICAgIENvdXJzZSBD b250cm9sIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAgICBNYXkgMjAwMSANCiAgICANCiAgICAN CiAgIGhpZ2ggZmx1Y3R1YXRpb25zIHJlZ2FyZGluZyB0aGUgcGFydGljaXBhbnSScyBhY3Rpdml0 eSBhbmQgDQogICBpbnRlcmVzdHMuIFNpbmNlIHRoZSBmb2N1cyBvZiB0aGUgZG9jdW1lbnQgaXMg b24gY29udHJvbCBpc3N1ZXMgaW4gDQogICBjb25mZXJlbmNpbmcsIGRhdGEgZGVsaXZlcnkgYXNw ZWN0cyBhcmUgbGVmdCBvdXQgb2YgY29uc2lkZXJhdGlvbi4gDQogICAgDQogICBUaGUgc2NlbmFy aW8gZmluZGluZ3MgYXJlIHRoZW4gdXNlZCB0byBkZWZpbmUgbW9kZWxzIGZvciBjb25mZXJlbmNl IA0KICAgY291cnNlIGNvbnRyb2wgcHJvdmlzaW9uLiANCiAgICANCiAgIE1vcmVvdmVyLCBjdXJy ZW50IGNvbmZlcmVuY2luZyBzb2x1dGlvbnMgYXJlIGJyaWVmbHkgZXZhbHVhdGVkIA0KICAgY29u Y2VybmluZyB0aGVpciBzaG9ydGNvbWluZ3MgaW4gY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCAN CiAgIGZ1bmN0aW9uYWxpdHkuIEZpbmFsbHksIG5leHQgc3RlcHMgZm9yIGNvbmZlcmVuY2UgY291 cnNlIGNvbnRyb2wgDQogICBlZmZvcnRzIHdpbGwgYmUgcHJlc2VudGVkLiANCiAgICANCjIuICAg ICBEZWZpbml0aW9uIG9mIFRlcm1zIA0KICAgIA0KICAgbyBBcHBsaWNhdGlvbiBzZXNzaW9uIChB UyksIFNlc3Npb24gDQogICAgIFRoZSBzZXQgb2YgbWVkaWEgYWdlbnRzL2FwcGxpY2F0aW9ucyB0 aGF0IGFjdCBhcyBwZWVycyB0byBlYWNoICANCiAgICAgb3RoZXIgd2l0aGluIGEgY29uZmVyZW5j ZS4gIEZvciByZWFsLXRpbWUgZGF0YSwgdGhpcyBnZW5lcmFsbHkgIA0KICAgICB3aWxsIGJlIGFu IFJUUCBzZXNzaW9uOyBmb3Igb3RoZXIgYXBwbGljYXRpb24gcHJvdG9jb2xzLCBvdGhlciAgDQog ICAgIGhvcml6b250YWwgcHJvdG9jb2xzIG1heSBkZWZpbmUgdGhlaXIgb3duIHR5cGUgb2Ygc2Vz c2lvbiBjb25jZXB0LiAgDQogICAgDQogICBvIFBhcnRpY2lwYW50IA0KICAgICBBIGh1bWFuIGJl aW5nIHRoYXQgdGFrZXMgcGFydCBpbiBhIGNvbmZlcmVuY2UsIGVpdGhlciBhY3RpdmVseSBvciAg DQogICAgIHBhc3NpdmVseSBsaXN0ZW5pbmcuIA0KICAgIA0KICAgbyBBY3RpdmUgUGFydGljaXBh bnQgDQogICAgIEEgcGFydGljaXBhbnQgb2YgYSBjb25mZXJlbmNlIGJlY29taW5nIHNlbmRlciBv ZiBtZWRpYSBpbmZvcm1hdGlvbiAgDQogICAgIGR1cmluZyBsaWZldGltZSBvZiB0aGUgY29uZmVy ZW5jZS4gDQogICAgDQogICBvIFBhc3NpdmUgUGFydGljaXBhbnQgDQogICAgIEEgcGFydGljaXBh bnQgb2YgYSBjb25mZXJlbmNlIHBhc3NpdmVseSByZWNlaXZpbmcgdGhlIG1lZGlhICANCiAgICAg aW5mb3JtYXRpb24gd2l0aG91dCBiZWNvbWluZyBzZW5kZXIgb2YgbWVkaWEgaW5mb3JtYXRpb24g IA0KICAgICBkdXJpbmcgbGlmZXRpbWUgb2YgdGhlIGNvbmZlcmVuY2UuIA0KICAgIA0KICAgbyBN ZW1iZXIgDQogICAgIFRoZSBzeXN0ZW0sIGluY2x1ZGluZyBzb2Z0d2FyZSBhbmQgaGFyZHdhcmUs IHRoYXQgdGFrZXMgcGFydCBpbiBhICAgIA0KICAgICBjb21wdXRlciBjb25mZXJlbmNlLCByZXBy ZXNlbnRpbmcgYSBzaW5nbGUgcGFydGljaXBhbnQuIA0KICAgIA0KICAgbyBQcm9maWxlIA0KICAg ICBBbiBpbml0aWFsIGRlc2NyaXB0aW9uIG9mIHRoZSBjb25mZXJlbmNlLCBpbmNsdWRpbmcgYXNz aWdubWVudCBvZiAgDQogICAgIHJvbGVzIHRvIHBhcnRpY3VsYXIgbWVtYmVycywgdGltZSBsaW1p dHMgZm9yIHNwZWFrZXJzLCBhdHRyaWJ1dGVzICANCiAgICAgb2YgdGhlIGNvbmZlcmVuY2UgKG9w ZW4vY2xvc2UsIGNvbmR1Y3RlZC9hbmFyY2hpYywgZXRjKS4gDQogICAgDQogICBvIENvbmZlcmVu Y2UgU2V0dXAgYW5kIERpc2NvdmVyeSANCiAgICAgQWNjb3JkaW5nIHRvIFszXSwgYXNwZWN0cyBm b3Igc2V0dGluZyB1cCBhbiBpbml0aWFsIGNvbmZlcmVuY2UgIA0KICAgICBTdGF0ZSBpbiBwYXJ0 aWNpcGF0aW5nIG1lbWJlcnMsIGluY2x1ZGluZyB0aGUgZXhjaGFuZ2Ugb2YgbWVkaWEgIA0KICAg ICBhbmQgY2FwYWJpbGl0aWVzIGluZm9ybWF0aW9uIGFtb25nIHRoZSBzZXQgb2YgcGFydGljaXBh bnRzLCBhcmUgIA0KICAgICBiZWluZyBhZGRyZXNzZWQgYnkgc2V0dXAgYW5kIGRpc2NvdmVyeSBm dW5jdGlvbmFsaXR5LiANCiAgICANCiAgIG8gQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJvbCANCiAg ICAgQWNjb3JkaW5nIHRvIFszXSwgYXNwZWN0cyB0byBjb250cm9sIHRoZSBjb25mZXJlbmNlIGR1 cmluZyBydW50aW1lICANCiAgICAgb2YgdGhlIGV2ZW50IGFyZSBiZWluZyBhZGRyZXNzZWQgYnkg Y29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbC4gDQogICAgDQogICAgIA0KVHJvc3NlbiAgICAgICAg ICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAgICAgWzNdIA0M DQpJbnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAg ICAgICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KMy4gICAgIFNjb3BlIA0KICAgIA0KICAgVGhl IHNjb3BlIG9mIGNvbmZlcmVuY2UgY291cnNlIGNvbnRyb2wgZnVuY3Rpb25hbGl0eSB3aWxsIGJl IA0KICAgZGV2ZWxvcGVkIGFzIHBhcnQgb2YgdGhlIHNvbHV0aW9uIHNwYWNlLiBQb3NzaWJsZSBm dW5jdGlvbmFsaXR5IA0KICAgaW5jbHVkZXM6IA0KICAgIA0KICAgbyAnY29uZmVyZW5jZSBjb250 ZXh0IGFkbWluaXN0cmF0aW9uJywgcHJvdmlkaW5nIG1lbWJlcnNoaXAgIA0KICAgICBhbmQgYXBw bGljYXRpb24vc2Vzc2lvbiBpbmZvcm1hdGlvbiBhZG1pbmlzdHJhdGlvbiANCiAgIG8gJ21lbWJl cnNoaXAgZW5mb3JjZW1lbnQnLCBwcm92aWRpbmcgbWVhbnMgdG8gZW5mb3JjZSBzcGVjaWZpYyAg DQogICAgIGNvbmZlcmVuY2UgbWVtYmVyc2hpcCANCiAgIG8gJ2Zsb29yIGNvbnRyb2wnLCBwcm92 aWRpbmcgbWVhbnMgdG8gbWFwIHNvY2lhbCBwcm90b2NvbHMgb250byAgDQogICAgIGRpc3RyaWJ1 dGVkIGVudmlyb25tZW50cy4gSG93ZXZlciwgdGhlIHNlbWFudGljcyBvZiBzcGVjaWZpYyAgDQog ICAgIHNvY2lhbCBwcm90b2NvbHMgaXMgbm90IHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIHBvc3Np YmxlICANCiAgICAgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBzb2x1dGlvbi4gDQogICBvICdh Y3RpdmUvcGFzc2l2ZSBtZW1iZXIgc3VwcG9ydCcsIGFsbG93aW5nIGZvciBkaWZmZXJlbnQgcG9s aWNpZXMgIA0KICAgICB3aXRoIHJlc3BlY3QgdG8gbWVtYmVyc2hpcCBhbmQgZmxvb3IgY29udHJv bC4gVGhpcyBpbmNsdWRlcyAgDQogICAgIGNoYW5nZXMgZnJvbSBhY3RpdmUgdG8gcGFzc2l2ZSBh bmQgdmljZSB2ZXJzYSwgZWl0aGVyIGltcGxpY2l0bHkgIA0KICAgICBvciBleHBsaWNpdGx5LiAN CiAgIG8gJ2NhcGFiaWxpdGllcyByZS1uZWdvdGlhdGlvbicsIGFsbG93aW5nIGZvciBjaGFuZ2Vz IGluICANCiAgICAgdGhlIGluaXRpYWwgY2FwYWJpbGl0aWVzIHNldCBvZiBwYXJ0aWNpcGFudHMg ZHVyaW5nIHJ1bnRpbWUgb2YgdGhlICANCiAgICAgY29uZmVyZW5jZS4gDQogICAgDQogICBUaGlz IGxpc3QgZG9lcyBub3QgY2xhaW0gdG8gYmUgZXhoYXVzdGl2ZS4gSG93ZXZlciwgaXQgcG9pbnRz IGluIHRoZSANCiAgIGRpcmVjdGlvbiBvZiBwcm92aWRlZCBmdW5jdGlvbmFsaXR5IGZvciBjb25m ZXJlbmNlIGNvdXJzZSBjb250cm9sIA0KICAgc29sdXRpb25zLiANCiAgICANCjQuICAgICBQcm9i bGVtIFN0YXRlbWVudCANCiAgICANCiAgIFRoZXJlIGFyZSBtYW55IGFwcHJvYWNoZXMgaW4gdGhl IHJlc2VhcmNoIGNvbW11bml0eSB0byByZWFsaXplIA0KICAgY29uZmVyZW5jZSBjb3Vyc2UgY29u dHJvbCBhcyBwYXJ0IG9mIGEgY29uZmVyZW5jaW5nIGFyY2hpdGVjdHVyZS4gDQogICBBbHNvIGlu IHN0YW5kYXJkaXphdGlvbiBib2RpZXMgKHN1Y2ggYXMgSC4zMjMgWzddIG9yIFNDQ1AgWzFdKSwg DQogICBjb25mZXJlbmNlIGNvdXJzZSBjb250cm9sIGhhcyBiZWVuIGFkZHJlc3NlZC4gSG93ZXZl ciwgbm9uZSBvZiB0aGVzZSANCiAgIGFwcHJvYWNoZXMgb2ZmZXJzIGEgdW5pZmllZCBhbmQgZmxl eGlibGUgc29sdXRpb24gZm9yIGNvbmZlcmVuY2UgDQogICBjb3Vyc2UgY29udHJvbCB0byBjb3Zl ciB0aGUgc3BlY3RydW0gb2Ygc2NlbmFyaW9zIG91dGxpbmVkIGluIA0KICAgU2VjdGlvbiA1LiAN CiAgICANCiAgIFNwZWNpZmljYWxseSwgYSBjb25mZXJlbmNlIGNvdXJzZSBjb250cm9sIHNvbHV0 aW9uIHNob3VsZCANCiAgICANCiAgIG8gZml0IGludG8gdGhlIGFscmVhZHkgZGVmaW5lZCBjb25m ZXJlbmNlIGNvbnRyb2wgYXJjaGl0ZWN0dXJlIGFuZCAgDQogICAgIGxldmVyYWdlIHRoZSBleGlz dGluZyBzdWl0ZSBvZiBtZWNoYW5pc21zIGFuZCBwcm90b2NvbHMsIHN1Y2ggYXMgIA0KICAgICAq IGNvbmZlcmVuY2UgZGVzY3JpcHRpb24sIGkuZS4sIFNEUCBbNF0gb3IgZnV0dXJlIHZlcnNpb25z IChTREctbmcgIA0KICAgICAgIFs5XSksIGFuZCBpbml0aWF0aW9uLCBpLmUuLCBTSVAgWzVdIA0K ICAgICAqIGxvY2FsIGNvb3JkaW5hdGlvbiwgaS5lLiwgTUJVUyBbMTBdIA0KICAgICAqIHRyYW5z cG9ydCBsYXllciBwcm90b2NvbHMsIHN1Y2ggYXMgZm9yIHJlbGlhYmxlIG11bHRpY2FzdCwgcmVh bC0gDQogICAgICAgdGltZSB0cmFuc2Zlciwgb3Igc2ltcGxlIHVuaWNhc3QgdHJhbnNtaXNzaW9u IA0KICAgICAqIHNlY3VyaXR5IGNvbXBvbmVudHMsIHN1Y2ggYXMgZ3JvdXAga2V5IHNvbHV0aW9u cyANCiAgIG8gcHJvdmlkZSBhIGZsZXhpYmxlIHNvbHV0aW9uLCBhbGxvd2luZyBmb3IgYSB2YXJp ZXR5IG9mIHNjZW5hcmlvcyAgDQogICAgIChzZWUgU2VjdGlvbiA1KSBhbmQgY2hhcmFjdGVyaXN0 aWNzIHRvIGJlIHBsdWdnZWQgaW4gdGhlIHN5c3RlbS4gIA0KICAgIA0KICAgRm9yIHRoYXQsIGEg YnVpbGRpbmcgYmxvY2sgYXBwcm9hY2ggd291bGQgYWxsb3cgdGhlIHByb3Zpc2lvbiBvZiANCiAg IHN0YW5kYXJkaXplZCBpbnRlcmZhY2VzIHRvIHRoZSBkZXNpcmVkIGNvbW1vbiBmdW5jdGlvbmFs aXR5LiBXaXRoIA0KICAgdGhhdCwgc3BlY2lmaWMgc2NlbmFyaW8tdGFpbG9yZWQgaW5zdGFudGlh dGlvbnMgZm9yIGNlcnRhaW4gDQogICBmdW5jdGlvbmFsaXR5LCByZXByZXNlbnRlZCBieSBhIGJ1 aWxkaW5nIGJsb2NrLCBhcmUgZW5hYmxlZCANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAg ICBFeHBpcmVzIE5vdmVtYmVyIDIwMDEgICAgICAgICAgICAgICAgICAgICBbNF0gDQwNCkludGVy bmV0IERyYWZ0ICAgICBDb3Vyc2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAg TWF5IDIwMDEgDQogICAgDQogICAgDQogICBwcmVzZXJ2aW5nIHRoZSBjb21tb24gdmlldyBvZiB0 aGUgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCANCiAgIGZ1bmN0aW9uYWxpdHkuIA0KICAgIA0K ICAgIA0KNS4gICAgIENvbmZlcmVuY2luZyBTY2VuYXJpb3MgDQogICAgDQogICBUaGlzIHNlY3Rp b24gaW5mb3JtYWxseSBvdXRsaW5lcyBzY2VuYXJpbyBjYXRlZ29yaWVzIGZvciBtdWx0aW1lZGlh IA0KICAgY29uZmVyZW5jaW5nIGluIHRoZSBJbnRlcm5ldC4gIA0KICAgIA0KICAgVGhlIGNvbmZl cmVuY2luZyBzY2VuYXJpb3MgYXJlIGNhdGVnb3JpemVkIGluIHRocmVlIHNlY3Rpb25zLiBGb3Ig DQogICBlYWNoIGNhdGVnb3J5LCB0eXBpY2FsIGNoYXJhY3RlcmlzdGljcyBhcmUgb3V0bGluZWQs IGFuZCBleGFtcGxlcyANCiAgIGFyZSBnaXZlbi4gRmluYWxseSwgYSB0YWJsZS13aXNlIG92ZXJ2 aWV3IGlzIGRlcml2ZWQgZnJvbSB0aGUgbW9yZSANCiAgIGluZm9ybWFsIGRlc2NyaXB0aW9uIHBp bnBvaW50aW5nIHRoZSB2ZXJ5IGZ1bmN0aW9uYWxpdHkgcmVxdWlyZWQgZm9yIA0KICAgdGhlIHNw ZWNpZmljIHNjZW5hcmlvcy4gVGhpcyB0YWJsZS13aXNlIGRlc2NyaXB0aW9uIHdpbGwgYmUgdXNl ZCBpbiANCiAgIFNlY3Rpb24gNSB0byBkaXNjdXNzIGNvbmZlcmVuY2UgY291cnNlIGNvbnRyb2wg bW9kZWxzLiANCiAgICANCiAgIEl0IGlzIHdvcnRoIG1lbnRpb25pbmcgdGhhdCBzaW1wbGUgc3Ry ZWFtaW5nIGlzIG5vdCBjb25zaWRlcmVkIGluIA0KICAgdGhlIGZvbGxvd2luZyBkdWUgdG8gaXRz IGxhY2sgb2YgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCANCiAgIGZ1bmN0aW9uYWxpdHkuIEhv d2V2ZXIsIGl0IG1pZ2h0IGJlIHVzZWQgdG8gcmVhbGl6ZSB2ZXJ5IHNpbXBsZSANCiAgIGNvbmZl cmVuY2luZyBzY2VuYXJpb3Mgc3VjaCBhcyBJbnRlcm5ldCBsZWN0dXJlcywgd2hlcmUgZGF0YSBp cyANCiAgIHNpbXBseSBzZW50IHRvIGEgc2V0IG9mIHJlY2VpdmVycyB3aXRob3V0IGZlZWRiYWNr IG9yIGludGVyYWN0aW9uLiAgDQogICAgDQo1LjEuICAgU2ltcGxlIENvbmZlcmVuY2luZyANCiAg ICANCiAgICdTaW1wbGUgQ29uZmVyZW5jaW5nJyByZWZsZWN0cyB0aGUgc2ltcGxlc3QgZm9ybSBv ZiBjb25mZXJlbmNpbmcgDQogICB3aXRoIGEgY2hhbmdlIG9mIHRoZSBzZW5kZXIvcmVjZWl2ZXIg cmVsYXRpb24gYmFzZWQgb24gY2VydGFpbiANCiAgICdzb2NpYWwgcnVsZXMnIGR1cmluZyB0aGUg bGlmZXRpbWUgb2YgdGhlIGNvbmZlcmVuY2UuIA0KICAgIA0KICAgQ29uZmVyZW5jZXMgb2YgdGhp cyB0eXBlIG1pZ2h0IGJlIGFubm91bmNlZCBiZWZvcmVoYW5kLCBpbmNsdWRpbmcgDQogICB0aGUg Y29uZmVyZW5jZZJzIHByb2ZpbGUgaW5mb3JtYXRpb24sIG9yIHRoZXkgdGFrZSBwbGFjZSBhcyBh ZC1ob2MgDQogICBtZWV0aW5ncy4gIA0KICAgIA0KICAgVGhlIGdyb3VwIG9mIHBhcnRpY2lwYW50 cyBtaWdodCBiZSB3ZWxsLWtub3duLCBpZiBhbm5vdW5jZWQsIG9yIGJlIA0KICAgYnVpbHQgYnkg aW52aXRhdGlvbiBvciByZXF1ZXN0LiBGb3IgdGhhdCwgc2V2ZXJhbCBpbml0aWF0aW9uIG1vZGVs cyANCiAgIG1pZ2h0IGJlIHJlYWxpemVkIChzZWUgYWxzbyBbMTFdKSwgd2hpY2ggcmVxdWlyZXMg YXBwcm9wcmlhdGUgDQogICBpbml0aWF0aW9uIGZ1bmN0aW9uYWxpdHkgaW5jbHVkaW5nIGF1dGhl bnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIA0KICAgbWVhbnMgZm9yIHJlc3RyaWN0ZWQgYWNj ZXNzIHRvIHRoZSBjb25mZXJlbmNlLiAgDQogICAgDQogICBGbG9vciBjb250cm9sIGZ1bmN0aW9u YWxpdHksIGUuZy4sIHRvIHJlYWxpemUgY29uZHVjdGVkIG1lZXRpbmcgDQogICBmdW5jdGlvbmFs aXR5LCBpcyBub3QgcHJvdmlkZWQgaW4gdGhpcyBjYXRlZ29yeS4gRHVlIHRvIHRoaXMgbGFjayBv ZiANCiAgIG1lZGlhdGlvbiBjb25jZXJuaW5nIHRoZSBhY2Nlc3Mgb24gdGhlIGNvbW1vbiBtZWRp YSByZXNvdXJjZSwgdGhlIA0KICAgbGV2ZWwgb2YgaW50ZXJhY3Rpdml0eSBpcyB1c3VhbGx5IGxp bWl0ZWQsIGV2ZW4gaWYgc2NhbGFibGUgDQogICBtdWx0aWNhc3QgdHJhbnNmZXIgaXMgdXNlZC4g IA0KICAgIA0KICAgVXN1YWxseSwgdGhlIGluaXRpYWwgc2V0IG9mIGNhcGFiaWxpdGllcyBpcyBu b3QgY2hhbmdlZCwgaS5lLiwgcmUtDQogICBuZWdvdGlhdGVkLCBkdXJpbmcgcnVudGltZSBvZiB0 aGUgY29uZmVyZW5jZS4gSG93ZXZlciwgc29tZSBzaW1wbGUgDQogICBmb3JtIG9mIHJlLW5lZ290 aWF0aW9uIGNvdWxkIGJlIHByb3ZpZGVkLiANCiAgICANCiAgIEFsdGhvdWdoIHRoZSBudW1iZXIg b2YgcGFydGljaXBhbnRzIGNhbiBlYXNpbHkgcmVhY2ggc2V2ZXJhbCANCiAgIHRob3VzYW5kcyBv ciBldmVuIG1vcmUsIHdoZW4gdXNpbmcgbXVsdGljYXN0IHRyYW5zZmVyIGNhcGFiaWxpdGllcywg DQogICBpdCBpcyBleHBlY3RlZCB0aGF0IHRoZSByZXF1aXJlbWVudHMgZm9yIHByZWNpc2UgbWVt YmVyc2hpcCANCiAgIGluZm9ybWF0aW9uIGFyZSBsZXNzIHN0cmluZ2VudCBpbiBsYXJnZXIgc2Nh bGVkIGNvbmZlcmVuY2VzLiANCiAgICANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAgICBF eHBpcmVzIE5vdmVtYmVyIDIwMDEgICAgICAgICAgICAgICAgICAgICBbNV0gDQwNCkludGVybmV0 IERyYWZ0ICAgICBDb3Vyc2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgTWF5 IDIwMDEgDQogICAgDQogICAgDQo1LjEuMS4gRXhhbXBsZXMgDQogICAgDQogICBFeGFtcGxlcyBm b3Igc2ltcGxlIGNvbmZlcmVuY2luZyBpbmNsdWRlIGFkLWhvYyBvciBwcmUtcGxhbm5lZCBzbWFs bCANCiAgIGdyb3VwIG1lZXRpbmdzLCByaWNoIGNhbGxzLCBJbnRlcm5ldCBsZWN0dXJlcywgdGVs ZS13b3JraW5nIGluIGEgDQogICB0ZWFtLiBNb3N0IG9mIHRoZSBjdXJyZW50IE1Cb25lIFsyXSBz ZXNzaW9ucyBhcmUgdHlwaWNhbCBleGFtcGxlcyANCiAgIGZvciBzaW1wbGUgY29uZmVyZW5jaW5n LiANCiAgICANCjUuMi4gICBGbG9vciBDb250cm9sbGVkIENvbmZlcmVuY2luZyANCiAgICANCiAg IFNjZW5hcmlvcyBvZiB0aGlzIGNhdGVnb3J5IGVucmljaCB0aGUgc2ltcGxlIGNvbmZlcmVuY2lu ZyANCiAgIGZ1bmN0aW9uYWxpdHkgb2Ygc2VjdGlvbiA1LjEuIGJ5IHByb3ZpZGluZyBmbG9vciBj b250cm9sIGZhY2lsaXRpZXMgDQogICB0byBjb250cm9sIHRoZSBhY2Nlc3Mgb24gZGlzdHJpYnV0 ZWQgcmVzb3VyY2VzLiBBbW9uZyBvdGhlcnMsIHRoZXNlIA0KICAgZGlzdHJpYnV0ZWQgcmVzb3Vy Y2VzIG1pZ2h0IHJlZmxlY3QgdGhlIGNvbW1vbmx5IHVzZWQgYXVkaW92aXN1YWwgDQogICBjaGFu bmVsIHdpdGhpbiB0aGUgY29uZmVyZW5jZSBidXQgYWxzbyB0aGUgY29udGVudCBvZiBhIHNoYXJl ZCANCiAgIHdoaXRlYm9hcmQsIG9yIGEgc2hhcmVkLCBsb2NhbGx5IGhvc3RlZCBhcHBsaWNhdGlv bi4gVGhlIGZsb29yIA0KICAgY29udHJvbCBzZW1hbnRpY3MgYXJlIHVzdWFsbHkga25vd24gYmVm b3JlaGFuZCwgb3IgdGhleSBtaWdodCBiZSANCiAgIGRpc3RyaWJ1dGVkIHVzaW5nIHRoZSBjb25m ZXJlbmNlIHByb2ZpbGUgaW5mb3JtYXRpb24uIFRoZSANCiAgIHJlYWxpemF0aW9uIG9mIHRoZSBm bG9vciBjb250cm9sIHNlbWFudGljcyBpcyB1c3VhbGx5IGhpZ2hseSANCiAgIGFwcGxpY2F0aW9u LXNwZWNpZmljLiANCiAgICANCiAgIEZvciBpbnN0YW5jZSwgZmxvb3IgY29udHJvbGxlZCBjb25m ZXJlbmNpbmcgbWlnaHQgYWxsb3cgJ2NvbmR1Y3RlZCANCiAgIG1lZXRpbmdzJywgZW5hYmxpbmcg dGhlIGNvbmR1Y3RvciBvZiBhIGNvbmZlcmVuY2UgZm9yIGluc3RhbmNlIHRvIA0KICAgZWplY3Qg cGFydGljaXBhbnRzIGZyb20gYSBjb25mZXJlbmNlIG9yIHRvIGRlbnkgYWNjZXNzIHRvIHRoZSAN CiAgIGNvbmZlcmVuY2UuIEhvd2V2ZXIsIGluIGFkZGl0aW9uIHRvIHRoZSByZWFsaXphdGlvbiBv ZiB0aGUgc29jaWFsIA0KICAgcnVsZXMgYnkgbWVhbnMgb2YgZmxvb3IgY29udHJvbCwgYXBwcm9w cmlhdGUgZnVuY3Rpb25hbGl0eSB0byANCiAgIGVuZm9yY2UgdGhlbSBvbiBkYXRhIGxldmVsIGlz IHJlcXVpcmVkIGJ5IG1lYW5zIG9mIGV4Y2x1ZGluZyANCiAgIHJlY2VpdmVyIHNldHMgZnJvbSBy ZWNlcHRpb24uIA0KICAgIA0KICAgQ2FwYWJpbGl0aWVzIHJlLW5lZ290aWF0aW9uIGlzIHVzdWFs bHkgcHJvdmlkZWQgaW4gdGhlc2Ugc2NlbmFyaW9zLCANCiAgIHdoaWNoIG1pZ2h0IGFsc28gYmUg dGllZCB0byB0aGUgaW1wbGVtZW50ZWQgZmxvb3IgY29udHJvbCBwb2xpY3kgb2YgDQogICB0aGUg c3BlY2lmaWMgc2NlbmFyaW8uIA0KICAgIA0KICAgSW4gZmxvb3IgY29udHJvbGxlZCBjb25mZXJl bmNlcywgdGhlcmUgaXMgYW4gZXhhY3Qga25vd2xlZGdlIG9mIHRoZSANCiAgIGN1cnJlbnQgbWVt YmVyc2hpcCBpbmZvcm1hdGlvbiBvZiB0aGUgcGFydGljaXBhbnRzLiBVc3VhbGx5LCB0aGUgDQog ICBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgZmxvb3IgY29udHJvbCByZXN0cmljdHMgdGhlIHNjYWxh YmlsaXR5IG9mIA0KICAgdGhpcyB0eXBlIG9mIGNvbmZlcmVuY2VzIHRvIGEgZmV3IHRlbnMuIEhv d2V2ZXIsIGFwcHJvYWNoZXMgYXMgDQogICBwcm9wb3NlZCBpbiBbMTNdLCBtaWdodCBiZSB1c2Vk IGluIHNwZWNpZmljIHNjZW5hcmlvcyB0byBpbXByb3ZlIHRoZSANCiAgIHNjYWxhYmlsaXR5LiAN CiAgICANCjUuMi4xLiBFeGFtcGxlcyANCiAgICANCiAgIEV4YW1wbGVzIGZvciBmbG9vciBjb250 cm9sbGVkIGNvbmZlcmVuY2VzIGluY2x1ZGUgc2NlbmFyaW9zIHdpdGggdGhlIA0KICAgbmVlZCB0 byByZWFsaXplIHNvY2lhbCBydWxlcyBvciBhY2Nlc3MgY29udHJvbCBvbiBzaGFyZWQgcmVzb3Vy Y2VzLCANCiAgIHN1Y2ggYXMgY29uZHVjdGVkIG1lZXRpbmdzLCBhcHBsaWNhdGlvbiBzaGFyaW5n IHNlc3Npb25zLCBkaXN0YW5jZSANCiAgIGxlYXJuaW5nIGluY2x1ZGluZyBkZW1vbnN0cmF0aW9u IG9mIHNoYXJlZCBpbmZvcm1hdGlvbiwgdGVsZS13b3JraW5nIA0KICAgd2l0aCBjb21tb24gcmVz b3VyY2VzIHRvIHNoYXJlLiANCiAgICANCjUuMy4gICBSaWNoIENvbmZlcmVuY2luZyANCiAgICAN CiAgIEEgJ3JpY2ggY29uZmVyZW5jaW5nJyBldmVudCwgd2hpY2ggaXMgZ29pbmcgdG8gaGFwcGVu LCBtaWdodCBiZSANCiAgIGFubm91bmNlZCBiZWZvcmVoYW5kIGJ1dCBhbiBhZC1ob2MgZXN0YWJs aXNobWVudCBtaWdodCBhbHNvIGJlIA0KICAgY29uc2lkZXJlZCwgc3VjaCBhcyBhICdyYW5kb21s eSBnYXRoZXJpbmcgYSBjcm93ZCBhcm91bmQgYW4gDQogICAgIA0KVHJvc3NlbiAgICAgICAgICAg ICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAgICAgWzZdIA0MDQpJ bnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAg ICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KICAgYXR0cmFjdGlvbicuIEF1dGhlbnRpY2F0aW9u IGFuZCBhdXRob3JpemF0aW9uIG1lYW5zIG1pZ2h0IGJlIHVzZWQgDQogICBmb3IgcmVzdHJpY3Rl ZCBhY2Nlc3MgdG8gdGhlIGV2ZW50LiANCiAgICANCiAgIFVzdWFsbHksIHRoZXJlIGlzIGEgKHNt YWxsKSB3ZWxsLWtub3duIGdyb3VwIG9mIGFjdGl2ZSBwYXJ0aWNpcGFudHMsIA0KICAgaS5lLiwg ZXhhY3QgbWVtYmVyc2hpcCBpbmZvcm1hdGlvbiBpcyByZXF1aXJlZCwgYW5kIGEgbGFyZ2VyIGdy b3VwIA0KICAgb2YgcGFzc2l2ZSBwYXJ0aWNpcGFudHMuIE1lbWJlcnNoaXAgaW5mb3JtYXRpb24g Zm9yIHRoaXMgbGFyZ2VyIA0KICAgZ3JvdXAgaXMgbGVzcyBzdHJpY3RseSBwcm92aWRlZCwgY29t cGFyYWJsZSB3aXRoICdibHVlIHNoZWV0cycgDQogICBhdHRlbmRlZXMgbGlzdHMuICANCiAgICAN CiAgIFRoZSBhY2Nlc3MgY29udHJvbCB3aXRoaW4gdGhlIGdyb3VwIG9mIGFjdGl2ZSBwYXJ0aWNp cGFudHMgaXMgDQogICByZWFsaXplZCBieSBtZWFucyBvZiBmbG9vciBjb250cm9sIHJlYWxpemlu ZyBzcGVjaWZpYyBzb2NpYWwgDQogICBpbnRlcmFjdGlvbnMgKGNvbmR1Y3RlZCBzZXNzaW9uLCBw YW5lbCBncm91cCkgc2ltaWxhciB0byBmbG9vciANCiAgIGNvbnRyb2xsZWQgY29uZmVyZW5jaW5n LiANCiAgICANCiAgIEFzIGEgc3BlY2lmaWMgY2hhcmFjdGVyaXN0aWMgb2YgdGhpcyBjYXRlZ29y eSwgZnJlcXVlbnQgY2hhbmdlcyANCiAgIGJldHdlZW4gYWN0aXZlIGFuZCBwYXNzaXZlIHBhcnRp Y2lwYXRpb24gaW4gdGhlIGNvbmZlcmVuY2UgYXJlIA0KICAgaGFwcGVuaW5nLCBlLmcuLCBhIHBh c3NpdmUgb2JzZXJ2ZXIgKHBhcnRpY2lwYW50KSBvZiB0aGUgZXZlbnQgbWlnaHQgDQogICByYWlz ZSBpdHMgaW50ZXJlc3QgaW4gYmVjb21pbmcgYWN0aXZlIGluIHRoZSBkaXNjdXNzaW9uLCBlaXRo ZXIgYnkgDQogICBvd24gcmVxdWVzdCBvciBieSBpbnZpdGF0aW9uLCBmb2xsb3dpbmcgdGhlIHNw ZWNpZmljIGFjY2VzcyBydWxlcyBvZiANCiAgIHRoZSBhY3RpdmUgcGFydGljaXBhbnQgZ3JvdXAg aW1wbGVtZW50ZWQgYnkgYXBwcm9wcmlhdGUgZmxvb3IgDQogICBjb250cm9sIG1lYW5zLiBUaGUg bW9kZSBjaGFuZ2UgY291bGQgaGFwcGVuICdleHBsaWNpdGx5JywgaS5lLiwgYnkgDQogICBqb2lu aW5nIHRoZSBhY3RpdmUgbWVtYmVyIGdyb3VwLCBvciAnaW1wbGljaXRseScsIGkuZS4sIGJ5IA0K ICAgcmVxdWVzdGluZyBmbG9vciBjb250cm9sIHNlcnZpY2VzLiANCiAgICANCiAgIFRoaXMgbW9k ZSBjaGFuZ2Ugc2hvdWxkIGJlIHBvc3NpYmxlIGluIHRoZSByZXZlcnNlIGRpcmVjdGlvbiwgdG9v LCANCiAgIGkuZS4sIHdoZW4gYW4gYWN0aXZlIHBhcnRpY2lwYW50IGxvb3NlcyBpbnRlcmVzdCBp biBhY3RpdmUgDQogICBwYXJ0aWNpcGF0aW9uLiANCiAgICANCjUuMy4xLiBFeGFtcGxlcyANCiAg ICANCiAgIEV4YW1wbGVzIGZvciBsYXJnZSBzY2FsZSByaWNoIGNvbmZlcmVuY2luZyBzY2VuYXJp b3MgYXJlIHRvd24gaGFsbCANCiAgIG1lZXRpbmdzLCBJRVRGIHdvcmtpbmcgZ3JvdXAgbWVldGlu Z3MsIHZpcnR1YWwgbGVjdHVyZXMgd2l0aCANCiAgIGZlZWRiYWNrLCB2aXJ0dWFsIG5ld3Nncm91 cHMuIEhvd2V2ZXIsIGV4YW1wbGVzIGZvciBzaW1wbGUgYW5kIGZsb29yIA0KICAgY29udHJvbGxl ZCBjb25mZXJlbmNpbmcgYXJlIGFsc28gYXBwbGljYWJsZSBmb3IgdGhpcyBjYXRlZ29yeSBkdWUg dG8gDQogICB0aGUgc3VwZXJzZXQgY2hhcmFjdGVyIG9mIHRoZSByaWNoIGNvbmZlcmVuY2luZyBj YXRlZ29yeSBjb21wYXJlZCB0byANCiAgIHRoZSBvdGhlciBvbmVzLiANCiAgICANCjUuNC4gICBT dW1tYXJ5IG9mIENoYXJhY3RlcmlzdGljcyANCiAgICANCiAgIFRoZSBmb2xsb3dpbmcgdGFibGUg c3VtbWFyaXplcyB0aGUgbWFpbiBjaGFyYWN0ZXJpc3RpY3MgZm9yIHRoZSANCiAgIGRpZmZlcmVu dCBzY2VuYXJpbyBjYXRlZ29yaWVzIHByZXNlbnRlZCBpbiBzZWN0aW9uIDUuMS4gdG8gNS4zLiAN CiAgICcoKyknIGluZGljYXRlcyBvcHRpb25hbCBmdW5jdGlvbmFsaXR5LiAgDQogICAgDQogICBU aGUgZmlyc3QgYmxvY2sgb2YgY2hhcmFjdGVyaXN0aWNzIGlzIHJlZmVycmVkIHRvIGFzIGNvbmZl cmVuY2UgDQogICBpbml0aWF0aW9uIGFuZCBzZXR1cCAoc2VlIFszXSksIHdoaWxlIHRoZSBzZWNv bmQgYmxvY2sgaXMgZGVkaWNhdGVkIA0KICAgdG8gY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBm dW5jdGlvbmFsaXR5LiANCiAgICANCiAgICANCiAgICANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgfCBGdW5jdGlv bmFsaXR5ICAgIHwgIFNpbXBsZSAgICAgfCAgICBGLkMuICAgICB8ICAgUmljaCAgICAgIHwgDQog ICB8ICAgICAgICAgICAgICAgICAgfCAgIENvbmYuICAgICB8ICAgQ29uZi4gICAgIHwgICBDb25m LiAgICAgfCANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgICANClRyb3NzZW4gICAgICAgICAgICAgICAgIEV4cGly ZXMgTm92ZW1iZXIgMjAwMSAgICAgICAgICAgICAgICAgICAgIFs3XSANDA0KSW50ZXJuZXQgRHJh ZnQgICAgIENvdXJzZSBDb250cm9sIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAgICBNYXkgMjAw MSANCiAgICANCiAgICANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgfCBQcm9maWxlIEluZi4gICAgIHwgICAgICAr ICAgICAgfCAgICAgICsgICAgICB8ICAgICAgKyAgICAgIHwgDQogICB8ICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICB8ICAgIGluY2wuICAgIHwgICAgaW5jbC4gICAgfCANCiAgIHwgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgIGZsb29yIGluZi4gfCAgZmxvb3IgaW5mLiB8 IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0gDQogICB8IEluaXRpYXRpb24gICAgICAgfCAgYW5ub3VuY2VkICB8ICBhbm5v dW5jZWQgIHwgIGFubm91bmNlZCAgfCANCiAgIHwgICAgICAgICAgICAgICAgICB8ICAgaW52aXRl ZCAgIHwgICBpbnZpdGVkICAgfCAgIGludml0ZWQgICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IENhcGFi aWxpdGllcyAgICAgfCAgICAgKCspICAgICB8ICAgICAgKyAgICAgIHwgICAgICArICAgICAgfCAN CiAgIHwgUmUtbmVnb3RpYXRpb24gICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAg ICAgICAgICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IEF1dGhlbnRpY2F0aW9uICsgfCAgICAgKCspICAg ICB8ICAgICAoKykgICAgIHwgICAgICgrKSAgICAgfCANCiAgIHwgQXV0aG9yaXphdGlvbiAgICB8 ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICB8IA0KICAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQog ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSANCiAgIHwgTWVtYmVyc2hpcCBJbmZvICB8ICAgICAgKyAgICAgIHwgICAgICArICAg ICAgfCAgICAgICsgICAgICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IEZsb29yIENvbnRyb2wgICAgfCAg ICAgIC0gICAgICB8ICAgICAgKyAgICAgIHwgICAgKyAoZm9yICAgfCANCiAgIHwgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICBhY3RpdmUpICB8IA0KICAg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0gDQogICB8IE1lbWJlcnNoaXAgICAgICAgfCAgYXQgc3RhcnR1cCB8IGJhc2VkIG9uICAg IHwgYmFzZWQgb24gICAgfCANCiAgIHwgRW5mb3JjZW1lbnQgICAgICB8ICAgICBvbmx5ICAgIHwg Zmxvb3IgY3RybCAgfCBmbG9vciBjdHJsICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IEFjdGl2ZS9QYXNz aXZlICAgfCAgICAgIC0gICAgICB8ICAgICAgLSAgICAgIHwgICAgICArICAgICAgfCANCiAgIHwg TW9kZSBDaGFuZ2UgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAg ICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0gDQogICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCiAgIHwgU2NhbGUgICAgICAgICAgICB8IHNtYWxs IGR1ZSB0b3wgZGVwZW5kcyBvbiAgfCAgIGxhcmdlICAgICB8IA0KICAgfCAgICAgICAgICAgICAg ICAgIHwgbGFjayBvZiAgICAgfCBmbG9vciAgY3RybC58ICAgICAgICAgICAgIHwgDQogICB8ICAg ICAgICAgICAgICAgICAgfCBtZWRpYXRpb24gICB8IHNjYWxlICAgICAgIHwgICAgICAgICAgICAg fCANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tIA0KICAgICAgICAgICAgICBUYWJsZSAxIDogU3VtbWFyeSBvZiBDaGFyYWN0 ZXJpc3RpY3MgDQogICAgDQogICBUaGUgZm9sbG93aW5nIEZpZ3VyZSAxIHRyaWVzIHRvIG91dGxp bmUgdGhlIGNhdGVnb3JpZXMgb2YgdGhpcyANCiAgIHNlY3Rpb24gaW4gYSBzY2FsZS1mdW5jdGlv bmFsaXR5IHNwYWNlLCBlbXBoYXNpemluZyB0aGUgc3VwZXJzZXQgDQogICBjaGFyYWN0ZXIgb2Yg dGhlICdyaWNoIGNvbmZlcmVuY2luZycgY2F0ZWdvcnkuIA0KICAgIA0KICAgU2NhbGUgL3xcIA0K ICAgICAgICAgIHx8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS18IA0KICAgICAgICAgIHx8ICAgICAgICAgICAgICAgIFJpY2ggQ29uZmVyZW5jaW5nICAg ICAgICAgICAgICAgICB8IA0KICAgICAgICAgIHx8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgIHx8ICAgICAgICBUb3duIEhhbGwg TWVldGluZ3MsIElFVEYgTWVldGluZ3MgICAgICAgICB8IA0KICAgICAgICAgIHx8fC0tLS0tLS0t LS0tLS0tLS0tLS0tLS18fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXx8IA0KICAgICAgICAgIHx8 fCBTaW1wbGUgQ29uZmVyZW5jaW5nICB8fCBGbG9vciBDb250cm9sbGVkIENvbmYuIHx8IA0KICAg ICAgICAgIHx8fCAgICAgICAgICAgICAgICAgICAgICB8fCAgICAgICAgICAgICAgICAgICAgICAg IHx8IA0KICAgICAgICAgIHx8fCBMZWN0dXJlcywgTWVldGluZ3MgICB8fCBjb25kdWN0ZWQgbWVl dGluZ3MgICAgIHx8IA0KICAgICAgICAgIHx8fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS18fC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLXx8IA0KICAgICAgICAgIHx8LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgICAgICAgIHwtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPiANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGdW5jdGlvbmFsaXR5IA0KICAgIA0K ICAgICAgICAgICAgICBGaWd1cmUgMSA6IENhdGVnb3JpZXMgaW4gU2NhbGUtRnVuY3Rpb25hbGl0 eSBTcGFjZSANCiAgICANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAgICBFeHBpcmVzIE5v dmVtYmVyIDIwMDEgICAgICAgICAgICAgICAgICAgICBbOF0gDQwNCkludGVybmV0IERyYWZ0ICAg ICBDb3Vyc2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgTWF5IDIwMDEgDQog ICAgDQogICAgDQo2LiAgICAgQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJvbCBNb2RlbHMgDQogICAg DQogICBUaGUgY29uZmVyZW5jaW5nIHNjZW5hcmlvcyBpbiBTZWN0aW9uIDUgY2FuIGVhc2lseSBi ZSBtYXBwZWQgb250byANCiAgIG1vZGVscyBmb3IgcmVhbGl6ZSBjb25mZXJlbmNlIGNvdXJzZSBj b250cm9sIHJlYWxpemF0aW9uIHdpdGggDQogICByZXNwZWN0IHRvIHRoZSBmdW5jdGlvbmFsaXRp ZXMgcHJlc2VudGVkIGluIFNlY3Rpb24gMi4gDQogICAgDQo2LjEuICAgTG9vc2UgQ29uZmVyZW5j ZSBDb3Vyc2UgQ29udHJvbCANCiAgICANCiAgICdMb29zZScgY29uZmVyZW5jZSBjb3Vyc2UgY29u dHJvbCAoYWxzbyByZWZlcnJlZCB0byBhcyAnbGlnaHQtd2VpZ2h0IA0KICAgc2Vzc2lvbiBjb250 cm9sJyBbM10pIGlzIHRoZSBtb2RlbCBhcHBsaWNhYmxlIGZvciB0aGUgc2ltcGxlIA0KICAgY29u ZmVyZW5jaW5nIHNjZW5hcmlvIGNhdGVnb3J5IG9mIFNlY3Rpb24gNS4xLiAgDQogICAgDQogICBI ZW5jZSwgdGhpcyBjb250cm9sIG1vZGVsIGxhY2tzIG9mIGV4cGxpY2l0IG1lbWJlcnNoaXAgYW5k IA0KICAgYXBwbGljYXRpb24gc2Vzc2lvbiBjb250cm9sLiBGdXJ0aGVybW9yZSwgZmxvb3IgY29u dHJvbCBmYWNpbGl0aWVzIA0KICAgYXJlIG5vdCBwcm92aWRlZC4gSG93ZXZlciwgbWVtYmVyc2hp cCBpbmZvcm1hdGlvbiBtaWdodCBiZSBnYXRoZXJlZCANCiAgIGR1cmluZyBydW50aW1lIG9mIHRo ZSBzZXNzaW9uLCBjb21wYXJhYmxlIHdpdGggdGhlIGJsdWUgc2hlZXRzIG9mIA0KICAgYXR0ZW5k ZWVzLiANCiAgICANCiAgIFVzdWFsbHksIGdyb3VwIGtleSBtZWNoYW5pc21zIGFyZSBhbHNvIG1p c3NpbmcgZm9yIG1lbWJlcnNoaXAgDQogICBlbmZvcmNlbWVudCBhZnRlciBzdGFydGluZyB0aGUg Y29uZmVyZW5jZS4gDQogICAgDQo2LjIuICAgVGlnaHQgQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJv bCANCiAgICANCiAgICdUaWdodCcgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBbM10gaXMgdGhl IG1vZGVsIGFwcGxpY2FibGUgZm9yIA0KICAgdGhlIGZsb29yIGNvbnRyb2wgY29uZmVyZW5jaW5n IHNjZW5hcmlvIGNhdGVnb3JpZXMgb2YgU2VjdGlvbiA1LjIuIA0KICAgIA0KICAgSGVuY2UsIGFk ZGl0aW9uYWwgZmxvb3IgY29udHJvbCBpbmZvcm1hdGlvbiBvZiB0aGUgY29uZmVyZW5jZSANCiAg IHByb2ZpbGUgb3Igc3RhdGljYWxseSBpbXBsZW1lbnRlZCBhcHBsaWNhdGlvbiBzZW1hbnRpYyBh cmUgdXNlZCBmb3IgDQogICBpbXBsZW1lbnRpbmcgZmxvb3IgY29udHJvbCB0byBtYXAgJ3NvY2lh bCBwcm90b2NvbCcgc2VtYW50aWNzIG9udG8gDQogICB0aGUgZGlzdHJpYnV0ZWQgc2NlbmFyaW8u IEV4YWN0IG1lbWJlcnNoaXAgYW5kIGFwcGxpY2F0aW9uIHNlc3Npb24gDQogICBpbmZvcm1hdGlv biBpcyB1c3VhbGx5IHByb3ZpZGVkIHRvZ2V0aGVyIHdpdGggbWVtYmVyc2hpcCBlbmZvcmNlbWVu dCANCiAgIGJhc2VkIG9uIGZsb29yIGNvbnRyb2wgcG9saWNpZXMgZHVyaW5nIHJ1bnRpbWUgb2Yg dGhlIGNvbmZlcmVuY2UuIA0KICAgIA0KNi4zLiAgICdKZWxseS1saWtlJyBDb25mZXJlbmNlIENv dXJzZSBDb250cm9sIA0KICAgIA0KICAgQXMgYSBjb21iaW5hdGlvbiBvZiB0aGUgbG9vc2UgYW5k IHRpZ2h0IGNvbnRyb2wgbW9kZWwgb2YgU2VjdGlvbiANCiAgIDYuMS4gYW5kIDYuMi4sICdqZWxs eS1saWtlJyBjb3Vyc2UgY29udHJvbCBpcyBjb25zaWRlcmVkIGZvciByaWNoIA0KICAgY29uZmVy ZW5jaW5nIChzZWUgU2VjdGlvbiA1LjMuKSByZWFsaXphdGlvbi4gDQogICAgDQogICBUaGUgdGln aHQgY29udHJvbCBtb2RlbCBpcyBhcHBsaWVkIGZvciB0aGUgYWN0aXZlIHBhcnRpY2lwYW50cyBp biANCiAgIHRoZSBjb25mZXJlbmNlLCB3aGlsZSBhIGxvb3NlIGNvbnRyb2wgbW9kZWwgaXMgdXNl ZCBmb3IgdGhlIHBhc3NpdmUgDQogICBvbmVzLiBJbiBhZGRpdGlvbiB0byB0aGUgZnVuY3Rpb25h bGl0eSBmb3IgdGhlIHNwZWNpZmljIHVzZXIgZ3JvdXAsIA0KICAgaS5lLiwgYWN0aXZlIG9yIHBh c3NpdmUsIG1lY2hhbmlzbXMgdG8gc3VwcG9ydCBtb2RlIGNoYW5nZXMgZnJvbSANCiAgIGFjdGl2 ZSB0byBwYXNzaXZlIGFuZCB2aWNlIHZlcnNhIG1pZ2h0IGJlIHJlcXVpcmVkIHdpdGhvdXQgDQog ICBkaXN0dXJiYW5jZSwgaS5lLiwgaW50ZXJydXB0aW9uLCBvZiB0aGUgcnVubmluZyBjb25mZXJl bmNlLiANCiAgICANCiAgIERpZmZlcmVudCBwb2xpY2llcyBmb3IgdGhpcyBtb2RlIGNoYW5nZSBz aG91bGQgYmUgZmVhc2libGUsIHN1Y2ggYXMgDQogICB1cG9uIGludml0YXRpb24gYnkgaW5kaXZp ZHVhbCBhY3RpdmUgcGFydGljaXBhbnRzIG9yIHVwb24gcmVxdWVzdCBvZiANCiAgIHRoZSBwYXNz aXZlIHBhcnRpY2lwYW50LiANCiAgICANCjcuICAgICBFeGlzdGluZyBTb2x1dGlvbnMgDQogICAg DQogICAgIA0KVHJvc3NlbiAgICAgICAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAg ICAgICAgICAgICAgICAgICAgWzldIA0MDQpJbnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRy b2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KICAg VGhlIGZvbGxvd2luZyBzZWN0aW9uIGlzIGJyaWVmbHkgZXZhbHVhdGluZyBleGlzdGluZyBjb25m ZXJlbmNpbmcgDQogICBzb2x1dGlvbnMgd2l0aCByZXNwZWN0IHRvIHRoZWlyIGNvbmZlcmVuY2Ug Y291cnNlIGNvbnRyb2wgDQogICBmdW5jdGlvbmFsaXR5LiBOb3RlIHRoYXQgdGhpcyBwcmVzZW50 YXRpb24gaXMgcmVzdHJpY3RlZCB0byBzeXN0ZW1zIA0KICAgYmFzZWQgb24gY2VydGFpbiBzdGFu ZGFyZHMsIGhlbmNlIHRoaXMgbGlzdCBkb2VzIG5vdCBjbGFpbSB0byBiZSBhbiANCiAgIGV4aGF1 c3RpdmUgcmV2aWV3IG9mIGV4aXN0aW5nIGNvbmZlcmVuY2luZyBzeXN0ZW1zLiANCiAgICANCiAg IFRoZSBmb2xsb3dpbmcsIGludGVydHdpbmVkLCBjcml0ZXJpYSBhcmUgdXNlZCB0byBldmFsdWF0 ZSB0aGVzZSANCiAgIHNvbHV0aW9uczogDQogICBvIFByb3ZpZGVkIEZ1bmN0aW9uYWxpdHk6IFdo YXQgZnVuY3Rpb25hbGl0eSBpcyBwcm92aWRlZCB3aXRoICANCiAgICAgcmVzcGVjdCB0byBUYWJs ZSAxPyANCiAgIG8gRmxleGliaWxpdHk6IFdoYXQgc2NlbmFyaW9zIGFyZSBjb3ZlcmVkPyBXaGF0 IHBvbGljaWVzIGFyZSAgDQogICAgIHByb3ZpZGVkPyBIb3cgZmxleGlibGUgaXMgdGhlIHByb3Zp ZGVkIGZ1bmN0aW9uYWxpdHk/IA0KICAgbyBFeHRlbmRpYmlsaXR5OiBUbyB3aGF0IGV4dGVudCBj YW4gdGhlIHNvbHV0aW9uIGJlIGV4dGVuZGVkIHRvICANCiAgICAgaW50ZWdyYXRlIG5ldyBmdW5j dGlvbmFsaXR5PyANCiAgIG8gU2NhbGFiaWxpdHk6IFdoYXQgcmVzdHJpY3Rpb25zIGR1ZSB0byBh cmNoaXRlY3R1cmU/IA0KICAgIA0KNy4xLiAgIEguMzJ4IFByb3RvY29sIFN1aXRlIA0KICAgIA0K ICAgbyBGdW5jdGlvbmFsaXR5OiAgDQogICAgIC0gY2VudHJhbGl6ZWQvZGVjZW50cmFsaXplZCBj b25mZXJlbmNpbmcgDQogICAgIC0gcHJldHR5IG11Y2ggYWltaW5nIGF0IGZsb29yIGNvbnRyb2xs ZWQgY29uZmVyZW5jaW5nLCBhbHRob3VnaCAgDQogICAgICAgb25seSBjb25kdWN0ZWQvbm9uLWNv bmR1Y3RlZCBtb2RlcyBzdXBwb3J0ZWQgDQogICAgIC0gTm8gcGFzc2l2ZS9hY3RpdmUgbm90aW9u IGluIHRoZSBvcmlnaW5hbCBILjMyeCwgSC4zMzIgZXh0ZW5zaW9uICANCiAgICAgICBkb2VzbpJ0 IHN1cHBvcnQgY2hhbmdlcyBvZiBsaXN0ZW5lcnMgdG8gYWN0aXZlIHVzZXJzLiANCiAgICAgIA0K ICAgbyBGbGV4aWJpbGl0eTogIA0KICAgICAtIEZsb29yIGNvbnRyb2xsZWQgY29uZmVyZW5jaW5n IGlzIHBvb3JseSBzdXBwb3J0ZWQsIGFsdGhvdWdoIHRoZSAgDQogICAgICAgZGF0YSBjb25mZXJl bmNpbmcgcGFydCBzdXBwb3J0cyB0b2tlbnMuICANCiAgICAgLSBQcmUtZGVmaW5lZCByb2xlIG1v ZGVscywgaS5lLiwgY29uZHVjdGVkIHZlcnN1cyBub24tY29uZHVjdGVkLCAgDQogICAgICAgZm9y IGF1ZGlvdmlzdWFsIHBhcnQuICANCiAgICAgLSBObyBwb2xpY3kgZGVmaW5pdGlvbiwgZS5nLiwg dXNpbmcgYXBwcm9wcmlhdGUgcHJvZmlsZSAgDQogICAgICAgaW5mb3JtYXRpb24uIA0KICAgICAt IHJlY29uZmlndXJhdGlvbiBvZiBydW5uaW5nIGNvbmZlcmVuY2VzIHBvb3JseSBzdXBwb3J0ZWQu IA0KICAgIA0KICAgbyBFeHRlbmRpYmlsaXR5OiANCiAgICAgLSBwcmV0dHkgY2xvc2VkIHN5c3Rl bSBvZiBhIHdob2xlIHNldCBvZiBzdGFuZGFyZHMgDQogICAgDQogICBvIFNjYWxhYmlsaXR5OiB2 ZXJ5IHJlc3RyaWN0ZWQgZHVlIHRvIHRpZ2h0IGNlbnRyYWxpemVkIGNvbnRyb2wgIA0KICAgICBz dHJ1Y3R1cmUgDQogICAgDQogICBbVEJEXSBhZGQgb3RoZXIgcG9pbnRzLCBlaXRoZXIgaXRlbXMg b3Igc3ViaXRlbXMgDQogICAgDQo3LjIuICAgU0lQLWJhc2VkIFNvbHV0aW9ucyANCiAgICANCiAg IG8gRnVuY3Rpb25hbGl0eTogIA0KICAgICAtIGZsZXhpYmxlIGluaXRpYXRpb24gbW9kZWxzIFsx MV0gIA0KICAgICAtIG1lbWJlcnNoaXAgaW5mb3JtYXRpb24gdXNpbmcgUlRDUCBpbmZvcm1hdGlv biAobG9vc2UgY29udHJvbCkgb3IgICAgICANCiAgICAgICBhLXByaW9yaSBpbmZvcm1hdGlvbiAN CiAgICAgLSBubyBtZW1iZXJzaGlwIGVuZm9yY2VtZW50IA0KICAgICAtIG5vIGZsb29yIGNvbnRy b2wgDQogICAgIC0gbm8gY2FwYWJpbGl0eSByZS1uZWdvdGlhdGlvbiANCiAgICANCiAgIG8gRmxl eGliaWxpdHkvRXh0ZW5kaWJpbGl0eTogDQogICAgIA0KVHJvc3NlbiAgICAgICAgICAgICAgICAg RXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAgICBbMTBdIA0MDQpJbnRlcm5l dCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgICAgIE1h eSAyMDAxIA0KICAgIA0KICAgIA0KICAgICAtIGV4dGVuc2lvbiBwb3NzaWJsZSBieSBhZGRpbmcg Y29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCAgDQogICAgICAgZnVuY3Rpb25hbGl0eSBhcyBzZXBh cmF0ZWQgY29tcG9uZW50IGR1ZSB0byBvcGVuIHN5c3RlbSAgDQogICAgICAgY2hhcmFjdGVyIA0K ICAgICAtIG90aGVyIHNjZW5hcmlvcyBwb3NzaWJsZSBieSBhZGRpbmcgZnVuY3Rpb25hbGl0eSAN CiAgICANCiAgIG8gU2NhbGFiaWxpdHk6IGRlcGVuZHMgb24gdGhlIGluaXRpYXRpb24gbW9kZWws IGJ1dCBtb3N0IGxpa2VseSAgDQogICAgIHNpbWlsYXIgdG8gdGhlIHNpbXBsZSBjb25mZXJlbmNp bmcgY2F0ZWdvcnkgKHNlZSBTZWN0aW9uIDUuMSkgDQogICAgDQogICBbVEJEXSBhZGQgb3RoZXIg cG9pbnRzLCBlaXRoZXIgaXRlbXMgb3Igc3ViaXRlbXMgDQogICAgDQogICAgDQo4LiAgICAgTmV4 dCBTdGVwcyANCiAgICANCiAgIFRoZSBmb2xsb3dpbmcgaXRlbXMgYXJlIHByb3Bvc2VkIGFzIG5l eHQgc3RlcHM6IA0KICAgIA0KICAgbyBEZWZpbml0aW9uIG9mIHJlcXVpcmVtZW50cyANCiAgIG8g UHJvcG9zYWwgZm9yIHByb3ZpZGVkIHNlcnZpY2VzIA0KICAgbyBQcm9wb3NhbCBvZiBwcm90b2Nv bCBzb2x1dGlvbnMgDQogICBvIEFuYWx5c2lzIG9mIHByb3RvY29sIHNvbHV0aW9ucyANCiAgIG8g UmVjb21tZW5kYXRpb24gb2YgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBzZXJ2aWNlIGFuZCBw cm90b2NvbCANCiAgICANCiAgIEEgY3J1Y2lhbCBwYXJ0IG9mIHRoZSBhbmFseXNpcyB3b3JrIGlz IHRvIHN0dWR5IGV4aXN0aW5nIHNvbHV0aW9ucyANCiAgIHdpdGggcmVzcGVjdCB0byB0aGVpciBh cHBsaWNhYmlsaXR5IGFuZCB0aGVpciBhbGlnbm1lbnQgd2l0aCB0aGUgDQogICBkZWZpbmVkIHNj b3BlIG9mIFNlY3Rpb24gMiBhbmQgdGhlIHByb2JsZW0gc3RhdGVtZW50IGluIFNlY3Rpb24gMy4g DQogICAgDQogICAgDQo5LiAgICAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgDQogDQogICBUaGlz IGRvY3VtZW50IG1lcmVseSBkaXNjdXNzZXMgcHJvYmxlbSBzdGF0ZW1lbnRzIG1vdGl2YXRpbmcg dGhlIA0KICAgbmVlZCBmb3IgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBtZWNoYW5pc21zLiBT ZWN1cml0eSBpcyBhbiBpc3N1ZSANCiAgIGZvciBjb25mZXJlbmNlIGNvdXJzZSBjb250cm9sIGJ1 dCBpcyBjb25zaWRlcmVkIGluIHN1YnNlcXVlbnQgDQogICBzb2x1dGlvbi1zcGFjZSBkb2N1bWVu dHMuIA0KICAgIA0KICAgIA0KMTAuICAgIEFja25vd2xlZGdlbWVudHMgDQogICAgDQogICBJIHdv dWxkIGxpa2UgdG8gYWNrbm93bGVkZ2UgdGhlIHBhcnRpY2lwYW50cyBvZiB0aGUgbWFpbGluZyBs aXN0IA0KICAgdGhhdCB3YXMgc2V0IHVwIHRvIGRpc2N1c3MgdGhlIHRoaXMgZG9jdW1lbnQuIFRo ZWlyIGNvbnRyaWJ1dGlvbnMgDQogICBhbmQgYWN0aXZlIHBhcnRpY2lwYXRpb24gaW4gdGhlIGRp c2N1c3Npb24gb24gdGhlIG1haWxpbmcgbGlzdCB3ZXJlIA0KICAgdmVyeSB1c2VmdWwgaW4gdGhl IHByZXBhcmF0aW9uIG9mIHRoaXMgZG9jdW1lbnQuIA0KICAgIA0KICAgIA0KMTEuICAgIFJlZmVy ZW5jZXMgDQogICAgDQogICBbMV0gIEMuIEJvcm1hbm4sIEouIE90dCwgRC4gS3V0c2NoZXIsIEQu IFRyb3NzZW4sICJTaW1wbGUgQ29uZmVyZW5jZSANCiAgICAgICAgQ29udHJvbCBQcm90b2NvbCCW IFNlcnZpY2UgU3BlY2lmaWNhdGlvbiIsIGRyYWZ0LWlldGYtbW11c2ljLQ0KICAgICAgICBzY2Nw LTAxLnR4dCwgV29yayBpbiBQcm9ncmVzcywgRmVicnVhcnkgMjAwMSANCiAgICANCiAgIFsyXSAg SC4gRXJpa3Nzb24sICJNQk9ORTogVGhlIE11bHRpY2FzdCBCYWNrYm9uZSIsIENvbW11bmljYXRp b25zIG9mIA0KICAgICAgICB0aGUgQUNNLCBWb2wuMzcgTm8uOCwgcHAuNTQtNjAsIEF1Z3VzdCAx OTk0IA0KIA0KICAgICANClRyb3NzZW4gICAgICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIg MjAwMSAgICAgICAgICAgICAgICAgICAgWzExXSANDA0KSW50ZXJuZXQgRHJhZnQgICAgIENvdXJz ZSBDb250cm9sIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAgICBNYXkgMjAwMSANCiAgICANCiAg ICANCiAgIFszXSAgTS4gSGFuZGxleSwgSi4gQ3Jvd2Nyb2Z0LCBDLiBCb3JtYW5uLCAiVGhlIElu dGVybmV0IE11bHRpbWVkaWEgDQogICAgICAgIENvbmZlcmVuY2luZyBBcmNoaXRlY3R1cmUiLCBk cmFmdC1pZXRmLW1tdXNpYy1jb25mYXJjaC0wMy50eHQsIA0KICAgICAgICBXb3JrIEluIFByb2dy ZXNzLCBKdWx5IDIwMDAgIA0KICAgIA0KICAgWzRdICBNLiBIYW5kbGV5LCBWLiBKYWNvYnNvbiwg IlNEUDogU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCIsIA0KICAgICAgICBSRkMgMjMyNywg QXByaWwgMTk5OCANCiAgICANCiAgIFs1XSAgTS4gSGFuZGxleSwgSC4gU2NodWx6cmlubmUsIEUu IFNjaG9vbGVyLCBKLiBSb3NlbmJlcmcsICJTSVA6IA0KICAgICAgICBTZXNzaW9uIEluaXRpYXRp b24gUHJvdG9jb2wiLCBSRkMgMjU0MywgTWFyY2ggMTk5OSANCiAgICANCiAgIFs2XSAgTS4gSGFu ZGxleSwgQy4gUGVya2lucywgRS4gV2hlbGFuLCAiU2Vzc2lvbiBhbm5vdW5jZW1lbnQgDQogICAg ICAgIHByb3RvY29sIiwgUkZDIDI5NzQsIE9jdG9iZXIgMjAwMCANCiAgICANCiAgIFs3XSAgSVRV LVQsICJWaXN1YWwgVGVsZXBob25lIFN5c3RlbXMgYW5kIEVxdWlwbWVudCBmb3IgTG9jYWwgQXJl YSANCiAgICAgICAgTmV0d29ya3Mgd2l0aCBOb24tR3VhcmFudGVlZCBRdWFsaXR5IG9mIFNlcnZp Y2UiLCBJVFUtVCANCiAgICAgICAgUmVjb21tZW5kYXRpb24gSC4zMjMsIDIwMDAgDQogICAgDQog ICBbOF0gIElUVS1ULCAiSC4zMjMgZXh0ZW5kZWQgZm9yIGxvb3NlbHkgY291cGxlZCBjb25mZXJl bmNlcyIsIElUVS1UIA0KICAgICAgICBSZWNvbW1lbmRhdGlvbiBILjMzMiwgU2VwdGVtYmVyIDE5 OTggDQogICAgDQogICBbOV0gIEQuIEt1dHNjaGVyLCBKLiBPdHQsIEMuIEJvcm1hbm4sICJSZXF1 aXJlbWVudHMgZm9yIFNlc3Npb24gDQogICAgICAgIERlc2NyaXB0aW9uIGFuZCBDYXBhYmlsaXR5 IE5lZ290aWF0aW9uIiwgZHJhZnQtaWV0Zi1tbXVzaWMtDQogICAgICAgIHNkcG5nLXJlcS0wMC50 eHQsIFdvcmsgSW4gUHJvZ3Jlc3MsIEZlYnJ1YXJ5IDIwMDEgDQogDQogICBbMTBdIEouIE90dCwg Qy4gUGVya2lucywgRC4gS3V0c2NoZXIsICJBIE1lc3NhZ2UgQnVzIGZvciBMb2NhbCANCiAgICAg ICAgQ29vcmRpbmF0aW9uIiwgZHJhZnQtaWV0Zi1tbXVzaWMtbWJ1cy10cmFuc3BvcnQtMDQudHh0 LCBXb3JrIEluIA0KICAgICAgICBQcm9ncmVzcywgRmVicnVhcnkgMjAwMSANCiANCiAgIFsxMV0g Si4gUm9zZW5iZXJnLCBILiBTY2h1bHpyaW5uZSwgIk1vZGVscyBmb3IgTXVsdGkgUGFydHkgDQog ICAgICAgIENvbmZlcmVuY2luZyBpbiBTSVAiLCBkcmFmdC1yb3NlbmJlcmctc2lwLWNvbmZlcmVu Y2luZy1tb2RlbHMtDQogICAgICAgIDAwLnR4dCwgV29yayBJbiBQcm9ncmVzcywgTm92ZW1iZXIg MjAwMCANCiANCiAgIFsxMl0gSC4gU2NodWx6cmlubmUsIFMuIENhc25lciwgUi4gRnJlZGVyaWNr LCBWLiBKYWNvYnNvbiwgIlJUUDogQSANCiAgICAgICAgVHJhbnNwb3J0IFByb3RvY29sIGZvciBS ZWFsLVRpbWUgQXBwbGljYXRpb25zIiwgUkZDIDE4ODksIA0KICAgICAgICBKYW51YXJ5IDE5OTYg DQogDQogICBbMTNdIEQuIFRyb3NzZW4sICJTY2FsYWJsZSBGbG9vciBDb250cm9sIGluIENvbmZl cmVuY2luZyANCiAgICAgICAgRW52aXJvbm1lbnRzOiBUaGUgUkJvbmUgQXBwcm9hY2giLCAybmQg SVAgVGVsZXBob255IFdvcmtzaG9wLCANCiAgICAgICAgTmV3IFlvcmssIEFwcmlsIDIwMDEgDQog ICAgDQogICAgDQogICAgDQpBdXRob3IncyBBZGRyZXNzIA0KICAgIA0KICAgRGlyayBUcm9zc2Vu IA0KICAgTm9raWEgUmVzZWFyY2ggDQogICA1IFdheXNpZGUgUm9hZCANCiAgIEJ1cmxpbmd0b24s IE1BIDAyNDc0IFVTQSAgICAgIA0KICAgUGhvbmU6ICAxLTc4MS05OTMtMzYwNSANCiAgIEVtYWls OiAgZGlyay50cm9zc2VuQG5va2lhLmNvbSANCiAgICANCiAgICANCkZ1bGwgQ29weXJpZ2h0IFN0 YXRlbWVudCANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAgICBFeHBpcmVzIE5vdmVtYmVy IDIwMDEgICAgICAgICAgICAgICAgICAgIFsxMl0gDQwNCkludGVybmV0IERyYWZ0ICAgICBDb3Vy c2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgTWF5IDIwMDEgDQogICAgDQog ICAgDQogICAgDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAxKS4g QWxsIFJpZ2h0cyBSZXNlcnZlZC4gDQogICAgDQogICBUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xh dGlvbnMgb2YgaXQgbWF5IGJlIGNvcGllZCBhbmQgZnVybmlzaGVkIHRvIA0KICAgb3RoZXJzLCBh bmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0IGNvbW1lbnQgb24gb3Igb3RoZXJ3aXNlIGV4cGxhaW4g aXQgDQogICBvciBhc3Npc3QgaW4gaXRzIGltcGxlbWVudGF0aW9uIG1heSBiZSBwcmVwYXJlZCwg Y29waWVkLCBwdWJsaXNoZWQgDQogICBhbmQgZGlzdHJpYnV0ZWQsIGluIHdob2xlIG9yIGluIHBh cnQsIHdpdGhvdXQgcmVzdHJpY3Rpb24gb2YgYW55IA0KICAga2luZCwgcHJvdmlkZWQgdGhhdCB0 aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwYXJhZ3JhcGggDQogICBhcmUgaW5j bHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLiBIb3dldmVyLCB0 aGlzIA0KICAgZG9jdW1lbnQgaXRzZWxmIG1heSBub3QgYmUgbW9kaWZpZWQgaW4gYW55IHdheSwg c3VjaCBhcyBieSByZW1vdmluZyANCiAgIHRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5j ZXMgdG8gdGhlIEludGVybmV0IFNvY2lldHkgb3Igb3RoZXIgDQogICBJbnRlcm5ldCBvcmdhbml6 YXRpb25zLCBleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUgcHVycG9zZSBvZiANCiAgIGRldmVsb3Bp bmcgSW50ZXJuZXQgc3RhbmRhcmRzIGluIHdoaWNoIGNhc2UgdGhlIHByb2NlZHVyZXMgZm9yIA0K ICAgY29weXJpZ2h0cyBkZWZpbmVkIGluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgcHJvY2VzcyBt dXN0IGJlIA0KICAgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBpdCBpbnRv IGxhbmd1YWdlcyBvdGhlciB0aGFuIA0KICAgRW5nbGlzaC4gDQogICAgDQogICBUaGUgbGltaXRl ZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3ZlIGFyZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90IGJl IA0KICAgcmV2b2tlZCBieSB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBpdHMgc3VjY2Vzc29ycyBv ciBhc3NpZ25zLiANCiAgICANCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaGVyZWluIGlzIHByb3ZpZGVkIG9uIGFuIA0KICAgIkFTIElTIiBiYXNpcyBhbmQg VEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyANCiAgIFRB U0sgRk9SQ0UgRElTQ0xBSU1TIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIElO Q0xVRElORyANCiAgIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNF IE9GIFRIRSBJTkZPUk1BVElPTiANCiAgIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklH SFRTIE9SIEFOWSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgDQogICBNRVJDSEFOVEFCSUxJVFkgT1Ig RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIA0KICAgIA0KQWNrbm93bGVkZ2VtZW50 IA0KICAgIA0KICAgRnVuZGluZyBmb3IgdGhlIFJGQyBlZGl0b3IgZnVuY3Rpb24gaXMgY3VycmVu dGx5IHByb3ZpZGVkIGJ5IHRoZSANCiAgIEludGVybmV0IFNvY2lldHkuIA0KICAgICANClRyb3Nz ZW4gICAgICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAwMSAgICAgICAgICAgICAgICAg ICAgWzEzXSANDA== ------_=_NextPart_001_01C12A7B.8C236B40-- >From owner-rmt@listserv.lbl.gov Tue Aug 21 14:05:36 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7LL3AM13020; Tue, 21 Aug 2001 14:03: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.11.2/8.11.2) with ESMTP id f7LL39V13016 for ; Tue, 21 Aug 2001 14:03:09 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LL38f25120 for ; Tue, 21 Aug 2001 14:03:08 -0700 (PDT) Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LL37525112 for ; Tue, 21 Aug 2001 14:03:07 -0700 (PDT) Received: from [63.105.122.193] (account marshall_eubanks HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1069763; Tue, 21 Aug 2001 16:57:59 -0400 Message-ID: <3B82CC8A.AB7C0BC@21rst-century.com> Date: Tue, 21 Aug 2001 17:03:09 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Trossen Dirk (NRC/Boston)" CC: mankin@ISI.EDU, Michael Luby , Rob Lanphier , Ross Finlayson , "Rmt@Lbl. Gov" , confctrl@ISI.EDU, sob@harvard.edu, ietf-floor control Subject: Re: Session control protocol instantiation discussion within the IETF References: Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk "Trossen Dirk (NRC/Boston)" wrote: > Hi all, > > as announced on the MMUSIC mailing list, a couple of people > being interested in conference course control met on Wednesday > August 8th (10-11pm) during the London IETF meeting to discuss > further steps in this direction. > > The following persons were present during this informal meeting: > Jun-Won Lee, Shin-Gak Kang, Jonathan Rosenberg, Eunsook Kim, > Colin Perkins, Joerg Ott, Dirk Kutscher, Dirk Trossen > > During the meeting, a general interest in this topic was > expressed by the attendents. However, the concern was > raised (by Jonathan, Joerg, and Colin) that the scope > of the work has to be defined very carefully. Especially > Jonathan expressed interest in 'doable' solutions, i.e., > covering rather simple centralized conferencing scenarios > first rather than defining a wide scope of the work. > > The following steps have been proposed to be undertaken in > this direction: > - provision of a problem statement document > - submission to mailing list(s) > - creation of own discussion list for this topic > > The problem statement document should be created by a circle > of people being interested in this topic and willing to contribute > to this work. > The discussion of the problem statement should end in a > decision how to bring this topic to the IETF within the > therein defined scope, either within the charter of existing > WGs or by organizing a BOF. > > Since similar discussions about future session control efforts > have been undertaken within the RMT WG, I'm sending this mail > also to this list to invite interested people to join the discussion. > > Enclosed you find the current document which was meant as a > problem statement for conference course control. This document > is far from being completed (it was not submitted as a draft although > it is written in Internet draft style) but it is intended as a basis > for discussion to reach final document status. > > Any comments are welcome. > > Best Regards, > > Dirk Trossen > ----------------------- > Dirk Trossen > Nokia Research Center > 5 Wayside Road > Burlington, MA 01803 > Tel: +1 (781) 993 3605 > Fax: +1 (781) 993 1907 > mob: +1 (617) 794 7041 > ----------------------- > > > -----Original Message----- > > From: ext Allison Mankin [mailto:mankin@ISI.EDU] > > Sent: Wednesday, August 08, 2001 11:49 PM > > To: Michael Luby > > Cc: Rob Lanphier; Ross Finlayson; Rmt@Lbl. Gov; confctrl@ISI.EDU; > > Allison Mankin; sob@harvard.edu > > Subject: Re: Session control protocol instantiation discussion within > > the IETF > > > > > > Mike, > > > > We ADs would be happy to talk with you about this sometime (but after > > we all recover from IETF). > > > > Having had one hallway talk with you while you were in London, > > I think there is some value to discussing session work (without > > prejudging if it would extend an existing charter or start up in > > a new situation of some sort). > > > > Mike Luby wrote: > > > All, > > > I unfortunately was only at the IETF for a couple of days, > > and am back in > > > the Bay Area now. I would first like to talk with the > > transport area > > > directorate (Scott and Allison) to get some advice on this, and then > > > probably followup with a conference call with whoever is > > interested. Would > > > a conference call be ok with you Rob, Ross (and whoever else is > > > interested?). > > > Mike > > > > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > Name: draft-trossen-problem-00.txt > draft-trossen-problem-00.txt Type: Plain Text (text/plain) > Encoding: base64 > Description: draft-trossen-problem-00.txt Are you planning to set up a separate mailing list devoted to this ? -- Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ Check the status of multicast in real time : http://www.multicasttech.com/status/index.html >From owner-rmt@listserv.lbl.gov Tue Aug 21 18:50:27 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7M1mSe24791; Tue, 21 Aug 2001 18:48:28 -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.11.2/8.11.2) with ESMTP id f7M1mQV24787 for ; Tue, 21 Aug 2001 18:48:26 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7M1mPa23709 for ; Tue, 21 Aug 2001 18:48:25 -0700 (PDT) Received: from cs.usm.my (cs.usm.my [161.142.8.1]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7M1mN523704 for ; Tue, 21 Aug 2001 18:48:23 -0700 (PDT) Received: from cs.usm.my (cs.usm.my [161.142.8.1]) by cs.usm.my (8.11.4/8.11.4) with ESMTP id f7M1ljp17732; Wed, 22 Aug 2001 09:47:45 +0800 (SGT) Date: Wed, 22 Aug 2001 09:47:45 +0800 (SGT) From: Sureswaran Ramadass To: Marshall Eubanks cc: "Trossen Dirk (NRC/Boston)" , , Michael Luby , Rob Lanphier , Ross Finlayson , "Rmt@Lbl. Gov" , , , Gopinath Rao , ietf-floor control Subject: Re: Session control protocol instantiation discussion within the IETF In-Reply-To: <3B82CC8A.AB7C0BC@21rst-century.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rmt@lbl.gov Precedence: bulk Hi Marshall, Yes, there currently is an email list. It is flr-ctrl-grp@network2.cs.usm.my To be added to the group, simple email your request to gopi@nrg.cs.usm.my Thanks for your interest and thanks to Dirk for getting this group moving. Sures. > Are you planning to set up a separate mailing list devoted to this ? > > -- > Regards > Marshall Eubanks > > > T.M. Eubanks > Multicast Technologies, Inc > 10301 Democracy Lane, Suite 410 > Fairfax, Virginia 22030 > Phone : 703-293-9624 Fax : 703-293-9609 > e-mail : tme@multicasttech.com > http://www.on-the-i.com > > Test your network for multicast : http://www.multicasttech.com/mt/ > Check the status of multicast in real time : > http://www.multicasttech.com/status/index.html > > > Dr. Sureswaran Ramadass Programme Chairman & email: sures@cs.usm.my Head of Network Research, tel: 604-8603004 School of Computer Sciences fax: 604-6573335 University of Science, http://network2.cs.usm.my 11800 Penang, Malaysia >From owner-rmt@listserv.lbl.gov Wed Aug 22 08:22:13 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7MFCYx10737; Wed, 22 Aug 2001 08:12: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.11.2/8.11.2) with ESMTP id f7MFCWV10733 for ; Wed, 22 Aug 2001 08:12:33 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7MFCVr25438 for ; Wed, 22 Aug 2001 08:12:31 -0700 (PDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7MFCU525420 for ; Wed, 22 Aug 2001 08:12:30 -0700 (PDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7MFCWi06173 for ; Wed, 22 Aug 2001 10:12:32 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 22 Aug 2001 10:12:26 -0500 content-class: urn:content-classes:message Subject: RE: Session control protocol instantiation discussion within the IETF Date: Wed, 22 Aug 2001 09:51:49 -0500 Message-ID: X-MS-Has-Attach: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C12B19.F8CF8190" X-MS-TNEF-Correlator: Thread-Topic: RE: Session control protocol instantiation discussion within the IETF Thread-Index: AcEqe4uEShQMW6crRN2OATPOjXiPhA== X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 From: "Trossen Dirk (NRC/Boston)" To: , "'Michael Luby'" Cc: "'Rob Lanphier'" , "'Ross Finlayson'" , "'Rmt@Lbl. Gov'" , , , "'ietf-floor control'" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C12B19.F8CF8190 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry, here's the document I was talking about in the previous mail. ------_=_NextPart_001_01C12B19.F8CF8190 Content-Type: text/plain; name="draft-trossen-problem-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-trossen-problem-00.txt Content-Disposition: attachment; filename="draft-trossen-problem-00.txt" DQpJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlICAgICAgICAgICAgICAgICAgRC4gVHJv c3NlbiAoRWRpdG9yKSANCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIE5va2lhIFJlc2VhcmNoIA0KZHJhZnQtdHJvc3Nlbi1wcm9ibGVtLTAwLnR4 dCAgICAgICAgICAgICAgICAgICAgICAgICAgICAxMS4gTWF5IDIwMDEgDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlczogTm92ZW1iZXIgMjAwMSAN CiANCiANCiAgICAgICAgICAgICAgICBDb25mZXJlbmNlIENvdXJzZSBDb250cm9sIFByb2JsZW0g U3RhdGVtZW50IA0KIA0KIA0KU3RhdHVzIG9mIHRoaXMgTWVtbyANCiANCiAgIFRoaXMgZG9jdW1l bnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2UgDQogICB3 aXRoIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4gDQogICAgDQogICAg DQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5l dCBFbmdpbmVlcmluZyANCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMg d29ya2luZyBncm91cHMuICBOb3RlIHRoYXQgICAgICANCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxz byBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLiAN CiAgICANCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBh IG1heGltdW0gb2Ygc2l4IA0KICAgbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQs IG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgDQogICBhdCBhbnkgdGltZS4gIEl0IGlz IGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyANCiAgIHJlZmVyZW5jZSBt YXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4i IA0KICAgIA0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFj Y2Vzc2VkIGF0IA0KICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0 cy50eHQgDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMg Y2FuIGJlIGFjY2Vzc2VkIGF0IA0KICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5o dG1sLiANCiAgICANCkNvcHlyaWdodCBOb3RpY2UgDQogICAgDQogICBDb3B5cmlnaHQgKGMpIFRo ZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAxKS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4gDQogICAgDQpB YnN0cmFjdCANCiAgICANCiAgIEFzIHBhcnQgb2YgdGhlIEludGVybmV0IE11bHRpbWVkaWEgQ29u ZmVyZW5jaW5nIEFyY2hpdGVjdHVyZSBbM10sIA0KICAgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJv bCBkZWFscyB3aXRoIHRoZSBjb250cm9sIG9mIHJ1bm5pbmcgDQogICBjb25mZXJlbmNlcyBhZnRl ciB0aGUgY3JlYXRpb24gb2YgdGhlIGluaXRpYWwgY29uZmVyZW5jZSBzdGF0ZSB3aXRoIA0KICAg cmVzcGVjdCB0byB0aGUgbWVtYmVyc2hpcCBhbmQgYWNjZXNzIGNvbnRyb2wgZHVyaW5nIHJ1bnRp bWUgb2YgdGhlIA0KICAgc2Vzc2lvbi4gVGhlIHNwZWN0cnVtIG9mIHNjZW5hcmlvcyByZWFjaGVz IGZyb20gc21hbGwgbXVsdGlwYXJ0eSANCiAgIGdhdGhlcmluZ3MgdXAgdG8gbGFyZ2Ugc2NhbGVk IG1lZXRpbmdzIHdpdGggYSBoaWdoIGZsdWN0dWF0aW9uIG9mIA0KICAgdXNlcpJzIG1lbWJlcnNo aXAgYW5kIGFjdGl2aXR5LiANCiAgICANCiAgIFRoaXMgZG9jdW1lbnQgaWRlbnRpZmllcyB0aGUg cHJvYmxlbSBhcmVhIHRvIGRlZmluZSB0aGUgc2NvcGUgb2YgYSANCiAgIGNvbmZlcmVuY2UgY291 cnNlIGNvbnRyb2wgd29ya2luZyBncm91cCBpbiB0aGUgSUVURi4gDQogDQogICAgIA0KVHJvc3Nl biAgICAgICAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAg ICAgWzFdIA0MDQpJbnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0 ZW1lbnQgICAgICAgICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KVGFibGUgb2YgQ29udGVudHMg DQogICAgDQogICAxLiBJbnRyb2R1Y3Rpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4yIA0KICAgMi4gRGVmaW5pdGlvbiBvZiBUZXJtcy4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMyANCiAgIDMuIFNjb3BlLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQgDQog ICA0LiBQcm9ibGVtIFN0YXRlbWVudC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi40IA0KICAgNS4gQ29uZmVyZW5jaW5nIFNjZW5hcmlvcy4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNSANCiAgIDUuMS4gIFNpbXBsZSBDb25mZXJlbmNp bmcuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUgDQogICA1LjEuMS4g IEV4YW1wbGVzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li42IA0KICAgNS4yLiAgRmxvb3IgQ29udHJvbGxlZCBDb25mZXJlbmNpbmcuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uNiANCiAgIDUuMi4xLiAgRXhhbXBsZXMuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYgDQogICA1LjMuICBSaWNoIENvbmZl cmVuY2luZy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42IA0KICAg NS4zLjEuICBFeGFtcGxlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uNyANCiAgIDUuNC4gIFN1bW1hcnkgb2YgQ2hhcmFjdGVyaXN0aWNzLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcgDQogICA2LiBDb25mZXJlbmNlIENvdXJzZSBDb250 cm9sIE1vZGVscy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45IA0KICAgNi4xLiAgTG9v c2UgQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJvbC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u OSANCiAgIDYuMi4gIFRpZ2h0IENvbmZlcmVuY2UgQ291cnNlIENvbnRyb2wuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjkgDQogICA2LjMuICAnSmVsbHktbGlrZScgQ29uZmVyZW5jZSBDb3Vy c2UgQ29udHJvbC4uLi4uLi4uLi4uLi4uLi4uLi4uLi45IA0KICAgNy4gRXhpc3RpbmcgU29sdXRp b25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOSANCiAgIDcu MS4gIEguMzJ4IFByb3RvY29sIFN1aXRlLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uMTAgDQogICA3LjIuICBTSVAtYmFzZWQgU29sdXRpb25zLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwIA0KICAgOC4gTmV4dCBTdGVwcy4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMSANCiAgIDkuIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTEg DQogICAxMC4gIEFja25vd2xlZGdlbWVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjExIA0KICAgMTEuICBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMSANCiAgICANCiAgICANCjEuICAgICBJbnRy b2R1Y3Rpb24gDQogICAgDQogICBJbnRlcmFjdGl2ZSBjb2xsYWJvcmF0aXZlIHNjZW5hcmlvcyBs aWtlIHJlbW90ZSBtZWV0aW5ncywgdmlydHVhbCANCiAgIGNsYXNzcm9vbXMsIG9yIHNoYXJpbmcg YXBwbGljYXRpb25zIHZpYSB0aGUgSW50ZXJuZXQgaGF2ZSBiZWNvbWUgDQogICBtb3JlIGFuZCBt b3JlIHBvcHVsYXIgaW4gdGhlIHBhc3QgdGVuIHllYXJzLiANCiAgICANCiAgIEFjY29yZGluZyB0 byBbM10sIHRoZSB0ZXJtICdjb25mZXJlbmNpbmcnIGlzIGNvbnNpZGVyZWQgaW4gdGhlIA0KICAg cmVtYWluZGVyIG9mIHRoaXMgZG9jdW1lbnQgYXMgc3luY2hyb25vdXMsIHJlYWwtdGltZSBjb21t dW5pY2F0aW9uLCANCiAgIHNwZWNpZmljYWxseSBpbmNsdWRpbmcgYXVkaW8gYW5kIHZpZGVvIG1l ZGlhIGJ1dCBhbHNvIHNoYXJlZCBkYXRhIA0KICAgbWVkaWEgc3VjaCBhcyB3aGl0ZWJvYXJkcywg YW1vbmcgYSBzZXQgb2YgbWVtYmVycy4gU2V2ZXJhbCwgcHJvYmFibHkgDQogICBpbmRlcGVuZGVu dGx5IGltcGxlbWVudGVkLCBhZ2VudHMgZm9yIG1lZGlhIGhhbmRsaW5nIGFuZCBjb250cm9sIA0K ICAgcHVycG9zZXMgaGF2ZSB0byBiZSBjb29yZGluYXRlZCBhbmQgc3luY2hyb25pemVkIGR1cmlu ZyBydW50aW1lIG9mIA0KICAgdGhlIGNvbmZlcmVuY2UsIHJlZmVycmVkIHRvIGFzICdjb25mZXJl bmNlIGNvdXJzZSBjb250cm9sJyBpbiB0aGUgDQogICBmb2xsb3dpbmcsIGFmdGVyIGNyZWF0aW5n IHRoZSBpbml0aWFsIGNvbmZlcmVuY2Ugc3RhdGUgYXMgcGFydCBvZiANCiAgIHRoZSBjb25mZXJl bmNpbmcgc2V0dXAgZnVuY3Rpb25hbGl0eS4gVGhlIHByb3ZpZGVkIGZ1bmN0aW9uYWxpdHkgDQog ICB3aXRoIHJlc3BlY3QgdG8gY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCB1c3VhbGx5IGRlcGVu ZHMgb24gdGhlIA0KICAgY29uc2lkZXJlZCBzY2VuYXJpbyBpbiB3aGljaCBpdCBpcyBuZWVkZWQu ICANCiAgICANCiAgIEluIHRoZSBmb2xsb3dpbmcsIHRoZSBzY29wZSBvZiBjb25mZXJlbmNpbmcg Y291cnNlIGNvbnRyb2wgYXMgd2VsbCANCiAgIGFzIGEgcHJvYmxlbSBzdGF0ZW1lbnQgd2lsbCBi ZSBwaW5wb2ludGVkLiBGdXJ0aGVybW9yZSwgc2NlbmFyaW9zIA0KICAgZm9yIG11bHRpbWVkaWEg Y29uZmVyZW5jaW5nIGluIHRoZSBJbnRlcm5ldCBhcmUgY2F0ZWdvcml6ZWQsIA0KICAgcmVhY2hp bmcgZnJvbSBzbWFsbCBjbG9zZWQgbWVldGluZ3MgdG8gbGFyZ2UgcGxlbmFyeSBzZXNzaW9ucyB3 aXRoIA0KICAgICANClRyb3NzZW4gICAgICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAw MSAgICAgICAgICAgICAgICAgICAgIFsyXSANDA0KSW50ZXJuZXQgRHJhZnQgICAgIENvdXJzZSBD b250cm9sIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAgICBNYXkgMjAwMSANCiAgICANCiAgICAN CiAgIGhpZ2ggZmx1Y3R1YXRpb25zIHJlZ2FyZGluZyB0aGUgcGFydGljaXBhbnSScyBhY3Rpdml0 eSBhbmQgDQogICBpbnRlcmVzdHMuIFNpbmNlIHRoZSBmb2N1cyBvZiB0aGUgZG9jdW1lbnQgaXMg b24gY29udHJvbCBpc3N1ZXMgaW4gDQogICBjb25mZXJlbmNpbmcsIGRhdGEgZGVsaXZlcnkgYXNw ZWN0cyBhcmUgbGVmdCBvdXQgb2YgY29uc2lkZXJhdGlvbi4gDQogICAgDQogICBUaGUgc2NlbmFy aW8gZmluZGluZ3MgYXJlIHRoZW4gdXNlZCB0byBkZWZpbmUgbW9kZWxzIGZvciBjb25mZXJlbmNl IA0KICAgY291cnNlIGNvbnRyb2wgcHJvdmlzaW9uLiANCiAgICANCiAgIE1vcmVvdmVyLCBjdXJy ZW50IGNvbmZlcmVuY2luZyBzb2x1dGlvbnMgYXJlIGJyaWVmbHkgZXZhbHVhdGVkIA0KICAgY29u Y2VybmluZyB0aGVpciBzaG9ydGNvbWluZ3MgaW4gY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCAN CiAgIGZ1bmN0aW9uYWxpdHkuIEZpbmFsbHksIG5leHQgc3RlcHMgZm9yIGNvbmZlcmVuY2UgY291 cnNlIGNvbnRyb2wgDQogICBlZmZvcnRzIHdpbGwgYmUgcHJlc2VudGVkLiANCiAgICANCjIuICAg ICBEZWZpbml0aW9uIG9mIFRlcm1zIA0KICAgIA0KICAgbyBBcHBsaWNhdGlvbiBzZXNzaW9uIChB UyksIFNlc3Npb24gDQogICAgIFRoZSBzZXQgb2YgbWVkaWEgYWdlbnRzL2FwcGxpY2F0aW9ucyB0 aGF0IGFjdCBhcyBwZWVycyB0byBlYWNoICANCiAgICAgb3RoZXIgd2l0aGluIGEgY29uZmVyZW5j ZS4gIEZvciByZWFsLXRpbWUgZGF0YSwgdGhpcyBnZW5lcmFsbHkgIA0KICAgICB3aWxsIGJlIGFu IFJUUCBzZXNzaW9uOyBmb3Igb3RoZXIgYXBwbGljYXRpb24gcHJvdG9jb2xzLCBvdGhlciAgDQog ICAgIGhvcml6b250YWwgcHJvdG9jb2xzIG1heSBkZWZpbmUgdGhlaXIgb3duIHR5cGUgb2Ygc2Vz c2lvbiBjb25jZXB0LiAgDQogICAgDQogICBvIFBhcnRpY2lwYW50IA0KICAgICBBIGh1bWFuIGJl aW5nIHRoYXQgdGFrZXMgcGFydCBpbiBhIGNvbmZlcmVuY2UsIGVpdGhlciBhY3RpdmVseSBvciAg DQogICAgIHBhc3NpdmVseSBsaXN0ZW5pbmcuIA0KICAgIA0KICAgbyBBY3RpdmUgUGFydGljaXBh bnQgDQogICAgIEEgcGFydGljaXBhbnQgb2YgYSBjb25mZXJlbmNlIGJlY29taW5nIHNlbmRlciBv ZiBtZWRpYSBpbmZvcm1hdGlvbiAgDQogICAgIGR1cmluZyBsaWZldGltZSBvZiB0aGUgY29uZmVy ZW5jZS4gDQogICAgDQogICBvIFBhc3NpdmUgUGFydGljaXBhbnQgDQogICAgIEEgcGFydGljaXBh bnQgb2YgYSBjb25mZXJlbmNlIHBhc3NpdmVseSByZWNlaXZpbmcgdGhlIG1lZGlhICANCiAgICAg aW5mb3JtYXRpb24gd2l0aG91dCBiZWNvbWluZyBzZW5kZXIgb2YgbWVkaWEgaW5mb3JtYXRpb24g IA0KICAgICBkdXJpbmcgbGlmZXRpbWUgb2YgdGhlIGNvbmZlcmVuY2UuIA0KICAgIA0KICAgbyBN ZW1iZXIgDQogICAgIFRoZSBzeXN0ZW0sIGluY2x1ZGluZyBzb2Z0d2FyZSBhbmQgaGFyZHdhcmUs IHRoYXQgdGFrZXMgcGFydCBpbiBhICAgIA0KICAgICBjb21wdXRlciBjb25mZXJlbmNlLCByZXBy ZXNlbnRpbmcgYSBzaW5nbGUgcGFydGljaXBhbnQuIA0KICAgIA0KICAgbyBQcm9maWxlIA0KICAg ICBBbiBpbml0aWFsIGRlc2NyaXB0aW9uIG9mIHRoZSBjb25mZXJlbmNlLCBpbmNsdWRpbmcgYXNz aWdubWVudCBvZiAgDQogICAgIHJvbGVzIHRvIHBhcnRpY3VsYXIgbWVtYmVycywgdGltZSBsaW1p dHMgZm9yIHNwZWFrZXJzLCBhdHRyaWJ1dGVzICANCiAgICAgb2YgdGhlIGNvbmZlcmVuY2UgKG9w ZW4vY2xvc2UsIGNvbmR1Y3RlZC9hbmFyY2hpYywgZXRjKS4gDQogICAgDQogICBvIENvbmZlcmVu Y2UgU2V0dXAgYW5kIERpc2NvdmVyeSANCiAgICAgQWNjb3JkaW5nIHRvIFszXSwgYXNwZWN0cyBm b3Igc2V0dGluZyB1cCBhbiBpbml0aWFsIGNvbmZlcmVuY2UgIA0KICAgICBTdGF0ZSBpbiBwYXJ0 aWNpcGF0aW5nIG1lbWJlcnMsIGluY2x1ZGluZyB0aGUgZXhjaGFuZ2Ugb2YgbWVkaWEgIA0KICAg ICBhbmQgY2FwYWJpbGl0aWVzIGluZm9ybWF0aW9uIGFtb25nIHRoZSBzZXQgb2YgcGFydGljaXBh bnRzLCBhcmUgIA0KICAgICBiZWluZyBhZGRyZXNzZWQgYnkgc2V0dXAgYW5kIGRpc2NvdmVyeSBm dW5jdGlvbmFsaXR5LiANCiAgICANCiAgIG8gQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJvbCANCiAg ICAgQWNjb3JkaW5nIHRvIFszXSwgYXNwZWN0cyB0byBjb250cm9sIHRoZSBjb25mZXJlbmNlIGR1 cmluZyBydW50aW1lICANCiAgICAgb2YgdGhlIGV2ZW50IGFyZSBiZWluZyBhZGRyZXNzZWQgYnkg Y29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbC4gDQogICAgDQogICAgIA0KVHJvc3NlbiAgICAgICAg ICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAgICAgWzNdIA0M DQpJbnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAg ICAgICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KMy4gICAgIFNjb3BlIA0KICAgIA0KICAgVGhl IHNjb3BlIG9mIGNvbmZlcmVuY2UgY291cnNlIGNvbnRyb2wgZnVuY3Rpb25hbGl0eSB3aWxsIGJl IA0KICAgZGV2ZWxvcGVkIGFzIHBhcnQgb2YgdGhlIHNvbHV0aW9uIHNwYWNlLiBQb3NzaWJsZSBm dW5jdGlvbmFsaXR5IA0KICAgaW5jbHVkZXM6IA0KICAgIA0KICAgbyAnY29uZmVyZW5jZSBjb250 ZXh0IGFkbWluaXN0cmF0aW9uJywgcHJvdmlkaW5nIG1lbWJlcnNoaXAgIA0KICAgICBhbmQgYXBw bGljYXRpb24vc2Vzc2lvbiBpbmZvcm1hdGlvbiBhZG1pbmlzdHJhdGlvbiANCiAgIG8gJ21lbWJl cnNoaXAgZW5mb3JjZW1lbnQnLCBwcm92aWRpbmcgbWVhbnMgdG8gZW5mb3JjZSBzcGVjaWZpYyAg DQogICAgIGNvbmZlcmVuY2UgbWVtYmVyc2hpcCANCiAgIG8gJ2Zsb29yIGNvbnRyb2wnLCBwcm92 aWRpbmcgbWVhbnMgdG8gbWFwIHNvY2lhbCBwcm90b2NvbHMgb250byAgDQogICAgIGRpc3RyaWJ1 dGVkIGVudmlyb25tZW50cy4gSG93ZXZlciwgdGhlIHNlbWFudGljcyBvZiBzcGVjaWZpYyAgDQog ICAgIHNvY2lhbCBwcm90b2NvbHMgaXMgbm90IHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIHBvc3Np YmxlICANCiAgICAgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBzb2x1dGlvbi4gDQogICBvICdh Y3RpdmUvcGFzc2l2ZSBtZW1iZXIgc3VwcG9ydCcsIGFsbG93aW5nIGZvciBkaWZmZXJlbnQgcG9s aWNpZXMgIA0KICAgICB3aXRoIHJlc3BlY3QgdG8gbWVtYmVyc2hpcCBhbmQgZmxvb3IgY29udHJv bC4gVGhpcyBpbmNsdWRlcyAgDQogICAgIGNoYW5nZXMgZnJvbSBhY3RpdmUgdG8gcGFzc2l2ZSBh bmQgdmljZSB2ZXJzYSwgZWl0aGVyIGltcGxpY2l0bHkgIA0KICAgICBvciBleHBsaWNpdGx5LiAN CiAgIG8gJ2NhcGFiaWxpdGllcyByZS1uZWdvdGlhdGlvbicsIGFsbG93aW5nIGZvciBjaGFuZ2Vz IGluICANCiAgICAgdGhlIGluaXRpYWwgY2FwYWJpbGl0aWVzIHNldCBvZiBwYXJ0aWNpcGFudHMg ZHVyaW5nIHJ1bnRpbWUgb2YgdGhlICANCiAgICAgY29uZmVyZW5jZS4gDQogICAgDQogICBUaGlz IGxpc3QgZG9lcyBub3QgY2xhaW0gdG8gYmUgZXhoYXVzdGl2ZS4gSG93ZXZlciwgaXQgcG9pbnRz IGluIHRoZSANCiAgIGRpcmVjdGlvbiBvZiBwcm92aWRlZCBmdW5jdGlvbmFsaXR5IGZvciBjb25m ZXJlbmNlIGNvdXJzZSBjb250cm9sIA0KICAgc29sdXRpb25zLiANCiAgICANCjQuICAgICBQcm9i bGVtIFN0YXRlbWVudCANCiAgICANCiAgIFRoZXJlIGFyZSBtYW55IGFwcHJvYWNoZXMgaW4gdGhl IHJlc2VhcmNoIGNvbW11bml0eSB0byByZWFsaXplIA0KICAgY29uZmVyZW5jZSBjb3Vyc2UgY29u dHJvbCBhcyBwYXJ0IG9mIGEgY29uZmVyZW5jaW5nIGFyY2hpdGVjdHVyZS4gDQogICBBbHNvIGlu IHN0YW5kYXJkaXphdGlvbiBib2RpZXMgKHN1Y2ggYXMgSC4zMjMgWzddIG9yIFNDQ1AgWzFdKSwg DQogICBjb25mZXJlbmNlIGNvdXJzZSBjb250cm9sIGhhcyBiZWVuIGFkZHJlc3NlZC4gSG93ZXZl ciwgbm9uZSBvZiB0aGVzZSANCiAgIGFwcHJvYWNoZXMgb2ZmZXJzIGEgdW5pZmllZCBhbmQgZmxl eGlibGUgc29sdXRpb24gZm9yIGNvbmZlcmVuY2UgDQogICBjb3Vyc2UgY29udHJvbCB0byBjb3Zl ciB0aGUgc3BlY3RydW0gb2Ygc2NlbmFyaW9zIG91dGxpbmVkIGluIA0KICAgU2VjdGlvbiA1LiAN CiAgICANCiAgIFNwZWNpZmljYWxseSwgYSBjb25mZXJlbmNlIGNvdXJzZSBjb250cm9sIHNvbHV0 aW9uIHNob3VsZCANCiAgICANCiAgIG8gZml0IGludG8gdGhlIGFscmVhZHkgZGVmaW5lZCBjb25m ZXJlbmNlIGNvbnRyb2wgYXJjaGl0ZWN0dXJlIGFuZCAgDQogICAgIGxldmVyYWdlIHRoZSBleGlz dGluZyBzdWl0ZSBvZiBtZWNoYW5pc21zIGFuZCBwcm90b2NvbHMsIHN1Y2ggYXMgIA0KICAgICAq IGNvbmZlcmVuY2UgZGVzY3JpcHRpb24sIGkuZS4sIFNEUCBbNF0gb3IgZnV0dXJlIHZlcnNpb25z IChTREctbmcgIA0KICAgICAgIFs5XSksIGFuZCBpbml0aWF0aW9uLCBpLmUuLCBTSVAgWzVdIA0K ICAgICAqIGxvY2FsIGNvb3JkaW5hdGlvbiwgaS5lLiwgTUJVUyBbMTBdIA0KICAgICAqIHRyYW5z cG9ydCBsYXllciBwcm90b2NvbHMsIHN1Y2ggYXMgZm9yIHJlbGlhYmxlIG11bHRpY2FzdCwgcmVh bC0gDQogICAgICAgdGltZSB0cmFuc2Zlciwgb3Igc2ltcGxlIHVuaWNhc3QgdHJhbnNtaXNzaW9u IA0KICAgICAqIHNlY3VyaXR5IGNvbXBvbmVudHMsIHN1Y2ggYXMgZ3JvdXAga2V5IHNvbHV0aW9u cyANCiAgIG8gcHJvdmlkZSBhIGZsZXhpYmxlIHNvbHV0aW9uLCBhbGxvd2luZyBmb3IgYSB2YXJp ZXR5IG9mIHNjZW5hcmlvcyAgDQogICAgIChzZWUgU2VjdGlvbiA1KSBhbmQgY2hhcmFjdGVyaXN0 aWNzIHRvIGJlIHBsdWdnZWQgaW4gdGhlIHN5c3RlbS4gIA0KICAgIA0KICAgRm9yIHRoYXQsIGEg YnVpbGRpbmcgYmxvY2sgYXBwcm9hY2ggd291bGQgYWxsb3cgdGhlIHByb3Zpc2lvbiBvZiANCiAg IHN0YW5kYXJkaXplZCBpbnRlcmZhY2VzIHRvIHRoZSBkZXNpcmVkIGNvbW1vbiBmdW5jdGlvbmFs aXR5LiBXaXRoIA0KICAgdGhhdCwgc3BlY2lmaWMgc2NlbmFyaW8tdGFpbG9yZWQgaW5zdGFudGlh dGlvbnMgZm9yIGNlcnRhaW4gDQogICBmdW5jdGlvbmFsaXR5LCByZXByZXNlbnRlZCBieSBhIGJ1 aWxkaW5nIGJsb2NrLCBhcmUgZW5hYmxlZCANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAg ICBFeHBpcmVzIE5vdmVtYmVyIDIwMDEgICAgICAgICAgICAgICAgICAgICBbNF0gDQwNCkludGVy bmV0IERyYWZ0ICAgICBDb3Vyc2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAg TWF5IDIwMDEgDQogICAgDQogICAgDQogICBwcmVzZXJ2aW5nIHRoZSBjb21tb24gdmlldyBvZiB0 aGUgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCANCiAgIGZ1bmN0aW9uYWxpdHkuIA0KICAgIA0K ICAgIA0KNS4gICAgIENvbmZlcmVuY2luZyBTY2VuYXJpb3MgDQogICAgDQogICBUaGlzIHNlY3Rp b24gaW5mb3JtYWxseSBvdXRsaW5lcyBzY2VuYXJpbyBjYXRlZ29yaWVzIGZvciBtdWx0aW1lZGlh IA0KICAgY29uZmVyZW5jaW5nIGluIHRoZSBJbnRlcm5ldC4gIA0KICAgIA0KICAgVGhlIGNvbmZl cmVuY2luZyBzY2VuYXJpb3MgYXJlIGNhdGVnb3JpemVkIGluIHRocmVlIHNlY3Rpb25zLiBGb3Ig DQogICBlYWNoIGNhdGVnb3J5LCB0eXBpY2FsIGNoYXJhY3RlcmlzdGljcyBhcmUgb3V0bGluZWQs IGFuZCBleGFtcGxlcyANCiAgIGFyZSBnaXZlbi4gRmluYWxseSwgYSB0YWJsZS13aXNlIG92ZXJ2 aWV3IGlzIGRlcml2ZWQgZnJvbSB0aGUgbW9yZSANCiAgIGluZm9ybWFsIGRlc2NyaXB0aW9uIHBp bnBvaW50aW5nIHRoZSB2ZXJ5IGZ1bmN0aW9uYWxpdHkgcmVxdWlyZWQgZm9yIA0KICAgdGhlIHNw ZWNpZmljIHNjZW5hcmlvcy4gVGhpcyB0YWJsZS13aXNlIGRlc2NyaXB0aW9uIHdpbGwgYmUgdXNl ZCBpbiANCiAgIFNlY3Rpb24gNSB0byBkaXNjdXNzIGNvbmZlcmVuY2UgY291cnNlIGNvbnRyb2wg bW9kZWxzLiANCiAgICANCiAgIEl0IGlzIHdvcnRoIG1lbnRpb25pbmcgdGhhdCBzaW1wbGUgc3Ry ZWFtaW5nIGlzIG5vdCBjb25zaWRlcmVkIGluIA0KICAgdGhlIGZvbGxvd2luZyBkdWUgdG8gaXRz IGxhY2sgb2YgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCANCiAgIGZ1bmN0aW9uYWxpdHkuIEhv d2V2ZXIsIGl0IG1pZ2h0IGJlIHVzZWQgdG8gcmVhbGl6ZSB2ZXJ5IHNpbXBsZSANCiAgIGNvbmZl cmVuY2luZyBzY2VuYXJpb3Mgc3VjaCBhcyBJbnRlcm5ldCBsZWN0dXJlcywgd2hlcmUgZGF0YSBp cyANCiAgIHNpbXBseSBzZW50IHRvIGEgc2V0IG9mIHJlY2VpdmVycyB3aXRob3V0IGZlZWRiYWNr IG9yIGludGVyYWN0aW9uLiAgDQogICAgDQo1LjEuICAgU2ltcGxlIENvbmZlcmVuY2luZyANCiAg ICANCiAgICdTaW1wbGUgQ29uZmVyZW5jaW5nJyByZWZsZWN0cyB0aGUgc2ltcGxlc3QgZm9ybSBv ZiBjb25mZXJlbmNpbmcgDQogICB3aXRoIGEgY2hhbmdlIG9mIHRoZSBzZW5kZXIvcmVjZWl2ZXIg cmVsYXRpb24gYmFzZWQgb24gY2VydGFpbiANCiAgICdzb2NpYWwgcnVsZXMnIGR1cmluZyB0aGUg bGlmZXRpbWUgb2YgdGhlIGNvbmZlcmVuY2UuIA0KICAgIA0KICAgQ29uZmVyZW5jZXMgb2YgdGhp cyB0eXBlIG1pZ2h0IGJlIGFubm91bmNlZCBiZWZvcmVoYW5kLCBpbmNsdWRpbmcgDQogICB0aGUg Y29uZmVyZW5jZZJzIHByb2ZpbGUgaW5mb3JtYXRpb24sIG9yIHRoZXkgdGFrZSBwbGFjZSBhcyBh ZC1ob2MgDQogICBtZWV0aW5ncy4gIA0KICAgIA0KICAgVGhlIGdyb3VwIG9mIHBhcnRpY2lwYW50 cyBtaWdodCBiZSB3ZWxsLWtub3duLCBpZiBhbm5vdW5jZWQsIG9yIGJlIA0KICAgYnVpbHQgYnkg aW52aXRhdGlvbiBvciByZXF1ZXN0LiBGb3IgdGhhdCwgc2V2ZXJhbCBpbml0aWF0aW9uIG1vZGVs cyANCiAgIG1pZ2h0IGJlIHJlYWxpemVkIChzZWUgYWxzbyBbMTFdKSwgd2hpY2ggcmVxdWlyZXMg YXBwcm9wcmlhdGUgDQogICBpbml0aWF0aW9uIGZ1bmN0aW9uYWxpdHkgaW5jbHVkaW5nIGF1dGhl bnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIA0KICAgbWVhbnMgZm9yIHJlc3RyaWN0ZWQgYWNj ZXNzIHRvIHRoZSBjb25mZXJlbmNlLiAgDQogICAgDQogICBGbG9vciBjb250cm9sIGZ1bmN0aW9u YWxpdHksIGUuZy4sIHRvIHJlYWxpemUgY29uZHVjdGVkIG1lZXRpbmcgDQogICBmdW5jdGlvbmFs aXR5LCBpcyBub3QgcHJvdmlkZWQgaW4gdGhpcyBjYXRlZ29yeS4gRHVlIHRvIHRoaXMgbGFjayBv ZiANCiAgIG1lZGlhdGlvbiBjb25jZXJuaW5nIHRoZSBhY2Nlc3Mgb24gdGhlIGNvbW1vbiBtZWRp YSByZXNvdXJjZSwgdGhlIA0KICAgbGV2ZWwgb2YgaW50ZXJhY3Rpdml0eSBpcyB1c3VhbGx5IGxp bWl0ZWQsIGV2ZW4gaWYgc2NhbGFibGUgDQogICBtdWx0aWNhc3QgdHJhbnNmZXIgaXMgdXNlZC4g IA0KICAgIA0KICAgVXN1YWxseSwgdGhlIGluaXRpYWwgc2V0IG9mIGNhcGFiaWxpdGllcyBpcyBu b3QgY2hhbmdlZCwgaS5lLiwgcmUtDQogICBuZWdvdGlhdGVkLCBkdXJpbmcgcnVudGltZSBvZiB0 aGUgY29uZmVyZW5jZS4gSG93ZXZlciwgc29tZSBzaW1wbGUgDQogICBmb3JtIG9mIHJlLW5lZ290 aWF0aW9uIGNvdWxkIGJlIHByb3ZpZGVkLiANCiAgICANCiAgIEFsdGhvdWdoIHRoZSBudW1iZXIg b2YgcGFydGljaXBhbnRzIGNhbiBlYXNpbHkgcmVhY2ggc2V2ZXJhbCANCiAgIHRob3VzYW5kcyBv ciBldmVuIG1vcmUsIHdoZW4gdXNpbmcgbXVsdGljYXN0IHRyYW5zZmVyIGNhcGFiaWxpdGllcywg DQogICBpdCBpcyBleHBlY3RlZCB0aGF0IHRoZSByZXF1aXJlbWVudHMgZm9yIHByZWNpc2UgbWVt YmVyc2hpcCANCiAgIGluZm9ybWF0aW9uIGFyZSBsZXNzIHN0cmluZ2VudCBpbiBsYXJnZXIgc2Nh bGVkIGNvbmZlcmVuY2VzLiANCiAgICANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAgICBF eHBpcmVzIE5vdmVtYmVyIDIwMDEgICAgICAgICAgICAgICAgICAgICBbNV0gDQwNCkludGVybmV0 IERyYWZ0ICAgICBDb3Vyc2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgTWF5 IDIwMDEgDQogICAgDQogICAgDQo1LjEuMS4gRXhhbXBsZXMgDQogICAgDQogICBFeGFtcGxlcyBm b3Igc2ltcGxlIGNvbmZlcmVuY2luZyBpbmNsdWRlIGFkLWhvYyBvciBwcmUtcGxhbm5lZCBzbWFs bCANCiAgIGdyb3VwIG1lZXRpbmdzLCByaWNoIGNhbGxzLCBJbnRlcm5ldCBsZWN0dXJlcywgdGVs ZS13b3JraW5nIGluIGEgDQogICB0ZWFtLiBNb3N0IG9mIHRoZSBjdXJyZW50IE1Cb25lIFsyXSBz ZXNzaW9ucyBhcmUgdHlwaWNhbCBleGFtcGxlcyANCiAgIGZvciBzaW1wbGUgY29uZmVyZW5jaW5n LiANCiAgICANCjUuMi4gICBGbG9vciBDb250cm9sbGVkIENvbmZlcmVuY2luZyANCiAgICANCiAg IFNjZW5hcmlvcyBvZiB0aGlzIGNhdGVnb3J5IGVucmljaCB0aGUgc2ltcGxlIGNvbmZlcmVuY2lu ZyANCiAgIGZ1bmN0aW9uYWxpdHkgb2Ygc2VjdGlvbiA1LjEuIGJ5IHByb3ZpZGluZyBmbG9vciBj b250cm9sIGZhY2lsaXRpZXMgDQogICB0byBjb250cm9sIHRoZSBhY2Nlc3Mgb24gZGlzdHJpYnV0 ZWQgcmVzb3VyY2VzLiBBbW9uZyBvdGhlcnMsIHRoZXNlIA0KICAgZGlzdHJpYnV0ZWQgcmVzb3Vy Y2VzIG1pZ2h0IHJlZmxlY3QgdGhlIGNvbW1vbmx5IHVzZWQgYXVkaW92aXN1YWwgDQogICBjaGFu bmVsIHdpdGhpbiB0aGUgY29uZmVyZW5jZSBidXQgYWxzbyB0aGUgY29udGVudCBvZiBhIHNoYXJl ZCANCiAgIHdoaXRlYm9hcmQsIG9yIGEgc2hhcmVkLCBsb2NhbGx5IGhvc3RlZCBhcHBsaWNhdGlv bi4gVGhlIGZsb29yIA0KICAgY29udHJvbCBzZW1hbnRpY3MgYXJlIHVzdWFsbHkga25vd24gYmVm b3JlaGFuZCwgb3IgdGhleSBtaWdodCBiZSANCiAgIGRpc3RyaWJ1dGVkIHVzaW5nIHRoZSBjb25m ZXJlbmNlIHByb2ZpbGUgaW5mb3JtYXRpb24uIFRoZSANCiAgIHJlYWxpemF0aW9uIG9mIHRoZSBm bG9vciBjb250cm9sIHNlbWFudGljcyBpcyB1c3VhbGx5IGhpZ2hseSANCiAgIGFwcGxpY2F0aW9u LXNwZWNpZmljLiANCiAgICANCiAgIEZvciBpbnN0YW5jZSwgZmxvb3IgY29udHJvbGxlZCBjb25m ZXJlbmNpbmcgbWlnaHQgYWxsb3cgJ2NvbmR1Y3RlZCANCiAgIG1lZXRpbmdzJywgZW5hYmxpbmcg dGhlIGNvbmR1Y3RvciBvZiBhIGNvbmZlcmVuY2UgZm9yIGluc3RhbmNlIHRvIA0KICAgZWplY3Qg cGFydGljaXBhbnRzIGZyb20gYSBjb25mZXJlbmNlIG9yIHRvIGRlbnkgYWNjZXNzIHRvIHRoZSAN CiAgIGNvbmZlcmVuY2UuIEhvd2V2ZXIsIGluIGFkZGl0aW9uIHRvIHRoZSByZWFsaXphdGlvbiBv ZiB0aGUgc29jaWFsIA0KICAgcnVsZXMgYnkgbWVhbnMgb2YgZmxvb3IgY29udHJvbCwgYXBwcm9w cmlhdGUgZnVuY3Rpb25hbGl0eSB0byANCiAgIGVuZm9yY2UgdGhlbSBvbiBkYXRhIGxldmVsIGlz IHJlcXVpcmVkIGJ5IG1lYW5zIG9mIGV4Y2x1ZGluZyANCiAgIHJlY2VpdmVyIHNldHMgZnJvbSBy ZWNlcHRpb24uIA0KICAgIA0KICAgQ2FwYWJpbGl0aWVzIHJlLW5lZ290aWF0aW9uIGlzIHVzdWFs bHkgcHJvdmlkZWQgaW4gdGhlc2Ugc2NlbmFyaW9zLCANCiAgIHdoaWNoIG1pZ2h0IGFsc28gYmUg dGllZCB0byB0aGUgaW1wbGVtZW50ZWQgZmxvb3IgY29udHJvbCBwb2xpY3kgb2YgDQogICB0aGUg c3BlY2lmaWMgc2NlbmFyaW8uIA0KICAgIA0KICAgSW4gZmxvb3IgY29udHJvbGxlZCBjb25mZXJl bmNlcywgdGhlcmUgaXMgYW4gZXhhY3Qga25vd2xlZGdlIG9mIHRoZSANCiAgIGN1cnJlbnQgbWVt YmVyc2hpcCBpbmZvcm1hdGlvbiBvZiB0aGUgcGFydGljaXBhbnRzLiBVc3VhbGx5LCB0aGUgDQog ICBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgZmxvb3IgY29udHJvbCByZXN0cmljdHMgdGhlIHNjYWxh YmlsaXR5IG9mIA0KICAgdGhpcyB0eXBlIG9mIGNvbmZlcmVuY2VzIHRvIGEgZmV3IHRlbnMuIEhv d2V2ZXIsIGFwcHJvYWNoZXMgYXMgDQogICBwcm9wb3NlZCBpbiBbMTNdLCBtaWdodCBiZSB1c2Vk IGluIHNwZWNpZmljIHNjZW5hcmlvcyB0byBpbXByb3ZlIHRoZSANCiAgIHNjYWxhYmlsaXR5LiAN CiAgICANCjUuMi4xLiBFeGFtcGxlcyANCiAgICANCiAgIEV4YW1wbGVzIGZvciBmbG9vciBjb250 cm9sbGVkIGNvbmZlcmVuY2VzIGluY2x1ZGUgc2NlbmFyaW9zIHdpdGggdGhlIA0KICAgbmVlZCB0 byByZWFsaXplIHNvY2lhbCBydWxlcyBvciBhY2Nlc3MgY29udHJvbCBvbiBzaGFyZWQgcmVzb3Vy Y2VzLCANCiAgIHN1Y2ggYXMgY29uZHVjdGVkIG1lZXRpbmdzLCBhcHBsaWNhdGlvbiBzaGFyaW5n IHNlc3Npb25zLCBkaXN0YW5jZSANCiAgIGxlYXJuaW5nIGluY2x1ZGluZyBkZW1vbnN0cmF0aW9u IG9mIHNoYXJlZCBpbmZvcm1hdGlvbiwgdGVsZS13b3JraW5nIA0KICAgd2l0aCBjb21tb24gcmVz b3VyY2VzIHRvIHNoYXJlLiANCiAgICANCjUuMy4gICBSaWNoIENvbmZlcmVuY2luZyANCiAgICAN CiAgIEEgJ3JpY2ggY29uZmVyZW5jaW5nJyBldmVudCwgd2hpY2ggaXMgZ29pbmcgdG8gaGFwcGVu LCBtaWdodCBiZSANCiAgIGFubm91bmNlZCBiZWZvcmVoYW5kIGJ1dCBhbiBhZC1ob2MgZXN0YWJs aXNobWVudCBtaWdodCBhbHNvIGJlIA0KICAgY29uc2lkZXJlZCwgc3VjaCBhcyBhICdyYW5kb21s eSBnYXRoZXJpbmcgYSBjcm93ZCBhcm91bmQgYW4gDQogICAgIA0KVHJvc3NlbiAgICAgICAgICAg ICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAgICAgWzZdIA0MDQpJ bnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAg ICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KICAgYXR0cmFjdGlvbicuIEF1dGhlbnRpY2F0aW9u IGFuZCBhdXRob3JpemF0aW9uIG1lYW5zIG1pZ2h0IGJlIHVzZWQgDQogICBmb3IgcmVzdHJpY3Rl ZCBhY2Nlc3MgdG8gdGhlIGV2ZW50LiANCiAgICANCiAgIFVzdWFsbHksIHRoZXJlIGlzIGEgKHNt YWxsKSB3ZWxsLWtub3duIGdyb3VwIG9mIGFjdGl2ZSBwYXJ0aWNpcGFudHMsIA0KICAgaS5lLiwg ZXhhY3QgbWVtYmVyc2hpcCBpbmZvcm1hdGlvbiBpcyByZXF1aXJlZCwgYW5kIGEgbGFyZ2VyIGdy b3VwIA0KICAgb2YgcGFzc2l2ZSBwYXJ0aWNpcGFudHMuIE1lbWJlcnNoaXAgaW5mb3JtYXRpb24g Zm9yIHRoaXMgbGFyZ2VyIA0KICAgZ3JvdXAgaXMgbGVzcyBzdHJpY3RseSBwcm92aWRlZCwgY29t cGFyYWJsZSB3aXRoICdibHVlIHNoZWV0cycgDQogICBhdHRlbmRlZXMgbGlzdHMuICANCiAgICAN CiAgIFRoZSBhY2Nlc3MgY29udHJvbCB3aXRoaW4gdGhlIGdyb3VwIG9mIGFjdGl2ZSBwYXJ0aWNp cGFudHMgaXMgDQogICByZWFsaXplZCBieSBtZWFucyBvZiBmbG9vciBjb250cm9sIHJlYWxpemlu ZyBzcGVjaWZpYyBzb2NpYWwgDQogICBpbnRlcmFjdGlvbnMgKGNvbmR1Y3RlZCBzZXNzaW9uLCBw YW5lbCBncm91cCkgc2ltaWxhciB0byBmbG9vciANCiAgIGNvbnRyb2xsZWQgY29uZmVyZW5jaW5n LiANCiAgICANCiAgIEFzIGEgc3BlY2lmaWMgY2hhcmFjdGVyaXN0aWMgb2YgdGhpcyBjYXRlZ29y eSwgZnJlcXVlbnQgY2hhbmdlcyANCiAgIGJldHdlZW4gYWN0aXZlIGFuZCBwYXNzaXZlIHBhcnRp Y2lwYXRpb24gaW4gdGhlIGNvbmZlcmVuY2UgYXJlIA0KICAgaGFwcGVuaW5nLCBlLmcuLCBhIHBh c3NpdmUgb2JzZXJ2ZXIgKHBhcnRpY2lwYW50KSBvZiB0aGUgZXZlbnQgbWlnaHQgDQogICByYWlz ZSBpdHMgaW50ZXJlc3QgaW4gYmVjb21pbmcgYWN0aXZlIGluIHRoZSBkaXNjdXNzaW9uLCBlaXRo ZXIgYnkgDQogICBvd24gcmVxdWVzdCBvciBieSBpbnZpdGF0aW9uLCBmb2xsb3dpbmcgdGhlIHNw ZWNpZmljIGFjY2VzcyBydWxlcyBvZiANCiAgIHRoZSBhY3RpdmUgcGFydGljaXBhbnQgZ3JvdXAg aW1wbGVtZW50ZWQgYnkgYXBwcm9wcmlhdGUgZmxvb3IgDQogICBjb250cm9sIG1lYW5zLiBUaGUg bW9kZSBjaGFuZ2UgY291bGQgaGFwcGVuICdleHBsaWNpdGx5JywgaS5lLiwgYnkgDQogICBqb2lu aW5nIHRoZSBhY3RpdmUgbWVtYmVyIGdyb3VwLCBvciAnaW1wbGljaXRseScsIGkuZS4sIGJ5IA0K ICAgcmVxdWVzdGluZyBmbG9vciBjb250cm9sIHNlcnZpY2VzLiANCiAgICANCiAgIFRoaXMgbW9k ZSBjaGFuZ2Ugc2hvdWxkIGJlIHBvc3NpYmxlIGluIHRoZSByZXZlcnNlIGRpcmVjdGlvbiwgdG9v LCANCiAgIGkuZS4sIHdoZW4gYW4gYWN0aXZlIHBhcnRpY2lwYW50IGxvb3NlcyBpbnRlcmVzdCBp biBhY3RpdmUgDQogICBwYXJ0aWNpcGF0aW9uLiANCiAgICANCjUuMy4xLiBFeGFtcGxlcyANCiAg ICANCiAgIEV4YW1wbGVzIGZvciBsYXJnZSBzY2FsZSByaWNoIGNvbmZlcmVuY2luZyBzY2VuYXJp b3MgYXJlIHRvd24gaGFsbCANCiAgIG1lZXRpbmdzLCBJRVRGIHdvcmtpbmcgZ3JvdXAgbWVldGlu Z3MsIHZpcnR1YWwgbGVjdHVyZXMgd2l0aCANCiAgIGZlZWRiYWNrLCB2aXJ0dWFsIG5ld3Nncm91 cHMuIEhvd2V2ZXIsIGV4YW1wbGVzIGZvciBzaW1wbGUgYW5kIGZsb29yIA0KICAgY29udHJvbGxl ZCBjb25mZXJlbmNpbmcgYXJlIGFsc28gYXBwbGljYWJsZSBmb3IgdGhpcyBjYXRlZ29yeSBkdWUg dG8gDQogICB0aGUgc3VwZXJzZXQgY2hhcmFjdGVyIG9mIHRoZSByaWNoIGNvbmZlcmVuY2luZyBj YXRlZ29yeSBjb21wYXJlZCB0byANCiAgIHRoZSBvdGhlciBvbmVzLiANCiAgICANCjUuNC4gICBT dW1tYXJ5IG9mIENoYXJhY3RlcmlzdGljcyANCiAgICANCiAgIFRoZSBmb2xsb3dpbmcgdGFibGUg c3VtbWFyaXplcyB0aGUgbWFpbiBjaGFyYWN0ZXJpc3RpY3MgZm9yIHRoZSANCiAgIGRpZmZlcmVu dCBzY2VuYXJpbyBjYXRlZ29yaWVzIHByZXNlbnRlZCBpbiBzZWN0aW9uIDUuMS4gdG8gNS4zLiAN CiAgICcoKyknIGluZGljYXRlcyBvcHRpb25hbCBmdW5jdGlvbmFsaXR5LiAgDQogICAgDQogICBU aGUgZmlyc3QgYmxvY2sgb2YgY2hhcmFjdGVyaXN0aWNzIGlzIHJlZmVycmVkIHRvIGFzIGNvbmZl cmVuY2UgDQogICBpbml0aWF0aW9uIGFuZCBzZXR1cCAoc2VlIFszXSksIHdoaWxlIHRoZSBzZWNv bmQgYmxvY2sgaXMgZGVkaWNhdGVkIA0KICAgdG8gY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBm dW5jdGlvbmFsaXR5LiANCiAgICANCiAgICANCiAgICANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgfCBGdW5jdGlv bmFsaXR5ICAgIHwgIFNpbXBsZSAgICAgfCAgICBGLkMuICAgICB8ICAgUmljaCAgICAgIHwgDQog ICB8ICAgICAgICAgICAgICAgICAgfCAgIENvbmYuICAgICB8ICAgQ29uZi4gICAgIHwgICBDb25m LiAgICAgfCANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgICANClRyb3NzZW4gICAgICAgICAgICAgICAgIEV4cGly ZXMgTm92ZW1iZXIgMjAwMSAgICAgICAgICAgICAgICAgICAgIFs3XSANDA0KSW50ZXJuZXQgRHJh ZnQgICAgIENvdXJzZSBDb250cm9sIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAgICBNYXkgMjAw MSANCiAgICANCiAgICANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgfCBQcm9maWxlIEluZi4gICAgIHwgICAgICAr ICAgICAgfCAgICAgICsgICAgICB8ICAgICAgKyAgICAgIHwgDQogICB8ICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICB8ICAgIGluY2wuICAgIHwgICAgaW5jbC4gICAgfCANCiAgIHwgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgIGZsb29yIGluZi4gfCAgZmxvb3IgaW5mLiB8 IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0gDQogICB8IEluaXRpYXRpb24gICAgICAgfCAgYW5ub3VuY2VkICB8ICBhbm5v dW5jZWQgIHwgIGFubm91bmNlZCAgfCANCiAgIHwgICAgICAgICAgICAgICAgICB8ICAgaW52aXRl ZCAgIHwgICBpbnZpdGVkICAgfCAgIGludml0ZWQgICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IENhcGFi aWxpdGllcyAgICAgfCAgICAgKCspICAgICB8ICAgICAgKyAgICAgIHwgICAgICArICAgICAgfCAN CiAgIHwgUmUtbmVnb3RpYXRpb24gICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAg ICAgICAgICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IEF1dGhlbnRpY2F0aW9uICsgfCAgICAgKCspICAg ICB8ICAgICAoKykgICAgIHwgICAgICgrKSAgICAgfCANCiAgIHwgQXV0aG9yaXphdGlvbiAgICB8 ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICB8IA0KICAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQog ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSANCiAgIHwgTWVtYmVyc2hpcCBJbmZvICB8ICAgICAgKyAgICAgIHwgICAgICArICAg ICAgfCAgICAgICsgICAgICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IEZsb29yIENvbnRyb2wgICAgfCAg ICAgIC0gICAgICB8ICAgICAgKyAgICAgIHwgICAgKyAoZm9yICAgfCANCiAgIHwgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICBhY3RpdmUpICB8IA0KICAg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0gDQogICB8IE1lbWJlcnNoaXAgICAgICAgfCAgYXQgc3RhcnR1cCB8IGJhc2VkIG9uICAg IHwgYmFzZWQgb24gICAgfCANCiAgIHwgRW5mb3JjZW1lbnQgICAgICB8ICAgICBvbmx5ICAgIHwg Zmxvb3IgY3RybCAgfCBmbG9vciBjdHJsICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IEFjdGl2ZS9QYXNz aXZlICAgfCAgICAgIC0gICAgICB8ICAgICAgLSAgICAgIHwgICAgICArICAgICAgfCANCiAgIHwg TW9kZSBDaGFuZ2UgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAg ICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0gDQogICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCiAgIHwgU2NhbGUgICAgICAgICAgICB8IHNtYWxs IGR1ZSB0b3wgZGVwZW5kcyBvbiAgfCAgIGxhcmdlICAgICB8IA0KICAgfCAgICAgICAgICAgICAg ICAgIHwgbGFjayBvZiAgICAgfCBmbG9vciAgY3RybC58ICAgICAgICAgICAgIHwgDQogICB8ICAg ICAgICAgICAgICAgICAgfCBtZWRpYXRpb24gICB8IHNjYWxlICAgICAgIHwgICAgICAgICAgICAg fCANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tIA0KICAgICAgICAgICAgICBUYWJsZSAxIDogU3VtbWFyeSBvZiBDaGFyYWN0 ZXJpc3RpY3MgDQogICAgDQogICBUaGUgZm9sbG93aW5nIEZpZ3VyZSAxIHRyaWVzIHRvIG91dGxp bmUgdGhlIGNhdGVnb3JpZXMgb2YgdGhpcyANCiAgIHNlY3Rpb24gaW4gYSBzY2FsZS1mdW5jdGlv bmFsaXR5IHNwYWNlLCBlbXBoYXNpemluZyB0aGUgc3VwZXJzZXQgDQogICBjaGFyYWN0ZXIgb2Yg dGhlICdyaWNoIGNvbmZlcmVuY2luZycgY2F0ZWdvcnkuIA0KICAgIA0KICAgU2NhbGUgL3xcIA0K ICAgICAgICAgIHx8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS18IA0KICAgICAgICAgIHx8ICAgICAgICAgICAgICAgIFJpY2ggQ29uZmVyZW5jaW5nICAg ICAgICAgICAgICAgICB8IA0KICAgICAgICAgIHx8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgIHx8ICAgICAgICBUb3duIEhhbGwg TWVldGluZ3MsIElFVEYgTWVldGluZ3MgICAgICAgICB8IA0KICAgICAgICAgIHx8fC0tLS0tLS0t LS0tLS0tLS0tLS0tLS18fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXx8IA0KICAgICAgICAgIHx8 fCBTaW1wbGUgQ29uZmVyZW5jaW5nICB8fCBGbG9vciBDb250cm9sbGVkIENvbmYuIHx8IA0KICAg ICAgICAgIHx8fCAgICAgICAgICAgICAgICAgICAgICB8fCAgICAgICAgICAgICAgICAgICAgICAg IHx8IA0KICAgICAgICAgIHx8fCBMZWN0dXJlcywgTWVldGluZ3MgICB8fCBjb25kdWN0ZWQgbWVl dGluZ3MgICAgIHx8IA0KICAgICAgICAgIHx8fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS18fC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLXx8IA0KICAgICAgICAgIHx8LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgICAgICAgIHwtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPiANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGdW5jdGlvbmFsaXR5IA0KICAgIA0K ICAgICAgICAgICAgICBGaWd1cmUgMSA6IENhdGVnb3JpZXMgaW4gU2NhbGUtRnVuY3Rpb25hbGl0 eSBTcGFjZSANCiAgICANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAgICBFeHBpcmVzIE5v dmVtYmVyIDIwMDEgICAgICAgICAgICAgICAgICAgICBbOF0gDQwNCkludGVybmV0IERyYWZ0ICAg ICBDb3Vyc2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgTWF5IDIwMDEgDQog ICAgDQogICAgDQo2LiAgICAgQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJvbCBNb2RlbHMgDQogICAg DQogICBUaGUgY29uZmVyZW5jaW5nIHNjZW5hcmlvcyBpbiBTZWN0aW9uIDUgY2FuIGVhc2lseSBi ZSBtYXBwZWQgb250byANCiAgIG1vZGVscyBmb3IgcmVhbGl6ZSBjb25mZXJlbmNlIGNvdXJzZSBj b250cm9sIHJlYWxpemF0aW9uIHdpdGggDQogICByZXNwZWN0IHRvIHRoZSBmdW5jdGlvbmFsaXRp ZXMgcHJlc2VudGVkIGluIFNlY3Rpb24gMi4gDQogICAgDQo2LjEuICAgTG9vc2UgQ29uZmVyZW5j ZSBDb3Vyc2UgQ29udHJvbCANCiAgICANCiAgICdMb29zZScgY29uZmVyZW5jZSBjb3Vyc2UgY29u dHJvbCAoYWxzbyByZWZlcnJlZCB0byBhcyAnbGlnaHQtd2VpZ2h0IA0KICAgc2Vzc2lvbiBjb250 cm9sJyBbM10pIGlzIHRoZSBtb2RlbCBhcHBsaWNhYmxlIGZvciB0aGUgc2ltcGxlIA0KICAgY29u ZmVyZW5jaW5nIHNjZW5hcmlvIGNhdGVnb3J5IG9mIFNlY3Rpb24gNS4xLiAgDQogICAgDQogICBI ZW5jZSwgdGhpcyBjb250cm9sIG1vZGVsIGxhY2tzIG9mIGV4cGxpY2l0IG1lbWJlcnNoaXAgYW5k IA0KICAgYXBwbGljYXRpb24gc2Vzc2lvbiBjb250cm9sLiBGdXJ0aGVybW9yZSwgZmxvb3IgY29u dHJvbCBmYWNpbGl0aWVzIA0KICAgYXJlIG5vdCBwcm92aWRlZC4gSG93ZXZlciwgbWVtYmVyc2hp cCBpbmZvcm1hdGlvbiBtaWdodCBiZSBnYXRoZXJlZCANCiAgIGR1cmluZyBydW50aW1lIG9mIHRo ZSBzZXNzaW9uLCBjb21wYXJhYmxlIHdpdGggdGhlIGJsdWUgc2hlZXRzIG9mIA0KICAgYXR0ZW5k ZWVzLiANCiAgICANCiAgIFVzdWFsbHksIGdyb3VwIGtleSBtZWNoYW5pc21zIGFyZSBhbHNvIG1p c3NpbmcgZm9yIG1lbWJlcnNoaXAgDQogICBlbmZvcmNlbWVudCBhZnRlciBzdGFydGluZyB0aGUg Y29uZmVyZW5jZS4gDQogICAgDQo2LjIuICAgVGlnaHQgQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJv bCANCiAgICANCiAgICdUaWdodCcgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBbM10gaXMgdGhl IG1vZGVsIGFwcGxpY2FibGUgZm9yIA0KICAgdGhlIGZsb29yIGNvbnRyb2wgY29uZmVyZW5jaW5n IHNjZW5hcmlvIGNhdGVnb3JpZXMgb2YgU2VjdGlvbiA1LjIuIA0KICAgIA0KICAgSGVuY2UsIGFk ZGl0aW9uYWwgZmxvb3IgY29udHJvbCBpbmZvcm1hdGlvbiBvZiB0aGUgY29uZmVyZW5jZSANCiAg IHByb2ZpbGUgb3Igc3RhdGljYWxseSBpbXBsZW1lbnRlZCBhcHBsaWNhdGlvbiBzZW1hbnRpYyBh cmUgdXNlZCBmb3IgDQogICBpbXBsZW1lbnRpbmcgZmxvb3IgY29udHJvbCB0byBtYXAgJ3NvY2lh bCBwcm90b2NvbCcgc2VtYW50aWNzIG9udG8gDQogICB0aGUgZGlzdHJpYnV0ZWQgc2NlbmFyaW8u IEV4YWN0IG1lbWJlcnNoaXAgYW5kIGFwcGxpY2F0aW9uIHNlc3Npb24gDQogICBpbmZvcm1hdGlv biBpcyB1c3VhbGx5IHByb3ZpZGVkIHRvZ2V0aGVyIHdpdGggbWVtYmVyc2hpcCBlbmZvcmNlbWVu dCANCiAgIGJhc2VkIG9uIGZsb29yIGNvbnRyb2wgcG9saWNpZXMgZHVyaW5nIHJ1bnRpbWUgb2Yg dGhlIGNvbmZlcmVuY2UuIA0KICAgIA0KNi4zLiAgICdKZWxseS1saWtlJyBDb25mZXJlbmNlIENv dXJzZSBDb250cm9sIA0KICAgIA0KICAgQXMgYSBjb21iaW5hdGlvbiBvZiB0aGUgbG9vc2UgYW5k IHRpZ2h0IGNvbnRyb2wgbW9kZWwgb2YgU2VjdGlvbiANCiAgIDYuMS4gYW5kIDYuMi4sICdqZWxs eS1saWtlJyBjb3Vyc2UgY29udHJvbCBpcyBjb25zaWRlcmVkIGZvciByaWNoIA0KICAgY29uZmVy ZW5jaW5nIChzZWUgU2VjdGlvbiA1LjMuKSByZWFsaXphdGlvbi4gDQogICAgDQogICBUaGUgdGln aHQgY29udHJvbCBtb2RlbCBpcyBhcHBsaWVkIGZvciB0aGUgYWN0aXZlIHBhcnRpY2lwYW50cyBp biANCiAgIHRoZSBjb25mZXJlbmNlLCB3aGlsZSBhIGxvb3NlIGNvbnRyb2wgbW9kZWwgaXMgdXNl ZCBmb3IgdGhlIHBhc3NpdmUgDQogICBvbmVzLiBJbiBhZGRpdGlvbiB0byB0aGUgZnVuY3Rpb25h bGl0eSBmb3IgdGhlIHNwZWNpZmljIHVzZXIgZ3JvdXAsIA0KICAgaS5lLiwgYWN0aXZlIG9yIHBh c3NpdmUsIG1lY2hhbmlzbXMgdG8gc3VwcG9ydCBtb2RlIGNoYW5nZXMgZnJvbSANCiAgIGFjdGl2 ZSB0byBwYXNzaXZlIGFuZCB2aWNlIHZlcnNhIG1pZ2h0IGJlIHJlcXVpcmVkIHdpdGhvdXQgDQog ICBkaXN0dXJiYW5jZSwgaS5lLiwgaW50ZXJydXB0aW9uLCBvZiB0aGUgcnVubmluZyBjb25mZXJl bmNlLiANCiAgICANCiAgIERpZmZlcmVudCBwb2xpY2llcyBmb3IgdGhpcyBtb2RlIGNoYW5nZSBz aG91bGQgYmUgZmVhc2libGUsIHN1Y2ggYXMgDQogICB1cG9uIGludml0YXRpb24gYnkgaW5kaXZp ZHVhbCBhY3RpdmUgcGFydGljaXBhbnRzIG9yIHVwb24gcmVxdWVzdCBvZiANCiAgIHRoZSBwYXNz aXZlIHBhcnRpY2lwYW50LiANCiAgICANCjcuICAgICBFeGlzdGluZyBTb2x1dGlvbnMgDQogICAg DQogICAgIA0KVHJvc3NlbiAgICAgICAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAg ICAgICAgICAgICAgICAgICAgWzldIA0MDQpJbnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRy b2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KICAg VGhlIGZvbGxvd2luZyBzZWN0aW9uIGlzIGJyaWVmbHkgZXZhbHVhdGluZyBleGlzdGluZyBjb25m ZXJlbmNpbmcgDQogICBzb2x1dGlvbnMgd2l0aCByZXNwZWN0IHRvIHRoZWlyIGNvbmZlcmVuY2Ug Y291cnNlIGNvbnRyb2wgDQogICBmdW5jdGlvbmFsaXR5LiBOb3RlIHRoYXQgdGhpcyBwcmVzZW50 YXRpb24gaXMgcmVzdHJpY3RlZCB0byBzeXN0ZW1zIA0KICAgYmFzZWQgb24gY2VydGFpbiBzdGFu ZGFyZHMsIGhlbmNlIHRoaXMgbGlzdCBkb2VzIG5vdCBjbGFpbSB0byBiZSBhbiANCiAgIGV4aGF1 c3RpdmUgcmV2aWV3IG9mIGV4aXN0aW5nIGNvbmZlcmVuY2luZyBzeXN0ZW1zLiANCiAgICANCiAg IFRoZSBmb2xsb3dpbmcsIGludGVydHdpbmVkLCBjcml0ZXJpYSBhcmUgdXNlZCB0byBldmFsdWF0 ZSB0aGVzZSANCiAgIHNvbHV0aW9uczogDQogICBvIFByb3ZpZGVkIEZ1bmN0aW9uYWxpdHk6IFdo YXQgZnVuY3Rpb25hbGl0eSBpcyBwcm92aWRlZCB3aXRoICANCiAgICAgcmVzcGVjdCB0byBUYWJs ZSAxPyANCiAgIG8gRmxleGliaWxpdHk6IFdoYXQgc2NlbmFyaW9zIGFyZSBjb3ZlcmVkPyBXaGF0 IHBvbGljaWVzIGFyZSAgDQogICAgIHByb3ZpZGVkPyBIb3cgZmxleGlibGUgaXMgdGhlIHByb3Zp ZGVkIGZ1bmN0aW9uYWxpdHk/IA0KICAgbyBFeHRlbmRpYmlsaXR5OiBUbyB3aGF0IGV4dGVudCBj YW4gdGhlIHNvbHV0aW9uIGJlIGV4dGVuZGVkIHRvICANCiAgICAgaW50ZWdyYXRlIG5ldyBmdW5j dGlvbmFsaXR5PyANCiAgIG8gU2NhbGFiaWxpdHk6IFdoYXQgcmVzdHJpY3Rpb25zIGR1ZSB0byBh cmNoaXRlY3R1cmU/IA0KICAgIA0KNy4xLiAgIEguMzJ4IFByb3RvY29sIFN1aXRlIA0KICAgIA0K ICAgbyBGdW5jdGlvbmFsaXR5OiAgDQogICAgIC0gY2VudHJhbGl6ZWQvZGVjZW50cmFsaXplZCBj b25mZXJlbmNpbmcgDQogICAgIC0gcHJldHR5IG11Y2ggYWltaW5nIGF0IGZsb29yIGNvbnRyb2xs ZWQgY29uZmVyZW5jaW5nLCBhbHRob3VnaCAgDQogICAgICAgb25seSBjb25kdWN0ZWQvbm9uLWNv bmR1Y3RlZCBtb2RlcyBzdXBwb3J0ZWQgDQogICAgIC0gTm8gcGFzc2l2ZS9hY3RpdmUgbm90aW9u IGluIHRoZSBvcmlnaW5hbCBILjMyeCwgSC4zMzIgZXh0ZW5zaW9uICANCiAgICAgICBkb2VzbpJ0 IHN1cHBvcnQgY2hhbmdlcyBvZiBsaXN0ZW5lcnMgdG8gYWN0aXZlIHVzZXJzLiANCiAgICAgIA0K ICAgbyBGbGV4aWJpbGl0eTogIA0KICAgICAtIEZsb29yIGNvbnRyb2xsZWQgY29uZmVyZW5jaW5n IGlzIHBvb3JseSBzdXBwb3J0ZWQsIGFsdGhvdWdoIHRoZSAgDQogICAgICAgZGF0YSBjb25mZXJl bmNpbmcgcGFydCBzdXBwb3J0cyB0b2tlbnMuICANCiAgICAgLSBQcmUtZGVmaW5lZCByb2xlIG1v ZGVscywgaS5lLiwgY29uZHVjdGVkIHZlcnN1cyBub24tY29uZHVjdGVkLCAgDQogICAgICAgZm9y IGF1ZGlvdmlzdWFsIHBhcnQuICANCiAgICAgLSBObyBwb2xpY3kgZGVmaW5pdGlvbiwgZS5nLiwg dXNpbmcgYXBwcm9wcmlhdGUgcHJvZmlsZSAgDQogICAgICAgaW5mb3JtYXRpb24uIA0KICAgICAt IHJlY29uZmlndXJhdGlvbiBvZiBydW5uaW5nIGNvbmZlcmVuY2VzIHBvb3JseSBzdXBwb3J0ZWQu IA0KICAgIA0KICAgbyBFeHRlbmRpYmlsaXR5OiANCiAgICAgLSBwcmV0dHkgY2xvc2VkIHN5c3Rl bSBvZiBhIHdob2xlIHNldCBvZiBzdGFuZGFyZHMgDQogICAgDQogICBvIFNjYWxhYmlsaXR5OiB2 ZXJ5IHJlc3RyaWN0ZWQgZHVlIHRvIHRpZ2h0IGNlbnRyYWxpemVkIGNvbnRyb2wgIA0KICAgICBz dHJ1Y3R1cmUgDQogICAgDQogICBbVEJEXSBhZGQgb3RoZXIgcG9pbnRzLCBlaXRoZXIgaXRlbXMg b3Igc3ViaXRlbXMgDQogICAgDQo3LjIuICAgU0lQLWJhc2VkIFNvbHV0aW9ucyANCiAgICANCiAg IG8gRnVuY3Rpb25hbGl0eTogIA0KICAgICAtIGZsZXhpYmxlIGluaXRpYXRpb24gbW9kZWxzIFsx MV0gIA0KICAgICAtIG1lbWJlcnNoaXAgaW5mb3JtYXRpb24gdXNpbmcgUlRDUCBpbmZvcm1hdGlv biAobG9vc2UgY29udHJvbCkgb3IgICAgICANCiAgICAgICBhLXByaW9yaSBpbmZvcm1hdGlvbiAN CiAgICAgLSBubyBtZW1iZXJzaGlwIGVuZm9yY2VtZW50IA0KICAgICAtIG5vIGZsb29yIGNvbnRy b2wgDQogICAgIC0gbm8gY2FwYWJpbGl0eSByZS1uZWdvdGlhdGlvbiANCiAgICANCiAgIG8gRmxl eGliaWxpdHkvRXh0ZW5kaWJpbGl0eTogDQogICAgIA0KVHJvc3NlbiAgICAgICAgICAgICAgICAg RXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAgICBbMTBdIA0MDQpJbnRlcm5l dCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgICAgIE1h eSAyMDAxIA0KICAgIA0KICAgIA0KICAgICAtIGV4dGVuc2lvbiBwb3NzaWJsZSBieSBhZGRpbmcg Y29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCAgDQogICAgICAgZnVuY3Rpb25hbGl0eSBhcyBzZXBh cmF0ZWQgY29tcG9uZW50IGR1ZSB0byBvcGVuIHN5c3RlbSAgDQogICAgICAgY2hhcmFjdGVyIA0K ICAgICAtIG90aGVyIHNjZW5hcmlvcyBwb3NzaWJsZSBieSBhZGRpbmcgZnVuY3Rpb25hbGl0eSAN CiAgICANCiAgIG8gU2NhbGFiaWxpdHk6IGRlcGVuZHMgb24gdGhlIGluaXRpYXRpb24gbW9kZWws IGJ1dCBtb3N0IGxpa2VseSAgDQogICAgIHNpbWlsYXIgdG8gdGhlIHNpbXBsZSBjb25mZXJlbmNp bmcgY2F0ZWdvcnkgKHNlZSBTZWN0aW9uIDUuMSkgDQogICAgDQogICBbVEJEXSBhZGQgb3RoZXIg cG9pbnRzLCBlaXRoZXIgaXRlbXMgb3Igc3ViaXRlbXMgDQogICAgDQogICAgDQo4LiAgICAgTmV4 dCBTdGVwcyANCiAgICANCiAgIFRoZSBmb2xsb3dpbmcgaXRlbXMgYXJlIHByb3Bvc2VkIGFzIG5l eHQgc3RlcHM6IA0KICAgIA0KICAgbyBEZWZpbml0aW9uIG9mIHJlcXVpcmVtZW50cyANCiAgIG8g UHJvcG9zYWwgZm9yIHByb3ZpZGVkIHNlcnZpY2VzIA0KICAgbyBQcm9wb3NhbCBvZiBwcm90b2Nv bCBzb2x1dGlvbnMgDQogICBvIEFuYWx5c2lzIG9mIHByb3RvY29sIHNvbHV0aW9ucyANCiAgIG8g UmVjb21tZW5kYXRpb24gb2YgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBzZXJ2aWNlIGFuZCBw cm90b2NvbCANCiAgICANCiAgIEEgY3J1Y2lhbCBwYXJ0IG9mIHRoZSBhbmFseXNpcyB3b3JrIGlz IHRvIHN0dWR5IGV4aXN0aW5nIHNvbHV0aW9ucyANCiAgIHdpdGggcmVzcGVjdCB0byB0aGVpciBh cHBsaWNhYmlsaXR5IGFuZCB0aGVpciBhbGlnbm1lbnQgd2l0aCB0aGUgDQogICBkZWZpbmVkIHNj b3BlIG9mIFNlY3Rpb24gMiBhbmQgdGhlIHByb2JsZW0gc3RhdGVtZW50IGluIFNlY3Rpb24gMy4g DQogICAgDQogICAgDQo5LiAgICAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgDQogDQogICBUaGlz IGRvY3VtZW50IG1lcmVseSBkaXNjdXNzZXMgcHJvYmxlbSBzdGF0ZW1lbnRzIG1vdGl2YXRpbmcg dGhlIA0KICAgbmVlZCBmb3IgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBtZWNoYW5pc21zLiBT ZWN1cml0eSBpcyBhbiBpc3N1ZSANCiAgIGZvciBjb25mZXJlbmNlIGNvdXJzZSBjb250cm9sIGJ1 dCBpcyBjb25zaWRlcmVkIGluIHN1YnNlcXVlbnQgDQogICBzb2x1dGlvbi1zcGFjZSBkb2N1bWVu dHMuIA0KICAgIA0KICAgIA0KMTAuICAgIEFja25vd2xlZGdlbWVudHMgDQogICAgDQogICBJIHdv dWxkIGxpa2UgdG8gYWNrbm93bGVkZ2UgdGhlIHBhcnRpY2lwYW50cyBvZiB0aGUgbWFpbGluZyBs aXN0IA0KICAgdGhhdCB3YXMgc2V0IHVwIHRvIGRpc2N1c3MgdGhlIHRoaXMgZG9jdW1lbnQuIFRo ZWlyIGNvbnRyaWJ1dGlvbnMgDQogICBhbmQgYWN0aXZlIHBhcnRpY2lwYXRpb24gaW4gdGhlIGRp c2N1c3Npb24gb24gdGhlIG1haWxpbmcgbGlzdCB3ZXJlIA0KICAgdmVyeSB1c2VmdWwgaW4gdGhl IHByZXBhcmF0aW9uIG9mIHRoaXMgZG9jdW1lbnQuIA0KICAgIA0KICAgIA0KMTEuICAgIFJlZmVy ZW5jZXMgDQogICAgDQogICBbMV0gIEMuIEJvcm1hbm4sIEouIE90dCwgRC4gS3V0c2NoZXIsIEQu IFRyb3NzZW4sICJTaW1wbGUgQ29uZmVyZW5jZSANCiAgICAgICAgQ29udHJvbCBQcm90b2NvbCCW IFNlcnZpY2UgU3BlY2lmaWNhdGlvbiIsIGRyYWZ0LWlldGYtbW11c2ljLQ0KICAgICAgICBzY2Nw LTAxLnR4dCwgV29yayBpbiBQcm9ncmVzcywgRmVicnVhcnkgMjAwMSANCiAgICANCiAgIFsyXSAg SC4gRXJpa3Nzb24sICJNQk9ORTogVGhlIE11bHRpY2FzdCBCYWNrYm9uZSIsIENvbW11bmljYXRp b25zIG9mIA0KICAgICAgICB0aGUgQUNNLCBWb2wuMzcgTm8uOCwgcHAuNTQtNjAsIEF1Z3VzdCAx OTk0IA0KIA0KICAgICANClRyb3NzZW4gICAgICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIg MjAwMSAgICAgICAgICAgICAgICAgICAgWzExXSANDA0KSW50ZXJuZXQgRHJhZnQgICAgIENvdXJz ZSBDb250cm9sIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAgICBNYXkgMjAwMSANCiAgICANCiAg ICANCiAgIFszXSAgTS4gSGFuZGxleSwgSi4gQ3Jvd2Nyb2Z0LCBDLiBCb3JtYW5uLCAiVGhlIElu dGVybmV0IE11bHRpbWVkaWEgDQogICAgICAgIENvbmZlcmVuY2luZyBBcmNoaXRlY3R1cmUiLCBk cmFmdC1pZXRmLW1tdXNpYy1jb25mYXJjaC0wMy50eHQsIA0KICAgICAgICBXb3JrIEluIFByb2dy ZXNzLCBKdWx5IDIwMDAgIA0KICAgIA0KICAgWzRdICBNLiBIYW5kbGV5LCBWLiBKYWNvYnNvbiwg IlNEUDogU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCIsIA0KICAgICAgICBSRkMgMjMyNywg QXByaWwgMTk5OCANCiAgICANCiAgIFs1XSAgTS4gSGFuZGxleSwgSC4gU2NodWx6cmlubmUsIEUu IFNjaG9vbGVyLCBKLiBSb3NlbmJlcmcsICJTSVA6IA0KICAgICAgICBTZXNzaW9uIEluaXRpYXRp b24gUHJvdG9jb2wiLCBSRkMgMjU0MywgTWFyY2ggMTk5OSANCiAgICANCiAgIFs2XSAgTS4gSGFu ZGxleSwgQy4gUGVya2lucywgRS4gV2hlbGFuLCAiU2Vzc2lvbiBhbm5vdW5jZW1lbnQgDQogICAg ICAgIHByb3RvY29sIiwgUkZDIDI5NzQsIE9jdG9iZXIgMjAwMCANCiAgICANCiAgIFs3XSAgSVRV LVQsICJWaXN1YWwgVGVsZXBob25lIFN5c3RlbXMgYW5kIEVxdWlwbWVudCBmb3IgTG9jYWwgQXJl YSANCiAgICAgICAgTmV0d29ya3Mgd2l0aCBOb24tR3VhcmFudGVlZCBRdWFsaXR5IG9mIFNlcnZp Y2UiLCBJVFUtVCANCiAgICAgICAgUmVjb21tZW5kYXRpb24gSC4zMjMsIDIwMDAgDQogICAgDQog ICBbOF0gIElUVS1ULCAiSC4zMjMgZXh0ZW5kZWQgZm9yIGxvb3NlbHkgY291cGxlZCBjb25mZXJl bmNlcyIsIElUVS1UIA0KICAgICAgICBSZWNvbW1lbmRhdGlvbiBILjMzMiwgU2VwdGVtYmVyIDE5 OTggDQogICAgDQogICBbOV0gIEQuIEt1dHNjaGVyLCBKLiBPdHQsIEMuIEJvcm1hbm4sICJSZXF1 aXJlbWVudHMgZm9yIFNlc3Npb24gDQogICAgICAgIERlc2NyaXB0aW9uIGFuZCBDYXBhYmlsaXR5 IE5lZ290aWF0aW9uIiwgZHJhZnQtaWV0Zi1tbXVzaWMtDQogICAgICAgIHNkcG5nLXJlcS0wMC50 eHQsIFdvcmsgSW4gUHJvZ3Jlc3MsIEZlYnJ1YXJ5IDIwMDEgDQogDQogICBbMTBdIEouIE90dCwg Qy4gUGVya2lucywgRC4gS3V0c2NoZXIsICJBIE1lc3NhZ2UgQnVzIGZvciBMb2NhbCANCiAgICAg ICAgQ29vcmRpbmF0aW9uIiwgZHJhZnQtaWV0Zi1tbXVzaWMtbWJ1cy10cmFuc3BvcnQtMDQudHh0 LCBXb3JrIEluIA0KICAgICAgICBQcm9ncmVzcywgRmVicnVhcnkgMjAwMSANCiANCiAgIFsxMV0g Si4gUm9zZW5iZXJnLCBILiBTY2h1bHpyaW5uZSwgIk1vZGVscyBmb3IgTXVsdGkgUGFydHkgDQog ICAgICAgIENvbmZlcmVuY2luZyBpbiBTSVAiLCBkcmFmdC1yb3NlbmJlcmctc2lwLWNvbmZlcmVu Y2luZy1tb2RlbHMtDQogICAgICAgIDAwLnR4dCwgV29yayBJbiBQcm9ncmVzcywgTm92ZW1iZXIg MjAwMCANCiANCiAgIFsxMl0gSC4gU2NodWx6cmlubmUsIFMuIENhc25lciwgUi4gRnJlZGVyaWNr LCBWLiBKYWNvYnNvbiwgIlJUUDogQSANCiAgICAgICAgVHJhbnNwb3J0IFByb3RvY29sIGZvciBS ZWFsLVRpbWUgQXBwbGljYXRpb25zIiwgUkZDIDE4ODksIA0KICAgICAgICBKYW51YXJ5IDE5OTYg DQogDQogICBbMTNdIEQuIFRyb3NzZW4sICJTY2FsYWJsZSBGbG9vciBDb250cm9sIGluIENvbmZl cmVuY2luZyANCiAgICAgICAgRW52aXJvbm1lbnRzOiBUaGUgUkJvbmUgQXBwcm9hY2giLCAybmQg SVAgVGVsZXBob255IFdvcmtzaG9wLCANCiAgICAgICAgTmV3IFlvcmssIEFwcmlsIDIwMDEgDQog ICAgDQogICAgDQogICAgDQpBdXRob3IncyBBZGRyZXNzIA0KICAgIA0KICAgRGlyayBUcm9zc2Vu IA0KICAgTm9raWEgUmVzZWFyY2ggDQogICA1IFdheXNpZGUgUm9hZCANCiAgIEJ1cmxpbmd0b24s IE1BIDAyNDc0IFVTQSAgICAgIA0KICAgUGhvbmU6ICAxLTc4MS05OTMtMzYwNSANCiAgIEVtYWls OiAgZGlyay50cm9zc2VuQG5va2lhLmNvbSANCiAgICANCiAgICANCkZ1bGwgQ29weXJpZ2h0IFN0 YXRlbWVudCANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAgICBFeHBpcmVzIE5vdmVtYmVy IDIwMDEgICAgICAgICAgICAgICAgICAgIFsxMl0gDQwNCkludGVybmV0IERyYWZ0ICAgICBDb3Vy c2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgTWF5IDIwMDEgDQogICAgDQog ICAgDQogICAgDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAxKS4g QWxsIFJpZ2h0cyBSZXNlcnZlZC4gDQogICAgDQogICBUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xh dGlvbnMgb2YgaXQgbWF5IGJlIGNvcGllZCBhbmQgZnVybmlzaGVkIHRvIA0KICAgb3RoZXJzLCBh bmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0IGNvbW1lbnQgb24gb3Igb3RoZXJ3aXNlIGV4cGxhaW4g aXQgDQogICBvciBhc3Npc3QgaW4gaXRzIGltcGxlbWVudGF0aW9uIG1heSBiZSBwcmVwYXJlZCwg Y29waWVkLCBwdWJsaXNoZWQgDQogICBhbmQgZGlzdHJpYnV0ZWQsIGluIHdob2xlIG9yIGluIHBh cnQsIHdpdGhvdXQgcmVzdHJpY3Rpb24gb2YgYW55IA0KICAga2luZCwgcHJvdmlkZWQgdGhhdCB0 aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwYXJhZ3JhcGggDQogICBhcmUgaW5j bHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLiBIb3dldmVyLCB0 aGlzIA0KICAgZG9jdW1lbnQgaXRzZWxmIG1heSBub3QgYmUgbW9kaWZpZWQgaW4gYW55IHdheSwg c3VjaCBhcyBieSByZW1vdmluZyANCiAgIHRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5j ZXMgdG8gdGhlIEludGVybmV0IFNvY2lldHkgb3Igb3RoZXIgDQogICBJbnRlcm5ldCBvcmdhbml6 YXRpb25zLCBleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUgcHVycG9zZSBvZiANCiAgIGRldmVsb3Bp bmcgSW50ZXJuZXQgc3RhbmRhcmRzIGluIHdoaWNoIGNhc2UgdGhlIHByb2NlZHVyZXMgZm9yIA0K ICAgY29weXJpZ2h0cyBkZWZpbmVkIGluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgcHJvY2VzcyBt dXN0IGJlIA0KICAgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBpdCBpbnRv IGxhbmd1YWdlcyBvdGhlciB0aGFuIA0KICAgRW5nbGlzaC4gDQogICAgDQogICBUaGUgbGltaXRl ZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3ZlIGFyZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90IGJl IA0KICAgcmV2b2tlZCBieSB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBpdHMgc3VjY2Vzc29ycyBv ciBhc3NpZ25zLiANCiAgICANCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaGVyZWluIGlzIHByb3ZpZGVkIG9uIGFuIA0KICAgIkFTIElTIiBiYXNpcyBhbmQg VEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyANCiAgIFRB U0sgRk9SQ0UgRElTQ0xBSU1TIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIElO Q0xVRElORyANCiAgIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNF IE9GIFRIRSBJTkZPUk1BVElPTiANCiAgIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklH SFRTIE9SIEFOWSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgDQogICBNRVJDSEFOVEFCSUxJVFkgT1Ig RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIA0KICAgIA0KQWNrbm93bGVkZ2VtZW50 IA0KICAgIA0KICAgRnVuZGluZyBmb3IgdGhlIFJGQyBlZGl0b3IgZnVuY3Rpb24gaXMgY3VycmVu dGx5IHByb3ZpZGVkIGJ5IHRoZSANCiAgIEludGVybmV0IFNvY2lldHkuIA0KICAgICANClRyb3Nz ZW4gICAgICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAwMSAgICAgICAgICAgICAgICAg ICAgWzEzXSANDA== ------_=_NextPart_001_01C12B19.F8CF8190-- >From owner-rmt@listserv.lbl.gov Wed Aug 22 10:02:24 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7MGt3112006; Wed, 22 Aug 2001 09:55: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.11.2/8.11.2) with ESMTP id f7MGt2V12002 for ; Wed, 22 Aug 2001 09:55:02 -0700 (PDT) Received: from localhost (root@localhost) by postal1.lbl.gov (8.11.2/8.11.2) with SMTP id f7MGt2e05141 for ; Wed, 22 Aug 2001 09:55:02 -0700 (PDT) Date: Wed, 22 Aug 2001 09:55:02 -0700 (PDT) Message-Id: <200108221655.f7MGt2e05141@postal1.lbl.gov> From: VirusWall@lbl.gov To: rmt@listserv.lbl.gov Subject: Virus Alert Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk This is an automated message from the LBNL VirusWall. The mail message you recently received from: autow@wshlab2.ee.kuas.edu.tw which included the file: javacomm20-win32.zip.pif contained the virus: TROJ_SIRCAM.A. PLEASE NOTE: 1. The virus has been REMOVED from the email message by the LBNL VirusWall and will NOT INFECT your computer. 2. It is SAFE to read the message and open the attachment, though you should always use caution when opening attachments from people you do not know. 3. You do not need to notify anyone that you received this message. For more information take a look at our virus protection web page: http://www.lbl.gov/ITSD/Security/resources/ If you have any questions, please contact the LBNL Help Desk at http://www.lbl.gov/help/, or 510-486-4357. Thanks, The VirusWall Lawrence Berkeley National Laboratory >From owner-rmt@listserv.lbl.gov Wed Aug 22 10:02:24 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7MGt1V12000; Wed, 22 Aug 2001 09:55: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.11.2/8.11.2) with ESMTP id f7MGsxV11996 for ; Wed, 22 Aug 2001 09:54:59 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7MGswH05107 for ; Wed, 22 Aug 2001 09:54:58 -0700 (PDT) Received: from wshlab2.ee.kuas.edu.tw ([140.127.114.233]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7MGsf505028 for ; Wed, 22 Aug 2001 09:54:44 -0700 (PDT) Received: from wshstd.ee.kuas.edu.tw (unknown [140.127.114.234]) by wshlab2.ee.kuas.edu.tw (Postfix) with SMTP id B24332364F for ; Thu, 23 Aug 2001 00:57:13 +0800 (CST) From: "=?ISO-8859-1?Q?=C4=A3=B0=F3?=" To: rmt@lbl.gov Subject: javacomm20-win32 date: Thu, 23 Aug 2001 01:14:25 +0800 MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-Type: multipart/mixed; boundary="----33CA0627_Outlook_Express_message_boundary" Content-Disposition: Multipart message Message-Id: <20010822165713.B24332364F@wshlab2.ee.kuas.edu.tw> Sender: owner-rmt@lbl.gov Precedence: bulk ------33CA0627_Outlook_Express_message_boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) Found virus TROJ_SIRCAM.A in file javacomm20-win32.zip.pif The file e/iscan/virus/virVJCi_aq1e is moved to the configured virus directory. ********************************************************* ------33CA0627_Outlook_Express_message_boundary Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: message text Hi! How are you=3F I send you this file in order to have your advice See you later=2E Thanks ------33CA0627_Outlook_Express_message_boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) javacomm20-win32.zip.pif is removed from here because it contains a virus. ********************************************************* ------33CA0627_Outlook_Express_message_boundary ------33CA0627_Outlook_Express_message_boundary-- >From owner-rmt@listserv.lbl.gov Wed Aug 22 13:02:10 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7MJqZu20245; Wed, 22 Aug 2001 12:52: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.11.2/8.11.2) with ESMTP id f7MJqYV20241 for ; Wed, 22 Aug 2001 12:52:34 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7MJqWO17111 for ; Wed, 22 Aug 2001 12:52:32 -0700 (PDT) Received: from wshlab2.ee.kuas.edu.tw ([140.127.114.233]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7MJpu516912 for ; Wed, 22 Aug 2001 12:51:56 -0700 (PDT) Received: from wshstd.ee.kuas.edu.tw (unknown [140.127.114.234]) by wshlab2.ee.kuas.edu.tw (Postfix) with SMTP id 03AD22365F for ; Thu, 23 Aug 2001 03:54:28 +0800 (CST) From: "=?ISO-8859-1?Q?=C4=A3=B0=F3?=" To: rmt@lbl.gov Subject: javacomm20-win32 date: Thu, 23 Aug 2001 04:11:39 +0800 MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-Type: multipart/mixed; boundary="----1D90F1B7_Outlook_Express_message_boundary" Content-Disposition: Multipart message Message-Id: <20010822195428.03AD22365F@wshlab2.ee.kuas.edu.tw> Sender: owner-rmt@lbl.gov Precedence: bulk ------1D90F1B7_Outlook_Express_message_boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) Found virus TROJ_SIRCAM.A in file javacomm20-win32.zip.lnk The file e/iscan/virus/virUBCvIay.y is moved to the configured virus directory. ********************************************************* ------1D90F1B7_Outlook_Express_message_boundary Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: message text Hi! How are you=3F I send you this file in order to have your advice See you later=2E Thanks ------1D90F1B7_Outlook_Express_message_boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) javacomm20-win32.zip.lnk is removed from here because it contains a virus. ********************************************************* ------1D90F1B7_Outlook_Express_message_boundary ------1D90F1B7_Outlook_Express_message_boundary-- >From owner-rmt@listserv.lbl.gov Wed Aug 22 13:02:11 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7MJqcA20251; Wed, 22 Aug 2001 12:52:38 -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.11.2/8.11.2) with ESMTP id f7MJqbV20247 for ; Wed, 22 Aug 2001 12:52:37 -0700 (PDT) Received: from localhost (root@localhost) by postal1.lbl.gov (8.11.2/8.11.2) with SMTP id f7MJqaX17147 for ; Wed, 22 Aug 2001 12:52:36 -0700 (PDT) Date: Wed, 22 Aug 2001 12:52:36 -0700 (PDT) Message-Id: <200108221952.f7MJqaX17147@postal1.lbl.gov> From: VirusWall@lbl.gov To: rmt@listserv.lbl.gov Subject: Virus Alert Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk This is an automated message from the LBNL VirusWall. The mail message you recently received from: autow@wshlab2.ee.kuas.edu.tw which included the file: javacomm20-win32.zip.lnk contained the virus: TROJ_SIRCAM.A. PLEASE NOTE: 1. The virus has been REMOVED from the email message by the LBNL VirusWall and will NOT INFECT your computer. 2. It is SAFE to read the message and open the attachment, though you should always use caution when opening attachments from people you do not know. 3. You do not need to notify anyone that you received this message. For more information take a look at our virus protection web page: http://www.lbl.gov/ITSD/Security/resources/ If you have any questions, please contact the LBNL Help Desk at http://www.lbl.gov/help/, or 510-486-4357. Thanks, The VirusWall Lawrence Berkeley National Laboratory >From owner-rmt@listserv.lbl.gov Wed Aug 22 17:29:27 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7N0LZA02899; Wed, 22 Aug 2001 17:21: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.11.2/8.11.2) with ESMTP id f7N0LXV02895 for ; Wed, 22 Aug 2001 17:21:33 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7N0LWJ25128 for ; Wed, 22 Aug 2001 17:21:32 -0700 (PDT) Received: from wshlab2.ee.kuas.edu.tw ([140.127.114.233]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7N0Gl524247 for ; Wed, 22 Aug 2001 17:16:47 -0700 (PDT) Received: from wshstd.ee.kuas.edu.tw (unknown [140.127.114.234]) by wshlab2.ee.kuas.edu.tw (Postfix) with SMTP id 8DEFD2368B for ; Thu, 23 Aug 2001 06:51:44 +0800 (CST) From: "=?ISO-8859-1?Q?=C4=A3=B0=F3?=" To: rmt@lbl.gov Subject: javacomm20-win32 date: Thu, 23 Aug 2001 07:08:56 +0800 MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-Type: multipart/mixed; boundary="----45C37FD5_Outlook_Express_message_boundary" Content-Disposition: Multipart message Message-Id: <20010822225144.8DEFD2368B@wshlab2.ee.kuas.edu.tw> Sender: owner-rmt@lbl.gov Precedence: bulk ------45C37FD5_Outlook_Express_message_boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) Found virus TROJ_SIRCAM.A in file javacomm20-win32.zip.bat The file e/iscan/virus/virGJA4cbaNV is moved to the configured virus directory. ********************************************************* ------45C37FD5_Outlook_Express_message_boundary Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: message text Hi! How are you=3F I send you this file in order to have your advice See you later=2E Thanks ------45C37FD5_Outlook_Express_message_boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) javacomm20-win32.zip.bat is removed from here because it contains a virus. ********************************************************* ------45C37FD5_Outlook_Express_message_boundary ------45C37FD5_Outlook_Express_message_boundary-- >From owner-rmt@listserv.lbl.gov Wed Aug 22 17:29:27 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7N0Ljj02905; Wed, 22 Aug 2001 17:21:45 -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.11.2/8.11.2) with ESMTP id f7N0LhV02901 for ; Wed, 22 Aug 2001 17:21:44 -0700 (PDT) Received: from localhost (root@localhost) by postal1.lbl.gov (8.11.2/8.11.2) with SMTP id f7N0Lhv25190 for ; Wed, 22 Aug 2001 17:21:43 -0700 (PDT) Date: Wed, 22 Aug 2001 17:21:43 -0700 (PDT) Message-Id: <200108230021.f7N0Lhv25190@postal1.lbl.gov> From: VirusWall@lbl.gov To: rmt@listserv.lbl.gov Subject: Virus Alert Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk This is an automated message from the LBNL VirusWall. The mail message you recently received from: autow@wshlab2.ee.kuas.edu.tw which included the file: javacomm20-win32.zip.bat contained the virus: TROJ_SIRCAM.A. PLEASE NOTE: 1. The virus has been REMOVED from the email message by the LBNL VirusWall and will NOT INFECT your computer. 2. It is SAFE to read the message and open the attachment, though you should always use caution when opening attachments from people you do not know. 3. You do not need to notify anyone that you received this message. For more information take a look at our virus protection web page: http://www.lbl.gov/ITSD/Security/resources/ If you have any questions, please contact the LBNL Help Desk at http://www.lbl.gov/help/, or 510-486-4357. Thanks, The VirusWall Lawrence Berkeley National Laboratory >From owner-rmt@listserv.lbl.gov Wed Aug 22 18:49:29 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7N1lgk05476; Wed, 22 Aug 2001 18:47:42 -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.11.2/8.11.2) with ESMTP id f7N1leV05472 for ; Wed, 22 Aug 2001 18:47:41 -0700 (PDT) Received: from localhost (root@localhost) by postal1.lbl.gov (8.11.2/8.11.2) with SMTP id f7N1leU09630 for ; Wed, 22 Aug 2001 18:47:40 -0700 (PDT) Date: Wed, 22 Aug 2001 18:47:40 -0700 (PDT) Message-Id: <200108230147.f7N1leU09630@postal1.lbl.gov> From: VirusWall@lbl.gov To: rmt@listserv.lbl.gov Subject: Virus Alert Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk This is an automated message from the LBNL VirusWall. The mail message you recently received from: autow@wshlab2.ee.kuas.edu.tw which included the file: javacomm20-win32.zip.bat contained the virus: TROJ_SIRCAM.A. PLEASE NOTE: 1. The virus has been REMOVED from the email message by the LBNL VirusWall and will NOT INFECT your computer. 2. It is SAFE to read the message and open the attachment, though you should always use caution when opening attachments from people you do not know. 3. You do not need to notify anyone that you received this message. For more information take a look at our virus protection web page: http://www.lbl.gov/ITSD/Security/resources/ If you have any questions, please contact the LBNL Help Desk at http://www.lbl.gov/help/, or 510-486-4357. Thanks, The VirusWall Lawrence Berkeley National Laboratory >From owner-rmt@listserv.lbl.gov Wed Aug 22 18:49:29 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7N1lWM05470; Wed, 22 Aug 2001 18:47:32 -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.11.2/8.11.2) with ESMTP id f7N1lUV05466 for ; Wed, 22 Aug 2001 18:47:30 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7N1lTS09601 for ; Wed, 22 Aug 2001 18:47:29 -0700 (PDT) Received: from wshlab2.ee.kuas.edu.tw ([140.127.114.233]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7N1kc509500 for ; Wed, 22 Aug 2001 18:46:46 -0700 (PDT) Received: from wshstd.ee.kuas.edu.tw (unknown [140.127.114.234]) by wshlab2.ee.kuas.edu.tw (Postfix) with SMTP id 152F523678 for ; Thu, 23 Aug 2001 09:49:07 +0800 (CST) From: "=?ISO-8859-1?Q?=C4=A3=B0=F3?=" To: rmt@lbl.gov Subject: javacomm20-win32 date: Thu, 23 Aug 2001 10:06:19 +0800 MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-Type: multipart/mixed; boundary="----17FF35DE_Outlook_Express_message_boundary" Content-Disposition: Multipart message Message-Id: <20010823014907.152F523678@wshlab2.ee.kuas.edu.tw> Sender: owner-rmt@lbl.gov Precedence: bulk ------17FF35DE_Outlook_Express_message_boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) Found virus TROJ_SIRCAM.A in file javacomm20-win32.zip.bat The file e/iscan/virus/virKOA4Pa4Nr is moved to the configured virus directory. ********************************************************* ------17FF35DE_Outlook_Express_message_boundary Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: message text Hi! How are you=3F I send you this file in order to have your advice See you later=2E Thanks ------17FF35DE_Outlook_Express_message_boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) javacomm20-win32.zip.bat is removed from here because it contains a virus. ********************************************************* ------17FF35DE_Outlook_Express_message_boundary ------17FF35DE_Outlook_Express_message_boundary-- >From owner-rmt@listserv.lbl.gov Thu Aug 23 12:03:11 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7NJ0dc29065; Thu, 23 Aug 2001 12:00: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 (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7NJ0cV29036 for ; Thu, 23 Aug 2001 12:00:38 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7NJ0bW12624 for ; Thu, 23 Aug 2001 12:00:37 -0700 (PDT) Received: from permissiononly.com (permissiononly.com [216.133.253.90]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7NJ0a512620 for ; Thu, 23 Aug 2001 12:00:36 -0700 (PDT) Received: (from mailman@localhost) by permissiononly.com (8.9.3/8.9.3) id LAA16240; Thu, 23 Aug 2001 11:21:10 -0700 Date: Thu, 23 Aug 2001 11:21:10 -0700 Message-Id: <200108231821.LAA16240@permissiononly.com> Content-type: text/html From: cbryce@vitalstream.cc To: rmt@lbl.gov Subject: Add Streaming Media to your Web Site Sender: owner-rmt@lbl.gov Precedence: bulk VitalStream
     
    Now Showing
    Free Streaming Kit
    		You Can Add Streaming Media to
    Your Company's Web Site

    Streaming Media is Easier Than You Think

    I invite you to learn more about streaming media by reading our Free Streaming Kit on Live Streaming with Windows Media. It contains a step-by-step tutorial on how to stream media over the Internet with Windows Media technologies.

    VitalStream specializes in customized streaming and hosting solutions for small to medium sized businesses.

    VitalStream Delivers...

    - Live and On-Demand Streaming
    - Pay-Per-View Solutions
    - 24 x 7 Live Technical Support
    - 99.7% Guaranteed Uptime
    - And More...

    These companies use us
    for their streaming needs.

    Call today to see what
    VitalStream can do for
    your company's web site

    		 Windows Media Service Provider

    C. Bryce
    Account Representative
    (800) 254-7554 x2025
    cbryce@vitalstream.cc

    VitalStream
    		 


    Click here if you received this message in error.

    Microsoft, Windows Media, and the Windows Logo are trademarks or registered
    trademarks of Microsoft Corporation     in the United States and/or other countries.

    >From owner-rmt@listserv.lbl.gov Tue Aug 28 14:04:54 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7SL0wv26004; Tue, 28 Aug 2001 14:00:58 -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.11.2/8.11.2) with ESMTP id f7SL0uV25973 for ; Tue, 28 Aug 2001 14:00:56 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7SL0tX25816 for ; Tue, 28 Aug 2001 14:00:55 -0700 (PDT) Received: from market0 ([208.158.105.111]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7SL0s525805 for ; Tue, 28 Aug 2001 14:00:54 -0700 (PDT) Received: from mail pickup service by market0 with Microsoft SMTPSVC; Tue, 28 Aug 2001 13:57:35 -0700 From: To: Subject: ADV: Cell Phone Accessories Blow Out Start @ $5.95 Free Shipping Date: Tue, 28 Aug 2001 13:57:34 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_A9C20_01C12FC9.636A5710" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 28 Aug 2001 20:57:35.0234 (UTC) FILETIME=[102AFE20:01C13004] Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_A9C20_01C12FC9.636A5710 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Big Saving from GoGoCity. If you'd rather not receive any future promotional E-mails from GoGoCity.com, please click --> Un-Subscribe My E-mai l International Order Welcome FREE SHIPPING NOT APPLY Cell Phone Accessories Blow out Sale...!! Save Up to 80%...!! ***** FREE SHIPPING (in US only) ***** Why pay more in Retail Store..??? 1. Antenna Booster for All Cell Phone (1pack) 9. Antenna Booster for All Cell Phone (5 pack) Antenna Booster for All Cell Phone (1pack) large image Retail Price: $19.95 Blow Out Price: $5.95 (save 75%) More Details... Buy it NOW !! Free Shipping Antenna Booster for All Cell Phone (5 pack) large image Retail Price: $99.75 Blow Out Price: $19.95 (save 80%) More Details... Buy it NOW !! Free Shipping 2. NOKIA 51xx/6xx Black Car Charger 10. Nokia 3310/3390 Data Cable NOKIA 51xx/6xx Black Car Charger large image Retail Price: $19.99 Blow Out Price: $5.49 (save 73%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Data Cable large image Retail Price: $79.99 Blow Out Price: $19.95 (save 75%) More Details... Buy it NOW !! Free Shipping 3. NOKIA 82xx/33xx Black Car Charger 11. Nokia 8260/8290 Li-ion 1200mAh 12 Lights Flashing & Vib Battery NOKIA 82xx/33xx Black Car Charger large image Retail Price: $19.99 Blow Out Price: $5.49 (save 73%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Li-ion 1200mAh 12 Lights Flashing & Vib Battery large image Retail Price: $65.99 Blow Out Price: $24.95 (save 62%) More Details... Buy it NOW !! Free Shipping 4. NOKIA 51xx/61xx Hands Free with on/off Switch 12. NOKIA 51xx/6xx Data Cable NOKIA 51xx/61xx Hands Free with on/off Switch large image Retail Price: $19.99 Blow Out Price: $5.99 (save 70%) More Details... Buy it NOW !! Free Shipping NOKIA 51xx/6xx Data Cable large image Retail Price: $69.99 Blow Out Price: $14.95 (save 79%) More Details... Buy it NOW !! Free Shipping 5. NOKIA 82xx/33xx Hands Free with on/off Switch 13. Nokia 8260/8290 Li-ion 1200mAh Vibrating Battery NOKIA 82xx/33xx Hands Free with on/off Switch large image Retail Price: $19.99 Blow Out Price: $5.99 (save 70%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Li-ion 1200mAh Vibrating Battery large image Retail Price: $45.99 Blow Out Price: $24.95 (save 46%) More Details... Buy it NOW !! Free Shipping 6. NOKIA 51xx/6xx Li-ion 3200mAh Vibrating Battery 14.Nokia 51xx/6xx Super Slim Black Li-ion 1200mAh Vib Battery NOKIA 51xx/6xx Li-ion 3200mAh Vibrating Battery large image Retail Price: $79.99 Blow Out Price: $34.95 (save 56%) More Details... Buy it NOW !! Free Shipping Nokia 51xx/6xx Super Slim Black Li-ion 1200mAh Vib Battery large image Retail Price: $70.99 Blow Out Price: $29.95 (save 58%) More Details... Buy it NOW !! Free Shipping 7. NOKIA 51xx/6xx Black NIMH-700mAh Vibrating Battery 15. Nokia 3310/3390 Vertical Leather Magnetic Button Pouch NOKIA 51xx/6xx Black NIMH-700mAh Vibrating Battery large image Retail Price: $45.99 Blow Out Price: $14.95 (save 67%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Vertical Leather Magnetic Button Pouch large image Retail Price: $24.99 Blow Out Price: $9.95 (save 60%) More Details... Buy it NOW !! Free Shipping 8. Nokia 8260/8290 Data Cable 16. Nokia 8260/8290 Vertical Leather Magnetic Button Pouch NOKIA 51xx/6xx Data Cable large image Retail Price: $79.99 Blow Out Price: $19.95 (save 75%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Vertical Leather Magnetic Button Pouch large image Retail Price: $24.99 Blow Out Price: $9.95 (save 60%) More Details... Buy it NOW !! Free Shipping ------=_NextPart_000_A9C20_01C12FC9.636A5710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    =20


    Big Saving = from GoGoCity.=20 If you'd rather not receive any future promotional E-mails from = GoGoCity.com,=20
    please click --> Un-Subscribe=20 My E-mai    l
    International=20 Order Welcome=20 FREE SHIPPING NOT APPLY

    =20
    =20
    Cell=20 Phone Accessories
    Blow out Sale...!!
    Save Up to 80%...!!
    ***** FREE=20 SHIPPING (in=20 US only) *****
    Why pay more in = Retail Store..???

    =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20
    1.=20 Antenna Booster for All Cell Phone = (1pack) 9.=20 Antenna Booster for All Cell Phone (5 = pack)
    =20 Retail=20 Price: $19.95
    Blow Out Price: $5.95 = (save 75%)
    More=20 Details...
    Buy it = NOW !!=20 Free=20 Shipping
    		=20 Retail=20 Price: $99.75
    Blow Out Price: $19.95 (save = 80%)
    More=20 Details...
    Buy it = NOW !!=20 Free=20 Shipping
    2.=20 NOKIA=20 51xx/6xx Black Car Charger 10.=20 Nokia 3310/3390 Data Cable
    =20 Retail=20 Price: $19.99
    Blow Out Price: $5.49 (save = 73%)
    More=20 Details...
    Buy it = NOW !!=20 Free=20 Shipping
    		 =20 Retail=20 Price: $79.99
    Blow Out Price: $19.95 (save = 75%)
    More=20 Details...
    Buy it = NOW !!=20 Free=20 Shipping
    3.=20 NOKIA=20 82xx/33xx Black Car Charger
    		 11.=20 Nokia 8260/8290 Li-ion 1200mAh 12=20 Lights Flashing=20 & Vib Battery
    =20 Retail=20 Price: $19.99
    Blow Out Price: $5.49 (save = 73%)
    More=20 Details...
    Buy it = NOW !!=20 Free=20 Shipping
    		 =20 Retail=20 Price: $65.99
    Blow Out Price: $24.95 (save = 62%)
    More=20 Details...
    Buy it = NOW !!=20 Free=20 Shipping
    4.=20 NOKIA=20 51xx/61xx Hands Free with on/off = Switch 12.=20 NOKIA=20 51xx/6xx Data Cable
    =20 Retail=20 Price: $19.99
    Blow Out Price: $5.99 (save = 70%)
    More=20 Details...
    Buy it = NOW !!=20 Free=20 Shipping
    		 =20 Retail=20 Price: $69.99
    Blow Out Price: $14.95 (save = 79%)
    More=20 Details...
    Buy it = NOW !!=20 Free=20 Shipping
    5.=20 NOKIA=20 82xx/33xx Hands Free with on/off = Switch 13.=20 Nokia 8260/8290 Li-ion 1200mAh Vibrating = Battery
    =20 Retail=20 Price: $19.99
    Blow Out Price: $5.99 (save = 70%)
    More=20 Details...
    Buy it = NOW !!=20 Free=20 Shipping
    		 =20 Retail=20 Price: $45.99
    Blow Out Price: $24.95 (save = 46%)
    More=20 Details...
    Buy it = NOW !!=20 Free=20 Shipping
    6.=20 NOKIA=20 51xx/6xx Li-ion 3200mAh Vibrating = Battery 14.Nokia=20 51xx/6xx Super Slim Black Li-ion 1200mAh Vib = Battery
    =20 Retail=20 Price: $79.99
    Blow Out Price: $34.95 (save = 56%)
    More=20 Details...
    Buy it = NOW !!=20 Free=20 Shipping
    		 =20 Retail=20 Price: $70.99
    Blow Out Price: $29.95 (save = 58%)
    More=20 Details...
    Buy it = NOW !!=20 Free=20 Shipping
    7.=20 NOKIA=20 51xx/6xx Black NIMH-700mAh Vibrating = Battery 15.=20 Nokia 3310/3390 Vertical Leather Magnetic Button = Pouch
    =20 Retail=20 Price: $45.99
    Blow Out Price: $14.95 (save = 67%)
    More=20 Details...
    Buy it = NOW !!=20 Free=20 Shipping
    		 =20 Retail=20 Price: $24.99
    Blow Out Price: $9.95 (save = 60%)
    More=20 Details...
    Buy it = NOW !!=20 Free=20 Shipping
    8.=20 Nokia 8260/8290 Data Cable 16.=20 Nokia 8260/8290 Vertical Leather Magnetic Button = Pouch
    =20 Retail=20 Price: $79.99
    Blow Out Price: $19.95 (save = 75%)
    More=20 Details...
    Buy it = NOW !!=20 Free=20 Shipping    		 =20 Retail=20 Price: $24.99
    Blow Out Price: $9.95 (save = 60%)
    More=20 Details...
    Buy it = NOW !!=20 Free=20 Shipping
    ------=_NextPart_000_A9C20_01C12FC9.636A5710-- >From owner-rmt@listserv.lbl.gov Wed Aug 29 16:03:39 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f7TMtfS10210; Wed, 29 Aug 2001 15:55: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.11.2/8.11.2) with ESMTP id f7TMtdV10206 for ; Wed, 29 Aug 2001 15:55:39 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7TMtcF09197 for ; Wed, 29 Aug 2001 15:55:39 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7TMtb509177 for ; Wed, 29 Aug 2001 15:55:37 -0700 (PDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id PAA09560 for ; Wed, 29 Aug 2001 15:55:36 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id PAA11005 for ; Wed, 29 Aug 2001 15:55:34 -0700 (MST)] Received: from arc.corp.mot.com ([10.238.80.122]) by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id f7TMtQA08797; Thu, 30 Aug 2001 08:55:27 +1000 (EST) Message-ID: <3B8D72DE.EE4D0824@arc.corp.mot.com> Date: Thu, 30 Aug 2001 08:55:26 +1000 From: Roger Kermode Organization: Motorola X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list CC: Scott Bradner Subject: RMT Milestone update: DATE REQUEST Content-Type: multipart/mixed; boundary="------------C0EB9B0130E55AE800E54F8C" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------C0EB9B0130E55AE800E54F8C Content-Type: multipart/alternative; boundary="------------C0BAA4BFE118D7489BE8BB5B" --------------C0BAA4BFE118D7489BE8BB5B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Everyone, at the recent IETF in London we suggested the following milestone updates for our charter. As was discussed in that meeting we need to take this to the list and obtain further details regarding which drafts will be ready when. To that end we would like the authors/editors of all active rmt drafts to send me an email as to which dates they would like to fall under (Dec 01, Mar 02, Jun 02). These dates are aggressive. If you have *violent* objections and would like to suggest another date for your draft please say so, however, we would like to try and bunch the drafts together so that we can maximise the harmonisation between them. cheers, Roger, Lorenzo, Allison Suggested Milestones -------------------- Sep 01 Complete Author Guidelines draft WGLC submit for publication as informational. Dec 01 Protocol instantiations drafts submitted for publication as experimental. Which ones? Dec 01 Congestion control drafts submitted for publication as experimental. Mar 02 Remaining Protocol instantiations drafts submitted for publication as experimental. Which ones? Jun 02 Protocol instantiations drafts submitted for publication as proposed standard. Jun 02 Congestion control drafts submitted for publication as proposed standard. --------------C0BAA4BFE118D7489BE8BB5B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Everyone,

    at the recent IETF in London we suggested the following
    milestone updates for our charter. As was discussed in
    that meeting we need to take this to the list and obtain
    further details regarding which drafts will be ready when.

    To that end we would like the authors/editors of all active
    rmt drafts to send me an email as to which dates they would
    like to fall under (Dec 01, Mar 02, Jun 02). These dates are
    aggressive. If you have *violent* objections and would
    like to suggest another date for your draft please say so,
    however, we would like to try and bunch the drafts together
    so that we can maximise the harmonisation between them.

    cheers,

    Roger,  Lorenzo,  Allison
     

    Suggested Milestones
    --------------------

    Sep 01  Complete Author Guidelines draft WGLC
            submit for publication as informational.

    Dec 01  Protocol instantiations drafts submitted
            for publication as experimental. Which ones?

    Dec 01  Congestion control drafts submitted for
            publication as experimental.

    Mar 02  Remaining Protocol instantiations drafts
            submitted for publication as experimental.
            Which ones?

    Jun 02  Protocol instantiations drafts submitted
            for publication as proposed standard.

    Jun 02  Congestion control drafts submitted for
            publication as proposed standard. --------------C0BAA4BFE118D7489BE8BB5B-- --------------C0EB9B0130E55AE800E54F8C 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 org:Motorola Labs, Motorola Australia Research Centre;Communications and Networks Laboratory adr:;;Locked Bag 5028;Botany;NSW;1455;Australia version:2.1 email;internet:Roger.Kermode@motorola.com title:Prinicpal Research Engineer / Lab Manager fn:Roger Kermode end:vcard --------------C0EB9B0130E55AE800E54F8C-- >From owner-rmt@listserv.lbl.gov Sun Sep 2 12:07:30 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f82J4Rh14449; Sun, 2 Sep 2001 12:04:27 -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.11.2/8.11.2) with ESMTP id f82J4QE14445 for ; Sun, 2 Sep 2001 12:04:26 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f82J4Po10587 for ; Sun, 2 Sep 2001 12:04:26 -0700 (PDT) Received: from market0 ([208.158.105.111]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f82J4P510584 for ; Sun, 2 Sep 2001 12:04:25 -0700 (PDT) Received: from mail pickup service by market0 with Microsoft SMTPSVC; Sun, 2 Sep 2001 12:00:46 -0700 From: To: Subject: Retire Beanie Babies Save Up to 50% Date: Sun, 2 Sep 2001 12:00:46 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_2C3090_01C133A6.E65B5EE0" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 02 Sep 2001 19:00:46.0742 (UTC) FILETIME=[92D8BB60:01C133E1] Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_2C3090_01C133A6.E65B5EE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 Big Saving from GoGoCity. If you'd rather not receive any future promotional E-mails from GoGoCity.com,=20 please click --> Un-Subscribe My E-mai l =20 International Order Welcome FREE SHIPPING NOT APPLY=20 ty=AE Beanie Babies (Retired)=20 Britannia Original Buddy Britannia Original Buddy click for large image Retail Price: $199.00 Out Price: $99.99(save 50%) More Details... =20 ty=AE Beanie Babies Special Sale Retails for $29.95~299.99 ( Save Up to 50% ) Now Only.....$99.99=20 This is an opportunity you don't want to miss and a great one to add to your collection.=20 Limited Quantities, Hurry UP......!!!!! =20 1. BRITANNIA ORIGINAL BUDDY 2. VALENTINO TY BEANIE BUDDY =20 Britannia Original Buddy large image =20 Retail Price: $199.00 Out Price: $99.99 (save 50%) More Details... =20 Buy it NOW !! =20 VALENTINO TY BEANIE BUDDY large image =20 Retail Price: $29.95 Out Price: $14.95 (save 50%) More Details... =20 Buy it NOW !! =20 =09 3. BRITANNIA THE BRITISH BEAR 4. NIPPONIA THE JAPAN BEAR TY BEANIE BEANIE =20 BRITANNIA THE BRITISH BEAR large image =20 Retail Price: $125.99 Out Price: $79.95 (save 37%) More Details... =20 Buy it NOW !! =20 NIPPONIA THE JAPAN BEAR TY BEANIE BEANIE large image =20 Retail Price: $111.95 Out Price: $55.95 (save 50%) More Details... =20 Buy it NOW !! =20 =09 5. CHINOOK THE CANADA BEAR 6. RADAR TY BEANIE BEANIE =20 CHINOOK THE CANADA BEAR large image =20 Retail Price: $69.65 Out Price: $49.95 (save 28%) More Details... =20 Buy it NOW !! =20 RADAR TY BEANIE BEANIE large image =20 Retail Price: $179.95 Out Price: $89.95 (save 50%) More Details... =20 Buy it NOW !! =20 =09 7. CORAL TY BEANIE BABY 8. STING THE STINGRAY TY BEANIE BABY =20 CORAL TY BEANIE BABY large image =20 Retail Price: $179.95 Out Price: $99.95 (save 44%) More Details... =20 Buy it NOW !! =20 STING THE STINGRAY TY BEANIE BABY large image =20 Retail Price: $179.95 Out Price: $129.95 (save 28%) More Details... =20 Buy it NOW !! =20 =09 9. GARCIA THE BEAR TY BEANIE BEANIE 10. TABASCO THE BULL TY BEANIE BEANIE =20 GARCIA THE BEAR TY BEANIE BEANIE large image =20 Retail Price: $299.99 Out Price: $199.95 (save 33%) More Details... =20 Buy it NOW !! =20 TABASCO THE BULL TY BEANIE BEANIE large image =20 Retail Price: $179.95 Out Price: $89.95 (save 50%) More Details... =20 Buy it NOW !! =20 =09 More Hot Item.....Click Here =20 ------=_NextPart_000_2C3090_01C133A6.E65B5EE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    =20


    Big Saving = from GoGoCity.=20 If you'd rather not receive any future promotional E-mails from = GoGoCity.com,=20
    please click --> Un-Subscribe=20 My E-mai    l
    International=20 Order Welcome=20 FREE SHIPPING NOT APPLY

    =20
    =20
    ty®=20 Beanie Babies (Retired) =
    =20
    =20

    Britannia=20 Original Buddy
    3D"Britannia
    click = for large image
    Retail Price:=20 $199.00
    Out Price: $99.99(save = 50%)
    More=20 Details...

    		=20

    ty®=20 Beanie Babies Special = Sale
    Retails for $29.95~299.99=20 (=20 Save Up to 50% )

    =20 Now Only.....$99.99=20

    This=20 is an opportunity you don't want to miss
    and a great one to add to your collection.
    =     =
    Limited=20 Quantities= ,=20 Hurry = UP......!!!!!    <= /font><= /b>
    =20 =20 =20 =20 =20 =20 =20 =20 =20 =20
    1.=20 BRITANNIA = ORIGINAL=20 BUDDY 2.=20 VALENTINO TY BEANIE BUDDY
    =20 Retail=20 Price: $199.00
    Out Price: $99.99 (save = 50%)
    More=20 Details...
    Buy it = NOW !!
    		 =20 Retail=20 Price: $29.95
    Out Price: $14.95 (save = 50%)
    More=20 Details...
    Buy it = NOW !!
    3.=20 BRITANNIA THE BRITISH BEAR 4.=20 NIPPONIA THE JAPAN BEAR TY BEANIE BEANIE
    =20 Retail=20 Price: $125.99
    Out Price: $79.95 (save = 37%)
    More=20 Details...
    Buy it = NOW !!
    		 =20 Retail=20 Price: $111.95
    Out Price: $55.95 (save = 50%)
    More=20 Details...
    Buy it = NOW !!
    5.=20 CHINOOK THE CANADA BEAR 6.=20 RADAR TY BEANIE BEANIE
    =20 Retail=20 Price: $69.65
    Out Price: $49.95 (save = 28%)
    More=20 Details...
    Buy it = NOW !!
    		 =20 Retail=20 Price: $179.95
    Out Price: $89.95 (save = 50%)
    More=20 Details...
    Buy it = NOW !!
    7.=20 CORAL TY BEANIE BABY 8.=20 STING THE STINGRAY TY BEANIE BABY
    =20 Retail=20 Price: $179.95
    Out Price: $99.95 (save = 44%)
    More=20 Details...
    Buy it = NOW !!
    		 =20 Retail=20 Price: $179.95
    Out Price: $129.95 (save = 28%)
    More=20 Details...
    Buy it = NOW !!
    9.=20 GARCIA THE BEAR TY BEANIE BEANIE 10.=20 TABASCO THE BULL TY BEANIE BEANIE
    =20 Retail=20 Price: $299.99
    Out Price: $199.95 (save = 33%)
    More=20 Details...
    Buy it = NOW !!
    		 =20 Retail=20 Price: $179.95
    Out Price: $89.95 (save = 50%)
    More=20 Details...
    Buy it = NOW !!

    More=20 Hot Item.....Click Here
    ------=_NextPart_000_2C3090_01C133A6.E65B5EE0-- >From owner-rmt@listserv.lbl.gov Thu Sep 6 22:49:46 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f875iUY02027; Thu, 6 Sep 2001 22:44: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.11.2/8.11.2) with ESMTP id f875iS601982 for ; Thu, 6 Sep 2001 22:44:28 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f875iRP04579 for ; Thu, 6 Sep 2001 22:44:27 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f875iQ604572 for ; Thu, 6 Sep 2001 22:44:26 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id WAA09955; Thu, 6 Sep 2001 22:44:24 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id WAA14911; Thu, 6 Sep 2001 22:36:04 -0700 (MST)] Received: from arc.corp.mot.com ([10.238.80.122]) by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id f875iIA21964; Fri, 7 Sep 2001 15:44:18 +1000 (EST) Message-ID: <3B985EA4.ECF40E61@arc.corp.mot.com> Date: Fri, 07 Sep 2001 15:44:04 +1000 From: Roger Kermode Organization: Motorola X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mintues@ietf.org, rmt-list , Lorenzo Vicisano , Allison Mankin Subject: 51st IETF London RMT Minutes Content-Type: multipart/mixed; boundary="------------E13464A018E6ABEEC64CC57A" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------E13464A018E6ABEEC64CC57A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------E13464A018E6ABEEC64CC57A Content-Type: text/plain; charset=us-ascii; name="ietf51_rmt_minutes.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ietf51_rmt_minutes.txt" Reliable Mulitcast Transport (rmt) WG 51st IETF, London Minute Taker: Jon Crowcroft, jon@cs.ucl.ac.uk Chairs: Roger Kermode, Roger.Kermode@motorola.com Lorenzo Vicisano, Session 1, Monday ================= 0. Agenda Bashing 1. rccp pi: Mike Luby 2. GRA Update: Tony Speakman 3. TRACK Update: Brian Whettan 4. NORM Update: Brian Adamson 5. NACk format: Brian Adamson 6. FEC BB: Lorenzo Vicisano 1/ Session control protocol discussion Mike Luby -------------------------------------- WG need to consider: style of session, what kind of features will be needed pros/cons of: security/DOS/authentication firewalls RMT support CDI cons why not RTSP/sip or other existing protocol? speakman@mike: given GRA need session (state setup) for RMT - hmmm for multicast in general...could be huge (mmusic) draft to date is v. large do we want to customize? kermode@mike can we scope the work into mmusic? colin perkins@mike outside of mmusic scope luby: not clear its out of scope... braden: session ctl is for state. Is this for transport, or for application? - first is appropriate, rest not. speakman: we need it for transport....(including net. elements)... but what is state? whettan: what is session ctl? e.g. in TRACK its clear (e.g aggregation) what isn't? business aggregation, firewall, etc etc,,, where is the line drawn bradner: where was luby draft...? at all where is cow (given we don't know color to paint it) to early to say what, but could be in scope - hard to say right now... luby: see draft Vicisano: OK get specific and work on plan... Ken Calvert: what about relation to to MSEC WG? answer : TBD 2. GRA Update Tony Speakman --------------------- model GRA is subset of routers predefined filters filter = fid+housekeeping/action/subfilter type e.g . see PGM lengthy example drawn from PGM...see slides for actions, headers, etc GRA schematic header... i-d's, operands (remember filter ("program") is static in current model sequence number (i.e.. other packet fields ) are implicit... need discussion about identifiers - need 1 (no more) to scope rest of action 1/2 the space of i-d's is for static i-d's 1/2 for dynamic i-d's...(i.e re-programmable) Question: how long is id? fixed/var? (var=future) filter function: packet accumulation is precluded by GRA modification is restricted to overwriting GRA fields i.e. v. limited - reformatting (e.g. encapsulation/decapsulation) no no no! operations (e.g. forwarding function:) e.g. multicast - don't change route (graph?) e.g. unicast yep - arbitrary... (w.g. need to get to turning point.) no (NO) packet generation. ctl protocol: in band info ok out of band administration Vicisano: what about transport protocol selector Bormann: isn't it implicit(scoped by net header) Speakman: only needs to be globally unique or scoped by transport no. need to decouple transport... some discussion of protocol v. gsi based de-multiplex (Calvert/Bormann/Vicisano/?)... GSI... GRA header processing...needs some more analysis... GRA header has operands - what and where? (note has a cost..) whettan: ? does this proposal preclude UDP encapsulation? e.g. where GRA header is... speakman answer: could put after transport header (i.e. UDP) e.g. end systems deployment Vicisano: UDP in this use is a hack. its a "net layer" so make EDP an exception.... goal: keep arch spec info make functional spec active... critical: define tight spec for language...flex v. safe... so from the lingo being specified, can take it, and define filter in that mode... an example will be from authors - other folks Alan roll their own... in band, need to propagate neighbor info... have people looking at who can use protocol specs etc... 3/ Track Update Brian Whetten ----------------- This has integration plan (with GRA implicit under NORM) TRACK over UDP/IP for completeness... (not recommended for general deployment) separate document over NORM for example instantiation show: TRACK/NACK/NORM/GRA/ instantiation/ protocol class hierarchy candy: application level confirm delivery; session parameters; statistics aggregation other session stuff? pro: simplicity good; but? (danger - see RTCP/RTSP/SDP etc) Handley: watch definition of TFMCC - generic. vs. specific (e.g. SIGCOMM paper or PGMCC paper? whettan: ? gave generic answer speakman: what do references to NORM mean? whettan: NACKS are part of NORM or PGM, not TRACK... oops = deep sixed on protocol v. class of building block! adamson/speakman/Handley:- arghh:- implicit v. block luby: how does it sit on ALC (instantiation. not building block|) Crowcroft: we have a lot of useful stuff here - need more small group effective understanding Handley: yes speakman: GRA case:- needs more work...NORM/TRACK/GRA - aggregation 4/ NORM BB draft Update Brian Adamson ----------------------- aggregation nack pieces GRA pieces 5/ NACK formats Brian Adamson ------------------- general purpose NACK encapsulation made consistent with ALC relates to FEC technique e.g. abstract data hierarchy nack type - has some semantics... includes something without object, stream, FEC if needed... presents various NACK forms - including "slack nack") composite encapsulation: e.g.of header to show specific segments in stream Is scope of GRA sufficient to parse general nack format? - (e.g. lists of layers, missing segments...) - could use this format for other protocol functions.... such as SACK speakman: problem: distance between GRA specification and NORM spec is too huge can separate function (structure of id can be opaque) e.g. sequence+parity count... Handley: problem is nack expresses too much - nack doesn't need to be globally defined receiver only needs to parse what sender said... can be session depended - so long as sender can say to receiver on a session basis what it meant speakman: can avoid baroque (elaborate) nack... kermode: nice structure - but need something more implementable... adamson need to reach consensus on service model... may need more than just tony and adamson kermode: could be closer than we realize time to move on... speakman: omitting discussion on RTT! debate... need to think about description of packet for local..v. global meaning of packet 6/ FEC BB Lorenzo Vicisano ---------------- removed feedback packet format (NACK) - now in NORM add id and relative small packet FEC code (see i-d) object length question: parameters of FEC etc is it here or somewhere else? Adamson/Calvert: sort of seems ok to put here Luby: could be de trop...sometimes, and other times need it - so it's a higher level function... ... ... ... discussion about LCT and ALC...last call Vicisano & luby both favor that! look forward to tomorrows agenda.. Session #2, Tuesday =================== 0/ Agenda Bashing 1/ Congestion ctl Standardisation Path: Mike Luby 2/ LCT BB Status Report: Mike Luby 3/ ALC BB Update: Mikle Luby 4/ WG overal progress/status report: Roger Kermode 1/ "What is the path for congestion ctl in the WG?" Mike Luby ---------------------------------------------------- We have several proposals for congestion control none going quickly to rfc no quick process to official approval catch 22 - no approval, no working code, no code, no approval proposes a process: perf mustbe shown on basic set of tests....(ns) real world data prove experimemntal rfc provide data to panel for review panel report to RMT then becomes a building block how would we constitute the panel? it's a long process - can we shorten it/streamline it? handley: suspect most people would have (or actually in real cases in front of RMT have already) written a paper for the early stage already doesn't have to be pass/fail so if we do hit a problem, need a path to revision Luby: yes, need to involve rm community Handley: need to avoid deadlock on proposed standard for protocol cross dependance on congestion control bb awaiting approval... and vice versa Kermode: wants to get a fuller set of drafts to cover the ground of RMT work... Vicisano: can stage things - say we use "a" congestion control so there's no link Handley: feedback process for congestion control is often associated with the feedback for reliability, so there's some Luby: not true for all protocols tho... Handley: with layered scheme, have another problem - dont have an idea of how much load router can take in terms of group mgmt load Luby: yes, need to study that for igmp and pim sparse mode stuff Handley: does anyone have a feel for this? Adamson: yes, we've done this! have some feel - more a network than a device problem... Luby: can you publish that (and tools to carry out experiments!) Vicisano: still need to decide how to proceed. room is silent... Kermode: should try to put a proposal together and do this decision/resolution on the list Vicisano: what is wrong with current approach (rough consenss and working code?) Luby: info needed is greater... Handley proposed this process: 1. write i-d to say what CC you use 2. write tech report saying what experiments you've done and results 3. make ns (or similar) scripts available for simulation then put on the list, and see what people say in terms of consensus. Luby: environmental factors should be documented too Kermode: need the caveats listed too, this is listed in the author guidelines draft 2/ LCT BB Status Report Mike Luby ----------------------- draft was updated from v00 to v01 LCT reminder: it's a transort control for a session made out of multiple objects over multiple channels - so CC is over multiple tunnels Allows unicast or multicast (preferred) multirate (preferred) or single rate congestion control Deltas to the i-d are in the draft - simplifications, transport object id more prominent, and variable length now tx & residual time independant new bits in the header: for close of object and close of session More version bits, header extensions clarified....and structure more logical. Changed congestion control so bits not ignored. See i-d for packet header (fixed and optional parts) Future: minor revisions - ready to go to rfc after that. 3/ ALC BB Update Mike Luby ----------------- draft was updated from v00 to v01 used to use UDP transport, now LCT - now allows push service, as well as on demnd - now is a simple combination of LCT, FEC and whatever congestion control building block (BB) we want (eg. LCC BB) See i-d for the packet format Future - minor revisions, then go to RFC. 4/ WG overal progress/status report Roger Kermode ========== Slides of all the i-d docs grouped by PI (Protocol Instantiation) [ see slides ] NORM, TRACK, ALC, Informational, RFC and where they are used We tried something new here (using BBs). How are we doing? - Getting there, with most drafts started. - Haven't got one single full protocol spec submitted quite yet. Need to have all authors talk to each other Proposal: - Interim meeting before next ietf - could be at ACIRI (offerred in next month or so). Suggested New Milestones sep 01 complete autor guidelines dec 01 protocol instants drafts dpme dec 01 congestion control mar 02 remaining PIs done jun 02 PI drafts submit as proposed standard jun 02 congestion control drafts submit as proposed standard Speakman: need emphasis on implementation Handley: yes; need to close gulf between GRA and other pieces (observed gulf in RMT #1) Luby: what does it mean to "implemeny something in a protocol"? Kermode: See what people code when they do it from spec independantly Speakman; problem for people working from drafts in flux Vicisano: so we only need interopability of things at after draft, only at proposed Handley; right we dont need it that strong at this stage (c.f. proposed milestone update above) Speakman: need to see more than one PI use the same BB So for GRA, we have a lot of references - but its only the NORM one We can do now so Adamson & speakman will follow Handley's remark and talk So as a BB tho, the GRA could stay as draft until there's more than one GRA Luby: FEC BB will be used in more than one PI but the timeing is different Speakman: hold up standardisation of BB (keep BB as experimental until we have all BBs used in several PIs. Kermode: so as an example - maybe should have the alc and other pieces go to experimental? Discussion on process for BBs ensued. - Consenss was that that experimental means we have room/flexibility to work on subsequent PIs with change (stress) to BBs as we would expect Vicisano: how does GRA fit the proposed new Milestones? Speakman: ok... --------------E13464A018E6ABEEC64CC57A 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 org:Motorola Labs, Motorola Australia Research Centre;Communications and Networks Laboratory adr:;;Locked Bag 5028;Botany;NSW;1455;Australia version:2.1 email;internet:Roger.Kermode@motorola.com title:Prinicpal Research Engineer / Lab Manager fn:Roger Kermode end:vcard --------------E13464A018E6ABEEC64CC57A-- >From owner-rmt@listserv.lbl.gov Thu Sep 6 23:19:33 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f876JCS13634; Thu, 6 Sep 2001 23:19: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.11.2/8.11.2) with ESMTP id f876JA613630 for ; Thu, 6 Sep 2001 23:19:10 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f876JAD08320 for ; Thu, 6 Sep 2001 23:19:10 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f876J8608314 for ; Thu, 6 Sep 2001 23:19:09 -0700 (PDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id XAA23753 for ; Thu, 6 Sep 2001 23:19:08 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id XAA24989 for ; Thu, 6 Sep 2001 23:10:49 -0700 (MST)] Received: from arc.corp.mot.com ([10.238.80.122]) by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id f876J4A24595 for ; Fri, 7 Sep 2001 16:19:04 +1000 (EST) Message-ID: <3B9866CA.CAD6764B@arc.corp.mot.com> Date: Fri, 07 Sep 2001 16:18:50 +1000 From: Roger Kermode Organization: Motorola X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: Correction: 51st IETF Lond RMT Minutes Content-Type: multipart/mixed; boundary="------------01AAB6FA32A7A39B33294D17" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------01AAB6FA32A7A39B33294D17 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------01AAB6FA32A7A39B33294D17 Content-Type: text/plain; charset=us-ascii; name="ietf51_rmt_minutes.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ietf51_rmt_minutes.txt" Reliable Mulitcast Transport (rmt) WG 51st IETF, London Minute Taker: Jon Crowcroft Chairs: Roger Kermode Lorenzo Vicisano Allison Mankin Session 1, Monday ================= 0. Agenda Bashing 1. rccp pi: Mike Luby 2. GRA Update: Tony Speakman 3. TRACK Update: Brian Whettan 4. NORM Update: Brian Adamson 5. NACk format: Brian Adamson 6. FEC BB: Lorenzo Vicisano 1/ Session control protocol discussion Mike Luby -------------------------------------- WG need to consider: style of session, what kind of features will be needed pros/cons of: security/DOS/authentication firewalls RMT support CDI cons why not RTSP/sip or other existing protocol? speakman@mike: given GRA need session (state setup) for RMT - hmmm for multicast in general...could be huge (mmusic) draft to date is v. large do we want to customize? kermode@mike can we scope the work into mmusic? colin perkins@mike outside of mmusic scope luby: not clear its out of scope... braden: session ctl is for state. Is this for transport, or for application? - first is appropriate, rest not. speakman: we need it for transport....(including net. elements)... but what is state? whettan: what is session ctl? e.g. in TRACK its clear (e.g aggregation) what isn't? business aggregation, firewall, etc etc,,, where is the line drawn bradner: where was luby draft...? at all where is cow (given we don't know color to paint it) to early to say what, but could be in scope - hard to say right now... luby: see draft Vicisano: OK get specific and work on plan... Ken Calvert: what about relation to to MSEC WG? answer : TBD 2. GRA Update Tony Speakman --------------------- model GRA is subset of routers predefined filters filter = fid+housekeeping/action/subfilter type e.g . see PGM lengthy example drawn from PGM...see slides for actions, headers, etc GRA schematic header... i-d's, operands (remember filter ("program") is static in current model sequence number (i.e.. other packet fields ) are implicit... need discussion about identifiers - need 1 (no more) to scope rest of action 1/2 the space of i-d's is for static i-d's 1/2 for dynamic i-d's...(i.e re-programmable) Question: how long is id? fixed/var? (var=future) filter function: packet accumulation is precluded by GRA modification is restricted to overwriting GRA fields i.e. v. limited - reformatting (e.g. encapsulation/decapsulation) no no no! operations (e.g. forwarding function:) e.g. multicast - don't change route (graph?) e.g. unicast yep - arbitrary... (w.g. need to get to turning point.) no (NO) packet generation. ctl protocol: in band info ok out of band administration Vicisano: what about transport protocol selector Bormann: isn't it implicit(scoped by net header) Speakman: only needs to be globally unique or scoped by transport no. need to decouple transport... some discussion of protocol v. gsi based de-multiplex (Calvert/Bormann/Vicisano/?)... GSI... GRA header processing...needs some more analysis... GRA header has operands - what and where? (note has a cost..) whettan: ? does this proposal preclude UDP encapsulation? e.g. where GRA header is... speakman answer: could put after transport header (i.e. UDP) e.g. end systems deployment Vicisano: UDP in this use is a hack. its a "net layer" so make EDP an exception.... goal: keep arch spec info make functional spec active... critical: define tight spec for language...flex v. safe... so from the lingo being specified, can take it, and define filter in that mode... an example will be from authors - other folks Alan roll their own... in band, need to propagate neighbor info... have people looking at who can use protocol specs etc... 3/ Track Update Brian Whetten ----------------- This has integration plan (with GRA implicit under NORM) TRACK over UDP/IP for completeness... (not recommended for general deployment) separate document over NORM for example instantiation show: TRACK/NACK/NORM/GRA/ instantiation/ protocol class hierarchy candy: application level confirm delivery; session parameters; statistics aggregation other session stuff? pro: simplicity good; but? (danger - see RTCP/RTSP/SDP etc) Handley: watch definition of TFMCC - generic. vs. specific (e.g. SIGCOMM paper or PGMCC paper? whettan: ? gave generic answer speakman: what do references to NORM mean? whettan: NACKS are part of NORM or PGM, not TRACK... oops = deep sixed on protocol v. class of building block! adamson/speakman/Handley:- arghh:- implicit v. block luby: how does it sit on ALC (instantiation. not building block|) Crowcroft: we have a lot of useful stuff here - need more small group effective understanding Handley: yes speakman: GRA case:- needs more work...NORM/TRACK/GRA - aggregation 4/ NORM BB draft Update Brian Adamson ----------------------- aggregation nack pieces GRA pieces 5/ NACK formats Brian Adamson ------------------- general purpose NACK encapsulation made consistent with ALC relates to FEC technique e.g. abstract data hierarchy nack type - has some semantics... includes something without object, stream, FEC if needed... presents various NACK forms - including "slack nack") composite encapsulation: e.g.of header to show specific segments in stream Is scope of GRA sufficient to parse general nack format? - (e.g. lists of layers, missing segments...) - could use this format for other protocol functions.... such as SACK speakman: problem: distance between GRA specification and NORM spec is too huge can separate function (structure of id can be opaque) e.g. sequence+parity count... Handley: problem is nack expresses too much - nack doesn't need to be globally defined receiver only needs to parse what sender said... can be session depended - so long as sender can say to receiver on a session basis what it meant speakman: can avoid baroque (elaborate) nack... kermode: nice structure - but need something more implementable... adamson need to reach consensus on service model... may need more than just tony and adamson kermode: could be closer than we realize time to move on... speakman: omitting discussion on RTT! debate... need to think about description of packet for local..v. global meaning of packet 6/ FEC BB Lorenzo Vicisano ---------------- removed feedback packet format (NACK) - now in NORM add id and relative small packet FEC code (see i-d) object length question: parameters of FEC etc is it here or somewhere else? Adamson/Calvert: sort of seems ok to put here Luby: could be de trop...sometimes, and other times need it - so it's a higher level function... ... ... ... discussion about LCT and ALC...last call Vicisano & luby both favor that! look forward to tomorrows agenda.. Session #2, Tuesday =================== 0/ Agenda Bashing 1/ Congestion ctl Standardisation Path: Mike Luby 2/ LCT BB Status Report: Mike Luby 3/ ALC BB Update: Mikle Luby 4/ WG overal progress/status report: Roger Kermode 1/ "What is the path for congestion ctl in the WG?" Mike Luby ---------------------------------------------------- We have several proposals for congestion control none going quickly to rfc no quick process to official approval catch 22 - no approval, no working code, no code, no approval proposes a process: perf mustbe shown on basic set of tests....(ns) real world data prove experimemntal rfc provide data to panel for review panel report to RMT then becomes a building block how would we constitute the panel? it's a long process - can we shorten it/streamline it? handley: suspect most people would have (or actually in real cases in front of RMT have already) written a paper for the early stage already doesn't have to be pass/fail so if we do hit a problem, need a path to revision Luby: yes, need to involve rm community Handley: need to avoid deadlock on proposed standard for protocol cross dependance on congestion control bb awaiting approval... and vice versa Kermode: wants to get a fuller set of drafts to cover the ground of RMT work... Vicisano: can stage things - say we use "a" congestion control so there's no link Handley: feedback process for congestion control is often associated with the feedback for reliability, so there's some Luby: not true for all protocols tho... Handley: with layered scheme, have another problem - dont have an idea of how much load router can take in terms of group mgmt load Luby: yes, need to study that for igmp and pim sparse mode stuff Handley: does anyone have a feel for this? Adamson: yes, we've done this! have some feel - more a network than a device problem... Luby: can you publish that (and tools to carry out experiments!) Vicisano: still need to decide how to proceed. room is silent... Kermode: should try to put a proposal together and do this decision/resolution on the list Vicisano: what is wrong with current approach (rough consenss and working code?) Luby: info needed is greater... Handley proposed this process: 1. write i-d to say what CC you use 2. write tech report saying what experiments you've done and results 3. make ns (or similar) scripts available for simulation then put on the list, and see what people say in terms of consensus. Luby: environmental factors should be documented too Kermode: need the caveats listed too, this is listed in the author guidelines draft 2/ LCT BB Status Report Mike Luby ----------------------- draft was updated from v00 to v01 LCT reminder: it's a transort control for a session made out of multiple objects over multiple channels - so CC is over multiple tunnels Allows unicast or multicast (preferred) multirate (preferred) or single rate congestion control Deltas to the i-d are in the draft - simplifications, transport object id more prominent, and variable length now tx & residual time independant new bits in the header: for close of object and close of session More version bits, header extensions clarified....and structure more logical. Changed congestion control so bits not ignored. See i-d for packet header (fixed and optional parts) Future: minor revisions - ready to go to rfc after that. 3/ ALC BB Update Mike Luby ----------------- draft was updated from v00 to v01 used to use UDP transport, now LCT - now allows push service, as well as on demnd - now is a simple combination of LCT, FEC and whatever congestion control building block (BB) we want (eg. LCC BB) See i-d for the packet format Future - minor revisions, then go to RFC. 4/ WG overal progress/status report Roger Kermode ========== Slides of all the i-d docs grouped by PI (Protocol Instantiation) [ see slides ] NORM, TRACK, ALC, Informational, RFC and where they are used We tried something new here (using BBs). How are we doing? - Getting there, with most drafts started. - Haven't got one single full protocol spec submitted quite yet. Need to have all authors talk to each other Proposal: - Interim meeting before next ietf - could be at ACIRI (offerred in next month or so). Suggested New Milestones sep 01 complete autor guidelines dec 01 protocol instants drafts dpme dec 01 congestion control mar 02 remaining PIs done jun 02 PI drafts submit as proposed standard jun 02 congestion control drafts submit as proposed standard Speakman: need emphasis on implementation Handley: yes; need to close gulf between GRA and other pieces (observed gulf in RMT #1) Luby: what does it mean to "implemeny something in a protocol"? Kermode: See what people code when they do it from spec independantly Speakman; problem for people working from drafts in flux Vicisano: so we only need interopability of things at after draft, only at proposed Handley; right we dont need it that strong at this stage (c.f. proposed milestone update above) Speakman: need to see more than one PI use the same BB So for GRA, we have a lot of references - but its only the NORM one We can do now so Adamson & speakman will follow Handley's remark and talk So as a BB tho, the GRA could stay as draft until there's more than one GRA Luby: FEC BB will be used in more than one PI but the timeing is different Speakman: hold up standardisation of BB (keep BB as experimental until we have all BBs used in several PIs. Kermode: so as an example - maybe should have the alc and other pieces go to experimental? Discussion on process for BBs ensued. - Consenss was that that experimental means we have room/flexibility to work on subsequent PIs with change (stress) to BBs as we would expect Vicisano: how does GRA fit the proposed new Milestones? Speakman: ok... --------------01AAB6FA32A7A39B33294D17 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 org:Motorola Labs, Motorola Australia Research Centre;Communications and Networks Laboratory adr:;;Locked Bag 5028;Botany;NSW;1455;Australia version:2.1 email;internet:Roger.Kermode@motorola.com title:Prinicpal Research Engineer / Lab Manager fn:Roger Kermode end:vcard --------------01AAB6FA32A7A39B33294D17-- >From owner-rmt@listserv.lbl.gov Sun Sep 9 15:18:58 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f89MEiM15887; Sun, 9 Sep 2001 15:14: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.11.2/8.11.2) with ESMTP id f89MEgq15883 for ; Sun, 9 Sep 2001 15:14:42 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f89MEgc26087 for ; Sun, 9 Sep 2001 15:14:42 -0700 (PDT) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f89MEf626084 for ; Sun, 9 Sep 2001 15:14:41 -0700 (PDT) Received: from localhost (speakman@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA07933; Sun, 9 Sep 2001 15:14:35 -0700 (PDT) Message-Id: <200109092214.PAA07933@cisco.com> To: Roger Kermode cc: rmt-list , Scott Bradner Subject: Re: RMT Milestone update: DATE REQUEST Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Date: Sun, 09 Sep 2001 15:14:35 -0700 From: Tony Speakman Sender: owner-rmt@lbl.gov Precedence: bulk Hmmm, I don't see any building block drafts, or are those what you call the CC drafts? In any case, I think it makes sense to publish from the bottom up, i.e., starting with building block drafts and let them mature a bit before publishing the PIs which are supposed to be constructed from those BBs. (I think I made the same point in the WG, and the response was that experimentals are revisable, so publication order doesn't matter, which I was only weakly convinced of). Are you going to reflect the discussion we had in London about the requirements on these drafts, specifically that for the PIs there be working implementations, and for the CCs there be simulation results and applicability statements? On the topic of GRA, we described three documents all of which I think are "building blocks": a filter language spec, filter definition specs, and a GRA protocol spec. Swapna and I are working on the latter and expect to present it in December with the goal of prototyping an implementation and revising the draft for last call by March. To write filter specs, we need the filter language spec which Ken Calvert is drafting. So I think your list would make more sense if it named specific drafts, the requirements on them, and any publication dependencies. Tony S > Suggested Milestones > -------------------- > > Sep 01 Complete Author Guidelines draft WGLC > submit for publication as informational. > > Dec 01 Protocol instantiations drafts submitted > for publication as experimental. Which ones? > > Dec 01 Congestion control drafts submitted for > publication as experimental. > > Mar 02 Remaining Protocol instantiations drafts > submitted for publication as experimental. > Which ones? > > Jun 02 Protocol instantiations drafts submitted > for publication as proposed standard. > > Jun 02 Congestion control drafts submitted for > publication as proposed standard. >From owner-rmt@listserv.lbl.gov Fri Sep 21 06:48:23 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f8LDesv27455; Fri, 21 Sep 2001 06:40:54 -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.11.2/8.11.2) with ESMTP id f8LDerq27451 for ; Fri, 21 Sep 2001 06:40:53 -0700 (PDT) Received: from localhost (root@localhost) by postal1.lbl.gov (8.11.2/8.11.2) with SMTP id f8LDer618755 for ; Fri, 21 Sep 2001 06:40:53 -0700 (PDT) Date: Fri, 21 Sep 2001 06:40:53 -0700 (PDT) Message-Id: <200109211340.f8LDer618755@postal1.lbl.gov> From: VirusWall@lbl.gov To: rmt@listserv.lbl.gov Subject: Virus Alert Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk This is an automated message from the LBNL VirusWall. The mail message you recently received from: jesus@prodigy.net.mx which included the file: Doc1.doc.bat contained the virus: TROJ_SIRCAM.A. PLEASE NOTE: 1. The virus has been REMOVED from the email message by the LBNL VirusWall and will NOT INFECT your computer. 2. It is SAFE to read the message and open the attachment, though you should always use caution when opening attachments from people you do not know. 3. You do not need to notify anyone that you received this message. For more information take a look at our virus protection web page: http://www.lbl.gov/ITSD/Security/resources/ If you have any questions, please contact the LBNL Help Desk at http://www.lbl.gov/help/, or 510-486-4357. Thanks, The VirusWall Lawrence Berkeley National Laboratory >From owner-rmt@listserv.lbl.gov Fri Sep 21 06:48:23 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f8LDeml27449; Fri, 21 Sep 2001 06:40: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.11.2/8.11.2) with ESMTP id f8LDekq27445 for ; Fri, 21 Sep 2001 06:40:46 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f8LDejo18716 for ; Fri, 21 Sep 2001 06:40:45 -0700 (PDT) Received: from aykran.upc.es (aykran.upc.es [147.83.21.28]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f8LDeg618713 for ; Fri, 21 Sep 2001 06:40:42 -0700 (PDT) Message-Id: <200109211340.f8LDeg618713@SpamWall.lbl.gov> Received: from pcgcr26.upc.es ([147.83.105.158]) by aykran.upc.es with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id T247H2HF; Fri, 21 Sep 2001 15:36:36 +0200 From: "jesus" To: rmt@lbl.gov Subject: Doc1 date: Fri, 21 Sep 2001 15:37:47 +0200 MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-Type: multipart/mixed; boundary="----42E8350B_Outlook_Express_message_boundary" Content-Disposition: Multipart message Sender: owner-rmt@lbl.gov Precedence: bulk ------42E8350B_Outlook_Express_message_boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) Found virus TROJ_SIRCAM.A in file Doc1.doc.bat The file e/iscan/virus/virXHAdNaGdK is moved to the configured virus directory. ********************************************************* ------42E8350B_Outlook_Express_message_boundary Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: message text Hola como estas =3F Te mando este archivo para que me des tu punto de vista Nos vemos pronto=2C gracias=2E ------42E8350B_Outlook_Express_message_boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) Doc1.doc.bat is removed from here because it contains a virus. ********************************************************* ------42E8350B_Outlook_Express_message_boundary ------42E8350B_Outlook_Express_message_boundary-- >From owner-rmt@listserv.lbl.gov Mon Sep 24 02:43:20 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f8O9eBu02793; Mon, 24 Sep 2001 02:40:11 -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.11.2/8.11.2) with ESMTP id f8O9eAq02789 for ; Mon, 24 Sep 2001 02:40:10 -0700 (PDT) Received: from localhost (root@localhost) by postal1.lbl.gov (8.11.2/8.11.2) with SMTP id f8O9e9h05162 for ; Mon, 24 Sep 2001 02:40:09 -0700 (PDT) Date: Mon, 24 Sep 2001 02:40:09 -0700 (PDT) Message-Id: <200109240940.f8O9e9h05162@postal1.lbl.gov> From: VirusWall@lbl.gov To: rmt@listserv.lbl.gov Subject: Virus Alert Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk This is an automated message from the LBNL VirusWall. The mail message you recently received from: jesus@prodigy.net.mx which included the file: Doc2.doc.com contained the virus: TROJ_SIRCAM.A. PLEASE NOTE: 1. The virus has been REMOVED from the email message by the LBNL VirusWall and will NOT INFECT your computer. 2. It is SAFE to read the message and open the attachment, though you should always use caution when opening attachments from people you do not know. 3. You do not need to notify anyone that you received this message. For more information take a look at our virus protection web page: http://www.lbl.gov/ITSD/Security/resources/ If you have any questions, please contact the LBNL Help Desk at http://www.lbl.gov/help/, or 510-486-4357. Thanks, The VirusWall Lawrence Berkeley National Laboratory >From owner-rmt@listserv.lbl.gov Mon Sep 24 02:43:20 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f8O9e9t02787; Mon, 24 Sep 2001 02:40: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.11.2/8.11.2) with ESMTP id f8O9e8q02783 for ; Mon, 24 Sep 2001 02:40:08 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f8O9e7u05155 for ; Mon, 24 Sep 2001 02:40:07 -0700 (PDT) Received: from aykran.upc.es (aykran.upc.es [147.83.21.28]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f8O9e3605152 for ; Mon, 24 Sep 2001 02:40:04 -0700 (PDT) Message-Id: <200109240940.f8O9e3605152@SpamWall.lbl.gov> Received: from pcgcr26.upc.es ([147.83.105.158]) by aykran.upc.es with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id T247HP8M; Mon, 24 Sep 2001 11:36:00 +0200 From: "jesus" To: rmt@lbl.gov Subject: Doc2 date: Mon, 24 Sep 2001 11:36:51 +0200 MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-Type: multipart/mixed; boundary="----327F0ECE_Outlook_Express_message_boundary" Content-Disposition: Multipart message Sender: owner-rmt@lbl.gov Precedence: bulk ------327F0ECE_Outlook_Express_message_boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) Found virus TROJ_SIRCAM.A in file Doc2.doc.com The file e/iscan/virus/virWHD_Ua4DS is moved to the configured virus directory. ********************************************************* ------327F0ECE_Outlook_Express_message_boundary Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: message text Hola como estas =3F Te mando este archivo para que me des tu punto de vista Nos vemos pronto=2C gracias=2E ------327F0ECE_Outlook_Express_message_boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on the network) Doc2.doc.com is removed from here because it contains a virus. ********************************************************* ------327F0ECE_Outlook_Express_message_boundary ------327F0ECE_Outlook_Express_message_boundary-- >From owner-rmt@listserv.lbl.gov Wed Sep 26 21:42:48 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f8R4SJL12639; Wed, 26 Sep 2001 21:28:19 -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.11.2/8.11.2) with ESMTP id f8R4SHq12635 for ; Wed, 26 Sep 2001 21:28:17 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f8R4SHs27683 for ; Wed, 26 Sep 2001 21:28:17 -0700 (PDT) Received: from chapweske.com (nic-41-c31-11.mn.mediaone.net [66.41.31.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f8R4SG627680 for ; Wed, 26 Sep 2001 21:28:16 -0700 (PDT) Received: (qmail 14179 invoked from network); 26 Sep 2001 23:44:40 -0000 Received: from unknown (HELO chapweske.com) (192.168.0.2) by 192.168.0.3 with SMTP; 26 Sep 2001 23:44:40 -0000 Message-ID: <3BB2AABE.8070006@chapweske.com> Date: Wed, 26 Sep 2001 23:27:42 -0500 From: Justin Chapweske User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: rmt@lbl.gov Subject: Java FEC Library Changes Maintainers Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk The Java Forward Error Correction (FEC) Library has grown beyond its Swarmcast beginnings and is now being maintained by Onion Networks (http://onionnetworks.com/). FEC is an essential component of any reliable multicast solution, and this library is the fastest and most mature Java solution available. It features: * Fast multi-threaded I/O routines for encoding and decoding files * Native linux, solaris, and win32 accellerators with pure Java fallback * Automatic deployment of native accellerators * FEC codec plugin interface * Cryptograhic hashes can be used for checking file integrity The library is based on Luigi Rizzo's original C FEC library, and is under a BSD-style license. The library can be found at http://onionnetworks.com/components.html and commercial support from Onion Networks is available. Thanks, -- Justin Chapweske, Onion Networks http://onionnetworks.com/ >From owner-rmt@listserv.lbl.gov Mon Oct 1 03:26:13 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f91ALt917877; Mon, 1 Oct 2001 03:21:55 -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.11.2/8.11.2) with ESMTP id f91ALrq17873 for ; Mon, 1 Oct 2001 03:21:53 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f91ALr423103 for ; Mon, 1 Oct 2001 03:21:53 -0700 (PDT) Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f91ALp623098 for ; Mon, 1 Oct 2001 03:21:52 -0700 (PDT) Received: from cbtlipnt01.btlabs.bt.co.uk by gandalf (local) with ESMTP; Mon, 1 Oct 2001 11:21:01 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Mon, 1 Oct 2001 11:20:57 +0100 Message-ID: From: maziar.nekovee@bt.com To: rmt@lbl.gov Subject: measuremets/simulations of delay times Date: Mon, 1 Oct 2001 11:17:38 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: owner-rmt@lbl.gov Precedence: bulk Dear all I am interested to find out about any available measurements/simulation results for delay times (and their statistical distributions) in reliable multicast (for large groups). I'd be grateful for any help. Best regards Maziar Nekovee ---------------------------- Dr Maziar Nekovee Complexity Research Group Admin2, pp5 BT Laboratories Martlesham Heath, Ipswich Suffolk IP5 3RE, UK tel: +44-1473 645470 fax: +44-1473-647410 web: www.labs.bt.com/projects/complexity/nekovee/ >From owner-rmt@listserv.lbl.gov Mon Oct 1 10:05:12 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f91H2iZ28772; Mon, 1 Oct 2001 10:02: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.11.2/8.11.2) with ESMTP id f91H2hq28768 for ; Mon, 1 Oct 2001 10:02:43 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f91H2g720953 for ; Mon, 1 Oct 2001 10:02:42 -0700 (PDT) Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f91H2g620943 for ; Mon, 1 Oct 2001 10:02:42 -0700 (PDT) Received: (qmail 3341 invoked from network); 1 Oct 2001 16:59:53 -0000 Received: from mail.intranet (10.1.1.37) by mx.digitalfountain.com with SMTP; 1 Oct 2001 16:59:53 -0000 Received: from mikedell (pptp-10-1-129-51.intranet [10.1.129.51]) by mail.intranet (8.9.3/8.9.3) with SMTP id JAA10225; Mon, 1 Oct 2001 09:59:27 -0700 X-Authentication-Warning: mail.intranet: Host pptp-10-1-129-51.intranet [10.1.129.51] claimed to be mikedell From: "Michael Luby" To: , Subject: RE: measuremets/simulations of delay times Date: Mon, 1 Oct 2001 09:59:59 -0700 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Sender: owner-rmt@lbl.gov Precedence: bulk How do you define "delay time"? -----Original Message----- From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of maziar.nekovee@bt.com Sent: Monday, October 01, 2001 3:18 AM To: rmt@lbl.gov Subject: measuremets/simulations of delay times Dear all I am interested to find out about any available measurements/simulation results for delay times (and their statistical distributions) in reliable multicast (for large groups). I'd be grateful for any help. Best regards Maziar Nekovee ---------------------------- Dr Maziar Nekovee Complexity Research Group Admin2, pp5 BT Laboratories Martlesham Heath, Ipswich Suffolk IP5 3RE, UK tel: +44-1473 645470 fax: +44-1473-647410 web: www.labs.bt.com/projects/complexity/nekovee/ >From owner-rmt@listserv.lbl.gov Fri Oct 5 19:33:59 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f962TuA27590; Fri, 5 Oct 2001 19:29: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.11.2/8.11.2) with ESMTP id f962Tsp27586 for ; Fri, 5 Oct 2001 19:29:54 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f962Tsj25041 for ; Fri, 5 Oct 2001 19:29:54 -0700 (PDT) Received: from chapweske.com (nic-41-c31-11.mn.mediaone.net [66.41.31.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f962Tq625036 for ; Fri, 5 Oct 2001 19:29:53 -0700 (PDT) Received: (qmail 22056 invoked from network); 6 Oct 2001 02:45:12 -0000 Received: from unknown (HELO onionnetworks.com) (192.168.0.2) by 192.168.0.3 with SMTP; 6 Oct 2001 02:45:12 -0000 Message-ID: <3BBE6C2C.70505@onionnetworks.com> Date: Fri, 05 Oct 2001 21:27:56 -0500 From: Justin Chapweske User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: rmt@lbl.gov Subject: ALC Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Hey gang, I just read the new ALC spec and it seems to be a vacuous document to me. What value does this protocol add beyond what the LCT protocol provides? Thanks, -- Justin Chapweske, Onion Networks http://onionnetworks.com/ >From owner-rmt@listserv.lbl.gov Fri Oct 5 19:52:49 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f962p7o27695; Fri, 5 Oct 2001 19:51:07 -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.11.2/8.11.2) with ESMTP id f962p6p27691 for ; Fri, 5 Oct 2001 19:51:06 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f962p5u26619 for ; Fri, 5 Oct 2001 19:51:05 -0700 (PDT) Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f962p4626616 for ; Fri, 5 Oct 2001 19:51:04 -0700 (PDT) Received: (qmail 18792 invoked from network); 6 Oct 2001 02:50:58 -0000 Received: from mail.intranet (10.1.1.37) by mx.digitalfountain.com with SMTP; 6 Oct 2001 02:50:58 -0000 Received: from mikedell (pptp-10-1-129-51.intranet [10.1.129.51]) by mail.intranet (8.9.3/8.9.3) with SMTP id TAA23859; Fri, 5 Oct 2001 19:50:31 -0700 X-Authentication-Warning: mail.intranet: Host pptp-10-1-129-51.intranet [10.1.129.51] claimed to be mikedell From: "Michael Luby" To: "Justin Chapweske" Cc: "Michael Luby" , Subject: RE: ALC Date: Fri, 5 Oct 2001 19:51:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3BBE6C2C.70505@onionnetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-rmt@lbl.gov Precedence: bulk Justin, LCT is not a protocol, it is a building block that could be used to build any number of other protocols as a building block. And, it can be used as the general session framework for a variety of other protocols, including but not limited to on-demand streaming, reliable content delivery of objects and live streaming. Each such complete protocol will potentially use a different reliability building block, and a different congestion control building block, in addition to LCT. ALC is a protocol instantiation, that in particular is a simple combination of the LCT building block as the general session framework, FEC with no feedback to the sender as the reliability building block, and a multi-rate building block using multiple channels that is TCP-friendly and requires no feedback to the sender as the congestion control (yet to be completely specified). Furthermore, ALC is specifically targeted for reliable content delivery of objects. You may call ALC vacuous. I call it a good combination of three well-designed building blocks that fit nicely together, as they are supposed to. Mike -----Original Message----- From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Justin Chapweske Sent: Friday, October 05, 2001 7:28 PM To: rmt@lbl.gov Subject: ALC Hey gang, I just read the new ALC spec and it seems to be a vacuous document to me. What value does this protocol add beyond what the LCT protocol provides? Thanks, -- Justin Chapweske, Onion Networks http://onionnetworks.com/ >From owner-rmt@listserv.lbl.gov Fri Oct 5 21:19:50 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f964Hsh28212; Fri, 5 Oct 2001 21:17:54 -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.11.2/8.11.2) with ESMTP id f964Hrp28208 for ; Fri, 5 Oct 2001 21:17:53 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f964HqC03628 for ; Fri, 5 Oct 2001 21:17:52 -0700 (PDT) Received: from chapweske.com (nic-41-c31-11.mn.mediaone.net [66.41.31.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f964Hq603625 for ; Fri, 5 Oct 2001 21:17:52 -0700 (PDT) Received: (qmail 22284 invoked from network); 6 Oct 2001 04:33:11 -0000 Received: from unknown (HELO onionnetworks.com) (192.168.0.2) by 192.168.0.3 with SMTP; 6 Oct 2001 04:33:11 -0000 Message-ID: <3BBE857C.8030304@onionnetworks.com> Date: Fri, 05 Oct 2001 23:15:56 -0500 From: Justin Chapweske User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: rmt@lbl.gov Subject: Re: ALC References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Michael, Thanks for the clarification. I think you guys have created here, some of the best designed protocols the IETF has to offer. What tripped me up is that ALC used to be a building block but has since been turned into an instantiation. Thus my usage of 'vacuous' was simply personal contextual baggage and meant no offense. Thanks, -- Justin Chapweske, Onion Networks http://onionnetworks.com/ Michael Luby wrote: >Justin, > >LCT is not a protocol, it is a building block that could be used to build >any number of other protocols as a building block. And, it can be used as >the general session framework for a variety of other protocols, including >but not limited to on-demand streaming, reliable content delivery of objects >and live streaming. Each such complete protocol will potentially use a >different reliability building block, and a different congestion control >building block, in addition to LCT. > >ALC is a protocol instantiation, that in particular is a simple combination >of the LCT building block as the general session framework, FEC with no >feedback to the sender as the reliability building block, and a multi-rate >building block using multiple channels that is TCP-friendly and requires no >feedback to the sender as the congestion control (yet to be completely >specified). Furthermore, ALC is specifically targeted for reliable content >delivery of objects. > >You may call ALC vacuous. I call it a good combination of three >well-designed building blocks that fit nicely together, as they are supposed >to. > >Mike > >-----Original Message----- >From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Justin >Chapweske >Sent: Friday, October 05, 2001 7:28 PM >To: rmt@lbl.gov >Subject: ALC > > >Hey gang, > >I just read the new ALC spec and it seems to be a vacuous document to >me. What value does this protocol add beyond what the LCT protocol >provides? > >Thanks, > >-- >Justin Chapweske, Onion Networks >http://onionnetworks.com/ > >From owner-rmt@listserv.lbl.gov Sat Oct 6 21:05:10 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f97412S17716; Sat, 6 Oct 2001 21:01:02 -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.11.2/8.11.2) with ESMTP id f97410p17707 for ; Sat, 6 Oct 2001 21:01:00 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9740xj11704 for ; Sat, 6 Oct 2001 21:00:59 -0700 (PDT) Received: from imses2.ims-cpm.ru (imses2.ims-cpm.ru [195.16.59.38]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9740w611700 for ; Sat, 6 Oct 2001 21:00:58 -0700 (PDT) Received: from unspecified.host (ims-srv.84.quantum.ru [213.170.84.146]) by imses2.ims-cpm.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 4JQXLQQB; Sun, 7 Oct 2001 07:42:31 +0400 Received: from 168.191.177.137 ([168.191.177.137]) by 213.170.84.146 (WinRoute Pro 4.1.25) with SMTP; Sun, 7 Oct 2001 07:41:03 +0400 Message-ID: <000041f56a5b$00001c05$00001e51@> To: From: gayle65@aemail4u.com Subject: Tired of Outrageous LD bills-2.9 cents per min! Date: Sat, 06 Oct 2001 22:22:50 -0500 X-Priority: 1 X-MSMail-Priority: High Sender: owner-rmt@lbl.gov Precedence: bulk * * * * * * * For The First Time in Telecom History * * * * * * * * * * * * * * You Can Have Your Cake and Eat It Too! * * * * * * * * * * * * * * * * * The Best of Both Worlds! * * * * * * * * * * * * * * * * * * 2.9 Cents per Minute Long Distance * * * * * * * * * OR * * * * * * * UNLIMITED FLAT RATE LONG DISTANCE * * * * * * * * ******************** YOU MAKE THE CALL! ********************** No Credit Check! No Contracts or long Term Obligations! No More "Local Long Distance" Calling! No Fine Print, or Hidden Fees! No Changing Carriers! Just TALK as much as you want with these incredible low rates 2.9 cents a minute or Flate Rate * * * * * * * * * * * ABSOLUTELY NO GIMMICKS * * * * * * * * * * * * * * * * * * * * * ACTIVATION IN 48 HOURS * * * * * * * * * * FOR MORE INFORMATION: on our 2.9 cents a minute Long Distance OR our Unlimited Long Distance click on the hyperlink below and mailto: bestinflatrate@yahoo.com.=Type more info in the subjct box. To unsubscribe:ilike2_9_ld@yahoo.com >From owner-rmt@listserv.lbl.gov Wed Oct 10 00:18:30 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9A7ECP20652; Wed, 10 Oct 2001 00:14: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.11.2/8.11.2) with ESMTP id f9A7EAp20648 for ; Wed, 10 Oct 2001 00:14:10 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9A7EA429881 for ; Wed, 10 Oct 2001 00:14:10 -0700 (PDT) Received: from chapweske.com (nic-41-c31-11.mn.mediaone.net [66.41.31.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9A7E9729878 for ; Wed, 10 Oct 2001 00:14:09 -0700 (PDT) Received: (qmail 32758 invoked from network); 10 Oct 2001 06:41:13 -0000 Received: from unknown (HELO onionnetworks.com) (192.168.0.2) by 192.168.0.3 with SMTP; 10 Oct 2001 06:41:13 -0000 Message-ID: <3BC3E941.3010705@onionnetworks.com> Date: Wed, 10 Oct 2001 01:22:57 -0500 From: Justin Chapweske User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: rmt@lbl.gov Subject: Last Header Extension Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Hello, What benefit does the Last Header Extension bit add when one can use the HDR_LEN field to determine when the header extensions are done? It might be nice to remove the Last Header Extension bit and make Header Extension Type an 8 bit field. Its just a suggestion, I don't feel strongly about it one way or the other. Thanks, -- Justin Chapweske, Onion Networks http://onionnetworks.com/ >From owner-rmt@listserv.lbl.gov Wed Oct 10 12:00:45 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9AIwC000105; Wed, 10 Oct 2001 11:58: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.11.2/8.11.2) with ESMTP id f9AIwAp00101 for ; Wed, 10 Oct 2001 11:58:10 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9AIw9O12920 for ; Wed, 10 Oct 2001 11:58:09 -0700 (PDT) Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9AIw8712908 for ; Wed, 10 Oct 2001 11:58:08 -0700 (PDT) Received: (qmail 22911 invoked from network); 10 Oct 2001 18:58:03 -0000 Received: from mail.intranet (10.1.1.37) by mx.digitalfountain.com with SMTP; 10 Oct 2001 18:58:03 -0000 Received: from bozz (dhcp-10-1-2-180.intranet [10.1.2.180]) by mail.intranet (8.9.3/8.9.3) with SMTP id LAA07623; Wed, 10 Oct 2001 11:57:36 -0700 X-Authentication-Warning: mail.intranet: Host dhcp-10-1-2-180.intranet [10.1.2.180] claimed to be bozz From: "Michael Luby" To: "Justin Chapweske" , Cc: "Michael Luby" Subject: RE: Last Header Extension Date: Wed, 10 Oct 2001 12:03:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3BC3E941.3010705@onionnetworks.com> Sender: owner-rmt@lbl.gov Precedence: bulk Justin, Interesting suggestion (Assuming you are talking about the LCT BB). Yes, there are two ways to determine the end of the header right now, one through the "next extension header exists bit" and one through the "total length of the header field". Not clear we need both. I'd be happy with what you suggest. Mike -----Original Message----- From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Justin Chapweske Sent: Tuesday, October 09, 2001 11:23 PM To: rmt@lbl.gov Subject: Last Header Extension Hello, What benefit does the Last Header Extension bit add when one can use the HDR_LEN field to determine when the header extensions are done? It might be nice to remove the Last Header Extension bit and make Header Extension Type an 8 bit field. Its just a suggestion, I don't feel strongly about it one way or the other. Thanks, -- Justin Chapweske, Onion Networks http://onionnetworks.com/ >From owner-rmt@listserv.lbl.gov Wed Oct 10 15:36:39 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9AMYL110727; Wed, 10 Oct 2001 15:34:21 -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.11.2/8.11.2) with ESMTP id f9AMYKp10723 for ; Wed, 10 Oct 2001 15:34:20 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9AMYJB19133 for ; Wed, 10 Oct 2001 15:34:19 -0700 (PDT) Received: from chapweske.com (nic-41-c31-11.mn.mediaone.net [66.41.31.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9AMYI719128 for ; Wed, 10 Oct 2001 15:34:18 -0700 (PDT) Received: (qmail 1540 invoked from network); 10 Oct 2001 22:50:03 -0000 Received: from unknown (HELO onionnetworks.com) (192.168.0.2) by 192.168.0.3 with SMTP; 10 Oct 2001 22:50:03 -0000 Message-ID: <3BC4CC4C.60101@onionnetworks.com> Date: Wed, 10 Oct 2001 17:31:40 -0500 From: Justin Chapweske User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: rmt@lbl.gov Subject: LCT Header Extensions Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk From LCT: "If present, Header Extensions MUST be processed to ensure that they are recognized before performing any congestion control procedure or otherwise accepting an LCT packet. LCT packets with unrecognised Header Extensions MUST be discarded by the receiving agent, hence the expected use of extensions SHOULD be signaled out-of-band before session startup." This concerns me because it means there is no mechanism for forward compatibility between implementations/versions. I would like to request that a Header Extension be specified for vendor-specific headers, perhaps as follows: EXT_VEND = 3 Vendor-specific Extension This extension allows vendors to add their own extensions in a backwords compatible fashion. Recievers MUST ignore any vender-specific extensions that they don't understand. A suggested format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| HET = 3 | HEL | VEND_CODE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Vender-specific Extension Content . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor Code (VEND_CODE): 16 bits Identifies which vendor this extension is from. The Vendor code determines how the vendor-specific extension content will be parsed. It is RECOMMENDED that vendors use an extensible format for their own extensions so that they only need a single vendor code. Thanks, -- Justin Chapweske, Onion Networks http://onionnetworks.com/ >From owner-rmt@listserv.lbl.gov Wed Oct 10 17:40:13 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9B0avE16914; Wed, 10 Oct 2001 17:36:57 -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.11.2/8.11.2) with ESMTP id f9B0atp16910 for ; Wed, 10 Oct 2001 17:36:55 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9B0at503591 for ; Wed, 10 Oct 2001 17:36:55 -0700 (PDT) Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9B0as703586 for ; Wed, 10 Oct 2001 17:36:54 -0700 (PDT) Received: (qmail 25783 invoked from network); 11 Oct 2001 00:36:49 -0000 Received: from mail.intranet (10.1.1.37) by mx.digitalfountain.com with SMTP; 11 Oct 2001 00:36:49 -0000 Received: from bozz (dhcp-10-1-2-180.intranet [10.1.2.180]) by mail.intranet (8.9.3/8.9.3) with SMTP id RAA30498; Wed, 10 Oct 2001 17:36:23 -0700 X-Authentication-Warning: mail.intranet: Host dhcp-10-1-2-180.intranet [10.1.2.180] claimed to be bozz From: "Michael Luby" To: "Justin Chapweske" , Cc: "Michael Luby" Subject: RE: LCT Header Extensions Date: Wed, 10 Oct 2001 17:42:16 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3BC4CC4C.60101@onionnetworks.com> Importance: Normal Sender: owner-rmt@lbl.gov Precedence: bulk Justin, I agree that it is not as clearly written as it should have been, and the writing needs to be changed. My proposal is written below. Before getting to that, the problems that I see with your proposal are that: (1) Your suggested format is quite complicated (embedding fields within fields), and wastes a lot of precious packet space. (2) It would most likely require vendors to register their vender code with IANA, and the IANA registry would have to be set up for this, etc., and this is an extra complication. The solution I propose is to leave everything the way it is right now (although I do think it is good to get rid of the header extension bit X in the first word of the header, and to get rid of the L in each header extension, as you suggested in an earlier email), but to change the language you called out to the following: "The expected use of Header Extensions, the list of Header Extension Types and how to process the corresponding Header Extension SHOULD be signaled out-of-band before session startup. If out-of-band signaling is used to communicate the possible Header Extensions Types to be used in the session, then Header Extension Types that are not crucial to the behavior of the receiving agent MAY be designated as optional. If the receiving agent does not recognize a Header Extension Type, or if the receiving agent does not know how to process a Header Extension with a recognized Header Extension Type that has not been designated as optional, then the LCT packet MUST be discarded without further processing. The receiving agent MUST process a Header Extension unless its Header Extension Type is designated as optional." -----Original Message----- From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Justin Chapweske Sent: Wednesday, October 10, 2001 3:32 PM To: rmt@lbl.gov Subject: LCT Header Extensions From LCT: "If present, Header Extensions MUST be processed to ensure that they are recognized before performing any congestion control procedure or otherwise accepting an LCT packet. LCT packets with unrecognised Header Extensions MUST be discarded by the receiving agent, hence the expected use of extensions SHOULD be signaled out-of-band before session startup." This concerns me because it means there is no mechanism for forward compatibility between implementations/versions. I would like to request that a Header Extension be specified for vendor-specific headers, perhaps as follows: EXT_VEND = 3 Vendor-specific Extension This extension allows vendors to add their own extensions in a backwords compatible fashion. Recievers MUST ignore any vender-specific extensions that they don't understand. A suggested format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| HET = 3 | HEL | VEND_CODE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Vender-specific Extension Content . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor Code (VEND_CODE): 16 bits Identifies which vendor this extension is from. The Vendor code determines how the vendor-specific extension content will be parsed. It is RECOMMENDED that vendors use an extensible format for their own extensions so that they only need a single vendor code. Thanks, -- Justin Chapweske, Onion Networks http://onionnetworks.com/ >From owner-rmt@listserv.lbl.gov Wed Oct 10 19:52:15 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9B2eXp22209; Wed, 10 Oct 2001 19:40:33 -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.11.2/8.11.2) with ESMTP id f9B2eVp22205 for ; Wed, 10 Oct 2001 19:40:31 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9B2eVR24954 for ; Wed, 10 Oct 2001 19:40:31 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9B2eU724951 for ; Wed, 10 Oct 2001 19:40:30 -0700 (PDT) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9B2eQk17791; Wed, 10 Oct 2001 19:40:26 -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 TAA17619; Wed, 10 Oct 2001 19:40:24 -0700 (PDT) Message-Id: <200110110240.TAA17619@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI] To: "Michael Luby" cc: "Justin Chapweske" , rmt@lbl.gov Subject: Re: LCT Header Extensions In-Reply-To: Your message of "Wed, 10 Oct 2001 17:42:16 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Oct 2001 19:40:24 -0700 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk Mike, Justin, Given that here we are defining a packet format (or at least a piece of it), I think we should be able to interpret all its fields, and define some sort of behavior for them, at least as far as LCT is concerned. If nothing else, this would allow us to debug the content of the LCT header (I'm thinking of tools like "tcpdump"). For this reason I don't like the idea of signaling Header Extension Types out of band. On the other hand it is nice to be able to add backward-compatible extensions, to refine the protocol without changing the version number. My proposal is: "All header extensions that are not understood can be safely ignored by the receiver. This allows to introduce backward-compatible enhancement to the protocol without changing the version number. Non backward-compatible header extensions CANNOT be introduced without changing the protocol version number." Lorenzo Note that in multicast, unlike unicast, the sender may not want/be able to negotiate protocol capabilities, either because the receiver population is heterogeneous or because there is no feedback channel. My proposal is to use the 1st bit of the header extension (the one that we were using for "L") to signal whether the header extention can be safely ignored, if not understood. As now we have 8 bits for the type (we got rid of "L"), we reserve types 128 through 254 for backward-compatible header extension, i.e. extension that will be ignored if not understood. Note that LCVv2 can narrow the subset of backward-compatible extension, if it needs to and if it hasn't used all of it already In message , "Michael Luby" writes: > Justin, > > I agree that it is not as clearly written as it should have been, and the > writing needs to be changed. My proposal is written below. Before getting > to that, the problems that I see with your proposal are that: > (1) Your suggested format is quite complicated (embedding fields within > fields), and wastes a lot of precious packet space. > (2) It would most likely require vendors to register their vender code with > IANA, and the IANA registry would have to be set up for this, etc., and this > is an extra complication. > > The solution I propose is to leave everything the way it is right now > (although I do think it is good to get rid of the header extension bit X in > the first word of the header, and to get rid of the L in each header > extension, as you suggested in an earlier email), but to change the language > you called out to the following: > > "The expected use of Header Extensions, the list of Header Extension Types > and > how to process the corresponding Header Extension SHOULD be signaled > out-of-band > before session startup. If out-of-band signaling is used to communicate the > possible Header Extensions Types to be used in the session, then > Header Extension Types that are not crucial to the behavior of the receiving > agent > MAY be designated as optional. > If the receiving agent does not recognize a Header Extension Type, > or if the receiving agent does not know how to process a Header Extension > with a recognized Header Extension Type that has not been designated as > optional, > then the LCT packet MUST be discarded without further processing. > The receiving agent MUST process a Header Extension unless its Header > Extension Type is designated as optional." > > -----Original Message----- > From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Justin > Chapweske > Sent: Wednesday, October 10, 2001 3:32 PM > To: rmt@lbl.gov > Subject: LCT Header Extensions > > > From LCT: > > "If present, Header Extensions MUST be processed to ensure that they are > recognized before performing any congestion control procedure or > otherwise accepting an LCT packet. LCT packets with unrecognised Header > Extensions MUST be discarded by the receiving agent, hence the expected > use of extensions SHOULD be signaled out-of-band before session startup." > > This concerns me because it means there is no mechanism for forward > compatibility between implementations/versions. I would like to request > that a Header Extension be specified for vendor-specific headers, > perhaps as follows: > > EXT_VEND = 3 Vendor-specific Extension > > This extension allows vendors to add their own extensions in a backwords > compatible fashion. > Recievers MUST ignore any vender-specific extensions that they don't > understand. > > A suggested format is as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |L| HET = 3 | HEL | VEND_CODE | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . Vender-specific Extension Content . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Vendor Code (VEND_CODE): 16 bits > > Identifies which vendor this extension is from. The Vendor code > determines how > the vendor-specific extension content will be parsed. It is RECOMMENDED > that > vendors use an extensible format for their own extensions so that they > only need a > single vendor code. > > > Thanks, > > -- > Justin Chapweske, Onion Networks > http://onionnetworks.com/ > >From owner-rmt@listserv.lbl.gov Wed Oct 10 19:56:13 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9B2jKv22226; Wed, 10 Oct 2001 19:45: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.11.2/8.11.2) with ESMTP id f9B2jIp22222 for ; Wed, 10 Oct 2001 19:45:18 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9B2jI525589 for ; Wed, 10 Oct 2001 19:45:18 -0700 (PDT) Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9B2jH725582 for ; Wed, 10 Oct 2001 19:45:17 -0700 (PDT) Received: (qmail 26479 invoked from network); 11 Oct 2001 02:45:12 -0000 Received: from mail.intranet (10.1.1.37) by mx.digitalfountain.com with SMTP; 11 Oct 2001 02:45:12 -0000 Received: from bozz (dhcp-10-1-2-180.intranet [10.1.2.180]) by mail.intranet (8.9.3/8.9.3) with SMTP id TAA04538; Wed, 10 Oct 2001 19:44:46 -0700 X-Authentication-Warning: mail.intranet: Host dhcp-10-1-2-180.intranet [10.1.2.180] claimed to be bozz From: "Michael Luby" To: "Lorenzo Vicisano" Cc: "Justin Chapweske" , , "Michael Luby" Subject: RE: LCT Header Extensions Date: Wed, 10 Oct 2001 19:50:39 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200110110240.TAA17619@lorenzo-u10.cisco.com> Sender: owner-rmt@lbl.gov Precedence: bulk I like this suggestion. Justin? -----Original Message----- From: Lorenzo Vicisano [mailto:lorenzo@cisco.com] Sent: Wednesday, October 10, 2001 7:40 PM To: Michael Luby Cc: Justin Chapweske; rmt@lbl.gov Subject: Re: LCT Header Extensions Mike, Justin, Given that here we are defining a packet format (or at least a piece of it), I think we should be able to interpret all its fields, and define some sort of behavior for them, at least as far as LCT is concerned. If nothing else, this would allow us to debug the content of the LCT header (I'm thinking of tools like "tcpdump"). For this reason I don't like the idea of signaling Header Extension Types out of band. On the other hand it is nice to be able to add backward-compatible extensions, to refine the protocol without changing the version number. My proposal is: "All header extensions that are not understood can be safely ignored by the receiver. This allows to introduce backward-compatible enhancement to the protocol without changing the version number. Non backward-compatible header extensions CANNOT be introduced without changing the protocol version number." Lorenzo Note that in multicast, unlike unicast, the sender may not want/be able to negotiate protocol capabilities, either because the receiver population is heterogeneous or because there is no feedback channel. My proposal is to use the 1st bit of the header extension (the one that we were using for "L") to signal whether the header extention can be safely ignored, if not understood. As now we have 8 bits for the type (we got rid of "L"), we reserve types 128 through 254 for backward-compatible header extension, i.e. extension that will be ignored if not understood. Note that LCVv2 can narrow the subset of backward-compatible extension, if it needs to and if it hasn't used all of it already In message , "Michael Luby" writes: > Justin, > > I agree that it is not as clearly written as it should have been, and the > writing needs to be changed. My proposal is written below. Before getting > to that, the problems that I see with your proposal are that: > (1) Your suggested format is quite complicated (embedding fields within > fields), and wastes a lot of precious packet space. > (2) It would most likely require vendors to register their vender code with > IANA, and the IANA registry would have to be set up for this, etc., and this > is an extra complication. > > The solution I propose is to leave everything the way it is right now > (although I do think it is good to get rid of the header extension bit X in > the first word of the header, and to get rid of the L in each header > extension, as you suggested in an earlier email), but to change the language > you called out to the following: > > "The expected use of Header Extensions, the list of Header Extension Types > and > how to process the corresponding Header Extension SHOULD be signaled > out-of-band > before session startup. If out-of-band signaling is used to communicate the > possible Header Extensions Types to be used in the session, then > Header Extension Types that are not crucial to the behavior of the receiving > agent > MAY be designated as optional. > If the receiving agent does not recognize a Header Extension Type, > or if the receiving agent does not know how to process a Header Extension > with a recognized Header Extension Type that has not been designated as > optional, > then the LCT packet MUST be discarded without further processing. > The receiving agent MUST process a Header Extension unless its Header > Extension Type is designated as optional." > > -----Original Message----- > From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Justin > Chapweske > Sent: Wednesday, October 10, 2001 3:32 PM > To: rmt@lbl.gov > Subject: LCT Header Extensions > > > From LCT: > > "If present, Header Extensions MUST be processed to ensure that they are > recognized before performing any congestion control procedure or > otherwise accepting an LCT packet. LCT packets with unrecognised Header > Extensions MUST be discarded by the receiving agent, hence the expected > use of extensions SHOULD be signaled out-of-band before session startup." > > This concerns me because it means there is no mechanism for forward > compatibility between implementations/versions. I would like to request > that a Header Extension be specified for vendor-specific headers, > perhaps as follows: > > EXT_VEND = 3 Vendor-specific Extension > > This extension allows vendors to add their own extensions in a backwords > compatible fashion. > Recievers MUST ignore any vender-specific extensions that they don't > understand. > > A suggested format is as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |L| HET = 3 | HEL | VEND_CODE | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . Vender-specific Extension Content . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Vendor Code (VEND_CODE): 16 bits > > Identifies which vendor this extension is from. The Vendor code > determines how > the vendor-specific extension content will be parsed. It is RECOMMENDED > that > vendors use an extensible format for their own extensions so that they > only need a > single vendor code. > > > Thanks, > > -- > Justin Chapweske, Onion Networks > http://onionnetworks.com/ > >From owner-rmt@listserv.lbl.gov Wed Oct 10 21:51:21 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9B4dm922800; Wed, 10 Oct 2001 21:39: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.11.2/8.11.2) with ESMTP id f9B4dlp22796 for ; Wed, 10 Oct 2001 21:39:47 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9B4dkm08831 for ; Wed, 10 Oct 2001 21:39:46 -0700 (PDT) Received: from chapweske.com (nic-41-c31-11.mn.mediaone.net [66.41.31.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9B4dj708822 for ; Wed, 10 Oct 2001 21:39:45 -0700 (PDT) Received: (qmail 1859 invoked from network); 11 Oct 2001 04:55:31 -0000 Received: from unknown (HELO onionnetworks.com) (192.168.0.2) by 192.168.0.3 with SMTP; 11 Oct 2001 04:55:31 -0000 Message-ID: <3BC521EE.2060903@onionnetworks.com> Date: Wed, 10 Oct 2001 23:37:02 -0500 From: Justin Chapweske User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: Michael Luby CC: Lorenzo Vicisano , rmt@lbl.gov Subject: Re: LCT Header Extensions References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk I like it too. There will of course have to be clarification as to which ranges are for fixed and variable length headers. -- Justin Chapweske, Onion Networks http://onionnetworks.com/ Michael Luby wrote: >I like this suggestion. Justin? > > >-----Original Message----- >From: Lorenzo Vicisano [mailto:lorenzo@cisco.com] >Sent: Wednesday, October 10, 2001 7:40 PM >To: Michael Luby >Cc: Justin Chapweske; rmt@lbl.gov >Subject: Re: LCT Header Extensions > > >Mike, Justin, > >Given that here we are defining a packet format (or at least >a piece of it), I think we should be able to interpret all >its fields, and define some sort of behavior for them, >at least as far as LCT is concerned. If nothing else, >this would allow us to debug the content of the LCT header >(I'm thinking of tools like "tcpdump"). > >For this reason I don't like the idea of signaling Header Extension >Types out of band. On the other hand it is nice to be able >to add backward-compatible extensions, to refine the protocol without >changing the version number. > >My proposal is: > >"All header extensions that are not understood can be safely >ignored by the receiver. This allows to introduce backward-compatible >enhancement to the protocol without changing the version number. >Non backward-compatible header extensions CANNOT be introduced without >changing the protocol version number." > > Lorenzo > >Note that in multicast, unlike unicast, the sender may not want/be able >to negotiate protocol capabilities, either because the receiver >population is heterogeneous or because there is no feedback channel. > >My proposal is to use the 1st bit of the header extension (the one >that we were using for "L") to signal whether the header extention can >be safely ignored, if not understood. > >As now we have 8 bits for the type (we got rid of "L"), >we reserve types 128 through 254 for backward-compatible >header extension, i.e. extension that will be ignored if >not understood. > >Note that LCVv2 can narrow the subset of backward-compatible >extension, if it needs to and if it hasn't used all of it already > > >In message , >"Michael Luby" writes: > >>Justin, >> >>I agree that it is not as clearly written as it should have been, and the >>writing needs to be changed. My proposal is written below. Before >> >getting > >>to that, the problems that I see with your proposal are that: >>(1) Your suggested format is quite complicated (embedding fields within >>fields), and wastes a lot of precious packet space. >>(2) It would most likely require vendors to register their vender code >> >with > >>IANA, and the IANA registry would have to be set up for this, etc., and >> >this > >>is an extra complication. >> >>The solution I propose is to leave everything the way it is right now >>(although I do think it is good to get rid of the header extension bit X >> >in > >>the first word of the header, and to get rid of the L in each header >>extension, as you suggested in an earlier email), but to change the >> >language > >>you called out to the following: >> >>"The expected use of Header Extensions, the list of Header Extension Types >>and >>how to process the corresponding Header Extension SHOULD be signaled >>out-of-band >>before session startup. If out-of-band signaling is used to communicate >> >the > >>possible Header Extensions Types to be used in the session, then >>Header Extension Types that are not crucial to the behavior of the >> >receiving > >>agent >>MAY be designated as optional. >>If the receiving agent does not recognize a Header Extension Type, >>or if the receiving agent does not know how to process a Header Extension >>with a recognized Header Extension Type that has not been designated as >>optional, >>then the LCT packet MUST be discarded without further processing. >>The receiving agent MUST process a Header Extension unless its Header >>Extension Type is designated as optional." >> >>-----Original Message----- >>From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Justin >>Chapweske >>Sent: Wednesday, October 10, 2001 3:32 PM >>To: rmt@lbl.gov >>Subject: LCT Header Extensions >> >> >> From LCT: >> >>"If present, Header Extensions MUST be processed to ensure that they are >>recognized before performing any congestion control procedure or >>otherwise accepting an LCT packet. LCT packets with unrecognised Header >>Extensions MUST be discarded by the receiving agent, hence the expected >>use of extensions SHOULD be signaled out-of-band before session startup." >> >>This concerns me because it means there is no mechanism for forward >>compatibility between implementations/versions. I would like to request >>that a Header Extension be specified for vendor-specific headers, >>perhaps as follows: >> >>EXT_VEND = 3 Vendor-specific Extension >> >>This extension allows vendors to add their own extensions in a backwords >>compatible fashion. >>Recievers MUST ignore any vender-specific extensions that they don't >>understand. >> >>A suggested format is as follows: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |L| HET = 3 | HEL | VEND_CODE | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> . . >> . Vender-specific Extension Content . >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>Vendor Code (VEND_CODE): 16 bits >> >>Identifies which vendor this extension is from. The Vendor code >>determines how >>the vendor-specific extension content will be parsed. It is RECOMMENDED >>that >>vendors use an extensible format for their own extensions so that they >>only need a >>single vendor code. >> >> >>Thanks, >> >>-- >>Justin Chapweske, Onion Networks >>http://onionnetworks.com/ >> > > >From owner-rmt@listserv.lbl.gov Thu Oct 11 19:55:31 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9C2oD012510; Thu, 11 Oct 2001 19:50:13 -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.11.2/8.11.2) with ESMTP id f9C2oBp12506 for ; Thu, 11 Oct 2001 19:50:12 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9C2oBl02796 for ; Thu, 11 Oct 2001 19:50:11 -0700 (PDT) Received: from chapweske.com ([66.41.31.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9C2oAF02791 for ; Thu, 11 Oct 2001 19:50:10 -0700 (PDT) Received: (qmail 3682 invoked from network); 12 Oct 2001 03:05:54 -0000 Received: from unknown (HELO onionnetworks.com) (192.168.0.2) by 192.168.0.3 with SMTP; 12 Oct 2001 03:05:54 -0000 Message-ID: <3BC659B3.6020102@onionnetworks.com> Date: Thu, 11 Oct 2001 21:47:15 -0500 From: Justin Chapweske User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: rmt@lbl.gov Subject: Questions/Comments Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk o In section 2.2 (Small Block Systematic FEC Codes) from the FEC BB document, it is unclear as to whether the number of redundant symbols refers to 'n' or 'n'-'k'. To me it would be much more natural for it to be the 'n' value. o Also in FEC BB, "source block length" is confusing. While I know that you are referring to symbol count, it could also be interpreted as bytes, or words. Thanks, -- Justin Chapweske, Onion Networks http://onionnetworks.com/ >From owner-rmt@listserv.lbl.gov Thu Oct 11 20:14:44 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9C3AKv12584; Thu, 11 Oct 2001 20:10: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.11.2/8.11.2) with ESMTP id f9C3AJp12580 for ; Thu, 11 Oct 2001 20:10:19 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9C3AJD05402 for ; Thu, 11 Oct 2001 20:10:19 -0700 (PDT) Received: from chapweske.com ([66.41.31.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9C3AHF05392 for ; Thu, 11 Oct 2001 20:10:17 -0700 (PDT) Received: (qmail 3721 invoked from network); 12 Oct 2001 03:26:02 -0000 Received: from unknown (HELO onionnetworks.com) (192.168.0.2) by 192.168.0.3 with SMTP; 12 Oct 2001 03:26:02 -0000 Message-ID: <3BC65E68.4090804@onionnetworks.com> Date: Thu, 11 Oct 2001 22:07:20 -0500 From: Justin Chapweske User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: rmt@lbl.gov Subject: sender authentication Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk From section 4.2. (Receiver Operation) from LCT BB: "If sender authentication information is present in an LCT packet header, it MUST be used as specified in Section 3.3. If a receiver is unable to implement the authentication mechanism used by the session, it MUST NOT join the session." This seems a bit strict to me. For Onion Networks' applications we use various cryptographic checksum constructs communicated out of band to perform file integrity checking. We don't care who the sender of the data is, we only care that we get the right data. I would like to be able to interoperate with other implementations w/o ascribing to their same authentication mechanisms. Thanks, -- Justin Chapweske, Onion Networks http://onionnetworks.com/ >From owner-rmt@listserv.lbl.gov Fri Oct 12 12:51:25 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9CJl6t17267; Fri, 12 Oct 2001 12:47: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.11.2/8.11.2) with ESMTP id f9CJl4p17263 for ; Fri, 12 Oct 2001 12:47:04 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9CJl2e28041 for ; Fri, 12 Oct 2001 12:47:03 -0700 (PDT) Received: from chapweske.com ([66.41.31.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9CJl1F28016 for ; Fri, 12 Oct 2001 12:47:01 -0700 (PDT) Received: (qmail 4911 invoked from network); 12 Oct 2001 20:02:50 -0000 Received: from unknown (HELO onionnetworks.com) (192.168.0.2) by 192.168.0.3 with SMTP; 12 Oct 2001 20:02:50 -0000 Message-ID: <3BC747FE.5030203@onionnetworks.com> Date: Fri, 12 Oct 2001 14:43:58 -0500 From: Justin Chapweske User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: rmt@lbl.gov Subject: source symbol flag Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk From FEC BB section 2.1: "In addition, a one bit FEC Encoding Flag MAY be included, and this flag indicates whether the encoding symbol(s) in the payload of the packet are source symbol(s) or redundant symbol(s)." The actual location of this flag is never specified, please clarify this. Thanks, -- Justin Chapweske, Onion Networks http://onionnetworks.com/ >From owner-rmt@listserv.lbl.gov Tue Oct 16 11:44:37 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9GIc4G12267; Tue, 16 Oct 2001 11:38:05 -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.11.2/8.11.2) with ESMTP id f9GIbLp12263 for ; Tue, 16 Oct 2001 11:37:21 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9GIbJd05861 for ; Tue, 16 Oct 2001 11:37:19 -0700 (PDT) Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9GIbJ105854 for ; Tue, 16 Oct 2001 11:37:19 -0700 (PDT) Received: (qmail 3052 invoked from network); 16 Oct 2001 18:37:12 -0000 Received: from mail.intranet (10.1.1.37) by mx.digitalfountain.com with SMTP; 16 Oct 2001 18:37:12 -0000 Received: from bozz (dhcp-10-1-2-180.intranet [10.1.2.180]) by mail.intranet (8.9.3/8.9.3) with SMTP id LAA11576; Tue, 16 Oct 2001 11:36:46 -0700 X-Authentication-Warning: mail.intranet: Host dhcp-10-1-2-180.intranet [10.1.2.180] claimed to be bozz From: "Michael Luby" To: "Justin Chapweske" Cc: "Jim Gemmell" , "Lorenzo Vicisano" , "Mark Handley" , "Jon Crowcroft" , "Luigi Rizzo" , "Rmt@Lbl. Gov" , "Michael Luby" , "Vincent Roca" Subject: RE: comments on the ALC/LCT/FEC I-D Date: Tue, 16 Oct 2001 11:42:18 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3BCC6B76.6080500@onionnetworks.com> Sender: owner-rmt@lbl.gov Precedence: bulk Thanks Justin for repsonding to one of the concerns raised by Vincent Roca. I have the same response, i.e. that the TOI is meant to be a globally unique identifier for the object, that will have the same value if the object is being sourced from multiple senders, and thus it may need to be rather long in some circumstances as Justin has outlined below. And yes, these comments should be sent to the list I believe (and I'm sending this one to the list). Mike -----Original Message----- From: Justin Chapweske [mailto:justin@onionnetworks.com] Sent: Tuesday, October 16, 2001 10:17 AM To: Vincent Roca Cc: Mike Luby; Jim Gemmell; Lorenzo Vicisano; Mark Handley; Jon Crowcroft; Luigi Rizzo Subject: Re: comments on the ALC/LCT/FEC I-D Is there any reason this isn't being CC'd to the mailing list? >3- LCT: Do we really need the possibility of having a 16 byte TOI field ? > Probably not if its only purpose is to identify objects. > In our implementation the TOI is just an object identifier managed > in a sequential manner and starting at a predifined initial seq > number (just like TCP does). I guess this will be the case in most > implementations. > Besides doing 16 byte TOI to object mapping with the out-of-band > mechanism (as suggested) can be rather heavy! > Can you clarify why the TOI field can be so large in some cases. > We will be using a 16 byte TOI field in our implementation. We will use the first 16 bytes of the SHA-1 hash of the content to provide a (somewhat) unique identifer for the content. We are doing this because we want to avoid any runtime negotiation of transport parameters to try to maintain a relatively loose coupling. This should make it easier for us to do things like have multiple senders, under seperate administrative control, for a single object. Thanks, -- Justin Chapweske, Onion Networks http://onionnetworks.com/ >From owner-rmt@listserv.lbl.gov Tue Oct 16 17:34:36 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9H0VFH28679; Tue, 16 Oct 2001 17:31:15 -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.11.2/8.11.2) with ESMTP id f9H0VEp28675 for ; Tue, 16 Oct 2001 17:31:14 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9H0VDR10542 for ; Tue, 16 Oct 2001 17:31:13 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9H0VC110536 for ; Tue, 16 Oct 2001 17:31:12 -0700 (PDT) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9H0VAk20492; Tue, 16 Oct 2001 17:31:10 -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 RAA20600; Tue, 16 Oct 2001 17:31:06 -0700 (PDT) Message-Id: <200110170031.RAA20600@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI] To: Vincent Roca cc: Mike Luby , Jim Gemmell , Mark Handley , Jon Crowcroft , Luigi Rizzo , Justin Chapweske , rmt@lbl.gov Subject: Re: comments on the ALC/LCT/FEC I-D In-Reply-To: Your message of "Tue, 16 Oct 2001 11:19:35 +0200." <3BCBFBA7.93E6E834@inrialpes.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Oct 2001 17:31:06 -0700 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk Vincent, a few comments, please check inline. Lorenzo > Serious problem: > ---------------- > > 1- ALC draft: it is assumed that the FPI field is always present. > This is a problem if the source wants to send a ``signaling only'' > packet, e.g. to close the session. > Don't forget that this close session packet may be sent in situations > where the session must be immediately released, no matter whether > there remains packets to be sent or not. > I suggest to add a bit in the LCT header to indicate wether the > FPI field is present or not. > Another advantage of doing that is that ALC would really be a > ``specialized version of an LCT packet'' rather than being an LCT > header plus a FPI field (and possibly other optional fields). Maybe we can just say this: + In some special cases an ALC source may need to produce ALC packets + that do not contain any payload. This may be required, for example, to + signal the end of a session or to convey congestion control + information. These data-less packets do not contain the FEC Payload ID + either, but only the LCT header fields. The total datagram length, + conveyed by outer protocol headers (e.g. the IP or UDP header), + enables receivers to detect the absence of the ALC payload and FEC + Payload ID. > > 7- LCT: add the DemuxLabel flag introduced in previous LCT draft. > This demux label can be usefull in case LCT is used directly > on top of IP rather than UDP as there would be no UDP port number. > This demux label can also be usefull to easily avoid LCT session > collisions. > This DemuxLabel can be carried in a dedicated Header Extension so > that there is no additional cost for the common case (LCT/UDP/IP). the current specification only allows ALC on top of UDP (made clear in the new text). > > 8- ALC: there is no ALC version number. This may be a problem... > Maybe some bits of the LCT version number could be used for that? There is no ALC header really.. or better the ALC header borrows its beginning from the LCT header, hence the ALC version number is the LCT version number.. this might need to change if we define ALC the goes directly on top of IP (now is UDP only). >From owner-rmt@listserv.lbl.gov Wed Oct 17 01:32:14 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9H8RcR25853; Wed, 17 Oct 2001 01:27:38 -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.11.2/8.11.2) with ESMTP id f9H8Rap25849 for ; Wed, 17 Oct 2001 01:27:36 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9H8Ra018537 for ; Wed, 17 Oct 2001 01:27:36 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9H8RY118534 for ; Wed, 17 Oct 2001 01:27:34 -0700 (PDT) Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id f9H8Odg18762; Wed, 17 Oct 2001 10:24:40 +0200 (MEST) Received: from inrialpes.fr (IDENT:roca@iseran.inrialpes.fr [194.199.24.100]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with ESMTP id f9H8Oej23813; Wed, 17 Oct 2001 10:24:40 +0200 (MEST) Message-ID: <3BCD41A0.6786E5A0@inrialpes.fr> Date: Wed, 17 Oct 2001 10:30:24 +0200 From: Vincent Roca Organization: INRIA X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Luby , rmt@lbl.gov CC: vincent.roca@inrialpes.fr Subject: Re: comments on the ALC/LCT/FEC I-D References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Michael Luby wrote: > And yes, these comments > should be sent to the list I believe (and I'm sending this one to the list). You're right Mike. Here is a copy of the comments I sent directly to the I-D authors yesterday for those who may be interested. Cheers, Vincent ------------- http://www.inrialpes.fr/planete/people/roca/ INRIA Rhone-Alpes Vincent ROCA projet Planete; B-219 vincent.roca@inrialpes.fr ZIRST; 655 av. de l'Europe phone: (+33) 4.76.61.52.16 38330 MONTBONNOT - France fax: (+33) 4.76.61.52.52 ---------------------------------------------------------- some comments on the LCT draft, draft-ietf-rmt-bb-lct-01.txt, July 2001 ALC draft, draft-ietf-rmt-pi-alc-02.txt, July 2001 FEC draft, draft-ietf-rmt-bb-fec-03.txt, July 2001 vincent roca - October 16th, 2001 ---------------------------------------------------------- Serious problem: ---------------- 1- ALC draft: it is assumed that the FPI field is always present. This is a problem if the source wants to send a ``signaling only'' packet, e.g. to close the session. Don't forget that this close session packet may be sent in situations where the session must be immediately released, no matter whether there remains packets to be sent or not. I suggest to add a bit in the LCT header to indicate wether the FPI field is present or not. Another advantage of doing that is that ALC would really be a ``specialized version of an LCT packet'' rather than being an LCT header plus a FPI field (and possibly other optional fields). Clarifications needed: ---------------------- 2- LCT: does the HDR_LEN field include the fixed size LCT header and fixed CCI? That was not the case in previous LCT versions, it seems to be the case now but this is not clearly said (e.g. is CCI part of the LCT packet header?). 3- LCT: Do we really need the possibility of having a 16 byte TOI field ? Probably not if its only purpose is to identify objects. In our implementation the TOI is just an object identifier managed in a sequential manner and starting at a predifined initial seq number (just like TCP does). I guess this will be the case in most implementations. Besides doing 16 byte TOI to object mapping with the out-of-band mechanism (as suggested) can be rather heavy! Can you clarify why the TOI field can be so large in some cases. 4- ALC draft, section 3.2: it is said that the ``FEC encoding flag'' may be communicated via the value of the LCT codepoint field. As Justin mentionned, the FEC BB draft says that a one bit ``FEC encoding flag'' may be included in the FPI. So there are two possibilities of indicating wether this is a source symbol or FEC symbol. Can you choose one (nice for interoperability purposes). I suggest the one bit flag in the FPI... 5- FEC BB: Can you justify the Small Block Systematic FEC formats. I don't understand the rationale for having a different block size in a given object (except for the last block of course), and thus having the block size specified in the FPI rather than in the FTI. Can you add a pointer to a document (publication, RR...) that motivates this choice... May be this is related to the following remark (object definition). What is an object? ------------------ 6- I'd like to see somewhere a discussion on a possible LCT/ALC service model. More specifically what is an object? The LCT draft, page 6 (General Archi), introduces several examples. The TV channel example puzzles me. It is suggested that objects could correspond to individual programs like a movie. Implicitely it is suggested that this is a streaming session. This is where I don't agree! For me an object is an Application Data Unit (ADU) in the ALF (Application Level Framing) sense. Therefore the object is the unit of data exchanged between the applications and the ALC/LCT protocols. For streaming sessions, each object could correspond to individual movie frames, but not to the whole movie. Said differently, IMHO a ``streaming object'' is a non-sense. I admit that we can make other hypotheses, i.e. assume that accesses to individual blocks is possible at a receiver, but I don't think that it would be a good choice. Nice to have / suggestions: --------------------------- 7- LCT: add the DemuxLabel flag introduced in previous LCT draft. This demux label can be usefull in case LCT is used directly on top of IP rather than UDP as there would be no UDP port number. This demux label can also be usefull to easily avoid LCT session collisions. This DemuxLabel can be carried in a dedicated Header Extension so that there is no additional cost for the common case (LCT/UDP/IP). 8- ALC: there is no ALC version number. This may be a problem... Maybe some bits of the LCT version number could be used for that? Minor remarks: -------------- 9- LCT: Update the [3] reference on FCAST. Published in IEEE Network, 2000. (easier to find than an internal RR) >From owner-rmt@listserv.lbl.gov Wed Oct 17 06:03:00 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9HCwaY20661; Wed, 17 Oct 2001 05:58: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 (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9HCwYp20657 for ; Wed, 17 Oct 2001 05:58:34 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9HCwYv28484 for ; Wed, 17 Oct 2001 05:58:34 -0700 (PDT) Received: from sm.luth.se (ny.sm.luth.se [130.240.3.1]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9HCwW128476 for ; Wed, 17 Oct 2001 05:58:32 -0700 (PDT) Received: from cdt.luth.se (fddi.cdt.luth.se [130.240.64.13]) by sm.luth.se (8.10.0/8.10.0) with ESMTP id f9HCwQC09030 for ; Wed, 17 Oct 2001 14:58:26 +0200 (MET DST) Message-ID: <3BCD823F.93BD7C6B@cdt.luth.se> Date: Wed, 17 Oct 2001 15:06:07 +0200 From: Jeremiah Scholl Organization: CDT, =?iso-8859-1?Q?Lule=E5?= University X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rmt@lbl.gov Subject: pgmcc Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Taking a look at the home page for the RMT workgroup today I noticed that a link to the Internet-Draft for PGMCC is no longer available. I am wondering why. Was it removed because the draft has expired?? did someone accidentaly remove the link from the page?? Perhaps is there some other reason?? Thanks, Jeremiah Scholl >From owner-rmt@listserv.lbl.gov Wed Oct 17 06:31:32 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9HDS4K24031; Wed, 17 Oct 2001 06:28:04 -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.11.2/8.11.2) with ESMTP id f9HDS2p24027 for ; Wed, 17 Oct 2001 06:28:03 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9HDS2v02352 for ; Wed, 17 Oct 2001 06:28:02 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9HDS0102346 for ; Wed, 17 Oct 2001 06:28:01 -0700 (PDT) Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id f9HDP5g26929; Wed, 17 Oct 2001 15:25:05 +0200 (MEST) Received: from inrialpes.fr (IDENT:roca@iseran.inrialpes.fr [194.199.24.100]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with ESMTP id f9HDP6j04262; Wed, 17 Oct 2001 15:25:06 +0200 (MEST) Message-ID: <3BCD880A.4FDD7D06@inrialpes.fr> Date: Wed, 17 Oct 2001 15:30:50 +0200 From: Vincent Roca Organization: INRIA X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Lorenzo Vicisano , rmt@lbl.gov CC: vincent.roca@inrialpes.fr Subject: Re: comments on the ALC/LCT/FEC I-D References: <200110170031.RAA20600@lorenzo-u10.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Lorenzo, > > 1- ALC draft: it is assumed that the FPI field is always present. > > This is a problem if the source wants to send a ``signaling only'' > > packet, e.g. to close the session. > > Don't forget that this close session packet may be sent in situations > > where the session must be immediately released, no matter whether > > there remains packets to be sent or not. > > I suggest to add a bit in the LCT header to indicate wether the > > FPI field is present or not. > > Another advantage of doing that is that ALC would really be a > > ``specialized version of an LCT packet'' rather than being an LCT > > header plus a FPI field (and possibly other optional fields). > > Maybe we can just say this: > > + In some special cases an ALC source may need to produce ALC packets > + that do not contain any payload. This may be required, for example, to > + signal the end of a session or to convey congestion control > + information. These data-less packets do not contain the FEC Payload ID > + either, but only the LCT header fields. The total datagram length, > + conveyed by outer protocol headers (e.g. the IP or UDP header), > + enables receivers to detect the absence of the ALC payload and FEC > + Payload ID. I agree that it works, but we can also say: "The presence of the FEC payload ID is indicated by the P flag of the LCT header." (and define the Payload ID present flag (P) in LCT) which is simpler and will always work. We can reasonably assume that any PI built on top of LCT will need a payload ID. In the particular case of ALC, this will be the ``FEC'' payload ID. If no FEC BB is used, this will simply be a ``source'' payload ID. Besides the ALC I-D says that it is recommended that the optional additional parameter fields adhere to the Header Extension format. Why not including them in the LCT Header Extension list instead of creating an additional list? The fact that the LCT Codepoint field may indicate the presence of these additional parameter fields too is not a problem. In other words do we really need to separate the ALC specific fields (as done today) or just integrate them in a natural fashion to LCT and say that their presence is required with ALC? LCT is a very broad BB, that can be used in many many different situations. ALC uses a subset of LCT plus some other BBs, so make ALC really a specialized version of LCT (as said in the ALC I-D) rather than LCT plus additional fields. > > 8- ALC: there is no ALC version number. This may be a problem... > > Maybe some bits of the LCT version number could be used > > for that? > > There is no ALC header really.. or better the ALC header borrows > its beginning from the LCT header, hence the ALC version number > is the LCT version number.. this might need to change if we define > ALC the goes directly on top of IP (now is UDP only). I've never seen any protocol without any explicit version number. Today the LCT version number is a BB version number. If it (or a part of it as I suggest) is meant to be used as a PI version number, it should be said. cheers, vincent. ------------- http://www.inrialpes.fr/planete/people/roca/ INRIA Rhone-Alpes Vincent ROCA projet Planete; B-219 vincent.roca@inrialpes.fr ZIRST; 655 av. de l'Europe phone: (+33) 4.76.61.52.16 38330 MONTBONNOT - France fax: (+33) 4.76.61.52.52 >From owner-rmt@listserv.lbl.gov Wed Oct 17 16:41:33 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9HMKEi15211; Wed, 17 Oct 2001 15:20: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.11.2/8.11.2) with ESMTP id f9HMKDp15207 for ; Wed, 17 Oct 2001 15:20:13 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9HMKC113286 for ; Wed, 17 Oct 2001 15:20:12 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9HMKB113276 for ; Wed, 17 Oct 2001 15:20:11 -0700 (PDT) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9HMK9U17170; Wed, 17 Oct 2001 15:20:10 -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 PAA24970; Wed, 17 Oct 2001 15:20:05 -0700 (PDT) Message-Id: <200110172220.PAA24970@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI] To: Jeremiah Scholl cc: rmt@lbl.gov Subject: Re: pgmcc In-Reply-To: Your message of "Wed, 17 Oct 2001 15:06:07 +0200." <3BCD823F.93BD7C6B@cdt.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Oct 2001 15:20:05 -0700 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk I believe that the only reason for this is that the draft has expired and is no longer available in the IETF directory. We plan to revise the draft and hopefully resubmit by the coming IETF deadline. thanks, Lorenzo In message <3BCD823F.93BD7C6B@cdt.luth.se>, Jeremiah Scholl writes: > Taking a look at the home page for the RMT workgroup today I noticed > that a link to the Internet-Draft for PGMCC is no longer available. I > am wondering why. Was it removed because the draft has expired?? did > someone accidentaly remove the link from the page?? Perhaps is there > some other reason?? > > Thanks, > > Jeremiah Scholl >From owner-rmt@listserv.lbl.gov Wed Oct 17 17:17:29 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9I0Bw920841; Wed, 17 Oct 2001 17:11:58 -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.11.2/8.11.2) with ESMTP id f9I0Bvp20837 for ; Wed, 17 Oct 2001 17:11:57 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9I0Bur04048 for ; Wed, 17 Oct 2001 17:11:56 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9HNcB505243 for ; Wed, 17 Oct 2001 16:38:12 -0700 (PDT) Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f9HN6qY13017; Wed, 17 Oct 2001 16:06: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 QAA25031; Wed, 17 Oct 2001 16:06:47 -0700 (PDT) Message-Id: <200110172306.QAA25031@lorenzo-u10.cisco.com> X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI] To: Vincent Roca cc: rmt@lbl.gov Subject: Re: comments on the ALC/LCT/FEC I-D In-Reply-To: Your message of "Wed, 17 Oct 2001 15:30:50 +0200." <3BCD880A.4FDD7D06@inrialpes.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Oct 2001 16:06:47 -0700 From: Lorenzo Vicisano Sender: owner-rmt@lbl.gov Precedence: bulk In message <3BCD880A.4FDD7D06@inrialpes.fr>, Vincent Roca writes: > Lorenzo, > > > > 1- ALC draft: it is assumed that the FPI field is always present. > > > This is a problem if the source wants to send a ``signaling only'' > > > packet, e.g. to close the session. > > > Don't forget that this close session packet may be sent in situatio >ns > > > where the session must be immediately released, no matter whether > > > there remains packets to be sent or not. > > > I suggest to add a bit in the LCT header to indicate wether the > > > FPI field is present or not. > > > Another advantage of doing that is that ALC would really be a > > > ``specialized version of an LCT packet'' rather than being an LCT > > > header plus a FPI field (and possibly other optional fields). > > > > Maybe we can just say this: > > > > + In some special cases an ALC source may need to produce ALC packets > > + that do not contain any payload. This may be required, for example, to > > + signal the end of a session or to convey congestion control > > + information. These data-less packets do not contain the FEC Payload ID > > + either, but only the LCT header fields. The total datagram length, > > + conveyed by outer protocol headers (e.g. the IP or UDP header), > > + enables receivers to detect the absence of the ALC payload and FEC > > + Payload ID. > > I agree that it works, but we can also say: > > "The presence of the FEC payload ID is indicated by > the P flag of the LCT header." > (and define the Payload ID present flag (P) in LCT) > > which is simpler and will always work. > We can reasonably assume that any PI built on top of LCT will > need a payload ID. In the particular case of ALC, this will be > the ``FEC'' payload ID. If no FEC BB is used, this will simply > be a ``source'' payload ID. > > Besides the ALC I-D says that it is recommended that the optional > additional parameter fields adhere to the Header Extension format. > Why not including them in the LCT Header Extension list instead > of creating an additional list? The fact that the LCT Codepoint > field may indicate the presence of these additional parameter > fields too is not a problem. > > In other words do we really need to separate the ALC specific > fields (as done today) or just integrate them in a natural > fashion to LCT and say that their presence is required with ALC? > > LCT is a very broad BB, that can be used in many many different > situations. ALC uses a subset of LCT plus some other BBs, > so make ALC really a specialized version of LCT (as said in the > ALC I-D) rather than LCT plus additional fields. We could use an LCT header extension to carry the FEC Payload ID and in the new version of the draft we have reserved some of those for this purpose. However this adds unnecessary header overhead (4 bytes). I would not do it at this point. > > > > > 8- ALC: there is no ALC version number. This may be a problem... > > > Maybe some bits of the LCT version number could be used > > > for that? > > > > There is no ALC header really.. or better the ALC header borrows > > its beginning from the LCT header, hence the ALC version number > > is the LCT version number.. this might need to change if we define > > ALC the goes directly on top of IP (now is UDP only). > > I've never seen any protocol without any explicit version > number. Today the LCT version number is a BB version number. > If it (or a part of it as I suggest) is meant to be used as a PI > version number, it should be said. Given that this version "0" of ALC refers to version "0" of LCT (and not any other future LCT) we can safely say that the LCT version number field is also the ALC version number field. If in the future we define a new ALC version, let's say 1, and this refers to a different LCT version, let's say 0, then we will have 2 options: 1) add an ALC specific version number (this would probably mean prepend 4-bytes ALC specific, at least) 2) let ALC version number override the LCT version number, this would have the drawback of not being able to interpret the LCT header out-of context, i.e. the new draft will have to say that when a receivers reads "1" in the version number field, this will mean ALC version 1 which is associated with LCT version 0. Not really a problem. Keeping the 2 version numbers distinct is only an issue on a protocol instantiation that can use multiple versions of LCT. thanks, Lorenzo >From owner-rmt@listserv.lbl.gov Thu Oct 18 14:20:55 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9ILG0R04254; Thu, 18 Oct 2001 14:16:00 -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.11.2/8.11.2) with ESMTP id f9ILFwp04250 for ; Thu, 18 Oct 2001 14:15:59 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9ILFvc18529 for ; Thu, 18 Oct 2001 14:15:57 -0700 (PDT) Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9ILFsb18458 for ; Thu, 18 Oct 2001 14:15:54 -0700 (PDT) Received: (qmail 23691 invoked from network); 18 Oct 2001 21:15:49 -0000 Received: from mail.intranet (10.1.1.37) by mx.digitalfountain.com with SMTP; 18 Oct 2001 21:15:49 -0000 Received: from bozz (dhcp-10-1-2-180.intranet [10.1.2.180]) by mail.intranet (8.9.3/8.9.3) with SMTP id OAA30944; Thu, 18 Oct 2001 14:15:22 -0700 X-Authentication-Warning: mail.intranet: Host dhcp-10-1-2-180.intranet [10.1.2.180] claimed to be bozz From: "Michael Luby" To: "Internet-Drafts@Ietf. Org" , "Rmt@Lbl. Gov" Cc: "Michael Luby" Subject: draft-ietf-rmt-info-fec-01.txt Date: Thu, 18 Oct 2001 14:20:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C157E0.145218E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C157E0.145218E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please post this draft on the IETF Internet Drafts archive. This is an update of an existing WG draft (RMT). This also serves as a last call before moving this towards RFC status. Please send any comments or concerns to the RMG list by Monday, October 22. Thanks, Mike Luby ------=_NextPart_000_0000_01C157E0.145218E0 Content-Type: text/plain; name="draft-ietf-rmt-info-fec-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-rmt-info-fec-01.txt" Internet Engineering Task Force RMT WG=0A= INTERNET-DRAFT M. Luby/Digital Fountain=0A= draft-ietf-rmt-info-fec-01.txt L. Vicisano/Cisco=0A= J. Gemmell/Microsoft=0A= L. Rizzo/ACIRI and Univ. Pisa=0A= M. Handley/ACIRI=0A= J. Crowcroft/UCL=0A= 18 October 2001=0A= Expires: April 2002=0A= =0A= =0A= The use of Forward Error Correction in Reliable Multicast=0A= =0A= =0A= This document is an Internet-Draft and is in full conformance with all=0A= provisions of Section 10 of RFC2026.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering Task=0A= Force (IETF), its areas, and its working groups. Note that other groups=0A= may also distribute working documents as Internet-Drafts.=0A= =0A= Internet-Drafts are valid for a maximum of six months and may be=0A= updated, replaced, or obsoleted by other documents at any time. It is=0A= inappropriate to use Internet-Drafts as reference material or to cite=0A= them other than as a "work in progress".=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt=0A= =0A= To view the list Internet-Draft Shadow Directories, see=0A= http://www.ietf.org/shadow.html.=0A= =0A= This document is a product of the IETF RMT WG. Comments should be=0A= addressed to the authors, or the WG's mailing list at rmt@lbl.gov.=0A= =0A= =0A= Abstract=0A= =0A= =0A= This memo describes the use of Forward Error Correction (FEC)=0A= codes within the context of reliable IP multicast transport=0A= and provides an introduction to some commonly-used FEC codes.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft [Page 1]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= 1. Rationale and Overview=0A= =0A= There are many ways to provide reliability for transmission protocols.=0A= A common method is to use ARQ, automatic request for retransmission.=0A= With ARQ, receivers use a back channel to the sender to send requests=0A= for retransmission of lost packets. ARQ works well for one-to-one=0A= reliable protocols, as evidenced by the pervasive success of TCP/IP.=0A= ARQ has also been an effective reliability tool for one-to-many=0A= reliability protocols, and in particular for some reliable IP multicast=0A= protocols. However, for one-to-very-many reliability protocols, ARQ has=0A= limitations, including the feedback implosion problem because many=0A= receivers are transmitting back to the sender, and the need for a back=0A= channel to send these requests from the receiver. Another limitation is=0A= that receivers may experience different loss patterns of packets, and=0A= thus receivers may be delayed by retransmission of packets that other=0A= receivers have lost that but they have already received. This may also=0A= cause wasteful use of bandwidth used to retransmit packets that have=0A= already been received by many of the receivers.=0A= =0A= In environments where ARQ is either costly or impossible because there=0A= is either a very limited capacity back channel or no back channel at=0A= all, such as satellite transmission, a Data Carousel approach to=0A= reliability is sometimes used [1]. With a Data Carousel, the sender=0A= partitions the object into equal length pieces of data, which we=0A= hereafter call source symbols, places them into packets, and then=0A= continually cycles through and sends these packets. Receivers=0A= continually receive packets until they have received a copy of each=0A= packet. Data Carousel has the advantage that it requires no back=0A= channel because there is no data that flows from receivers to the=0A= sender. However, Data Carousel also has limitations. For example, if a=0A= receiver loses a packet in one round of transmission it must wait an=0A= entire round before it has a chance to receive that packet again. This=0A= may also cause wasteful use of bandwidth, as the sender continually=0A= cycles through and transmits the packets until no receiver is missing a=0A= packet.=0A= =0A= FEC codes provide a reliability method that can be used to augment or=0A= replace other reliability methods, especially for one-to-many=0A= reliability protocols such as reliable IP multicast. We first briefly=0A= review some of the basic properties and types of FEC codes before=0A= reviewing their uses in the context of reliable IP multicast. Later, we=0A= provide a more detailed description of some of FEC codes.=0A= =0A= In the general literature, FEC refers to the ability to overcome both=0A= erasures (losses) and bit-level corruption. However, in the case of IP=0A= multicast, lower network layers will detect corrupted packets and=0A= discard them. Therefore, an IP multicast protocol need not be concerned=0A= with corruption; the focus is solely on erasure codes. The payloads are=0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1. [Page 2]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= generated and processed using an FEC erasure encoder and objects are=0A= reassembled from reception of packets using the corresponding FEC=0A= erasure decoder.=0A= =0A= The input to an FEC encoder is some number k of equal length source=0A= symbols. The FEC encoder generates some number of encoding symbols that=0A= are of the same length as the source symbols. The chosen length of the=0A= symbols can vary upon each application of the FEC encoder, or it can be=0A= fixed. These encoding symbols are placed into packets for transmission.=0A= The number of encoding symbols placed into each packet can vary on a per=0A= packet basis, or a fixed number of symbols (often one) can be placed=0A= into each packet. Also, in each packet is placed enough information to=0A= identify the particular encoding symbols carried in that packet. Upon=0A= receipt of packets containing encoding symbols, the receiver feeds these=0A= encoding symbols into the corresponding FEC decoder to recreate an exact=0A= copy of the k source symbols. Ideally, the FEC decoder can recreate an=0A= exact copy from any k of the encoding symbols.=0A= =0A= In a later section, we describe a technique for using FEC codes as=0A= described above to handle blocks with variable length source symbols.=0A= =0A= Block FEC codes work as follows. The input to a block FEC encoder is k=0A= source symbols and a number n. The encoder generates a total of n=0A= encoding symbols. The encoder is systematic if it generates n-k=0A= redundant symbols yielding an encoding block of n encoding symbols in=0A= total composed of the k source symbols and the n-k redundant symbols. A=0A= block FEC decoder has the property that any k of the n encoding symbols=0A= in the encoding block is sufficient to reconstruct the original k source=0A= symbols.=0A= =0A= Expandable FEC codes work as follows. An expandable FEC encoder takes=0A= as input k source symbols and generates as many unique encoding symbols=0A= as requested on demand, where the amount of time for generating each=0A= encoding symbol is the same independent of how many encoding symbols are=0A= generated. An expandable FEC decoder has the property that any k of the=0A= unique encoding symbols is sufficient to reconstruct the original k=0A= source symbols.=0A= =0A= The above definitions explain the ideal situation when the reception of=0A= any k encoding symbols is sufficient to recover the k source symbols, in=0A= which case the reception overhead is 0%. For some practical FEC codes,=0A= slightly more than k encoding symbols are needed to recover the k source=0A= symbols. If k*(1+ep) encoding symbols are needed, we say the reception=0A= overhead is ep*100%, e.g., if k*1.05 encoding symbols are needed then=0A= the reception overhead is 5%.=0A= =0A= Along a different dimension, we classify FEC codes loosely as being=0A= either small or large. A small FEC code is efficient in terms of=0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1. [Page 3]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= processing time requirements for encoding and decoding for small values=0A= of k, and a large FEC code is efficient for encoding and decoding for=0A= much large values of k. There are implementations of block FEC codes=0A= that have encoding times proportional to n times the length of the k=0A= source symbols, and decoding times proportional l times the length of=0A= the k source symbols, where l is the number of missing source symbols=0A= among the k received encoding symbols. Because of the growth rate of=0A= the encoding and decoding times as a product of k and n, these are=0A= typically considered to be small block FEC codes. There are block FEC=0A= codes with a small reception overhead that can generate n encoding=0A= symbols and can decode the k source symbols in time proportional to the=0A= length of the n encoding symbols. These codes are considered to be=0A= large block FEC codes. There are expandable FEC codes with a small=0A= reception overhead that can generate each encoding symbol in time=0A= roughly proportional to its length, and can decode all k source symbols=0A= in time roughly proportional to their length. These are considered to=0A= be large expandable FEC codes.=0A= =0A= Ideally, FEC codes in the context of IP multicast can be used to=0A= generate encoding symbols that are transmitted in packets in such a way=0A= that each received packet is fully useful to a receiver to reassemble=0A= the object regardless of previous packet reception patterns. Thus, if=0A= some packets are lost in transit between the sender and the receiver,=0A= instead of asking for specific retransmission of the lost packets or=0A= waiting till the packets are resent using Data Carousel, the receiver=0A= can use any other subsequent equal number of packets that arrive to=0A= reassemble the object. These packets can either be proactively=0A= transmitted or they can be explicitly requested by receivers. This=0A= implies that the same packet is fully useful to all receivers to=0A= reassemble the object, even though the receivers may have previously=0A= experienced different packet loss patterns. This property can reduce or=0A= even eliminate the problems mentioned above associated with ARQ and Data=0A= Carousel and thereby dramatically increase the scalability of the=0A= protocol to orders of magnitude more receivers.=0A= =0A= =0A= 1.1. Application of FEC codecs=0A= =0A= For some reliable IP multicast protocols, FEC codes are used in=0A= conjunction with ARQ to provide reliability. For example, a large=0A= object could be partitioned into a number of source blocks consisting of=0A= a small number of source symbols each, and in a first round of=0A= transmission all of the source symbols for all the source blocks could=0A= be transmitted. Then, receivers could report back to the sender the=0A= number of source symbols they are missing from each source block. The=0A= sender could then compute the maximum number of missing source symbols=0A= from each source block among all receivers. Based on this, a small=0A= block FEC encoder could be used to generate for each source block a=0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1.1. [Page 4]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= number of redundant symbols equal to the computed maximum number of=0A= missing source symbols from the block among all receivers, as long as=0A= this maximum maximum for each block does not exceed the number of=0A= redundant symbols that can be generated efficiently. In a second round=0A= of transmission, the server would then send all of these redundant=0A= symbols for all blocks. In this example, if there are no losses in the=0A= second round of transmission then all receivers will be able to recreate=0A= an exact copy of each original block. In this case, even if different=0A= receivers are missing different symbols in different blocks, transmitted=0A= redundant symbols for a given block are useful to all receivers missing=0A= symbols from that block in the second round.=0A= =0A= For other reliable IP multicast protocols, FEC codes are used in a Data=0A= Carousel fashion to provide reliability, which we call an FEC Data=0A= Carousel. For example, an FEC Data Carousel using a large block FEC=0A= code could work as follows. The large block FEC encoder produces n=0A= encoding symbols considering all the k source symbols of an object as=0A= one block. The sender cycles through and transmits the n encoding=0A= symbols in packets in the same order in each round. An FEC Data=0A= Carousel can have much better protection against packet loss than a Data=0A= Carousel. For example, a receiver can join the transmission at any=0A= point in time, and, as long as the receiver receives at least k encoding=0A= symbols during the transmission of the next n encoding symbols, the=0A= receiver can completely recover the object. This is true even if the=0A= receiver starts receiving packets in the middle of a pass through the=0A= encoding symbols. This method can also be used when the object is=0A= partitioned into blocks and a short block FEC code is applied to each=0A= block separately. In this case, as we explain in more detail below, it=0A= is useful to interleave the symbols from the different blocks when they=0A= are transmitted.=0A= =0A= Since any number of encoding symbols can be generated using an=0A= expandable FEC encoder, reliable IP multicast protocols that use=0A= expandable FEC codes generally rely solely on these codes for=0A= reliability. For example, when an expandable FEC code is used in a FEC=0A= Data Carousel application, the encoding packets never repeat, and thus=0A= any k of the encoding symbols in the potentially unbounded number of=0A= encoding symbols are sufficient to recover the original k source=0A= symbols.=0A= =0A= For yet other reliable IP multicast protocols the method to obtain=0A= reliability is to generate enough encoding symbols so that each encoding=0A= symbol is transmitted at most once. For example, the sender can decide=0A= a priori how many encoding symbols it will transmit, use an FEC code to=0A= generate that number of encoding symbols from the object, and then=0A= transmit the encoding symbols to all receivers. This method is for=0A= example applicable to streaming protocols, where the stream is=0A= partitioned into objects, the source symbols for each object are encoded=0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1.1. [Page 5]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= into encoding symbols using an FEC code, and then the sets of encoding=0A= symbols for each object are transmitted one after the other using IP=0A= multicast.=0A= =0A= =0A= 2. FEC Codes=0A= =0A= =0A= 2.1. Simple codes=0A= =0A= There are some very simple codes that are effective for repairing packet=0A= loss under very low loss conditions. For example, one simple way to=0A= provide protection from a single loss is to partition the object into=0A= fixed size source symbols and then add a redundant symbol that is the=0A= parity (XOR) of all the source symbols. The size of a source symbol is=0A= chosen so that it fits perfectly into the payload of a packet, i.e. if=0A= the packet payload is 512 bytes then each source symbol is 512 bytes.=0A= The header of each packet contains enough information to identify the=0A= payload. In this case, this is an encoding symbol ID. The encoding=0A= symbol IDs can consist of two parts in this example. The first part is=0A= an encoding flag that is equal to 1 if the encoding symbol is a source=0A= symbol and is equal to 0 if the encoding symbol is a redundant symbol.=0A= The second part of the encoding symbol ID is a source symbol ID if the=0A= encoding flag is 1 and a redundant symbol ID if the encoding flag is 0.=0A= The source symbol IDs can be numbered from 0 to k-1 and the redundant=0A= symbol ID can be 0. For example, if the object consists of four source=0A= symbols that have values a, b, c and d, then the value of the redundant=0A= symbol is e =3D a XOR b XOR c XOR d. Then, the packets carrying these=0A= symbols look like=0A= (1, 0: a), (1, 1: b), (1, 2: c), (1, 3: d), (0, 0: e).=0A= =0A= In this example, the encoding symbol ID consists of the first two=0A= values, where the first value is the encoding flag and the second value=0A= is either a source symbol ID or the redundant symbol ID. The portion of=0A= the packet after the colon is the value of the encoding symbol. Any=0A= single source symbol of the object can be recovered as the parity of all=0A= the other symbols. For example, if packets=0A= (1, 0: a), (1, 1: b), (1, 3: d), (0, 0: e)=0A= =0A= are received then the missing source symbol value with source symbol ID=0A= =3D 2 can be recovered by computing a XOR b XOR d XOR e =3D c.=0A= =0A= Another way of forming the encoding symbol ID is to let values 0,...,k-1=0A= correspond to the k source symbols and value k corresponds to the=0A= redundant symbol that is the XOR of the k source symbols.=0A= =0A= When the number of source symbols in the object is large, a simple block=0A= code variant of the above can be used. In this case, the source symbols=0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.1. [Page 6]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= are grouped together into source blocks of some number k of consecutive=0A= symbols each, where k may be different for different blocks. If a block=0A= consists of k source symbols then a redundant symbol is added to form an=0A= encoding block consisting of k+1 encoding symbols. Then, a source block=0A= consisting of k source symbols can be recovered from any k of the k+1=0A= encoding symbols from the associated encoding block.=0A= =0A= Slightly more sophisticated ways of adding redundant symbols using=0A= parity can also be used. For example, one can group a block consisting=0A= of k source symbols in an object into a p x p square matrix, where p =3D=0A= sqrt(k). Then, for each row a redundant symbol is added that is the=0A= parity of all the source symbols in the row. Similarly, for each column=0A= a redundant symbol is added that is the parity of all the source symbols=0A= in the column. Then, any row of the matrix can be recovered from any p=0A= of the p+1 symbols in the row, and similarly for any column. Higher=0A= dimensional product codes using this technique can also be used.=0A= However, one must be wary of using these constructions without some=0A= thought towards the possible loss patterns of symbols. Ideally, the=0A= property that one would like to obtain is that if k source symbols are=0A= encoded into n encoding symbols (the encoding symbols consist of the=0A= source symbols and the redundant symbols) then the k source symbols can=0A= be recovered from any k of the n encoding symbols. Using the simple=0A= constructions described above does not yield codes that come close to=0A= obtaining this ideal behavior.=0A= =0A= =0A= 2.2. Small block FEC codes=0A= =0A= Reliable IP multicast protocols may use a block (n, k) FEC code [2]. For=0A= such codes, k source symbols are encoded into n > k encoding symbols,=0A= such that any k of the encoding symbols can be used to reassemble the=0A= original k source symbols. Thus, these codes have no reception overhead=0A= when used to encode the entire object directly. Block codes are usually=0A= systematic, which means that the n encoding symbols consist of the k=0A= source symbols and n-k redundant symbols generated from these k source=0A= symbols, where the size of a redundant symbol is the same as that for a=0A= source symbol. For example, the first simple code (XOR) described in=0A= the previous subsection is a (k+1, k) code. In general, the freedom to=0A= choose n larger than k+1 is desirable, as this can provide much better=0A= protection against losses. A popular example of these types of codes is=0A= a class of Reed-Solomon codes, which are based on algebraic methods=0A= using finite fields. Implementations of (n, k) FEC erasure codes are=0A= efficient enough to be used by personal computers [8]. For example, [7]=0A= describes an implementation where the encoding and decoding speeds decay=0A= as C/j, where the constant C is on the order of 10 to 80 Mbytes/second=0A= for Pentium class machines of various vintages and j is upper bounded by=0A= min(k, n-k).=0A= =0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.2. [Page 7]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= In practice, the values of k and n must be small (for example below 256)=0A= for such FEC codes as large values make encoding and decoding=0A= prohibitively expensive. As many objects are longer than k symbols for=0A= reasonable values of k and the symbol length (e.g. larger than 16=0A= kilobyte for k =3D 16 using 1 kilobyte symbols), they can be divided into=0A= a number of source blocks. Each source block consists of some number k=0A= of source symbols, where k may vary between different source blocks.=0A= The FEC encoder is used to encode a k source symbol source block into a=0A= n encoding symbol encoding block, where the number n of encoding symbols=0A= in the encoding block may vary for each source block. For a receiver to=0A= completely recover the object, for each source block consisting of k=0A= source symbols, k distinct encoding symbols (i.e., with different=0A= encoding symbol IDs) must be received from the corresponding encoding=0A= block. For some encoding blocks, more encoding symbols may be received=0A= than there are source symbols in the corresponding source block, in=0A= which case the excess encoding symbols are discarded. An example=0A= encoding structure is shown in Figure 1.=0A= =0A= =0A= =0A= | source symbol IDs | source symbols IDs |=0A= | of source block 0 | of source block 1 |=0A= | |=0A= v v=0A= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=0A= |0 |1 |2 |3 |4 |5 |6 |7 |0 |1 |2 |3 | 4|5 |6 |7 |=0A= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=0A= |=0A= FEC encoder=0A= |=0A= v=0A= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=0A= |0 |1 |2 |3 | 4| 5| 6| 7| 8| 9| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|=0A= +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=0A= ^ ^=0A= | |=0A= | encoding symbol IDs | encoding symbol IDs |=0A= | of encoding block 0 | of encoding block 1 |=0A= =0A= =0A= Figure 1. Encoding structure for object divided into two source=0A= blocks consisting of 8 source symbols each, and the FEC encoder is used = to=0A= generate 2 additional redundant symbols (10 encoding symbols in total)=0A= for each of the two source blocks.=0A= =0A= =0A= In many cases, an object is partitioned into equal length source blocks=0A= each consisting of k contiguous source symbols of the object, i.e.,=0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.2. [Page 8]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= block c consists of the range of source symbols [ck, (c+1)k-1]. This=0A= ensures that the FEC encoder can be optimized to handle a particular=0A= number k of source symbols. This also ensures that memory references=0A= are local when the sender reads source symbols to encode, and when the=0A= receiver reads encoding symbols to decode. Locality of reference is=0A= particularly important when the object is stored on disk, as it reduces=0A= the disk seeks required. The block number and the source symbol ID=0A= within that block can be used to uniquely specify a source symbol within=0A= the object. If the size of the object is not a multiple of k source=0A= symbols, then the last source block will contain less than k symbols.=0A= =0A= The block numbers can be numbered consecutively starting from zero.=0A= Encoding symbols within a block can be uniquely identified by an=0A= encoding symbol ID. One way of identifying encoding symbols within a=0A= block is to use the combination of an encoding flag that identifies the=0A= symbol as either a source symbol or a redundant symbol together with=0A= either a source symbol ID or a redundant symbol ID. For example, an=0A= encoding flag value of 1 can indicate that the encoding symbol is a=0A= source symbol and 0 can indicate that it is a redundant symbol. The=0A= source symbol IDs can be numbered from 0 to k-1 and the redundant symbol=0A= IDs can be numbered from 0 to n-k-1.=0A= =0A= For example, if the object consists 10 source symbols with values a, b,=0A= c, d, e, f, g, h, i, and j, and k =3D 5 and n =3D 8, then there are two=0A= source blocks consisting of 5 symbols each, and there are two encoding=0A= blocks consisting of 8 symbols each. Let p, q and r be the values of=0A= the redundant symbols for the first encoding block, and let x, y and z=0A= be the values of the redundant symbols for the second encoding block.=0A= Then the encoding symbols together with their identifiers are=0A= =0A= (0, 1, 0: a), (0, 1, 1: b), (0, 1, 2: c), (0, 1, 3: d), (0, 1, 4: e),=0A= (0, 0, 0: p), (0, 0, 1: q), (0, 0, 2: r),=0A= (1, 1, 0: f), (1, 1, 1: g), (1, 1, 2: h), (1, 1, 3: i), (1, 1, 4: j),=0A= (1, 0, 0: x), (1, 0, 1: y), (1, 0, 2: z).=0A= =0A= =0A= In this example, the first value identifies the block number and the=0A= second two values together identify the encoding symbol within the=0A= block, i.e, the encoding symbol ID consists of the encoding flag=0A= together with either the source symbol ID or the redundant symbol ID=0A= depending on the value of the encoding flag. The value of the encoding=0A= symbol is written after the colon. Each block can be recovered from any=0A= 5 of the 8 encoding symbols associated with that block. For example,=0A= reception of=0A= =0A= (0, 1, 1: b), (0, 1, 2: c), (0, 1, 3: d), (0, 0, 0: p), (0, 0, 1: q)=0A= =0A= is sufficient to recover the first source block, and reception of=0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.2. [Page 9]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= (1, 1, 0: f), (1, 1, 1: g), (1, 0, 0: x), (1, 0, 1: y), (1, 0, 2: z)=0A= =0A= =0A= is sufficient to recover the second source block.=0A= =0A= Another way of uniquely identifying encoding symbols within a block is=0A= to let the encoding symbol IDs for source symbols be 0,...,k-1 and to=0A= let the encoding symbol IDs for redundant symbols be k,...,n-1.=0A= =0A= =0A= 2.3. Large block FEC codes=0A= =0A= Tornado codes [4] are large block FEC codes that provide an alternative=0A= to small block FEC codes. An (n, k) Tornado code requires slightly more=0A= than k out of n encoding symbols to recover k source symbols, i.e.,=0A= there is a small reception overhead. However, the advantage is that the=0A= value of k may be on the order of tens of thousands and still run=0A= efficiently. Because of memory considerations, in practice the value of=0A= n is restricted to be a small multiple of k, e.g., n =3D 2k. For = example,=0A= [3] describes an implementation of Tornado codes where the encoding and=0A= decoding speeds are tens of megabytes per second for Pentium class=0A= machines of various vintages when k is in the tens of thousands and n =3D=0A= 2k. The reception overhead for such values of k and n is in the 5-10%=0A= range. Tornado codes require a large amount of out of band information=0A= to be communicated to all senders and receivers for each different=0A= object length, and require an amount of memory on the encoder and=0A= decoder which is proportional to the object length times 2n/k.=0A= =0A= Tornado codes are designed to have low reception overhead on average=0A= with respect to reception of a random portion of the encoding packets.=0A= Thus, to ensure that a receiver can reassemble the object with low=0A= reception overhead, the packets are permuted into a random order before=0A= transmission.=0A= =0A= =0A= 2.4. Expandable FEC codes=0A= =0A= All of the FEC codes described up to this point are block codes. There=0A= is a different type of FEC codes that we call expandable FEC codes.=0A= Like block codes, an expandable FEC encoder operates on an object of=0A= known size that is partitioned into equal length source symbols. Unlike=0A= block codes, there is no predetermined number of encoding symbols that=0A= can be generated for expandable FEC codes. Instead, an expandable FEC=0A= encoder can generate as few or as many unique encoding symbols as=0A= required on demand.=0A= =0A= LT codes [5] are an example of large expandable FEC codes with a small=0A= reception overhead. An LT encoder uses randomization to generate each=0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.4. [Page 10]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= encoding symbol randomly and independently of all other encoding=0A= symbols. Like Tornado codes, the number of source symbols k may be very=0A= large for LT codes, i.e., on the order of tens to hundreds of thousands,=0A= and the encoder and decoder run efficiently in software. For example the=0A= encoding and decoding speeds for LT codes are in the range 3-20=0A= megabytes per second for Pentium class machines of various vintages when=0A= k is in the high tens of thousands. An LT encoder can generate as few=0A= or as many encoding symbols as required on demand. When a new encoding=0A= symbol is to be generated by an LT encoder, it is based on a randomly=0A= chosen encoding symbol ID that uniquely describes how the encoding=0A= symbol is to be generated from the source symbols. In general, each=0A= encoding symbol ID value corresponds to a unique encoding symbol, and=0A= thus the space of possible encoding symbols is approximately four=0A= billion if for example the encoding symbol ID is 4 bytes. Thus, the=0A= chance that a particular encoding symbol is the same as any other=0A= particular encoding symbol is inversely proportional to the number of=0A= possible encoding symbol IDs. An LT decoder has the property that with=0A= very high probability the receipt of any set of slightly more than k=0A= randomly and independently generated encoding symbols is sufficient to=0A= reassemble the k source symbols. For example, when k is on the order of=0A= tens to hundreds of thousands the reception overhead is less than 5%=0A= with no failures in hundreds of millions of trials under any loss=0A= conditions.=0A= =0A= Because encoding symbols are randomly and independently generated by=0A= choosing random encoding symbol IDs, LT codes have the property that=0A= encoding symbols for the same k source symbols can be generated and=0A= transmitted from multiple senders and received by a receiver and the=0A= reception overhead and the decoding time is the same as if though all=0A= the encoding symbols were generated by a single sender. The only=0A= requirement is that the senders choose their encoding symbol IDs=0A= randomly and independently of one another.=0A= =0A= There is a weak tradeoff between the number of source symbols and the=0A= reception overhead for LT codes, and the larger the number of source=0A= symbols the smaller the reception overhead. Thus, for shorter objects,=0A= it is sometimes advantageous to partition the object into many short=0A= source symbols and include multiple encoding symbols in each packet. In=0A= this case, a single encoding symbol ID is used to identify the multiple=0A= encoding symbols contained in a single packet.=0A= =0A= There are a couple of factors for choosing the appropriate symbol=0A= length/ number of source symbols tradeoff. The primary consideration is=0A= that there is a fixed overhead per symbol in the overall processing=0A= requirements of the encoding and decoding, independent of the number of=0A= source symbols. Thus, using shorter symbols means that this fixed=0A= overhead processing per symbol will be a larger component of the overall=0A= processing requirements, leading to larger overall processing=0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.4. [Page 11]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= requirements. A second much less important consideration is that there=0A= is a component of the processing per symbol that depends logarithmically=0A= on the number of source symbols, and thus for this reason there is a=0A= slight preference towards fewer source symbols.=0A= =0A= Like small block codes, there is a point when the object is large enough=0A= that it makes sense to partition it into blocks when using LT codes.=0A= Generally the object is partitioned into blocks whenever the number of=0A= source symbols times the packet payload length is less than the size of=0A= the object. Thus, if the packet payload is 1024 bytes and the maximum=0A= number of source symbols is 128,000 then any object over 128 megabytes=0A= will be partitioned into more than one block. One can choose the=0A= maximum number of source symbols to use, depending on the desired=0A= encoding and decoding speed versus reception overhead tradeoff desired.=0A= Encoding symbols can be uniquely identified by a block number (when the=0A= object is large enough to be partitioned into more than one block) and=0A= an encoding symbol ID. The block numbers, if they are used, are=0A= generally numbered consecutively starting from zero within the object.=0A= The block number and the encoding symbol ID are both chosen uniformly=0A= and randomly from their range when an encoding symbol is to be=0A= transmitted. For example, suppose the number of source symbols is=0A= 128,000 and the number of blocks is 2. Then, each packet generated by=0A= the LT encoder could be of the form (b, x: y). In this example, the=0A= first value identifies the block number and the second value identifies=0A= the encoding symbol within the block. In this example, the block number=0A= b is either 0 or 1, and the encoding symbol ID x might be a 32-bit=0A= value. The value y after the colon is the value of the encoding symbol.=0A= =0A= =0A= 2.5. Source blocks with variable length source symbols=0A= =0A= For all the FEC codes described above, all the source symbols in the=0A= same source block are all of the same length. In this section, we=0A= describe a general technique to handle the case when it is desirable to=0A= use source symbols of varying lengths in a single source block. This=0A= technique is applicable to block FEC codes.=0A= =0A= Let l_1, l_2, ... , l_k be the lengths in bytes of k varying length=0A= source symbols to be considered part of the same source block. Let lmax=0A= be the maximum over i =3D 1, ... , k of l_i. To prepare the source block=0A= for the FEC encoder, pad each source symbol i out to length lmax with a=0A= suffix of lmax-l_i zeroes, and then prepend to the beginning of this the=0A= value l_i. Thus, each padded source symbol is of length x+lmax,=0A= assuming that it takes x bytes to store an integer with possible values=0A= 0,...,lmax, where x is a protocol constant known to both the encoder and=0A= the decoder. These padded source symbols, each of length x+lmax, are=0A= the input to the encoder, together with the value n. The encoder then=0A= generates n-k redundant symbols, each of length x+lmax.=0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.5. [Page 12]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= The encoding symbols that are placed into packets consist of the=0A= original k varying length source symbols and n-k redundant symbols, each=0A= of length x+lmax. From any k of the received encoding symbols, the FEC=0A= decoder recreates the k original source symbols as follows. If all k=0A= original source symbols are received, then no decoding is necessary.=0A= Otherwise, at least one redundant symbol is received, from which the=0A= receiver can easily determine if the block is composed of variable-=0A= length source symbols: if the redundant symbol(s) is longer than the=0A= source symbols then the source symbols are variable-length. Note that in=0A= a variable-length block the redundant symbols are always longer than the=0A= longest source symbol, due to the presence of the prepended symbol-=0A= length. The receiver can determine the value of lmax by subtracting x=0A= from the length of a received redundant symbol. For each of the=0A= received original source symbols, the receiver can generate the=0A= corresponding padded source symbol as described above. Then, the input=0A= to the FEC decoder is the set of received redundant symbols, together=0A= with the set of padded source symbols constructed from the received=0A= original symbols. The FEC decoder then produces the set of k padded=0A= source symbols. Once the k padded source symbols have been recovered,=0A= the length l_i of original source symbol i can be recovered from the=0A= first x bytes of the ith padded source symbol, and then original source=0A= symbol i is obtained by taking the next l_i bytes following the x bytes=0A= of the length field.=0A= =0A= =0A= 3. Security Considerations=0A= =0A= The use of FEC, in and of itself, imposes no additional security=0A= considerations versus sending the same information without FEC.=0A= However, just like for any transmission system, a malicious sender may=0A= try to inject packets carrying corrupted encoding symbols. If a=0A= receiver accepts one or more corrupted encoding symbol in place of=0A= authentic ones then such a receiver may reconstruct a corrupted object.=0A= =0A= Application-level transmission object authentication can detect the=0A= corrupted transfer, but the receiver must then discard the transferred=0A= object. Thus, injecting corrupted encoding symbols they are accepted as=0A= valid encoding symbols by a receiver is at the very least an effective=0A= denial of service attack.=0A= =0A= In light of this possibility, FEC receivers may screen the source=0A= address of a received symbol against a list of authentic transmitter=0A= addresses. Since source addresses may be spoofed, transport protocols=0A= using FEC may provide mechanisms for robust source authentication of=0A= each encoding symbol. Multicast routers along the path of a FEC transfer=0A= may provide the capability of discarding multicast packets that=0A= originated on that subnet, and whose source IP address does not=0A= correspond with that subnet.=0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 3. [Page 13]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= It is recommended that a packet authentication scheme such as TESLA [6]=0A= be used in conjunction with FEC codes. Then, packets that cannot be=0A= authenticated can be discarded and the object can be reliably recovered=0A= from the received authenticated packets.=0A= =0A= =0A= 4. Intellectual Property Disclosure=0A= =0A= Tornado codes [4] have both patents issued and patents pending. There=0A= is an issued patent for LT codes [5].=0A= =0A= 5. Acknowledgments=0A= =0A= Thanks to Vincent Roca and Hayder Radha for their detailed comments on=0A= this draft.=0A= =0A= =0A= 6. References=0A= =0A= [1] Acharya, S., Franklin, M., and Zdonik, S., ``Dissemination- Based=0A= Data Delivery Using Broadcast Disks'', IEEE Personal Communications,=0A= pp.50-60, Dec 1995.=0A= =0A= [2] Blahut, R.E., ``Theory and Practice of Error Control Codes'',=0A= Addison Wesley, MA 1984.=0A= =0A= [3] Byers, J.W., Luby, M., Mitzenmacher, M., and Rege, A., ``A Digital=0A= Fountain Approach to Reliable Distribution of Bulk Data'', Proceedings=0A= ACM SIGCOMM '98, Vancouver, Canada, Sept 1998.=0A= =0A= [4] Luby, M., Mitzenmacher, M., Shokrollahi, A., Spielman, D.,=0A= ``Efficient Erasure Correcting Codes'', IEEE Transactions on Information=0A= Theory, Special Issue: Codes on Graphs and Iterative Algorithms, pp.=0A= 569-584, Vol. 47, No. 2, February 2001.=0A= =0A= [5] Luby, M., "Information Additive Code Generator and Decoder for=0A= Communication Systems", U.S. Patent No. 6,307,487, October 23, 2001.=0A= =0A= [6] Perrig, A., Canetti, R., Song, D., Tygar, J.D., "Efficient and=0A= Secure Source Authentication for Multicast", Network and Distributed=0A= System Security Symposium, NDSS 2001, pp. 35-46, February 2001.=0A= =0A= [7] Rizzo, L., ``Effective Erasure Codes for Reliable Computer=0A= Communication Protocols'', ACM SIGCOMM Computer Communication Review,=0A= Vol.27, No.2, pp.24-36, Apr 1997.=0A= =0A= [8] Rizzo, L., ``On the Feasibility of Software FEC'', DEIT Tech Report,=0A= http://www.iet.unipi.it/~luigi/softfec.ps, Jan 1997.=0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 6. [Page 14]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= 7. Authors' Addresses=0A= =0A= Michael Luby=0A= luby@digitalfountain.com=0A= Digital Fountain=0A= 39141 Civic Center Drive=0A= Suite 300=0A= Fremont, CA 94538=0A= =0A= Lorenzo Vicisano=0A= lorenzo@cisco.com=0A= cisco Systems, Inc.=0A= 170 West Tasman Dr.,=0A= San Jose, CA, USA, 95134=0A= =0A= Jim Gemmell=0A= jgemmell@microsoft.com=0A= Microsoft Research=0A= 301 Howard St., #830=0A= San Francisco, CA, USA, 94105=0A= =0A= Luigi Rizzo=0A= luigi@iet.unipi.it=0A= ACIRI, 1947 Center St., Berkeley CA 94704=0A= and=0A= Dip. di Ing. dell'Informazione=0A= Universita` di Pisa=0A= via Diotisalvi 2, 56126 Pisa, Italy=0A= =0A= Mark Handley=0A= mjh@aciri.org=0A= ACIRI=0A= 1947 Center St.=0A= Berkeley CA, USA, 94704=0A= =0A= Jon Crowcroft=0A= J.Crowcroft@cs.ucl.ac.uk=0A= Department of Computer Science=0A= University College London=0A= Gower Street,=0A= London WC1E 6BT, UK=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 7. [Page 15]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= 8. Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2001). All Rights Reserved.=0A= =0A= This document and translations of it may be copied and furnished to=0A= others, and derivative works that comment on or otherwise explain it or=0A= assist in its implementation may be prepared, copied, published and=0A= distributed, in whole or in part, without restriction of any kind,=0A= provided that the above copyright notice and this paragraph are included=0A= on all such copies and derivative works. However, this document itself=0A= may not be modified in any way, such as by removing the copyright notice=0A= or references to the Internet Society or other Internet organizations,=0A= except as needed for the purpose of developing Internet standards in=0A= which case the procedures for copyrights defined in the Internet=0A= languages other than English.=0A= =0A= The limited permissions granted above are perpetual and will not be=0A= revoked by the Internet Society or its successors or assigns.=0A= =0A= This document and the information contained herein is provided on an "AS=0A= IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK=0A= FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT=0A= LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT=0A= INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR=0A= FITNESS FOR A PARTICULAR PURPOSE."=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 8. [Page 16]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 8. [Page 17]=0A= ------=_NextPart_000_0000_01C157E0.145218E0 Content-Type: application/postscript; name="draft-ietf-rmt-info-fec-01.ps" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-rmt-info-fec-01.ps" %!PS-Adobe-3.0=0A= %%Creator: groff version 1.15=0A= %%CreationDate: Thu Oct 18 10:44:37 2001=0A= %%DocumentNeededResources: font Courier-Bold=0A= %%+ font Times-Bold=0A= %%+ font Times-Roman=0A= %%+ font Courier=0A= %%DocumentSuppliedResources: procset grops 1.15 1=0A= %%Pages: 15=0A= %%PageOrder: Ascend=0A= %%Orientation: Portrait=0A= %%EndComments=0A= %%BeginProlog=0A= %%BeginResource: procset grops 1.15 1=0A= /setpacking where{=0A= pop=0A= currentpacking=0A= true setpacking=0A= }if=0A= /grops 120 dict dup begin=0A= /SC 32 def=0A= /A/show load def=0A= /B{0 SC 3 -1 roll widthshow}bind def=0A= /C{0 exch ashow}bind def=0A= /D{0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /E{0 rmoveto show}bind def=0A= /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def=0A= /G{0 rmoveto 0 exch ashow}bind def=0A= /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /I{0 exch rmoveto show}bind def=0A= /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def=0A= /K{0 exch rmoveto 0 exch ashow}bind def=0A= /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /M{rmoveto show}bind def=0A= /N{rmoveto 0 SC 3 -1 roll widthshow}bind def=0A= /O{rmoveto 0 exch ashow}bind def=0A= /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /Q{moveto show}bind def=0A= /R{moveto 0 SC 3 -1 roll widthshow}bind def=0A= /S{moveto 0 exch ashow}bind def=0A= /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /SF{=0A= findfont exch=0A= [exch dup 0 exch 0 exch neg 0 0]makefont=0A= dup setfont=0A= [exch/setfont cvx]cvx bind def=0A= }bind def=0A= /MF{=0A= findfont=0A= [5 2 roll=0A= 0 3 1 roll=0A= neg 0 0]makefont=0A= dup setfont=0A= [exch/setfont cvx]cvx bind def=0A= }bind def=0A= /level0 0 def=0A= /RES 0 def=0A= /PL 0 def=0A= /LS 0 def=0A= /MANUAL{=0A= statusdict begin/manualfeed true store end=0A= }bind def=0A= /PLG{=0A= gsave newpath clippath pathbbox grestore=0A= exch pop add exch pop=0A= }bind def=0A= /BP{=0A= /level0 save def=0A= 1 setlinecap=0A= 1 setlinejoin=0A= 72 RES div dup scale=0A= LS{=0A= 90 rotate=0A= }{=0A= 0 PL translate=0A= }ifelse=0A= 1 -1 scale=0A= }bind def=0A= /EP{=0A= level0 restore=0A= showpage=0A= }bind def=0A= /DA{=0A= newpath arcn stroke=0A= }bind def=0A= /SN{=0A= transform=0A= .25 sub exch .25 sub exch=0A= round .25 add exch round .25 add exch=0A= itransform=0A= }bind def=0A= /DL{=0A= SN=0A= moveto=0A= SN=0A= lineto stroke=0A= }bind def=0A= /DC{=0A= newpath 0 360 arc closepath=0A= }bind def=0A= /TM matrix def=0A= /DE{=0A= TM currentmatrix pop=0A= translate scale newpath 0 0 .5 0 360 arc closepath=0A= TM setmatrix=0A= }bind def=0A= /RC/rcurveto load def=0A= /RL/rlineto load def=0A= /ST/stroke load def=0A= /MT/moveto load def=0A= /CL/closepath load def=0A= /FL{=0A= currentgray exch setgray fill setgray=0A= }bind def=0A= /BL/fill load def=0A= /LW/setlinewidth load def=0A= /RE{=0A= findfont=0A= dup maxlength 1 index/FontName known not{1 add}if dict begin=0A= {=0A= 1 index/FID ne{def}{pop pop}ifelse=0A= }forall=0A= /Encoding exch def=0A= dup/FontName exch def=0A= currentdict end definefont pop=0A= }bind def=0A= /DEFS 0 def=0A= /EBEGIN{=0A= moveto=0A= DEFS begin=0A= }bind def=0A= /EEND/end load def=0A= /CNT 0 def=0A= /level1 0 def=0A= /PBEGIN{=0A= /level1 save def=0A= translate=0A= div 3 1 roll div exch scale=0A= neg exch neg exch translate=0A= 0 setgray=0A= 0 setlinecap=0A= 1 setlinewidth=0A= 0 setlinejoin=0A= 10 setmiterlimit=0A= []0 setdash=0A= /setstrokeadjust where{=0A= pop=0A= false setstrokeadjust=0A= }if=0A= /setoverprint where{=0A= pop=0A= false setoverprint=0A= }if=0A= newpath=0A= /CNT countdictstack def=0A= userdict begin=0A= /showpage{}def=0A= }bind def=0A= /PEND{=0A= clear=0A= countdictstack CNT sub{end}repeat=0A= level1 restore=0A= }bind def=0A= end def=0A= /setpacking where{=0A= pop=0A= setpacking=0A= }if=0A= %%EndResource=0A= %%IncludeResource: font Courier-Bold=0A= %%IncludeResource: font Times-Bold=0A= %%IncludeResource: font Times-Roman=0A= %%IncludeResource: font Courier=0A= grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72=0A= def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron=0A= /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef=0A= /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef=0A= /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef=0A= /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent=0A= /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen=0A= /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon=0A= /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O=0A= /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex=0A= /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y=0A= /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft=0A= /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl=0A= /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut=0A= /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash=0A= /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen=0A= /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft=0A= /logicalnot/minus/registered/macron/degree/plusminus/twosuperior=0A= /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior=0A= /ordmasculine/guilsinglright/onequarter/onehalf/threequarters=0A= /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE=0A= /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex=0A= /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis=0A= /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn=0A= /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla=0A= /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis=0A= /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash=0A= /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def=0A= /Courier@0 ENC0/Courier RE/Times-Roman@0 ENC0/Times-Roman RE=0A= /Times-Bold@0 ENC0/Times-Bold RE/Courier-Bold@0 ENC0/Courier-Bold RE=0A= %%EndProlog=0A= %%Page: 1 1=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 10/Courier-Bold@0 SF(Internet Engineering Task Force)72 85 Q(RMT WG)=0A= 209.998 E 197.998(INTERNET-DRAFT M.)72 98 R(Luby/Digital Fountain)6 E=0A= 149.998(draft-ietf-rmt-info-fec-01.ps L.)72 111 R(Vicisano/Cisco)6 E=0A= (J. Gemmell/Microsoft)383.998 124 Q(L. Rizzo/ACIRI and Univ. Pisa)=0A= 329.998 137 Q(M. Handley/ACIRI)407.998 150 Q(J. Crowcroft/UCL)407.998=0A= 163 Q(18 October 2001)413.998 176 Q(Expires: April 2002)389.998 189 Q/F1=0A= 14/Times-Bold@0 SF(The use of F)111.894 214 Q(orward Err)-.35 E(or Corr)=0A= -.252 E(ection in Reliable Multicast)-.252 E/F2 11/Times-Roman@0 SF(Thi\=0A= s document is an Internet-Draft and is in full conformance with all pro)=0A= 72 246 Q(visions of Section 10 of)-.165 E(RFC2026.)72 259 Q=0A= (Internet-Drafts are w)72 285 Q=0A= (orking documents of the Internet Engineering T)-.11 E(ask F)-.88 E=0A= (orce \(IETF\), its areas,)-.165 E(and its w)72 298 Q(orking groups.)=0A= -.11 E(Note that other groups may also distrib)5.5 E(ute w)-.22 E=0A= (orking documents as)-.11 E(Internet-Drafts.)72 311 Q=0A= (Internet-Drafts are v)72 337 Q=0A= (alid for a maximum of six months and may be updated, replaced, or)-.275=0A= E(obsoleted by other documents at an)72 350 Q 2.75(yt)-.165 G 2.75=0A= (ime. It)-2.75 F(is inappropriate to use Internet-Drafts as reference)=0A= 2.75 E(material or to cite them other than as a "w)72 363 Q=0A= (ork in progress".)-.11 E=0A= (The list of current Internet-Drafts can be accessed at http://www)72=0A= 389 Q(.ietf.or)-.715 E(g/ietf/1id-abstracts.txt)-.198 E 1.76 -.88(To v)=0A= 72 415 T(ie).88 E 2.75(wt)-.275 G(he list Internet-Draft Shado)-2.75 E=0A= 2.75(wD)-.275 G(irectories, see http://www)-2.75 E(.ietf.or)-.715 E=0A= (g/shado)-.198 E -.715(w.)-.275 G(html.).715 E=0A= (This document is a product of the IETF RMT WG.)72 441 Q=0A= (Comments should be addressed to the)5.5 E(authors, or the WG')72 454 Q=0A= 2.75(sm)-.605 G(ailing list at rmt@lbl.go)-2.75 E -.715(v.)-.165 G/F3 11=0A= /Times-Bold@0 SF(Abstract)267.534 486 Q F2=0A= (This memo describes the use of F)97 508.6 Q(orw)-.165 E=0A= (ard Error Correction \(FEC\) codes within the)-.11 E(conte)97 521.6 Q=0A= (xt of reliable IP multicast transport and pro)-.165 E=0A= (vides an introduction to some)-.165 E(commonly-used FEC codes.)97 534.6=0A= Q F3(1.)72 573.6 Q F1(Rationale and Ov)5.5 E(er)-.14 E(view)-.14 E F2=0A= (There are man)72 590.2 Q 2.75(yw)-.165 G(ays to pro)-2.86 E=0A= (vide reliability for transmission protocols.)-.165 E 2.75(Ac)5.5 G=0A= (ommon method is to)-2.75 E=0A= (use ARQ, automatic request for retransmission.)72 603.2 Q -.44(Wi)5.5 G=0A= (th ARQ, recei).44 E -.165(ve)-.275 G(rs use a back channel to the).165=0A= E(sender to send requests for retransmission of lost pack)72 616.2 Q=0A= 2.75(ets. ARQ)-.11 F -.11(wo)2.75 G(rks well for one-to-one).11 E=0A= (reliable protocols, as e)72 629.2 Q(videnced by the perv)-.275 E(asi)=0A= -.275 E .33 -.165(ve s)-.275 H(uccess of TCP/IP).165 E 5.5(.A)-1.221 G=0A= (RQ has also been an)-5.5 E(ef)72 642.2 Q(fecti)-.275 E .33 -.165(ve r)=0A= -.275 H(eliability tool for one-to-man).165 E 2.75(yr)-.165 G=0A= (eliability protocols, and in particular for some reliable)-2.75 E=0A= (IP multicast protocols.)72 655.2 Q(Ho)5.5 E(we)-.275 E -.165(ve)-.275 G=0A= .88 -.44(r, f).165 H(or one-to-v).44 E(ery-man)-.165 E 2.75(yr)-.165 G=0A= (eliability protocols, ARQ has)-2.75 E=0A= (limitations, including the feedback implosion problem because man)72=0A= 668.2 Q 2.75(yr)-.165 G(ecei)-2.75 E -.165(ve)-.275 G=0A= (rs are transmitting).165 E(back to the sender)72 681.2 Q 2.75(,a)-.44 G=0A= (nd the need for a back channel to send these requests from the recei)=0A= -2.75 E -.165(ve)-.275 G -.605(r.).165 G=0A= (Another limitation is that recei)72 694.2 Q -.165(ve)-.275 G(rs may e)=0A= .165 E(xperience dif)-.165 E(ferent loss patterns of pack)-.275 E=0A= (ets, and thus)-.11 E(recei)72 707.2 Q -.165(ve)-.275 G=0A= (rs may be delayed by retransmission of pack).165 E=0A= (ets that other recei)-.11 E -.165(ve)-.275 G(rs ha).165 E .33 -.165=0A= (ve l)-.22 H(ost that b).165 E(ut the)-.22 E(y)-.165 E(ha)72 720.2 Q .33=0A= -.165(ve a)-.22 H(lready recei).165 E -.165(ve)-.275 G 2.75(d. This).165=0A= F(may also cause w)2.75 E=0A= (asteful use of bandwidth used to retransmit pack)-.11 E(ets)-.11 E=0A= (Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A= 117.356(wcroft Section)-.275 F 2.75(1. [P)2.75 F(age 1])-.165 E EP=0A= %%Page: 2 2=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E(that ha)72 85 Q .33 -.165=0A= (ve a)-.22 H(lready been recei).165 E -.165(ve)-.275 G 2.75(db).165 G=0A= 2.75(ym)-2.75 G(an)-2.75 E 2.75(yo)-.165 G 2.75(ft)-2.75 G(he recei)=0A= -2.75 E -.165(ve)-.275 G(rs.).165 E(In en)72 111 Q(vironments where ARQ\=0A= is either costly or impossible because there is either a v)-.44 E=0A= (ery limited)-.165 E(capacity back channel or no back channel at all, s\=0A= uch as satellite transmission, a Data Carousel)72 124 Q=0A= (approach to reliability is sometimes used [1]. W)72 137 Q=0A= (ith a Data Carousel, the sender partitions the)-.44 E(object into equa\=0A= l length pieces of data, which we hereafter call source symbols, places\=0A= them into)72 150 Q(pack)72 163 Q(ets, and then continually c)-.11 E=0A= (ycles through and sends these pack)-.165 E(ets. Recei)-.11 E -.165(ve)=0A= -.275 G(rs continually).165 E(recei)72 176 Q .33 -.165(ve p)-.275 H(ack)=0A= .165 E(ets until the)-.11 E 2.75(yh)-.165 G -2.475 -.22(av e)-2.75 H=0A= (recei)2.97 E -.165(ve)-.275 G 2.75(dac).165 G(op)-2.75 E 2.75(yo)-.11 G=0A= 2.75(fe)-2.75 G(ach pack)-2.75 E 2.75(et. Data)-.11 F=0A= (Carousel has the adv)2.75 E(antage)-.275 E=0A= (that it requires no back channel because there is no data that \215o)72=0A= 189 Q(ws from recei)-.275 E -.165(ve)-.275 G(rs to the sender).165 E(.)=0A= -.605 E(Ho)72 202 Q(we)-.275 E -.165(ve)-.275 G .88 -.44(r, D).165 H=0A= (ata Carousel also has limitations. F).44 E(or e)-.165 E=0A= (xample, if a recei)-.165 E -.165(ve)-.275 G 2.75(rl).165 G(oses a pack)=0A= -2.75 E(et in one)-.11 E(round of transmission it must w)72 215 Q=0A= (ait an entire round before it has a chance to recei)-.11 E .33 -.165=0A= (ve t)-.275 H(hat pack).165 E(et)-.11 E(ag)72 228 Q 2.75(ain. This)-.055=0A= F(may also cause w)2.75 E=0A= (asteful use of bandwidth, as the sender continually c)-.11 E=0A= (ycles through)-.165 E(and transmits the pack)72 241 Q=0A= (ets until no recei)-.11 E -.165(ve)-.275 G 2.75(ri).165 G 2.75(sm)-2.75=0A= G(issing a pack)-2.75 E(et.)-.11 E(FEC codes pro)72 267 Q(vide a reliab\=0A= ility method that can be used to augment or replace other reliability)=0A= -.165 E(methods, especially for one-to-man)72 280 Q 2.75(yr)-.165 G=0A= (eliability protocols such as reliable IP multicast.)-2.75 E 1.76 -.88=0A= (We \214)5.5 H(rst).88 E(brie\215y re)72 293 Q(vie)-.275 E 2.75(ws)-.275=0A= G(ome of the basic properties and types of FEC codes before re)-2.75 E=0A= (vie)-.275 E(wing their uses in)-.275 E(the conte)72 306 Q=0A= (xt of reliable IP multicast.)-.165 E(Later)5.5 E 2.75(,w)-.44 G 2.75=0A= (ep)-2.75 G(ro)-2.75 E(vide a more detailed description of some of)-.165=0A= E(FEC codes.)72 319 Q=0A= (In the general literature, FEC refers to the ability to o)72 345 Q=0A= -.165(ve)-.165 G(rcome both erasures \(losses\) and bit-le).165 E -.165=0A= (ve)-.275 G(l).165 E(corruption. Ho)72 358 Q(we)-.275 E -.165(ve)-.275 G=0A= .88 -.44(r, i).165 H 2.75(nt).44 G(he case of IP multicast, lo)-2.75 E=0A= (wer netw)-.275 E(ork layers will detect corrupted)-.11 E(pack)72 371 Q=0A= (ets and discard them. Therefore, an IP multicast protocol need not be \=0A= concerned with)-.11 E(corruption; the focus is solely on erasure codes.)=0A= 72 384 Q(The payloads are generated and processed using)5.5 E(an FEC er\=0A= asure encoder and objects are reassembled from reception of pack)72 397=0A= Q(ets using the)-.11 E(corresponding FEC erasure decoder)72 410 Q(.)=0A= -.605 E(The input to an FEC encoder is some number k of equal length so\=0A= urce symbols.)72 436 Q(The FEC)5.5 E(encoder generates some number of e\=0A= ncoding symbols that are of the same length as the source)72 449 Q 2.75=0A= (symbols. The)72 462 R(chosen length of the symbols can v)2.75 E=0A= (ary upon each application of the FEC encoder)-.275 E(,)-.44 E=0A= (or it can be \214x)72 475 Q 2.75(ed. These)-.165 F=0A= (encoding symbols are placed into pack)2.75 E(ets for transmission.)-.11=0A= E(The number)5.5 E(of encoding symbols placed into each pack)72 488 Q=0A= (et can v)-.11 E(ary on a per pack)-.275 E(et basis, or a \214x)-.11 E=0A= (ed number of)-.165 E=0A= (symbols \(often one\) can be placed into each pack)72 501 Q 2.75=0A= (et. Also,)-.11 F(in each pack)2.75 E(et is placed enough)-.11 E(inform\=0A= ation to identify the particular encoding symbols carried in that pack)=0A= 72 514 Q 2.75(et. Upon)-.11 F(receipt of)2.75 E(pack)72 527 Q=0A= (ets containing encoding symbols, the recei)-.11 E -.165(ve)-.275 G 2.75=0A= (rf).165 G(eeds these encoding symbols into the)-2.75 E=0A= (corresponding FEC decoder to recreate an e)72 540 Q(xact cop)-.165 E=0A= 2.75(yo)-.11 G 2.75(ft)-2.75 G(he k source symbols.)-2.75 E(Ideally)5.5=0A= E 2.75(,t)-.715 G(he FEC)-2.75 E(decoder can recreate an e)72 553 Q=0A= (xact cop)-.165 E 2.75(yf)-.11 G(rom an)-2.75 E 2.75(yko)-.165 G 2.75=0A= (ft)-2.75 G(he encoding symbols.)-2.75 E(In a later section, we describ\=0A= e a technique for using FEC codes as described abo)72 579 Q .33 -.165=0A= (ve t)-.165 H 2.75(oh).165 G(andle)-2.75 E(blocks with v)72 592 Q=0A= (ariable length source symbols.)-.275 E(Block FEC codes w)72 618 Q=0A= (ork as follo)-.11 E 2.75(ws. The)-.275 F=0A= (input to a block FEC encoder is k source symbols and a)2.75 E=0A= (number n.)72 631 Q=0A= (The encoder generates a total of n encoding symbols.)5.5 E=0A= (The encoder is systematic if it)5.5 E(generates n-k redundant symbols \=0A= yielding an encoding block of n encoding symbols in total)72 644 Q=0A= (composed of the k source symbols and the n-k redundant symbols.)72 657=0A= Q 2.75(Ab)5.5 G(lock FEC decoder has the)-2.75 E(property that an)72 670=0A= Q 2.75(yko)-.165 G 2.75(ft)-2.75 G=0A= (he n encoding symbols in the encoding block is suf)-2.75 E=0A= (\214cient to reconstruct)-.275 E(the original k source symbols.)72 683=0A= Q(Expandable FEC codes w)72 709 Q(ork as follo)-.11 E 2.75(ws. An)-.275=0A= F -.165(ex)2.75 G(pandable FEC encoder tak).165 E(es as input k source)=0A= -.11 E(symbols and generates as man)72 722 Q 2.75(yu)-.165 G=0A= (nique encoding symbols as requested on demand, where the)-2.75 E=0A= (Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A= 117.356(wcroft Section)-.275 F 2.75(1. [P)2.75 F(age 2])-.165 E EP=0A= %%Page: 3 3=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E(amount of time for generating\=0A= each encoding symbol is the same independent of ho)72 85 Q 2.75(wm)=0A= -.275 G(an)-2.75 E(y)-.165 E(encoding symbols are generated.)72 98 Q=0A= (An e)5.5 E(xpandable FEC decoder has the property that an)-.165 E 2.75=0A= (yko)-.165 G 2.75(ft)-2.75 G(he)-2.75 E(unique encoding symbols is suf)=0A= 72 111 Q(\214cient to reconstruct the original k source symbols.)-.275 E=0A= (The abo)72 137 Q .33 -.165(ve d)-.165 H(e\214nitions e).165 E=0A= (xplain the ideal situation when the reception of an)-.165 E 2.75(yke)=0A= -.165 G(ncoding symbols is)-2.75 E(suf)72 150 Q(\214cient to reco)-.275=0A= E -.165(ve)-.165 G 2.75(rt).165 G=0A= (he k source symbols, in which case the reception o)-2.75 E -.165(ve)=0A= -.165 G(rhead is 0%.).165 E -.165(Fo)5.5 G 2.75(rs).165 G(ome)-2.75 E(p\=0A= ractical FEC codes, slightly more than k encoding symbols are needed to\=0A= reco)72 163 Q -.165(ve)-.165 G 2.75(rt).165 G(he k source)-2.75 E 2.75=0A= (symbols. If)72 176 R=0A= (k*\(1+ep\) encoding symbols are needed, we say the reception o)2.75 E=0A= -.165(ve)-.165 G(rhead is ep*100%,).165 E=0A= (e.g., if k*1.05 encoding symbols are needed then the reception o)72 189=0A= Q -.165(ve)-.165 G(rhead is 5%.).165 E(Along a dif)72 215 Q(ferent dime\=0A= nsion, we classify FEC codes loosely as being either small or lar)-.275=0A= E 2.75(ge. A)-.198 F(small FEC code is ef)72 228 Q(\214cient in terms o\=0A= f processing time requirements for encoding and decoding)-.275 E=0A= (for small v)72 241 Q(alues of k, and a lar)-.275 E(ge FEC code is ef)=0A= -.198 E(\214cient for encoding and decoding for much lar)-.275 E(ge)=0A= -.198 E -.275(va)72 254 S(lues of k.).275 E=0A= (There are implementations of block FEC codes that ha)5.5 E .33 -.165=0A= (ve e)-.22 H(ncoding times).165 E(proportional to n times the length of\=0A= the k source symbols, and decoding times proportional l)72 267 Q(times\=0A= the length of the k source symbols, where l is the number of missing s\=0A= ource symbols among)72 280 Q(the k recei)72 293 Q -.165(ve)-.275 G 2.75=0A= (de).165 G(ncoding symbols.)-2.75 E(Because of the gro)5.5 E=0A= (wth rate of the encoding and decoding times)-.275 E(as a product of k \=0A= and n, these are typically considered to be small block FEC codes.)72=0A= 306 Q(There are)5.5 E(block FEC codes with a small reception o)72 319 Q=0A= -.165(ve)-.165 G(rhead that can generate n encoding symbols and can).165=0A= E(decode the k source symbols in time proportional to the length of the\=0A= n encoding symbols.)72 332 Q(These)5.5 E=0A= (codes are considered to be lar)72 345 Q(ge block FEC codes.)-.198 E=0A= (There are e)5.5 E(xpandable FEC codes with a small)-.165 E(reception o)=0A= 72 358 Q -.165(ve)-.165 G(rhead that can generate each encoding symbol \=0A= in time roughly proportional to its).165 E(length, and can decode all k\=0A= source symbols in time roughly proportional to their length.)72 371 Q=0A= (These)5.5 E(are considered to be lar)72 384 Q(ge e)-.198 E=0A= (xpandable FEC codes.)-.165 E(Ideally)72 410 Q 2.75(,F)-.715 G=0A= (EC codes in the conte)-2.75 E=0A= (xt of IP multicast can be used to generate encoding symbols that)-.165=0A= E(are transmitted in pack)72 423 Q(ets in such a w)-.11 E=0A= (ay that each recei)-.11 E -.165(ve)-.275 G 2.75(dp).165 G(ack)-2.75 E=0A= (et is fully useful to a recei)-.11 E -.165(ve)-.275 G 2.75(rt).165 G(o)=0A= -2.75 E(reassemble the object re)72 436 Q -.055(ga)-.165 G=0A= (rdless of pre).055 E(vious pack)-.275 E=0A= (et reception patterns. Thus, if some pack)-.11 E(ets are)-.11 E=0A= (lost in transit between the sender and the recei)72 449 Q -.165(ve)=0A= -.275 G .88 -.44(r, i).165 H=0A= (nstead of asking for speci\214c retransmission of).44 E(the lost pack)=0A= 72 462 Q(ets or w)-.11 E(aiting till the pack)-.11 E=0A= (ets are resent using Data Carousel, the recei)-.11 E -.165(ve)-.275 G=0A= 2.75(rc).165 G(an use an)-2.75 E(y)-.165 E=0A= (other subsequent equal number of pack)72 475 Q(ets that arri)-.11 E .33=0A= -.165(ve t)-.275 H 2.75(or).165 G(eassemble the object.)-2.75 E=0A= (These pack)5.5 E(ets can)-.11 E(either be proacti)72 488 Q -.165(ve)=0A= -.275 G(ly transmitted or the).165 E 2.75(yc)-.165 G(an be e)-2.75 E=0A= (xplicitly requested by recei)-.165 E -.165(ve)-.275 G 2.75(rs. This)=0A= .165 F(implies)2.75 E(that the same pack)72 501 Q=0A= (et is fully useful to all recei)-.11 E -.165(ve)-.275 G=0A= (rs to reassemble the object, e).165 E -.165(ve)-.275 G 2.75(nt).165 G=0A= (hough the)-2.75 E(recei)72 514 Q -.165(ve)-.275 G(rs may ha).165 E .33=0A= -.165(ve p)-.22 H(re).165 E(viously e)-.275 E(xperienced dif)-.165 E=0A= (ferent pack)-.275 E(et loss patterns.)-.11 E(This property can)5.5 E=0A= (reduce or e)72 527 Q -.165(ve)-.275 G 2.75(ne).165 G=0A= (liminate the problems mentioned abo)-2.75 E .33 -.165(ve a)-.165 H=0A= (ssociated with ARQ and Data Carousel).165 E(and thereby dramatically i\=0A= ncrease the scalability of the protocol to orders of magnitude more)72=0A= 540 Q(recei)72 553 Q -.165(ve)-.275 G(rs.).165 E/F1 11/Times-Bold@0 SF=0A= (1.1.)72 592 Q/F2 13/Times-Bold@0 SF -.325(Ap)5.5 G=0A= (plication of FEC codecs).325 E F0 -.165(Fo)72 608.6 S 2.75(rs).165 G(o\=0A= me reliable IP multicast protocols, FEC codes are used in conjunction w\=0A= ith ARQ to pro)-2.75 E(vide)-.165 E(reliability)72 621.6 Q 5.5(.F)-.715=0A= G(or e)-5.665 E(xample, a lar)-.165 E=0A= (ge object could be partitioned into a number of source blocks)-.198 E(\=0A= consisting of a small number of source symbols each, and in a \214rst r\=0A= ound of transmission all of)72 634.6 Q=0A= (the source symbols for all the source blocks could be transmitted.)72=0A= 647.6 Q(Then, recei)5.5 E -.165(ve)-.275 G(rs could report).165 E=0A= (back to the sender the number of source symbols the)72 660.6 Q 2.75(ya)=0A= -.165 G(re missing from each source block.)-2.75 E(The)5.5 E(sender cou\=0A= ld then compute the maximum number of missing source symbols from each \=0A= source)72 673.6 Q(block among all recei)72 686.6 Q -.165(ve)-.275 G 2.75=0A= (rs. Based).165 F=0A= (on this, a small block FEC encoder could be used to generate)2.75 E(fo\=0A= r each source block a number of redundant symbols equal to the computed\=0A= maximum number)72 699.6 Q=0A= (of missing source symbols from the block among all recei)72 712.6 Q=0A= -.165(ve)-.275 G(rs, as long as this maximum).165 E=0A= (maximum for each block does not e)72 725.6 Q=0A= (xceed the number of redundant symbols that can be generated)-.165 E=0A= (Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A= 109.106(wcroft Section)-.275 F 2.75(1.1. [P)2.75 F(age 3])-.165 E EP=0A= %%Page: 4 4=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E(ef)72 85 Q(\214ciently)-.275 E=0A= 5.5(.I)-.715 G 2.75(nas)-5.5 G(econd round of transmission, the serv)=0A= -2.75 E(er w)-.165 E(ould then send all of these redundant)-.11 E=0A= (symbols for all blocks.)72 98 Q(In this e)5.5 E=0A= (xample, if there are no losses in the second round of transmission)=0A= -.165 E(then all recei)72 111 Q -.165(ve)-.275 G=0A= (rs will be able to recreate an e).165 E(xact cop)-.165 E 2.75(yo)-.11 G=0A= 2.75(fe)-2.75 G(ach original block.)-2.75 E(In this case, e)5.5 E -.165=0A= (ve)-.275 G(n).165 E(if dif)72 124 Q(ferent recei)-.275 E -.165(ve)-.275=0A= G(rs are missing dif).165 E(ferent symbols in dif)-.275 E=0A= (ferent blocks, transmitted redundant)-.275 E(symbols for a gi)72 137 Q=0A= -.165(ve)-.275 G 2.75(nb).165 G(lock are useful to all recei)-2.75 E=0A= -.165(ve)-.275 G(rs missing symbols from that block in the).165 E=0A= (second round.)72 150 Q -.165(Fo)72 176 S 2.75(ro).165 G(ther reliable \=0A= IP multicast protocols, FEC codes are used in a Data Carousel f)-2.75 E=0A= (ashion to)-.11 E(pro)72 189 Q(vide reliability)-.165 E 2.75(,w)-.715 G=0A= (hich we call an FEC Data Carousel.)-2.75 E -.165(Fo)5.5 G 2.75(re).165=0A= G(xample, an FEC Data Carousel)-2.915 E(using a lar)72 202 Q=0A= (ge block FEC code could w)-.198 E(ork as follo)-.11 E 2.75(ws. The)=0A= -.275 F(lar)2.75 E(ge block FEC encoder produces n)-.198 E(encoding sym\=0A= bols considering all the k source symbols of an object as one block. Th\=0A= e sender)72 215 Q -.165(cy)72 228 S=0A= (cles through and transmits the n encoding symbols in pack).165 E=0A= (ets in the same order in each round.)-.11 E=0A= (An FEC Data Carousel can ha)72 241 Q .33 -.165(ve m)-.22 H=0A= (uch better protection ag).165 E(ainst pack)-.055 E=0A= (et loss than a Data Carousel.)-.11 E -.165(Fo)72 254 S 2.75(re).165 G=0A= (xample, a recei)-2.915 E -.165(ve)-.275 G 2.75(rc).165 G=0A= (an join the transmission at an)-2.75 E 2.75(yp)-.165 G=0A= (oint in time, and, as long as the recei)-2.75 E -.165(ve)-.275 G(r).165=0A= E(recei)72 267 Q -.165(ve)-.275 G 2.75(sa).165 G 2.75(tl)-2.75 G=0A= (east k encoding symbols during the transmission of the ne)-2.75 E=0A= (xt n encoding symbols, the)-.165 E(recei)72 280 Q -.165(ve)-.275 G 2.75=0A= (rc).165 G(an completely reco)-2.75 E -.165(ve)-.165 G 2.75(rt).165 G=0A= (he object.)-2.75 E(This is true e)5.5 E -.165(ve)-.275 G 2.75(ni).165 G=0A= 2.75(ft)-2.75 G(he recei)-2.75 E -.165(ve)-.275 G 2.75(rs).165 G=0A= (tarts recei)-2.75 E(ving)-.275 E(pack)72 293 Q=0A= (ets in the middle of a pass through the encoding symbols.)-.11 E=0A= (This method can also be used)5.5 E(when the object is partitioned into\=0A= blocks and a short block FEC code is applied to each block)72 306 Q=0A= (separately)72 319 Q 5.5(.I)-.715 G 2.75(nt)-5.5 G(his case, as we e)=0A= -2.75 E(xplain in more detail belo)-.165 E 1.43 -.715(w, i)-.275 H 2.75=0A= (ti).715 G 2.75(su)-2.75 G(seful to interlea)-2.75 E .33 -.165(ve t)-.22=0A= H(he symbols).165 E(from the dif)72 332 Q(ferent blocks when the)-.275 E=0A= 2.75(ya)-.165 G(re transmitted.)-2.75 E(Since an)72 358 Q 2.75(yn)-.165=0A= G(umber of encoding symbols can be generated using an e)-2.75 E=0A= (xpandable FEC encoder)-.165 E(,)-.44 E=0A= (reliable IP multicast protocols that use e)72 371 Q=0A= (xpandable FEC codes generally rely solely on these codes)-.165 E=0A= (for reliability)72 384 Q 5.5(.F)-.715 G(or e)-5.665 E=0A= (xample, when an e)-.165 E=0A= (xpandable FEC code is used in a FEC Data Carousel)-.165 E=0A= (application, the encoding pack)72 397 Q(ets ne)-.11 E -.165(ve)-.275 G=0A= 2.75(rr).165 G(epeat, and thus an)-2.75 E 2.75(yko)-.165 G 2.75(ft)-2.75=0A= G(he encoding symbols in the)-2.75 E=0A= (potentially unbounded number of encoding symbols are suf)72 410 Q=0A= (\214cient to reco)-.275 E -.165(ve)-.165 G 2.75(rt).165 G=0A= (he original k source)-2.75 E(symbols.)72 423 Q -.165(Fo)72 449 S 2.75=0A= (ry).165 G(et other reliable IP multicast protocols the method to obtai\=0A= n reliability is to generate enough)-2.75 E(encoding symbols so that ea\=0A= ch encoding symbol is transmitted at most once.)72 462 Q -.165(Fo)5.5 G=0A= 2.75(re).165 G(xample, the)-2.915 E(sender can decide a priori ho)72 475=0A= Q 2.75(wm)-.275 G(an)-2.75 E 2.75(ye)-.165 G=0A= (ncoding symbols it will transmit, use an FEC code to)-2.75 E(generate \=0A= that number of encoding symbols from the object, and then transmit the \=0A= encoding)72 488 Q(symbols to all recei)72 501 Q -.165(ve)-.275 G 2.75=0A= (rs. This).165 F(method is for e)2.75 E=0A= (xample applicable to streaming protocols, where the)-.165 E(stream is \=0A= partitioned into objects, the source symbols for each object are encode\=0A= d into encoding)72 514 Q(symbols using an FEC code, and then the sets o\=0A= f encoding symbols for each object are)72 527 Q=0A= (transmitted one after the other using IP multicast.)72 540 Q/F1 11=0A= /Times-Bold@0 SF(2.)72 579 Q/F2 14/Times-Bold@0 SF(FEC Codes)5.5 E F1=0A= (2.1.)72 618 Q/F3 13/Times-Bold@0 SF(Simple codes)5.5 E F0=0A= (There are some v)72 634.6 Q(ery simple codes that are ef)-.165 E(fecti)=0A= -.275 E .33 -.165(ve f)-.275 H(or repairing pack).165 E(et loss under v)=0A= -.11 E(ery lo)-.165 E 2.75(wl)-.275 G(oss)-2.75 E 2.75(conditions. F)72=0A= 647.6 R(or e)-.165 E(xample, one simple w)-.165 E(ay to pro)-.11 E=0A= (vide protection from a single loss is to partition)-.165 E=0A= (the object into \214x)72 660.6 Q(ed size source symbols and then add a\=0A= redundant symbol that is the parity)-.165 E=0A= (\(XOR\) of all the source symbols.)72 673.6 Q=0A= (The size of a source symbol is chosen so that it \214ts perfectly)5.5 E=0A= (into the payload of a pack)72 686.6 Q(et, i.e. if the pack)-.11 E=0A= (et payload is 512 bytes then each source symbol is 512)-.11 E 2.75=0A= (bytes. The)72 699.6 R(header of each pack)2.75 E=0A= (et contains enough information to identify the payload.)-.11 E(In this)=0A= 5.5 E(case, this is an encoding symbol ID.)72 712.6 Q=0A= (The encoding symbol IDs can consist of tw)5.5 E 2.75(op)-.11 G=0A= (arts in this)-2.75 E -.165(ex)72 725.6 S 2.75(ample. The).165 F(\214rs\=0A= t part is an encoding \215ag that is equal to 1 if the encoding symbol \=0A= is a source)2.75 E(Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E=0A= (y/Cro)-.165 E 109.106(wcroft Section)-.275 F 2.75(2.1. [P)2.75 F=0A= (age 4])-.165 E EP=0A= %%Page: 5 5=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E=0A= (symbol and is equal to 0 if the encoding symbol is a redundant symbol.)=0A= 72 85 Q(The second part of the)5.5 E(encoding symbol ID is a source sym\=0A= bol ID if the encoding \215ag is 1 and a redundant symbol ID if)72 98 Q=0A= (the encoding \215ag is 0.)72 111 Q=0A= (The source symbol IDs can be numbered from 0 to k-1 and the redundant)=0A= 5.5 E(symbol ID can be 0.)72 124 Q -.165(Fo)5.5 G 2.75(re).165 G=0A= (xample, if the object consists of four source symbols that ha)-2.915 E=0A= .33 -.165(ve v)-.22 H(alues)-.11 E(a, b, c and d, then the v)72 137 Q=0A= (alue of the redundant symbol is e =3D a XOR b XOR c XOR d.)-.275 E=0A= (Then, the)5.5 E(pack)72 150 Q(ets carrying these symbols look lik)-.11=0A= E(e)-.11 E=0A= (\(1, 0: a\), \(1, 1: b\), \(1, 2: c\), \(1, 3: d\), \(0, 0: e\).)=0A= 188.714 163 Q(In this e)72 189 Q=0A= (xample, the encoding symbol ID consists of the \214rst tw)-.165 E 2.75=0A= (ov)-.11 G(alues, where the \214rst v)-3.025 E(alue is)-.275 E=0A= (the encoding \215ag and the second v)72 202 Q=0A= (alue is either a source symbol ID or the redundant symbol ID.)-.275 E=0A= (The portion of the pack)72 215 Q(et after the colon is the v)-.11 E=0A= (alue of the encoding symbol.)-.275 E(An)5.5 E 2.75(ys)-.165 G=0A= (ingle source)-2.75 E(symbol of the object can be reco)72 228 Q -.165=0A= (ve)-.165 G(red as the parity of all the other symbols.).165 E -.165(Fo)=0A= 5.5 G 2.75(re).165 G(xample, if)-2.915 E(pack)72 241 Q(ets)-.11 E=0A= (\(1, 0: a\), \(1, 1: b\), \(1, 3: d\), \(0, 0: e\))210.098 254 Q=0A= (are recei)72 280 Q -.165(ve)-.275 G 2.75(dt).165 G=0A= (hen the missing source symbol v)-2.75 E=0A= (alue with source symbol ID =3D 2 can be reco)-.275 E -.165(ve)-.165 G=0A= (red by).165 E(computing a XOR b XOR d XOR e =3D c.)72 293 Q(Another w)72=0A= 319 Q(ay of forming the encoding symbol ID is to let v)-.11 E=0A= (alues 0,...,k-1 correspond to the k)-.275 E(source symbols and v)72 332=0A= Q(alue k corresponds to the redundant symbol that is the XOR of the k s\=0A= ource)-.275 E(symbols.)72 345 Q=0A= (When the number of source symbols in the object is lar)72 371 Q=0A= (ge, a simple block code v)-.198 E(ariant of the)-.275 E(abo)72 384 Q=0A= .33 -.165(ve c)-.165 H(an be used.).165 E(In this case, the source symb\=0A= ols are grouped together into source blocks of)5.5 E=0A= (some number k of consecuti)72 397 Q .33 -.165(ve s)-.275 H=0A= (ymbols each, where k may be dif).165 E(ferent for dif)-.275 E=0A= (ferent blocks.)-.275 E(If a)5.5 E(block consists of k source symbols t\=0A= hen a redundant symbol is added to form an encoding block)72 410 Q=0A= (consisting of k+1 encoding symbols.)72 423 Q=0A= (Then, a source block consisting of k source symbols can be)5.5 E(reco)=0A= 72 436 Q -.165(ve)-.165 G(red from an).165 E 2.75(yko)-.165 G 2.75(ft)=0A= -2.75 G(he k+1 encoding symbols from the associated encoding block.)=0A= -2.75 E(Slightly more sophisticated w)72 462 Q=0A= (ays of adding redundant symbols using parity can also be used. F)-.11 E=0A= (or)-.165 E -.165(ex)72 475 S(ample, one can group a block consisting o\=0A= f k source symbols in an object into a p x p square).165 E=0A= (matrix, where p =3D sqrt\(k\).)72 488 Q(Then, for each ro)5.5 E = 2.75(war)=0A= -.275 G(edundant symbol is added that is the parity of all)-2.75 E=0A= (the source symbols in the ro)72 501 Q 4.18 -.715(w. S)-.275 H(imilarly)=0A= .715 E 2.75(,f)-.715 G=0A= (or each column a redundant symbol is added that is the)-2.75 E=0A= (parity of all the source symbols in the column.)72 514 Q(Then, an)5.5 E=0A= 2.75(yr)-.165 G .55 -.275(ow o)-2.75 H 2.75(ft).275 G=0A= (he matrix can be reco)-2.75 E -.165(ve)-.165 G(red).165 E(from an)72=0A= 527 Q 2.75(ypo)-.165 G 2.75(ft)-2.75 G(he p+1 symbols in the ro)-2.75 E=0A= 1.43 -.715(w, a)-.275 H(nd similarly for an).715 E 2.75(yc)-.165 G 2.75=0A= (olumn. Higher)-2.75 F(dimensional)2.75 E=0A= (product codes using this technique can also be used.)72 540 Q(Ho)5.5 E=0A= (we)-.275 E -.165(ve)-.275 G .88 -.44(r, o).165 H(ne must be w).44 E=0A= (ary of using these)-.11 E(constructions without some thought to)72 553=0A= Q -.11(wa)-.275 G(rds the possible loss patterns of symbols.).11 E=0A= (Ideally)5.5 E 2.75(,t)-.715 G(he)-2.75 E(property that one w)72 566 Q=0A= (ould lik)-.11 E 2.75(et)-.11 G 2.75(oo)-2.75 G=0A= (btain is that if k source symbols are encoded into n encoding)-2.75 E(\=0A= symbols \(the encoding symbols consist of the source symbols and the re\=0A= dundant symbols\) then)72 579 Q(the k source symbols can be reco)72 592=0A= Q -.165(ve)-.165 G(red from an).165 E 2.75(yko)-.165 G 2.75(ft)-2.75 G=0A= (he n encoding symbols.)-2.75 E(Using the simple)5.5 E=0A= (constructions described abo)72 605 Q .33 -.165(ve d)-.165 H=0A= (oes not yield codes that come close to obtaining this ideal).165 E=0A= (beha)72 618 Q(vior)-.22 E(.)-.605 E/F1 11/Times-Bold@0 SF(2.2.)72 657 Q=0A= /F2 13/Times-Bold@0 SF(Small block FEC codes)5.5 E F0(Reliable IP multi\=0A= cast protocols may use a block \(n, k\) FEC code [2]. F)72 673.6 Q=0A= (or such codes, k source)-.165 E=0A= (symbols are encoded into n > k encoding symbols, such that an)72 686.6=0A= Q 2.75(yko)-.165 G 2.75(ft)-2.75 G(he encoding symbols can)-2.75 E=0A= (be used to reassemble the original k source symbols.)72 699.6 Q=0A= (Thus, these codes ha)5.5 E .33 -.165(ve n)-.22 H 2.75(or).165 G=0A= (eception)-2.75 E -.165(ove)72 712.6 S=0A= (rhead when used to encode the entire object directly).165 E 5.5(.B)=0A= -.715 G(lock codes are usually systematic,)-5.5 E(which means that the \=0A= n encoding symbols consist of the k source symbols and n-k redundant)72=0A= 725.6 Q(Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165=0A= E 109.106(wcroft Section)-.275 F 2.75(2.2. [P)2.75 F(age 5])-.165 E EP=0A= %%Page: 6 6=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E(symbols generated from these \=0A= k source symbols, where the size of a redundant symbol is the)72 85 Q=0A= (same as that for a source symbol.)72 98 Q -.165(Fo)5.5 G 2.75(re).165 G=0A= (xample, the \214rst simple code \(XOR\) described in the)-2.915 E(pre)=0A= 72 111 Q(vious subsection is a \(k+1, k\) code.)-.275 E=0A= (In general, the freedom to choose n lar)5.5 E(ger than k+1 is)-.198 E=0A= (desirable, as this can pro)72 124 Q(vide much better protection ag)=0A= -.165 E(ainst losses.)-.055 E 2.75(Ap)5.5 G(opular e)-2.75 E=0A= (xample of these)-.165 E(types of codes is a class of Reed-Solomon code\=0A= s, which are based on algebraic methods using)72 137 Q=0A= (\214nite \214elds.)72 150 Q=0A= (Implementations of \(n, k\) FEC erasure codes are ef)5.5 E=0A= (\214cient enough to be used by)-.275 E(personal computers [8]. F)72 163=0A= Q(or e)-.165 E=0A= (xample, [7] describes an implementation where the encoding and)-.165 E=0A= (decoding speeds decay as C/j, where the constant C is on the order of \=0A= 10 to 80 Mbytes/second for)72 176 Q(Pentium class machines of v)72 189 Q=0A= (arious vintages and j is upper bounded by min\(k, n-k\).)-.275 E=0A= (In practice, the v)72 215 Q(alues of k and n must be small \(for e)=0A= -.275 E(xample belo)-.165 E 2.75(w2)-.275 G(56\) for such FEC codes as)=0A= -2.75 E(lar)72 228 Q(ge v)-.198 E(alues mak)-.275 E 2.75(ee)-.11 G=0A= (ncoding and decoding prohibiti)-2.75 E -.165(ve)-.275 G(ly e).165 E=0A= (xpensi)-.165 E -.165(ve)-.275 G 5.5(.A).165 G 2.75(sm)-5.5 G(an)-2.75 E=0A= 2.75(yo)-.165 G(bjects are longer)-2.75 E=0A= (than k symbols for reasonable v)72 241 Q=0A= (alues of k and the symbol length \(e.g. lar)-.275 E=0A= (ger than 16 kilobyte for k)-.198 E 2.75(=3D1)72 254 S 2.75(6u)-2.75 G=0A= (sing 1 kilobyte symbols\), the)-2.75 E 2.75(yc)-.165 G(an be di)-2.75 E=0A= (vided into a number of source blocks.)-.275 E(Each source)5.5 E=0A= (block consists of some number k of source symbols, where k may v)72 267=0A= Q(ary between dif)-.275 E(ferent source)-.275 E 2.75(blocks. The)72 280=0A= R(FEC encoder is used to encode a k source symbol source block into a n\=0A= encoding)2.75 E(symbol encoding block, where the number n of encoding \=0A= symbols in the encoding block may v)72 293 Q(ary)-.275 E=0A= (for each source block.)72 306 Q -.165(Fo)5.5 G 2.75(rar).165 G(ecei)=0A= -2.75 E -.165(ve)-.275 G 2.75(rt).165 G 2.75(oc)-2.75 G(ompletely reco)=0A= -2.75 E -.165(ve)-.165 G 2.75(rt).165 G=0A= (he object, for each source block)-2.75 E(consisting of k source symbol\=0A= s, k distinct encoding symbols \(i.e., with dif)72 319 Q=0A= (ferent encoding symbol)-.275 E(IDs\) must be recei)72 332 Q -.165(ve)=0A= -.275 G 2.75(df).165 G(rom the corresponding encoding block.)-2.75 E=0A= -.165(Fo)5.5 G 2.75(rs).165 G(ome encoding blocks, more)-2.75 E=0A= (encoding symbols may be recei)72 345 Q -.165(ve)-.275 G 2.75(dt).165 G=0A= (han there are source symbols in the corresponding source)-2.75 E=0A= (block, in which case the e)72 358 Q=0A= (xcess encoding symbols are discarded.)-.165 E(An e)5.5 E=0A= (xample encoding structure)-.165 E(is sho)72 371 Q(wn in Figure 1.)-.275=0A= E(Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A= 109.106(wcroft Section)-.275 F 2.75(2.2. [P)2.75 F(age 6])-.165 E EP=0A= %%Page: 7 7=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E/F1 8/Courier@0 SF 14.4(|s)91.2=0A= 85 S(ource symbol IDs)-14.4 E 14.4(|s)14.4 G(ource symbols IDs)-14.4 E=0A= (|)9.6 E 14.4(|o)91.2 98 S 4.8(fs)-14.4 G(ource block 0)-4.8 E 14.4(|o)=0A= 14.4 G 4.8(fs)-14.4 G(ource block 1)-4.8 E(|)14.4 E 124.8(||)153.6 111 S=0A= 124.8(vv)153.6 124 S(+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+)=0A= 91.2 137 Q(|0 |1 |2 |3 |4 |5 |6 |7 |0 |1 |2 |3 | 4|5 |6 |7 |)91.2 150 Q=0A= (+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+)91.2 163 Q(|)206.4=0A= 176 Q(FEC encoder)187.2 189 Q(|)206.4 202 Q(v)206.4 215 Q=0A= (+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+)72 228 Q=0A= (|0 |1 |2 |3 | 4| 5| 6| 7| 8| 9| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|)72 241 Q=0A= (+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+)72 254 Q=0A= 139.2(^^)144 267 S 139.2(||)144 280 S 9.6(|e)72 293 S=0A= (ncoding symbol IDs)-9.6 E 4.8(|e)38.4 G(ncoding symbol IDs)-4.8 E(|)=0A= 43.2 E 9.6(|o)72 306 S 4.8(fe)-9.6 G(ncoding block 0)-4.8 E 4.8(|o)38.4=0A= G 4.8(fe)-4.8 G(ncoding block 1)-4.8 E(|)43.2 E/F2 10/Times-Roman@0 SF=0A= (Figure 1. Encoding structure for object di)72 345 Q(vided into tw)-.25=0A= E 2.5(os)-.1 G(ource)-2.5 E(blocks consisting of 8 source symbols each,\=0A= and the FEC encoder is used to)72 358 Q(generate 2 additional redundan\=0A= t symbols \(10 encoding symbols in total\))72 371 Q(for each of the tw)=0A= 72 384 Q 2.5(os)-.1 G(ource blocks.)-2.5 E F0(In man)72 413.6 Q 2.75(yc)=0A= -.165 G(ases, an object is partitioned into equal length source blocks \=0A= each consisting of k)-2.75 E(contiguous source symbols of the object, i\=0A= .e., block c consists of the range of source symbols [ck,)72 426.6 Q=0A= 2.75(\(c+1\)k-1]. This)72 439.6 R(ensures that the FEC encoder can be o\=0A= ptimized to handle a particular number k)2.75 E(of source symbols.)72=0A= 452.6 Q(This also ensures that memory references are local when the sen\=0A= der reads)5.5 E(source symbols to encode, and when the recei)72 465.6 Q=0A= -.165(ve)-.275 G 2.75(rr).165 G(eads encoding symbols to decode.)-2.75 E=0A= (Locality of)5.5 E(reference is particularly important when the object \=0A= is stored on disk, as it reduces the disk seeks)72 478.6 Q 2.75=0A= (required. The)72 491.6 R(block number and the source symbol ID within \=0A= that block can be used to uniquely)2.75 E(specify a source symbol withi\=0A= n the object. If the size of the object is not a multiple of k source)72=0A= 504.6 Q=0A= (symbols, then the last source block will contain less than k symbols.)=0A= 72 517.6 Q(The block numbers can be numbered consecuti)72 543.6 Q -.165=0A= (ve)-.275 G(ly starting from zero.).165 E(Encoding symbols within)5.5 E=0A= 2.75(ab)72 556.6 S=0A= (lock can be uniquely identi\214ed by an encoding symbol ID.)-2.75 E=0A= (One w)5.5 E(ay of identifying encoding)-.11 E(symbols within a block i\=0A= s to use the combination of an encoding \215ag that identi\214es the sy\=0A= mbol as)72 569.6 Q(either a source symbol or a redundant symbol togethe\=0A= r with either a source symbol ID or a)72 582.6 Q(redundant symbol ID.)72=0A= 595.6 Q -.165(Fo)5.5 G 2.75(re).165 G(xample, an encoding \215ag v)=0A= -2.915 E(alue of 1 can indicate that the encoding)-.275 E(symbol is a s\=0A= ource symbol and 0 can indicate that it is a redundant symbol.)72 608.6=0A= Q(The source symbol)5.5 E(IDs can be numbered from 0 to k-1 and the red\=0A= undant symbol IDs can be numbered from 0 to n-)72 621.6 Q(k-1.)72 634.6=0A= Q -.165(Fo)72 660.6 S 2.75(re).165 G=0A= (xample, if the object consists 10 source symbols with v)-2.915 E=0A= (alues a, b, c, d, e, f, g, h, i, and j, and)-.275 E 2.75(k=3D5a)72 673.6=0A= S(nd n =3D 8, then there are tw)-2.75 E 2.75(os)-.11 G=0A= (ource blocks consisting of 5 symbols each, and there are tw)-2.75 E(o)=0A= -.11 E(encoding blocks consisting of 8 symbols each.)72 686.6 Q=0A= (Let p, q and r be the v)5.5 E(alues of the redundant)-.275 E=0A= (symbols for the \214rst encoding block, and let x, y and z be the v)72=0A= 699.6 Q(alues of the redundant symbols for)-.275 E=0A= (the second encoding block.)72 712.6 Q=0A= (Then the encoding symbols together with their identi\214ers are)5.5 E=0A= (Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A= 109.106(wcroft Section)-.275 F 2.75(2.2. [P)2.75 F(age 7])-.165 E EP=0A= %%Page: 8 8=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E/F1 8/Courier@0 SF(\(0, 1, 0: \=0A= a\), \(0, 1, 1: b\), \(0, 1, 2: c\), \(0, 1, 3: d\), \(0, 1, 4: e\),)72=0A= 85 Q(\(0, 0, 0: p\), \(0, 0, 1: q\), \(0, 0, 2: r\),)72 98 Q(\(1, 1, 0:\=0A= f\), \(1, 1, 1: g\), \(1, 1, 2: h\), \(1, 1, 3: i\), \(1, 1, 4: j\),)72=0A= 111 Q(\(1, 0, 0: x\), \(1, 0, 1: y\), \(1, 0, 2: z\).)72 124 Q/F2 10=0A= /Times-Roman@0 SF(In this e)72 163 Q(xample, the \214rst v)-.15 E=0A= (alue identi\214es the block number and the second tw)-.25 E 2.5(ov)-.1=0A= G(alues together identify the)-2.75 E(encoding symbol within the block,\=0A= i.e, the encoding symbol ID consists of the encoding \215ag together w\=0A= ith)72 176 Q(either the source symbol ID or the redundant symbol ID dep\=0A= ending on the v)72 189 Q(alue of the encoding \215ag.)-.25 E(The)5 E=0A= -.25(va)72 202 S(lue of the encoding symbol is written after the colon.)=0A= .25 E(Each block can be reco)5 E -.15(ve)-.15 G(red from an).15 E 2.5=0A= (y5o)-.15 G 2.5(ft)-2.5 G(he 8)-2.5 E=0A= (encoding symbols associated with that block.)72 215 Q -.15(Fo)5 G 2.5=0A= (re).15 G(xample, reception of)-2.65 E/F3 10/Courier@0 SF(\(0, 1, 1: b\=0A= \), \(0, 1, 2: c\), \(0, 1, 3: d\), \(0, 0, 0: p\), \(0, 0, 1: q\))84=0A= 241 Q F2(is suf)74.5 267 Q(\214cient to reco)-.25 E -.15(ve)-.15 G 2.5=0A= (rt).15 G(he \214rst source block, and reception of)-2.5 E F3(\(1, 1, 0\=0A= : f\), \(1, 1, 1: g\), \(1, 0, 0: x\), \(1, 0, 1: y\), \(1, 0, 2: z\))84=0A= 293 Q F2(is suf)72 332 Q(\214cient to reco)-.25 E -.15(ve)-.15 G 2.5(rt)=0A= .15 G(he second source block.)-2.5 E(Another w)72 358 Q(ay of uniquely \=0A= identifying encoding symbols within a block is to let the encoding symb\=0A= ol IDs for)-.1 E(source symbols be 0,...,k-1 and to let the encoding sy\=0A= mbol IDs for redundant symbols be k,...,n-1.)72 371 Q/F4 11/Times-Bold@0=0A= SF(2.3.)72 410 Q/F5 13/Times-Bold@0 SF(Lar)5.5 E(ge block FEC codes)-.13=0A= E F0 -.88(To)72 426.6 S(rnado codes [4] are lar).88 E=0A= (ge block FEC codes that pro)-.198 E(vide an alternati)-.165 E .33 -.165=0A= (ve t)-.275 H 2.75(os).165 G(mall block FEC)-2.75 E 2.75(codes. An)72=0A= 439.6 R(\(n, k\) T)2.75 E(ornado code requires slightly more than k out\=0A= of n encoding symbols to reco)-.88 E -.165(ve)-.165 G(r).165 E 2.75(ks)=0A= 72 452.6 S(ource symbols, i.e., there is a small reception o)-2.75 E=0A= -.165(ve)-.165 G 2.75(rhead. Ho).165 F(we)-.275 E -.165(ve)-.275 G .88=0A= -.44(r, t).165 H(he adv).44 E(antage is that the)-.275 E -.275(va)72=0A= 465.6 S=0A= (lue of k may be on the order of tens of thousands and still run ef).275=0A= E(\214ciently)-.275 E 5.5(.B)-.715 G(ecause of memory)-5.5 E=0A= (considerations, in practice the v)72 478.6 Q=0A= (alue of n is restricted to be a small multiple of k, e.g., n =3D 2k.)=0A= -.275 E -.165(Fo)5.5 G(r).165 E -.165(ex)72 491.6 S=0A= (ample, [3] describes an implementation of T).165 E=0A= (ornado codes where the encoding and decoding)-.88 E=0A= (speeds are tens of me)72 504.6 Q -.055(ga)-.165 G=0A= (bytes per second for Pentium class machines of v).055 E=0A= (arious vintages when k)-.275 E(is in the tens of thousands and n =3D = 2k.)=0A= 72 517.6 Q(The reception o)5.5 E -.165(ve)-.165 G(rhead for such v).165=0A= E(alues of k and n is in the)-.275 E(5-10% range.)72 530.6 Q -.88(To)5.5=0A= G(rnado codes require a lar).88 E=0A= (ge amount of out of band information to be)-.198 E=0A= (communicated to all senders and recei)72 543.6 Q -.165(ve)-.275 G=0A= (rs for each dif).165 E(ferent object length, and require an amount)=0A= -.275 E(of memory on the encoder and decoder which is proportional to t\=0A= he object length times 2n/k.)72 556.6 Q -.88(To)72 582.6 S=0A= (rnado codes are designed to ha).88 E .33 -.165(ve l)-.22 H .55 -.275=0A= (ow r).165 H(eception o).275 E -.165(ve)-.165 G(rhead on a).165 E -.165=0A= (ve)-.22 G(rage with respect to reception).165 E=0A= (of a random portion of the encoding pack)72 595.6 Q 2.75(ets. Thus,)=0A= -.11 F(to ensure that a recei)2.75 E -.165(ve)-.275 G 2.75(rc).165 G=0A= (an reassemble the)-2.75 E(object with lo)72 608.6 Q 2.75(wr)-.275 G=0A= (eception o)-2.75 E -.165(ve)-.165 G(rhead, the pack).165 E=0A= (ets are permuted into a random order before)-.11 E(transmission.)72=0A= 621.6 Q F4(2.4.)72 660.6 Q F5(Expandable FEC codes)5.5 E F0=0A= (All of the FEC codes described up to this point are block codes.)72=0A= 677.2 Q(There is a dif)5.5 E(ferent type of FEC)-.275 E=0A= (codes that we call e)72 690.2 Q(xpandable FEC codes.)-.165 E(Lik)5.5 E=0A= 2.75(eb)-.11 G(lock codes, an e)-2.75 E(xpandable FEC encoder)-.165 E=0A= (operates on an object of kno)72 703.2 Q=0A= (wn size that is partitioned into equal length source symbols.)-.275 E=0A= (Unlik)5.5 E(e)-.11 E(block codes, there is no predetermined number of \=0A= encoding symbols that can be generated for)72 716.2 Q(Luby/V)72 769 Q=0A= (icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E 109.106=0A= (wcroft Section)-.275 F 2.75(2.4. [P)2.75 F(age 8])-.165 E EP=0A= %%Page: 9 9=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E -.165(ex)72 85 S=0A= (pandable FEC codes. Instead, an e).165 E=0A= (xpandable FEC encoder can generate as fe)-.165 E 2.75(wo)-.275 G 2.75=0A= (ra)-2.75 G 2.75(sm)-2.75 G(an)-2.75 E(y)-.165 E=0A= (unique encoding symbols as required on demand.)72 98 Q 2.024 -1.012=0A= (LT c)72 124 T(odes [5] are an e)1.012 E(xample of lar)-.165 E(ge e)=0A= -.198 E(xpandable FEC codes with a small reception o)-.165 E -.165(ve)=0A= -.165 G 2.75(rhead. An).165 F 2.024 -1.012(LT e)72 137 T(ncoder uses ra\=0A= ndomization to generate each encoding symbol randomly and independently\=0A= of)1.012 E(all other encoding symbols.)72 150 Q(Lik)5.5 E 2.75(eT)-.11=0A= G(ornado codes, the number of source symbols k may be v)-3.63 E(ery)=0A= -.165 E(lar)72 163 Q(ge for L)-.198 E 2.75(Tc)-1.012 G(odes, i.e., on t\=0A= he order of tens to hundreds of thousands, and the encoder and)-2.75 E=0A= (decoder run ef)72 176 Q(\214ciently in softw)-.275 E(are. F)-.11 E=0A= (or e)-.165 E(xample the encoding and decoding speeds for L)-.165 E 2.75=0A= (Tc)-1.012 G(odes)-2.75 E(are in the range 3-20 me)72 189 Q -.055(ga)=0A= -.165 G(bytes per second for Pentium class machines of v).055 E=0A= (arious vintages when)-.275 E 2.75(ki)72 202 S 2.75(si)-2.75 G 2.75(nt)=0A= -2.75 G(he high tens of thousands.)-2.75 E(An L)5.5 E 2.75(Te)-1.012 G=0A= (ncoder can generate as fe)-2.75 E 2.75(wo)-.275 G 2.75(ra)-2.75 G 2.75=0A= (sm)-2.75 G(an)-2.75 E 2.75(ye)-.165 G(ncoding)-2.75 E=0A= (symbols as required on demand.)72 215 Q(When a ne)5.5 E 2.75(we)-.275 G=0A= (ncoding symbol is to be generated by an L)-2.75 E(T)-1.012 E(encoder)72=0A= 228 Q 2.75(,i)-.44 G 2.75(ti)-2.75 G 2.75(sb)-2.75 G(ased on a randomly\=0A= chosen encoding symbol ID that uniquely describes ho)-2.75 E 2.75(wt)=0A= -.275 G(he)-2.75 E(encoding symbol is to be generated from the source s\=0A= ymbols. In general, each encoding symbol)72 241 Q(ID v)72 254 Q(alue co\=0A= rresponds to a unique encoding symbol, and thus the space of possible e\=0A= ncoding)-.275 E(symbols is approximately four billion if for e)72 267 Q=0A= (xample the encoding symbol ID is 4 bytes.)-.165 E(Thus,)5.5 E=0A= (the chance that a particular encoding symbol is the same as an)72 280 Q=0A= 2.75(yo)-.165 G(ther particular encoding symbol)-2.75 E(is in)72 293 Q=0A= -.165(ve)-.44 G=0A= (rsely proportional to the number of possible encoding symbol IDs.).165=0A= E(An L)5.5 E 2.75(Td)-1.012 G(ecoder has the)-2.75 E=0A= (property that with v)72 306 Q(ery high probability the receipt of an)=0A= -.165 E 2.75(ys)-.165 G(et of slightly more than k randomly)-2.75 E=0A= (and independently generated encoding symbols is suf)72 319 Q=0A= (\214cient to reassemble the k source symbols.)-.275 E -.165(Fo)72 332 S=0A= 2.75(re).165 G(xample, when k is on the order of tens to hundreds of th\=0A= ousands the reception o)-2.915 E -.165(ve)-.165 G(rhead is).165 E=0A= (less than 5% with no f)72 345 Q=0A= (ailures in hundreds of millions of trials under an)-.11 E 2.75(yl)-.165=0A= G(oss conditions.)-2.75 E(Because encoding symbols are randomly and ind\=0A= ependently generated by choosing random)72 371 Q(encoding symbol IDs, L)=0A= 72 384 Q 2.75(Tc)-1.012 G(odes ha)-2.75 E .33 -.165(ve t)-.22 H=0A= (he property that encoding symbols for the same k source).165 E(symbols\=0A= can be generated and transmitted from multiple senders and recei)72 397=0A= Q -.165(ve)-.275 G 2.75(db).165 G 2.75(yar)-2.75 G(ecei)-2.75 E -.165=0A= (ve)-.275 G 2.75(ra).165 G(nd)-2.75 E(the reception o)72 410 Q -.165(ve)=0A= -.165 G(rhead and the decoding time is the same as if though all the en\=0A= coding symbols).165 E(were generated by a single sender)72 423 Q 5.5(.T)=0A= -.605 G(he only requirement is that the senders choose their)-5.5 E=0A= (encoding symbol IDs randomly and independently of one another)72 436 Q=0A= (.)-.605 E(There is a weak tradeof)72 462 Q 2.75(fb)-.275 G=0A= (etween the number of source symbols and the reception o)-2.75 E -.165=0A= (ve)-.165 G(rhead for).165 E 2.024 -1.012(LT c)72 475 T=0A= (odes, and the lar)1.012 E=0A= (ger the number of source symbols the smaller the reception o)-.198 E=0A= -.165(ve)-.165 G 2.75(rhead. Thus,).165 F=0A= (for shorter objects, it is sometimes adv)72 488 Q=0A= (antageous to partition the object into man)-.275 E 2.75(ys)-.165 G=0A= (hort source)-2.75 E=0A= (symbols and include multiple encoding symbols in each pack)72 501 Q=0A= 2.75(et. In)-.11 F(this case, a single encoding)2.75 E(symbol ID is use\=0A= d to identify the multiple encoding symbols contained in a single pack)=0A= 72 514 Q(et.)-.11 E(There are a couple of f)72 540 Q=0A= (actors for choosing the appropriate symbol length/ number of source)=0A= -.11 E(symbols tradeof)72 553 Q=0A= (f. The primary consideration is that there is a \214x)-.275 E(ed o)=0A= -.165 E -.165(ve)-.165 G(rhead per symbol in the).165 E -.165(ove)72 566=0A= S(rall processing requirements of the encoding and decoding, independen\=0A= t of the number of).165 E(source symbols.)72 579 Q=0A= (Thus, using shorter symbols means that this \214x)5.5 E(ed o)-.165 E=0A= -.165(ve)-.165 G(rhead processing per).165 E(symbol will be a lar)72 592=0A= Q(ger component of the o)-.198 E -.165(ve)-.165 G=0A= (rall processing requirements, leading to lar).165 E(ger)-.198 E -.165=0A= (ove)72 605 S(rall processing requirements.).165 E 2.75(As)5.5 G=0A= (econd much less important consideration is that there is a)-2.75 E=0A= (component of the processing per symbol that depends log)72 618 Q=0A= (arithmically on the number of source)-.055 E=0A= (symbols, and thus for this reason there is a slight preference to)72=0A= 631 Q -.11(wa)-.275 G(rds fe).11 E(wer source symbols.)-.275 E(Lik)72=0A= 657 Q 2.75(es)-.11 G=0A= (mall block codes, there is a point when the object is lar)-2.75 E=0A= (ge enough that it mak)-.198 E(es sense to)-.11 E=0A= (partition it into blocks when using L)72 670 Q 2.75(Tc)-1.012 G 2.75=0A= (odes. Generally)-2.75 F(the object is partitioned into blocks)2.75 E=0A= (whene)72 683 Q -.165(ve)-.275 G 2.75(rt).165 G=0A= (he number of source symbols times the pack)-2.75 E=0A= (et payload length is less than the size of)-.11 E(the object.)72 696 Q=0A= (Thus, if the pack)5.5 E=0A= (et payload is 1024 bytes and the maximum number of source)-.11 E=0A= (symbols is 128,000 then an)72 709 Q 2.75(yo)-.165 G(bject o)-2.75 E=0A= -.165(ve)-.165 G 2.75(r1).165 G(28 me)-2.75 E -.055(ga)-.165 G=0A= (bytes will be partitioned into more than one).055 E 2.75(block. One)72=0A= 722 R(can choose the maximum number of source symbols to use, depending\=0A= on the desired)2.75 E(Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66=0A= E(y/Cro)-.165 E 109.106(wcroft Section)-.275 F 2.75(2.4. [P)2.75 F=0A= (age 9])-.165 E EP=0A= %%Page: 10 10=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E(encoding and decoding speed v)=0A= 72 85 Q(ersus reception o)-.165 E -.165(ve)-.165 G(rhead tradeof).165 E=0A= 2.75(fd)-.275 G 2.75(esired. Encoding)-2.75 F(symbols can)2.75 E=0A= (be uniquely identi\214ed by a block number \(when the object is lar)72=0A= 98 Q(ge enough to be partitioned into)-.198 E=0A= (more than one block\) and an encoding symbol ID.)72 111 Q=0A= (The block numbers, if the)5.5 E 2.75(ya)-.165 G(re used, are)-2.75 E=0A= (generally numbered consecuti)72 124 Q -.165(ve)-.275 G=0A= (ly starting from zero within the object. The block number and the).165=0A= E(encoding symbol ID are both chosen uniformly and randomly from their \=0A= range when an encoding)72 137 Q(symbol is to be transmitted. F)72 150 Q=0A= (or e)-.165 E=0A= (xample, suppose the number of source symbols is 128,000 and)-.165 E=0A= (the number of blocks is 2.)72 163 Q(Then, each pack)5.5 E=0A= (et generated by the L)-.11 E 2.75(Te)-1.012 G=0A= (ncoder could be of the form)-2.75 E(\(b, x: y\).)72 176 Q(In this e)5.5=0A= E(xample, the \214rst v)-.165 E=0A= (alue identi\214es the block number and the second v)-.275 E(alue)-.275=0A= E(identi\214es the encoding symbol within the block.)72 189 Q(In this e)=0A= 5.5 E(xample, the block number b is either 0)-.165 E=0A= (or 1, and the encoding symbol ID x might be a 32-bit v)72 202 Q 2.75=0A= (alue. The)-.275 F -.275(va)2.75 G(lue y after the colon is the).275 E=0A= -.275(va)72 215 S(lue of the encoding symbol.).275 E/F1 11/Times-Bold@0=0A= SF(2.5.)72 254 Q/F2 13/Times-Bold@0 SF(Sour)5.5 E(ce blocks with v)-.234=0A= E(ariable length sour)-.13 E(ce symbols)-.234 E F0 -.165(Fo)72 270.6 S=0A= 2.75(ra).165 G(ll the FEC codes described abo)-2.75 E -.165(ve)-.165 G=0A= 2.75(,a).165 G=0A= (ll the source symbols in the same source block are all of)-2.75 E=0A= (the same length.)72 283.6 Q(In this section, we describe a general tec\=0A= hnique to handle the case when it is)5.5 E=0A= (desirable to use source symbols of v)72 296.6 Q=0A= (arying lengths in a single source block.)-.275 E(This technique is)5.5=0A= E(applicable to block FEC codes.)72 309.6 Q=0A= (Let l_1, l_2, ... , l_k be the lengths in bytes of k v)72 335.6 Q=0A= (arying length source symbols to be considered)-.275 E=0A= (part of the same source block.)72 348.6 Q(Let lmax be the maximum o)5.5=0A= E -.165(ve)-.165 G 2.75(ri=3D1).165 G 2.75(,.)-2.75 G(.. , k of = l_i.)-2.75=0A= E 1.76 -.88(To p)5.5 H(repare the).88 E=0A= (source block for the FEC encoder)72 361.6 Q 2.75(,p)-.44 G=0A= (ad each source symbol i out to length lmax with a suf)-2.75 E(\214x of)=0A= -.275 E(lmax-l_i zeroes, and then prepend to the be)72 374.6 Q=0A= (ginning of this the v)-.165 E(alue l_i.)-.275 E(Thus, each padded)5.5 E=0A= (source symbol is of length x+lmax, assuming that it tak)72 387.6 Q=0A= (es x bytes to store an inte)-.11 E(ger with possible)-.165 E -.275(va)=0A= 72 400.6 S(lues 0,...,lmax, where x is a protocol constant kno).275 E=0A= (wn to both the encoder and the decoder)-.275 E(.)-.605 E(These padded \=0A= source symbols, each of length x+lmax, are the input to the encoder)72=0A= 413.6 Q 2.75(,t)-.44 G(ogether with)-2.75 E(the v)72 426.6 Q(alue n.)=0A= -.275 E(The encoder then generates n-k redundant symbols, each of lengt\=0A= h x+lmax.)5.5 E(The encoding symbols that are placed into pack)72 452.6=0A= Q(ets consist of the original k v)-.11 E(arying length source)-.275 E=0A= (symbols and n-k redundant symbols, each of length x+lmax.)72 465.6 Q=0A= (From an)5.5 E 2.75(yko)-.165 G 2.75(ft)-2.75 G(he recei)-2.75 E -.165=0A= (ve)-.275 G(d).165 E(encoding symbols, the FEC decoder recreates the k \=0A= original source symbols as follo)72 478.6 Q 2.75(ws. If)-.275 F(all k)=0A= 2.75 E(original source symbols are recei)72 491.6 Q -.165(ve)-.275 G=0A= (d, then no decoding is necessary).165 E 5.5(.O)-.715 G=0A= (therwise, at least one)-5.5 E(redundant symbol is recei)72 504.6 Q=0A= -.165(ve)-.275 G(d, from which the recei).165 E -.165(ve)-.275 G 2.75=0A= (rc).165 G(an easily determine if the block is)-2.75 E(composed of v)72=0A= 517.6 Q(ariable-length source symbols: if the redundant symbol\(s\) is \=0A= longer than the source)-.275 E(symbols then the source symbols are v)72=0A= 530.6 Q(ariable-length. Note that in a v)-.275 E=0A= (ariable-length block the)-.275 E(redundant symbols are al)72 543.6 Q=0A= -.11(wa)-.11 G=0A= (ys longer than the longest source symbol, due to the presence of the)=0A= .11 E(prepended symbol-length.)72 556.6 Q(The recei)5.5 E -.165(ve)-.275=0A= G 2.75(rc).165 G(an determine the v)-2.75 E=0A= (alue of lmax by subtracting x from)-.275 E(the length of a recei)72=0A= 569.6 Q -.165(ve)-.275 G 2.75(dr).165 G(edundant symbol.)-2.75 E -.165=0A= (Fo)5.5 G 2.75(re).165 G(ach of the recei)-2.75 E -.165(ve)-.275 G 2.75=0A= (do).165 G(riginal source symbols, the)-2.75 E(recei)72 582.6 Q -.165=0A= (ve)-.275 G 2.75(rc).165 G=0A= (an generate the corresponding padded source symbol as described abo)=0A= -2.75 E -.165(ve)-.165 G 5.5(.T).165 G(hen, the)-5.5 E=0A= (input to the FEC decoder is the set of recei)72 595.6 Q -.165(ve)-.275=0A= G 2.75(dr).165 G(edundant symbols, together with the set of padded)-2.75=0A= E(source symbols constructed from the recei)72 608.6 Q -.165(ve)-.275 G=0A= 2.75(do).165 G(riginal symbols.)-2.75 E(The FEC decoder then produces)=0A= 5.5 E(the set of k padded source symbols.)72 621.6 Q=0A= (Once the k padded source symbols ha)5.5 E .33 -.165(ve b)-.22 H=0A= (een reco).165 E -.165(ve)-.165 G(red, the).165 E=0A= (length l_i of original source symbol i can be reco)72 634.6 Q -.165(ve)=0A= -.165 G(red from the \214rst x bytes of the ith padded).165 E(source sy\=0A= mbol, and then original source symbol i is obtained by taking the ne)72=0A= 647.6 Q(xt l_i bytes)-.165 E(follo)72 660.6 Q=0A= (wing the x bytes of the length \214eld.)-.275 E(Luby/V)72 769 Q=0A= (icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E 103.606=0A= (wcroft Section)-.275 F 2.75(2.5. [P)2.75 F(age 10])-.165 E EP=0A= %%Page: 11 11=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(3.)72 85=0A= Q/F2 14/Times-Bold@0 SF(Security Considerations)5.5 E F0(The use of FEC\=0A= , in and of itself, imposes no additional security considerations v)72=0A= 101.6 Q(ersus sending the)-.165 E(same information without FEC.)72 114.6=0A= Q(Ho)5.5 E(we)-.275 E -.165(ve)-.275 G .88 -.44(r, j).165 H(ust lik).44=0A= E 2.75(ef)-.11 G(or an)-2.75 E 2.75(yt)-.165 G=0A= (ransmission system, a malicious)-2.75 E(sender may try to inject pack)=0A= 72 127.6 Q(ets carrying corrupted encoding symbols.)-.11 E(If a recei)=0A= 5.5 E -.165(ve)-.275 G 2.75(ra).165 G(ccepts one)-2.75 E(or more corrup\=0A= ted encoding symbol in place of authentic ones then such a recei)72=0A= 140.6 Q -.165(ve)-.275 G 2.75(rm).165 G(ay)-2.75 E=0A= (reconstruct a corrupted object.)72 153.6 Q(Application-le)72 179.6 Q=0A= -.165(ve)-.275 G 2.75(lt).165 G=0A= (ransmission object authentication can detect the corrupted transfer)=0A= -2.75 E 2.75(,b)-.44 G(ut the)-2.97 E(recei)72 192.6 Q -.165(ve)-.275 G=0A= 2.75(rm).165 G(ust then discard the transferred object. Thus, injecting\=0A= corrupted encoding symbols the)-2.75 E(y)-.165 E(are accepted as v)72=0A= 205.6 Q(alid encoding symbols by a recei)-.275 E -.165(ve)-.275 G 2.75=0A= (ri).165 G 2.75(sa)-2.75 G 2.75(tt)-2.75 G(he v)-2.75 E(ery least an ef)=0A= -.165 E(fecti)-.275 E .33 -.165(ve d)-.275 H(enial of).165 E=0A= (service attack.)72 218.6 Q(In light of this possibility)72 244.6 Q 2.75=0A= (,F)-.715 G(EC recei)-2.75 E -.165(ve)-.275 G=0A= (rs may screen the source address of a recei).165 E -.165(ve)-.275 G=0A= 2.75(ds).165 G(ymbol)-2.75 E(ag)72 257.6 Q=0A= (ainst a list of authentic transmitter addresses.)-.055 E=0A= (Since source addresses may be spoofed, transport)5.5 E=0A= (protocols using FEC may pro)72 270.6 Q(vide mechanisms for rob)-.165 E=0A= (ust source authentication of each encoding)-.22 E=0A= (symbol. Multicast routers along the path of a FEC transfer may pro)72=0A= 283.6 Q(vide the capability of)-.165 E(discarding multicast pack)72=0A= 296.6 Q(ets that originated on that subnet, and whose source IP address\=0A= does not)-.11 E(correspond with that subnet.)72 309.6 Q=0A= (It is recommended that a pack)72 335.6 Q=0A= (et authentication scheme such as TESLA [6] be used in conjunction)-.11=0A= E(with FEC codes.)72 348.6 Q(Then, pack)5.5 E=0A= (ets that cannot be authenticated can be discarded and the object can)=0A= -.11 E(be reliably reco)72 361.6 Q -.165(ve)-.165 G(red from the recei)=0A= .165 E -.165(ve)-.275 G 2.75(da).165 G(uthenticated pack)-2.75 E(ets.)=0A= -.11 E F1(4.)72 400.6 Q F2(Intellectual Pr)5.5 E(operty Disclosur)-.252=0A= E(e)-.252 E F0 -.88(To)72 417.2 S(rnado codes [4] ha).88 E .33 -.165=0A= (ve b)-.22 H(oth patents issued and patents pending.).165 E=0A= (There is an issued patent for L)5.5 E(T)-1.012 E(codes [5].)72 430.2 Q=0A= F1(5.)72 456.2 Q F2(Ackno)5.5 E(wledgments)-.14 E F0(Thanks to V)72=0A= 472.8 Q(incent Roca and Hayder Radha for their detailed comments on thi\=0A= s draft.)-.66 E F1(6.)72 511.8 Q F2(Refer)5.5 E(ences)-.252 E F0=0A= ([1] Acharya, S., Franklin, M., and Zdonik, S., `)72 528.4 Q=0A= (`Dissemination- Based Data Deli)-.814 E -.165(ve)-.275 G(ry Using).165=0A= E(Broadcast Disks')72 541.4 Q=0A= (', IEEE Personal Communications, pp.50-60, Dec 1995.)-.814 E=0A= ([2] Blahut, R.E., `)72 567.4 Q=0A= (`Theory and Practice of Error Control Codes')-.814 E(', Addison W)-.814=0A= E(esle)-.88 E 1.43 -.715(y, M)-.165 H 2.75(A1).715 G(984.)-2.75 E=0A= ([3] Byers, J.W)72 593.4 Q(., Luby)-1.012 E 2.75(,M)-.715 G=0A= (., Mitzenmacher)-2.75 E 2.75(,M)-.44 G(., and Re)-2.75 E(ge, A., `)=0A= -.165 E 1.76 -.88(`A D)-.814 H(igital F).88 E(ountain Approach to)-.165=0A= E(Reliable Distrib)72 606.4 Q(ution of Bulk Data')-.22 E=0A= (', Proceedings A)-.814 E(CM SIGCOMM '98, V)-.44 E(ancouv)-1.221 E(er)=0A= -.165 E 2.75(,C)-.44 G(anada,)-2.75 E(Sept 1998.)72 619.4 Q([4] Luby)72=0A= 645.4 Q 2.75(,M)-.715 G(., Mitzenmacher)-2.75 E 2.75(,M)-.44 G=0A= (., Shokrollahi, A., Spielman, D., `)-2.75 E(`Ef)-.814 E=0A= (\214cient Erasure Correcting)-.275 E(Codes')72 658.4 Q(', IEEE T)-.814=0A= E(ransactions on Information Theory)-.385 E 2.75(,S)-.715 G=0A= (pecial Issue: Codes on Graphs and Iterati)-2.75 E -.165(ve)-.275 G=0A= (Algorithms, pp. 569-584, V)72 671.4 Q(ol. 47, No. 2, February 2001.)=0A= -1.419 E([5] Luby)72 697.4 Q 2.75(,M)-.715 G(., "Information Additi)=0A= -2.75 E .33 -.165(ve C)-.275 H=0A= (ode Generator and Decoder for Communication Systems",).165 E(U.S. P)72=0A= 710.4 Q(atent No. 6,307,487, October 23, 2001.)-.165 E(Luby/V)72 769 Q=0A= (icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E 111.856=0A= (wcroft Section)-.275 F 2.75(6. [P)2.75 F(age 11])-.165 E EP=0A= %%Page: 12 12=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E=0A= ([6] Perrig, A., Canetti, R., Song, D., T)72 85 Q(yg)-.88 E(ar)-.055 E=0A= 2.75(,J)-.44 G(.D., "Ef)-2.75 E=0A= (\214cient and Secure Source Authentication for)-.275 E=0A= (Multicast", Netw)72 98 Q(ork and Distrib)-.11 E=0A= (uted System Security Symposium, NDSS 2001, pp. 35-46,)-.22 E=0A= (February 2001.)72 111 Q([7] Rizzo, L., `)72 137 Q(`Ef)-.814 E(fecti)=0A= -.275 E .33 -.165(ve E)-.275 H=0A= (rasure Codes for Reliable Computer Communication Protocols').165 E=0A= (', A)-.814 E(CM)-.44 E(SIGCOMM Computer Communication Re)72 150 Q(vie)=0A= -.275 E 1.43 -.715(w, V)-.275 H(ol.27, No.2, pp.24-36, Apr 1997.)-.704 E=0A= ([8] Rizzo, L., `)72 176 Q(`On the Feasibility of Softw)-.814 E=0A= (are FEC')-.11 E(', DEIT T)-.814 E(ech Report,)-.77 E(http://www)72 189=0A= Q(.iet.unipi.it/~luigi/softfec.ps, Jan 1997.)-.715 E/F1 11/Times-Bold@0=0A= SF(7.)72 241 Q/F2 14/Times-Bold@0 SF -.7(Au)5.5 G(thors' Addr).7 E=0A= (esses)-.252 E F0(Michael Luby)80.25 257.6 Q(luby@digitalfountain.com)=0A= 80.25 270.6 Q(Digital F)80.25 283.6 Q(ountain)-.165 E(39141 Ci)80.25=0A= 296.6 Q(vic Center Dri)-.275 E -.165(ve)-.275 G(Suite 300)80.25 309.6 Q=0A= (Fremont, CA)80.25 322.6 Q(94538)5.5 E(Lorenzo V)80.25 348.6 Q(icisano)=0A= -.66 E(lorenzo@cisco.com)80.25 361.6 Q(cisco Systems, Inc.)80.25 374.6 Q=0A= (170 W)80.25 387.6 Q(est T)-.88 E(asman Dr)-.88 E(.,)-.605 E=0A= (San Jose, CA, USA, 95134)80.25 400.6 Q(Jim Gemmell)80.25 426.6 Q=0A= (jgemmell@microsoft.com)80.25 439.6 Q(Microsoft Research)80.25 452.6 Q=0A= (301 Ho)80.25 465.6 Q -.11(wa)-.275 G(rd St., #830).11 E=0A= (San Francisco, CA, USA, 94105)80.25 478.6 Q(Luigi Rizzo)80.25 504.6 Q=0A= (luigi@iet.unipi.it)80.25 517.6 Q -.44(AC)80.25 530.6 S=0A= (IRI, 1947 Center St., Berk).44 E(ele)-.11 E 2.75(yC)-.165 G 2.75(A9)=0A= -2.75 G(4704)-2.75 E(and)80.25 543.6 Q(Dip. di Ing. dell'Informazione)=0A= 80.25 556.6 Q(Uni)80.25 569.6 Q -.165(ve)-.275 G(rsita` di Pisa).165 E=0A= (via Diotisalvi 2, 56126 Pisa, Italy)80.25 582.6 Q(Mark Handle)80.25=0A= 608.6 Q(y)-.165 E(mjh@aciri.or)80.25 621.6 Q(g)-.198 E -.44(AC)80.25=0A= 634.6 S(IRI).44 E(1947 Center St.)80.25 647.6 Q(Berk)80.25 660.6 Q(ele)=0A= -.11 E 2.75(yC)-.165 G(A, USA, 94704)-2.75 E(Jon Cro)80.25 686.6 Q=0A= (wcroft)-.275 E(J.Cro)80.25 699.6 Q(wcroft@cs.ucl.ac.uk)-.275 E=0A= (Department of Computer Science)80.25 712.6 Q(Uni)80.25 725.6 Q -.165=0A= (ve)-.275 G(rsity Colle).165 E(ge London)-.165 E(Luby/V)72 769 Q=0A= (icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E 111.856=0A= (wcroft Section)-.275 F 2.75(7. [P)2.75 F(age 12])-.165 E EP=0A= %%Page: 13 13=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E(Go)80.25 85 Q(wer Street,)=0A= -.275 E(London WC1E 6BT)80.25 98 Q 2.75(,U)-.814 G(K)-2.75 E(Luby/V)72=0A= 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E 111.856=0A= (wcroft Section)-.275 F 2.75(7. [P)2.75 F(age 13])-.165 E EP=0A= %%Page: 14 14=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(8.)72 85=0A= Q/F2 14/Times-Bold@0 SF(Full Copyright Statement)5.5 E F0(Cop)72 101.6 Q=0A= (yright \(C\) The Internet Society \(2001\).)-.11 E(All Rights Reserv)=0A= 5.5 E(ed.)-.165 E(This document and translations of it may be copied an\=0A= d furnished to others, and deri)72 118.2 Q -.275(va)-.275 G(ti).275 E=0A= .33 -.165(ve w)-.275 H(orks).055 E(that comment on or otherwise e)72=0A= 131.2 Q=0A= (xplain it or assist in its implementation may be prepared, copied,)=0A= -.165 E(published and distrib)72 144.2 Q=0A= (uted, in whole or in part, without restriction of an)-.22 E 2.75(yk)=0A= -.165 G(ind, pro)-2.75 E(vided that the)-.165 E(abo)72 157.2 Q .33 -.165=0A= (ve c)-.165 H(op).165 E(yright notice and this paragraph are included o\=0A= n all such copies and deri)-.11 E -.275(va)-.275 G(ti).275 E .33 -.165=0A= (ve w)-.275 H(orks.).055 E(Ho)72 170.2 Q(we)-.275 E -.165(ve)-.275 G .88=0A= -.44(r, t).165 H(his document itself may not be modi\214ed in an).44 E=0A= 2.75(yw)-.165 G(ay)-2.86 E 2.75(,s)-.715 G(uch as by remo)-2.75 E=0A= (ving the)-.165 E(cop)72 183.2 Q(yright notice or references to the Int\=0A= ernet Society or other Internet or)-.11 E -.055(ga)-.198 G(nizations, e)=0A= .055 E(xcept as)-.165 E(needed for the purpose of de)72 196.2 Q -.165=0A= (ve)-.275 G(loping Internet standards in which case the procedures for)=0A= .165 E(cop)72 209.2 Q=0A= (yrights de\214ned in the Internet languages other than English.)-.11 E=0A= (The limited permissions granted abo)72 225.8 Q .33 -.165(ve a)-.165 H=0A= (re perpetual and will not be re).165 E -.22(vo)-.275 G -.11(ke).22 G=0A= 2.75(db).11 G 2.75(yt)-2.75 G(he Internet)-2.75 E=0A= (Society or its successors or assigns.)72 238.8 Q=0A= (This document and the information contained herein is pro)72 255.4 Q=0A= (vided on an "AS IS" basis and THE)-.165 E=0A= (INTERNET SOCIETY AND THE INTERNET ENGINEERING T)72 268.4 Q=0A= (ASK FORCE DISCLAIMS)-1.023 E(ALL W)72 281.4 Q=0A= (ARRANTIES, EXPRESS OR IMPLIED, INCLUDING B)-1.32 E(UT NO)-.11 E 2.75=0A= (TL)-.44 G(IMITED T)-2.75 E 2.75(OA)-.198 G(NY)-2.75 E -1.32(WA)72 294.4=0A= S(RRANTY THA)1.32 E 2.75(TT)-1.221 G(HE USE OF THE INFORMA)-2.75 E=0A= (TION HEREIN WILL NO)-1.221 E 2.75(TI)-.44 G(NFRINGE)-2.75 E=0A= (ANY RIGHTS OR ANY IMPLIED W)72 307.4 Q(ARRANTIES OF MERCHANT)-1.32 E=0A= (ABILITY OR FITNESS)-1.023 E(FOR A P)72 320.4 Q(AR)-1.012 E=0A= (TICULAR PURPOSE.")-.66 E(Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)=0A= -.66 E(y/Cro)-.165 E 111.856(wcroft Section)-.275 F 2.75(8. [P)2.75 F=0A= (age 14])-.165 E EP=0A= %%Page: 15 15=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E(Luby/V)72 769 Q=0A= (icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E 111.856=0A= (wcroft Section)-.275 F 2.75(8. [P)2.75 F(age 15])-.165 E EP=0A= %%Trailer=0A= end=0A= %%EOF=0A= ------=_NextPart_000_0000_01C157E0.145218E0-- >From owner-rmt@listserv.lbl.gov Thu Oct 18 14:23:30 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9ILKGV04294; Thu, 18 Oct 2001 14:20:16 -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.11.2/8.11.2) with ESMTP id f9ILKFp04290 for ; Thu, 18 Oct 2001 14:20:15 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9ILKEj23001 for ; Thu, 18 Oct 2001 14:20:14 -0700 (PDT) Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9ILKCb22959 for ; Thu, 18 Oct 2001 14:20:12 -0700 (PDT) Received: (qmail 23767 invoked from network); 18 Oct 2001 21:20:07 -0000 Received: from mail.intranet (10.1.1.37) by mx.digitalfountain.com with SMTP; 18 Oct 2001 21:20:07 -0000 Received: from bozz (dhcp-10-1-2-180.intranet [10.1.2.180]) by mail.intranet (8.9.3/8.9.3) with SMTP id OAA31278; Thu, 18 Oct 2001 14:19:40 -0700 X-Authentication-Warning: mail.intranet: Host dhcp-10-1-2-180.intranet [10.1.2.180] claimed to be bozz From: "Michael Luby" To: "Internet-Drafts@Ietf. Org" , "Rmt@Lbl. Gov" Cc: "Michael Luby" Subject: draft-ietf-rmt-bb-lct-02.txt Date: Thu, 18 Oct 2001 14:25:04 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0005_01C157E0.AE079D70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C157E0.AE079D70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please post this draft on the IETF Internet Drafts archive. This is an update of an existing WG draft (RMT). This also serves as a last call before moving this towards RFC status. Please send any comments or concerns to the RMT list by Monday, October 22. Thanks, Mike Luby ------=_NextPart_000_0005_01C157E0.AE079D70 Content-Type: text/plain; name="draft-ietf-rmt-bb-lct-02.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-rmt-bb-lct-02.txt" Internet Engineering Task Force RMT WG=0A= INTERNET-DRAFT M.Luby/Digital Fountain=0A= draft-ietf-rmt-bb-lct-02.txt J.Gemmell/Microsoft=0A= L.Vicisano/Cisco=0A= L.Rizzo/ACIRI and Univ. Pisa=0A= M.Handley/ACIRI=0A= J. Crowcroft/UCL=0A= 18 October 2001=0A= Expires: April 2002=0A= =0A= =0A= Layered Coding Transport:=0A= A massively scalable content delivery transport building block=0A= =0A= =0A= =0A= Status of this Document=0A= =0A= This document is an Internet-Draft and is in full conformance with all=0A= provisions of Section 10 of RFC2026.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering Task=0A= Force (IETF), its areas, and its working groups. Note that other groups=0A= may also distribute working documents as Internet-Drafts.=0A= =0A= Internet-Drafts are valid for a maximum of six months and may be=0A= updated, replaced, or obsoleted by other documents at any time. It is=0A= inappropriate to use Internet-Drafts as reference material or to cite=0A= them other than as a "work in progress".=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt=0A= =0A= To view the list Internet-Draft Shadow Directories, see=0A= http://www.ietf.org/shadow.html.=0A= =0A= This document is a product of the IETF RMT WG. Comments should be=0A= addressed to the authors, or the WG's mailing list at rmt@lbl.gov.=0A= =0A= =0A= Abstract=0A= =0A= =0A= This document describes Layered Coding Transport, a massively=0A= scalable reliable content delivery and stream delivery=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft [Page 1]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= transport, hereafter referred to as LCT. LCT can be used for=0A= multi-rate delivery to large sets of receivers. In LCT,=0A= scalability and congestion control are supported through the=0A= use of layered coding techniques. Coding techniques can be=0A= combined with LCT to provide support for reliability.=0A= =0A= Congestion control is receiver driven, and can be achieved by=0A= sending packets in the session to multiple ``LCT channels'',=0A= and having receivers join and leave LCT channels (thus=0A= adjusting their reception rate) in reaction to network=0A= conditions in a manner that is network friendly.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft [Page 2]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= Table of Contents=0A= =0A= =0A= 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4=0A= 1.1. Related Documents. . . . . . . . . . . . . . . . . . 6=0A= 1.2. Environmental Requirements and Considerations. . . . 7=0A= 2. General Architecture. . . . . . . . . . . . . . . . . . 9=0A= 2.1. Delivery service models. . . . . . . . . . . . . . . 10=0A= 2.2. Congestion Control . . . . . . . . . . . . . . . . . 12=0A= 3. LCT header. . . . . . . . . . . . . . . . . . . . . . . 12=0A= 3.1. Default LCT header format. . . . . . . . . . . . . . 12=0A= 3.2. Header-Extension Fields. . . . . . . . . . . . . . . 18=0A= 4. Procedures. . . . . . . . . . . . . . . . . . . . . . . 21=0A= 4.1. Sender Operation . . . . . . . . . . . . . . . . . . 21=0A= 4.2. Receiver Operation . . . . . . . . . . . . . . . . . 23=0A= 5. Security Considerations . . . . . . . . . . . . . . . . 24=0A= 6. IANA Considerations . . . . . . . . . . . . . . . . . . 24=0A= 7. Intellectual Property Issues. . . . . . . . . . . . . . 24=0A= 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 25=0A= 9. References. . . . . . . . . . . . . . . . . . . . . . . 25=0A= 10. Authors' Addresses . . . . . . . . . . . . . . . . . . 26=0A= 11. Full Copyright Statement . . . . . . . . . . . . . . . 28=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft [Page 3]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= 1. Introduction=0A= =0A= This document describes a massively scalable reliable content delivery=0A= and stream delivery transport, Layered Coding Transport (LCT), for=0A= multi-rate content delivery primarily designed to be used with the IP=0A= multicast network service, but may also be used with other basic=0A= underlying network or transport services such as unicast UDP. LCT=0A= supports both reliable and unreliable delivery.=0A= =0A= LCT is a building block as defined in RFC3048. Protocol instantiations=0A= may be built by combining the LCT framework with other components. A=0A= complete protocol instantiation that uses LCT must include a congestion=0A= control protocol that is compatible with LCT and that conforms to=0A= RFC2357. A complete protocol instantiation that uses LCT may include a=0A= scalable reliability protocol that is compatible with LCT, it may=0A= include an session control protocol that is compatible with LCT, and it=0A= may include other protocols such as security protocols.=0A= =0A= LCT is presumed to be used with an underlying network or transport=0A= service that is a "best effort" service that does not guarantee packet=0A= reception, packet reception order, and which does not have any support=0A= for flow or congestion control. For example, the Any-Source Multicast=0A= (ASM) model of IP multicast as defined in RFC1112 is such a "best=0A= effort" network service. While the basic service provided by RFC1112 is=0A= largely scalable, providing congestion control or reliability should be=0A= done carefully to avoid severe scalability limitations, especially in=0A= presence of heterogeneous sets of receivers.=0A= =0A= Packets with LCT headers are carried in LCT channels. An LCT channel is=0A= defined by the combination of a sender and an address associated with=0A= the channel by the sender. A receiver may join a channel to start=0A= receiving the data packets sent to the channel by the sender, and a=0A= receiver may leave a channel to stop receiving data packets from the=0A= channel.=0A= =0A= An LCT session consists of a set of logically grouped LCT channels=0A= associated with a single sender carrying packets with LCT headers for=0A= one or more objects. Congestion control that conforms to RFC2357 must=0A= be used between receivers and the sender for each LCT session.=0A= Congestion control refers to the ability to adapt throughput to the=0A= available bandwidth on the path from the sender to a receiver, and to=0A= share bandwidth fairly with competing flows such as TCP. Thus, the total=0A= flow of packets flowing to each receiver participating in an LCT session=0A= must not compete unfairly with existing flow adaptive protocols such as=0A= TCP.=0A= =0A= A multi-rate or a single-rate congestion control protcol can be used=0A= with LCT. For multi-rate protocols, a session typically consists of=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 1. [Page 4]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= more than one channel and the sender sends packets to the channels in=0A= the session at rates that do not depend on the receivers. Each receiver=0A= adjusts its reception rate during its participation in the session by=0A= joining and leaving channels dynamically depending on the available=0A= bandwidth to the sender independent of all other receivers. Thus, for=0A= multi-rate protocols, the reception rate of each receiver may vary=0A= dynamically independent of the other receivers.=0A= =0A= For single-rate protocols, a session typically consists of one channel=0A= and the sender sends packets to the channel at variable rates over time=0A= depending on feedback from receivers. Each receiver remains joined to=0A= the channel during its participation in the session. Thus, for single-=0A= rate protocols, the reception rate of each receiver may vary dynamically=0A= but in coordination with all receivers. Generally, a multi-rate=0A= protocol is preferable to a single-rate protocol in a heterogeneous=0A= receiver environment, but only if it can be achieved without sacrificing=0A= scalability. Some possible multi-rate congestion control protocols are=0A= described in [11] and [1]. A possible single-rate congestion control=0A= protocol is described in [10].=0A= =0A= Layered coding refers to the ability to produce a coded stream of=0A= packets that can be partioned into an ordered set of layers. The coding=0A= is meant to provide some form of reliability, and the layering is meant=0A= to allow the receiver experience (in terms of quality of playout, or=0A= overall transfer speed) to vary in a predictable way depending on how=0A= many consecutive layers of packets the receiver is receiving.=0A= =0A= Layered coding can be naturally combined with multi-rate congestion=0A= control. For example, the sender could send the packets for each layer=0A= to a separate channel associated with the session, and then receivers=0A= dynamically join and leave channels to adjust their reception rate=0A= according to the multi-rate congestion control protocol.=0A= =0A= Layered coding can also be combined with single-rate congestion control.=0A= For example, the sender could dynamically vary how many layers are sent=0A= to the channel associated with the session as the rate of transmission=0A= varies according to the single-rate congestion control protocol.=0A= =0A= The concept of layered coding was first introduced with reference to=0A= audio and video streams. For example, the information associated with a=0A= TV broadcast could be partitioned into three layers, corresponding to=0A= black and white, color, and HDTV quality. Receivers can experience=0A= different quality without the need for the sender to replicate=0A= information in the different layers.=0A= =0A= The concept of layered coding can be naturally extended to reliable=0A= content delivery protocols when Forward Error Correction (FEC)=0A= techniques are used for coding the data stream [9] [7] [3] [11] [2]. By=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 1. [Page 5]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= using FEC, the data stream is transformed in such a way that=0A= reconstruction of a data object does not depend on the reception of=0A= specific data packets, but only on the number of different packets=0A= received. As a result, by increasing the number of layers a receiver is=0A= receiving from, the receiver can reduce the transfer time accordingly.=0A= More details on the use of FEC for reliable content delivery can be=0A= found in [5]. Reliable protocols aim at giving guarantees on the=0A= reliable delivery of data from the sender to the intended recipients.=0A= Guarantees vary from simple packet data integrity to reliable delivery=0A= of a precise copy of an object to all intended recipients. Several=0A= reliable content delivery protocols have been built on top of IP=0A= multicast, but scalability was not a design goal for many of them.=0A= =0A= Two of the key difficulties in scaling reliable content delivery using=0A= IP multicast are dealing with the amount of data that flows from=0A= receivers back to the sender, and the associated response (generally=0A= data retransmissions) from the sender. Protocols that avoid any such=0A= feedback, and minimize the amount of retransmissions, can be massively=0A= scalable. LCT can be used in conjunction with FEC codes or a layered=0A= codec to achieve reliability with little or no feedback.=0A= =0A= Scalability refers to the behavior of the protocol in relation to the=0A= number of receivers and network paths, their heterogeneity, and the=0A= ability to accommodate dynamically variable sets of receivers.=0A= Scalability limitations can come from memory or processing requirements,=0A= or from the amount of packet traffic generated by the protocol. In=0A= turn, such limitations may be a consequence of the features that a=0A= complete reliable content delivery or stream delivery protocol is=0A= expected to provide.=0A= =0A= In this document we present the architecture and abstract LCT header=0A= structure, and describe its support for congestion control.=0A= =0A= The key words "must", "must not", "required", "shall", "shall not",=0A= "should", "should not", "recommended", "may", and "optional" in this=0A= document are to be interpreted as described in RFC2119.=0A= =0A= =0A= 1.1. Related Documents=0A= =0A= As described in RFC3048, LCT is a building block that is intended to be=0A= used, in conjunction with other building blocks, to help specify a=0A= protocol instantiation. A congestion control building block that uses=0A= the Congestion Control information field within the LCT header must be=0A= used by any protocol instantiation that uses LCT, and other building=0A= blocks may also be used, such as a reliability building block.=0A= =0A= A more in-depth description of the use of FEC in Reliable Multicast=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 1.1. [Page 6]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= Transport (RMT) protocols is given in [5]. Some of the FEC codecs that=0A= may be used in conjunction with LCT for reliable content delivery are=0A= specified in [6]. The Codepoint field in the LCT header is an opaque=0A= field that can be used to carry information related to the encoding of=0A= the packet payload.=0A= =0A= Implementors of protocol instantiations that use LCT must also implement=0A= congestion control in accordance to RFC2357, where the congestion=0A= control is over the entire session. Some possible schemes are specified=0A= in [11] and [1]. The Congestion Control Information field in the LCT=0A= header is an opaque field that is reserved to carry information related=0A= to congestion control. There may also be congestion control Header=0A= Extension fields that carry additional information related to congestion=0A= control.=0A= =0A= Generic Router Assist may be used in conjunction with LCT.=0A= =0A= It is recommended that LCT implementors use some packet authentication=0A= scheme to protect the protocol from attacks. An example of a possibly=0A= suitable scheme is described in [8].=0A= =0A= 1.2. Environmental Requirements and Considerations=0A= =0A= LCT is intended for congestion controlled delivery of objects and=0A= streams (both reliable content delivery and streaming of multimedia=0A= information).=0A= =0A= LCT is most applicable for delivery of objects or streams of substantial=0A= length, i.e., objects or streams that range in length from hundreds of=0A= kilobytes to many gigabytes, and whose transfer time is in the order of=0A= tens of seconds or more.=0A= =0A= LCT can be used with both multicast and unicast delivery. LCT requires=0A= connectivity between a sender and receivers, but does not require=0A= connectivity from receivers to a sender. LCT inherently works with all=0A= types of networks, including LANs, WANs, Intranets, the Internet,=0A= asymmetric networks, wireless networks, and satellite networks. Thus,=0A= the inherent raw scalability of LCT is unlimited. However, when other=0A= specific applications are built on top of LCT, then these applications=0A= by their very nature may limit scalability. For example, if an=0A= application requires receivers to retrieve out of band information in=0A= order to join a session, or an application allows receivers to send=0A= requests back to the sender to report reception statistics, then the=0A= scalability of the application is limited by the ability to send,=0A= receive, and process this additional data.=0A= =0A= LCT requires receivers to be able to uniquely identify and demultiplex=0A= packets associated with an LCT session. In particular, there must be a=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 1.2. [Page 7]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= Transport Session Identifier (TSI) associated with each LCT session.=0A= The TSI is scoped by the IP address of the sender, and the IP address of=0A= the sender together with the TSI must uniquely identify the session. If=0A= the underlying transport is UDP as described in RFC768, then the 16 bit=0A= UDP source port number may serve as the TSI for the session. If Generic=0A= Router Assist (GRA) is being used then additional dependencies may be=0A= introduced by GRA on the TSI field. GRA work is ongoing within the RMT=0A= working group at this time. The TSI value must be the same in all=0A= places it occurs within a packet. If there is no underlying TSI=0A= provided by the network, transport or any other layer, then the TSI must=0A= be included in the LCT header.=0A= =0A= There are currently two models of multicast delivery, the Any-Source=0A= Multicast (ASM) model as defined in RFC1112 and the Source-Specific=0A= Multicast (SSM) model as defined in [4]. LCT works with both multicast=0A= models, but in a slightly different way with somewhat different=0A= environmental concerns. When using ASM, a sender S sends packets to a=0A= multicast group G, and the LCT channel address consists of the pair=0A= (S,G), where S is the IP address of the sender and G is a multicast=0A= group address. When using SSM, a sender S sends packets to an SSM=0A= channel (S,G), and the LCT channel address coincides with the SSM=0A= channel address.=0A= =0A= A sender can locally allocate unique SSM channel addresses, and this=0A= makes allocation of LCT channel addresses easy with SSM. To allocate=0A= LCT channel addresses using ASM, the sender must uniquely chose the ASM=0A= multicast group address across the scope of the group, and this makes=0A= allocation of LCT channel addresses more difficult with ASM.=0A= =0A= LCT channels and SSM channels coincide, and thus the receiver will only=0A= receive packets sent to the requested LCT channel. With ASM, the=0A= receiver joins an LCT channel by joining a multicast group G, and all=0A= packets sent to G, regardless of the sender, may be received by the=0A= receiver. Thus, SSM has compelling security advantages over ASM for=0A= prevention of denial of service attacks. In either case, receivers=0A= should use mechanisms to filter out packets from unwanted sources.=0A= =0A= LCT also requires receivers to obtain Session Description Information,=0A= as described in Section 4.1. The session description could be in a form=0A= such as SDP as defined in RFC2327, or XML metadata, or HTTP/Mime headers=0A= as defined in RFC2068, and distributed with SAP as defined in RFC2974,=0A= using HTTP, or in other ways.=0A= =0A= The particular layered encoder and congestion control protocols used=0A= with LCT have an impact on the performance and applicability of LCT.=0A= For example, some layered encoders used for video and audio streams can=0A= produce a very limited number of layers, thus providing a very coarse=0A= control in the reception rate of packets by receivers in a session.=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 1.2. [Page 8]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= When LCT is used for reliable data transfer, some FEC codecs are=0A= inherently limited in the size of the object they can encode, and for=0A= objects larger than this size the reception overhead on the receivers=0A= can grow substantially.=0A= =0A= Some networks are not amenable to some congestion control protocols that=0A= could be used with LCT. In particular, for a satellite or wireless=0A= network, there may be no mechanism for receivers to effectively reduce=0A= their reception rate since there may be a fixed transmission rate=0A= allocated to the session.=0A= =0A= Some protocol instantiations that use LCT may require the generation of=0A= feedback from the receivers to the sender. For example, Generic Router=0A= Assist may be used to help in passing real-time statistics in a scalable=0A= manner from receivers back to the sender. However, the mechanism for=0A= doing this is outside the scope of LCT.=0A= =0A= =0A= 2. General Architecture=0A= =0A= An LCT session comprises a logically related set of one or more LCT=0A= channels originating at a single sender that are used for some period of=0A= time to carry packets containing LCT headers pertaining to the=0A= transmission of one or more objects that can be of interest to=0A= receivers.=0A= =0A= For example, an LCT session could be used to deliver a TV program using=0A= three LCT channels. Receiving packets from the first LCT channel could=0A= allow black and white reception, receiving the first two LCT channels=0A= could also permit color reception, whereas receiving all three channels=0A= could allow HDTV quality reception. Objects in this example could=0A= correspond to individual TV programs being transmitted.=0A= =0A= As another example, a reliable LCT session could be used to reliably=0A= deliver hourly-updated weather maps (objects) using ten LCT channels at=0A= different rates, using FEC coding. A receiver may join and concurrently=0A= receive packets from subsets of these channels, until it has enough=0A= packets in total to recover the object, then leave the session (or=0A= remain connected listening for session description information only)=0A= until it is time to receive the next object. In this case, the quality=0A= metric is the time required to receive each object.=0A= =0A= Before joining a session, the receivers must obtain enough of the=0A= session description to start the session. This must include the=0A= relevant session parameters needed by a receiver to participate in the=0A= session, including all information relevant to congestion control. The=0A= session description is determined by the sender, and is typically=0A= communicated to the receivers out of band. In some cases, as described=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 2. [Page 9]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= later, parts of the session description that are not required to=0A= initiate a session may be included in the LCT header or communicated to=0A= a receiver out of band after the receiver has joined the session.=0A= =0A= An encoder may be used to generate the data that is placed in the packet=0A= payload in order to provide reliability. A suitable decoder is used to=0A= reproduce the original information from the packet payload. There may=0A= be a reliability header that follows the LCT header if such an encoder=0A= and decoder is used. The reliability header helps to describe the=0A= encoding data carried in the payload of the packet. The format of the=0A= reliability header depends on the coding used, and this is negotiated=0A= out-of-band. As an example, one of the FEC headers described in [6]=0A= could be used.=0A= =0A= For LCT, when multi-rate congestion control is used, congestion control=0A= is achieved by sending packets associated with a given session to=0A= several LCT channels. Individual receivers dynamically join one or more=0A= of these channels, according to the network congestion as seen by the=0A= receiver. LCT headers include an opaque field which must be used to=0A= convey congestion control information to the receivers. The actual=0A= congestion control scheme to use with LCT is negotiated out-of-band.=0A= Some examples of congestion control protocols that may be suitable for=0A= content delivery are described in [11] and [1]. Other congestion=0A= controls may be suitable when LCT is used for a streaming application.=0A= =0A= LCT can be used with other congestion control protocols such as the one=0A= described in [11], or Generic Router Assist schemes where the selection=0A= of which packets to forward is performed by routers. This latter=0A= approach potentially allows for finer grain congestion control and a=0A= faster reaction to network congestion, but requires changes to the=0A= router infrastructure. We do not discuss this approach further in this=0A= document.=0A= =0A= =0A= 2.1. Delivery service models=0A= =0A= LCT can support several different delivery service models. Two examples=0A= are briefly described here.=0A= =0A= =0A= Push service model.=0A= =0A= One way a push service model can be used for reliable content delivery=0A= is to deliver a series of objects. For example, a receiver could join=0A= the session and dynamically adapt the number of LCT channels the=0A= receiver is joined to until enough packets have been received to=0A= reconstruct an object. After reconstructing the object the receiver may=0A= stay in the session and wait for the transmission of the next object.=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 2.1. [Page 10]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= The push model is particularly attractive in satellite networks and=0A= wireless networks. In these cases, a session may consist of one fixed=0A= rate LCT channel.=0A= =0A= =0A= On-demand content delivery model.=0A= =0A= For an on-demand content delivery service model, senders typically=0A= transmit for some given time period selected to be long enough to allow=0A= all the intended receivers to join the session and recover the object.=0A= For example a popular software update might be transmitted using LCT for=0A= several days, even though a receiver may be able to complete the=0A= download in one hour total of connection time, perhaps spread over=0A= several intervals of time.=0A= =0A= In this case the receivers join the session, and dynamically adapt the=0A= number of LCT channels they subscribe to (and the reception quality)=0A= according to the available bandwidth. Receivers then drop from the=0A= session when they have received enough packets to recover the object.=0A= =0A= As an example, assume that an object is 50 MB. The sender could send 1=0A= KB packets to the first LCT channel at 50 packets per second, so that=0A= receivers using just this LCT channel could complete reception of the=0A= object in 1,000 seconds in absence of loss, and would be able to=0A= complete reception even in presence of some substantial amount of losses=0A= with the use of coding for reliability. Furthermore, the sender could=0A= use a number of LCT channels such that the aggregate rate of 1 KB=0A= packets to all LCT channels is 1,000 packets per second, so that a=0A= receiver could be able to complete reception of the object in as little=0A= 50 seconds (assuming no loss and that the congestion control mechanism=0A= immediately converges to the use of all LCT channels).=0A= =0A= =0A= Other service models.=0A= =0A= =0A= There are many other delivery service models that LCT can be used for=0A= that are not covered above. As examples, a live streaming or an on-=0A= demand archival content streaming service model. The description of the=0A= many potential applications, the appropriate delivery service model, and=0A= the additional mechanisms to support such functionalities when combined=0A= with LCT is beyond the scope of this document. This document only=0A= attempts to describe the minimal common scalable elements to these=0A= diverse applications using LCT as the delivery transport.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 2.1. [Page 11]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= 2.2. Congestion Control=0A= =0A= The specific congestion control protocol to be used for LCT sessions=0A= depends on the type of content to be delivered. While the general=0A= behavior of the congestion control protocol is to reduce the throughput=0A= in presence of congestion and gradually increase it in the absence of=0A= congestion, the actual dynamic behavior (e.g. response to single losses)=0A= can vary.=0A= =0A= Some possible congestion control protocols for reliable content delivery=0A= using LCT are described in [11] and [1]. Different delivery service=0A= models might require different congestion control protocols.=0A= =0A= =0A= 3. LCT header=0A= =0A= Packets sent to an LCT session must include an "LCT header". The LCT=0A= header format described below is the default format, and this is the=0A= format that is recommended for use by protocol instantiations to ensure=0A= a uniform format across different protocol instantiations. Other LCT=0A= header formats may be used by protocol instantiations, but if the=0A= default LCT header format is not used by a protocol insantiation that=0A= uses LCT, then the protocol instantiation must specify the lengths and=0A= positions within the LCT header it uses of all fields described in the=0A= default LCT header.=0A= =0A= Other building blocks may describe some of the same fields as described=0A= for the LCT header. It is recommended that protocol instantiations=0A= using multiple building blocks include shared fields at most once in=0A= each packet. Thus, for example, if another building block is used with=0A= LCT that includes the optional Expected Residual Time field, then the=0A= Expected Residual Time field should be carried in each packet at most=0A= once.=0A= =0A= The position of the LCT header within a packet must be specified by any=0A= protocol instantiation that uses LCT.=0A= =0A= =0A= 3.1. Default LCT header format=0A= =0A= The default LCT header is of variable size, which is specified by a=0A= length field in the third byte of the header. In the LCT header, all=0A= integer fields are carried in "big-endian" or "network order" format,=0A= that is, most significant byte (octet) first. Bits designated as=0A= "padding" or "reserved" (r) must by set to 0 by senders and ignored by=0A= receivers. Unless otherwise noted, numeric constants in this=0A= specification are in decimal (base 10).=0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.1. [Page 12]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= The format of the default LCT header is depicted in Figure 1.=0A= =0A= =0A= 0 1 2 3=0A= 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | V |C| r |H|S| O |T|R|A|B| HDR_LEN | Codepoint (CP)|=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | Congestion Control Information (CCI) |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | CCI continued (if C =3D 1) |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | Transport Session Identifier (TSI, length =3D 32*S+16*H bits) |=0A= | ... |=0A= + +=0A= | Transport Object Identifier (TOI, length =3D 32*O+16*H bits) |=0A= | ... |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | Sender Current Time (SCT, if T =3D 1) |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | Expected Residual Time (ERT, if R =3D 1) |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | Header Extensions (if applicable) |=0A= | |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= =0A= =0A= Figure 1 - Default LCT header format=0A= =0A= =0A= The function and length of each field in the default LCT header is the=0A= following. Fields marked as "1" mean that the corresponding bits must=0A= be set to "1" by the sender. Fields marked as "r" or "0" mean that the=0A= corresponding bits must be set to "0" by the sender.=0A= =0A= =0A= LCT version number (V): 4 bits=0A= =0A= Indicates the LCT version number. The LCT version number for this=0A= specification is 0.=0A= =0A= =0A= Congestion control flag (C): 1 bit=0A= =0A= C=3D0 indicates the Congestion Control Information (CCI) field is=0A= 32-bits in length.=0A= C=3D1 indicates the CCI field is 64-bits in length.=0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.1. [Page 13]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= Reserved (r): 3 bits=0A= =0A= Reserved for future use. A sender must set these bits to zero and=0A= a receiver must ignore these bits.=0A= =0A= =0A= Half-word flag (H): 1 bit=0A= =0A= The TSI and the TOI fields are both multiples of 32-bits plus 16*H=0A= bits in length. This allows the TSI and TOI field lengths to be=0A= multiples of a half-word (16 bits), while ensuring that the=0A= aggregate length of the TSI and TOI fields is a multiple of=0A= 32-bits.=0A= =0A= =0A= Transport Session Identifier flag (S): 1 bit=0A= =0A= This is the number of full 32-bit words in the TSI field. The TSI=0A= field is 32*S + 16*H bits in length, i.e. the length is either 0=0A= bits, 16 bits, 32 bits, or 48 bits.=0A= =0A= =0A= Transport Object Identifier flag (O): 2 bits=0A= =0A= This is the number of full 32-bit words in the TOI field. The TOI=0A= field is 32*O + 16*H bits in length, i.e., the length is either 0=0A= bits, 16 bits, 32 bits, 48 bits, 64 bits, 80 bits, 96 bits, or 112=0A= bits.=0A= =0A= =0A= Sender Current Time present flag (T): 1 bit=0A= =0A= T =3D 0 indicates that the Sender Current Time (SCT) field is not=0A= present.=0A= T =3D 1 indicates that the SCT field is present.=0A= The SCT is inserted by senders to indicate to receivers how long=0A= the session has been in progress.=0A= =0A= =0A= Expected Residual Time present flag (R): 1 bit=0A= =0A= R =3D 0 indicates that the Expected Residual Time (ERT) field is = not=0A= present.=0A= R =3D 1 indicates that the ERT field is present.=0A= The ERT is inserted by senders to indicate to receivers how much=0A= longer the session / object transmission will continue.=0A= Senders must not set R =3D 1 when the ERT for the session is more=0A= than 2^32-1 time units (approximately 49 days), where time is=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.1. [Page 14]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= measured in units of milliseconds.=0A= =0A= =0A= Close Session flag (A): 1 bit=0A= =0A= Normally, A is set to 0. The sender may set A to 1 when=0A= termination of transmission of packets for the session is=0A= imminent. A may be set to 1 in just the last packet transmitted=0A= for the session, or A may be set to 1 in the last few seconds of=0A= packets transmitted for the session. Once the sender sets A to 1=0A= in one packet, the sender should set A to 1 in all subsequent=0A= packets until termination of transmission of packets for the=0A= session. A received packet with A set to 1 indicates to a=0A= receiver that the sender will immediately stop sending packets for=0A= the session. When a receiver receives a packet with A set to 1=0A= the receiver should assume that no more packets will be sent to=0A= the session.=0A= =0A= =0A= Close Object flag (B): 1 bit=0A= =0A= Normally, B is set to 0. The sender may set B to 1 when=0A= termination of transmission of packets for an object is imminent.=0A= If the TOI field is in use and B is set to 1 then termination of=0A= transmission for the object identified by the TOI field is=0A= imminent. If the TOI field is not in use and B is set to 1 then=0A= termination of transmission for the one object in the session=0A= identified by out of band information is imminent. B may be set=0A= to 1 in just the last packet transmitted for the object, or B may=0A= be set to 1 in the last few seconds packets transmitted for the=0A= object. Once the sender sets B to 1 in one packet for a=0A= particular object, the sender should set B to 1 in all subsequent=0A= packets for the object until termination of transmission of=0A= packets for the object. A received packet with B set to 1=0A= indicates to a receiver that the sender will immediately stop=0A= sending packets for the object. When a receiver receives a packet=0A= with B set to 1 then it should assume that no more packets will be=0A= sent for the object to the session.=0A= =0A= =0A= LCT header length (HDR_LEN): 8 bits=0A= =0A= Total length of the LCT header in units of 32-bit words. The=0A= length of the LCT header must be a multiple of 32-bits. This=0A= field can be used to directly access the portion of the packet=0A= beyond the LCT header, i.e., to the first other header if it=0A= exists, or to the packet payload if it exists and there is no=0A= other header, or to the end of the packet if there are no other=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.1. [Page 15]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= headers or packet payload.=0A= =0A= =0A= Codepoint (CP): 8 bits=0A= =0A= An opaque identifier which is passed to the packet payload decoder=0A= to convey information on the codec being used for the packet=0A= payload. The mapping between the codepoint and the actual codec is=0A= defined on a per session basis and communicated out-of-band as=0A= part of the session description information. The use of the CP=0A= field is similar to the Payload Type (PT) field in RTP headers as=0A= described in RFC1889.=0A= =0A= =0A= Congestion Control Information (CCI): 32 or 64 bits=0A= =0A= Used to carry congestion control information. For example, the=0A= congestion control information could include layer numbers,=0A= logical channel numbers, and sequence numbers. This field is=0A= opaque for the purpose of this specification.=0A= This field must be 32 bits if C=3D0.=0A= This field must be 64 bits if C=3D1.=0A= =0A= =0A= Transport Session Identifier (TSI): 0, 16, 32 or 48 bits=0A= =0A= The TSI uniquely identifies a session among all sessions from a=0A= particular sender. The TSI is scoped by the IP address of the=0A= sender, and thus the IP address of the sender and the TSI together=0A= uniquely identify the session. Although a TSI in conjunction with=0A= the IP address of the sender must always uniquely identify a=0A= session, whether or not the TSI is incuded in the LCT header=0A= depends on what is used as the TSI value. If the underlying=0A= transport is UDP, then the 16 bit UDP source port number may serve=0A= as the TSI for the session. If Generic Router Assist (GRA) is=0A= being used then additional dependencies may be introduced by GRA=0A= on the TSI field. If the TSI value appears multiple times in a=0A= packet then all occurrences must be the same value. If there is=0A= no underlying TSI provided by the network, transport or any other=0A= layer, then the TSI must be included in the LCT header.=0A= =0A= The TSI must be unique among all sessions served by the sender=0A= during the period when the session is active, and for a large=0A= period of time preceding and following when the session is active.=0A= A primary purpose of the TSI is to prevent receivers from=0A= inadvertently accepting packets from a sender that belong to=0A= sessions other than sessions receivers are subscribed to. For=0A= example, suppose a session is deactivated and then another session=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.1. [Page 16]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= is activated by a sender and the two sessions use an overlapping=0A= set of channels. A receiver that connects and remains connected=0A= to the first session during this sender activity could possibly=0A= accept packets from the second session as belonging to the first=0A= session if the TSI for the two sessions were identical. The=0A= mapping of TSI field values to sessions must be done out of band.=0A= The length of the TSI field is 32*S + 16*H bits. Note that the=0A= aggregate lengths of the TSI field plus the TOI field is a=0A= multiple of 32 bits.=0A= =0A= =0A= Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96 or 112=0A= bits.=0A= =0A= This field indicates which object within the session this packet=0A= pertains to. For example, a sender might send a number of files=0A= in the same session, using TOI=3D0 for the first file, TOI=3D1 for = the=0A= second one, etc. As another example, the TOI may be a unique=0A= global identifier of the object that is being transmitted from=0A= several senders concurrently, and the TOI value may be the ouptut=0A= of a hash function applied to the object. The mapping of TOI field=0A= values to objects must be done out of band. The TOI field must be=0A= used in all packets if more than one object is to be transmitted=0A= in a session, i.e. the TOI field is either present in all the=0A= packets of a session or is never present.=0A= The length of the TOI field is 32*O + 16*H bits. Note that the=0A= aggregate lengths of the TSI field plus the TOI field is a=0A= multiple of 32 bits.=0A= =0A= =0A= Sender Current Time (SCT): 0 or 32 bits=0A= =0A= This field represents the current clock at the sender at the time=0A= this packet was transmitted, measured in units of 1ms and computed=0A= modulo 2^32 units from the start of the session.=0A= This field must not be present if T=3D0 and must be present if = T=3D1.=0A= =0A= =0A= Expected Residual Time (ERT): 0 or 32 bits=0A= =0A= This field represents the sender expected residual transmission=0A= time for the current session or for the transmission of the=0A= current object, measured in units of 1ms. If the packet containing=0A= the ERT field also contains the TOI field, then ERT refers to the=0A= object corresponding to the TOI field, otherwise it refers to the=0A= session.=0A= This field must not be present if R=3D0 and must be present if = R=3D1.=0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.1. [Page 17]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= 3.2. Header-Extension Fields=0A= =0A= Header Extensions are used in LCT to accommodate optional header fields=0A= that are not always used or have variable size. Examples of the use of=0A= Header Extensions include:=0A= =0A= o Extended-size versions of already existing header fields.=0A= =0A= o Sender and Receiver authentication information.=0A= =0A= =0A= The presence of Header Extensions can be inferred by the LCT header=0A= length (HDR_LEN): if HDR_LEN is larger than the length of the standard=0A= header then the remaining header space is taken by Header Extension=0A= fields.=0A= =0A= =0A= If present, Header Extensions must be processed to ensure that they are=0A= recognized before performing any congestion control procedure or=0A= otherwise accepting a packet. The default action for unrecognized header=0A= extensions is to ignore them. This allows the future introduction of=0A= backward-compatible enhancements to LCT without changing the LCT version=0A= number. Non backward-compatible header extensions CANNOT be introduced=0A= without changing the LCT version number.=0A= =0A= Protocol instantiation may override this default behavior for PI-=0A= specific extensions (see below).=0A= =0A= There are two formats for Header Extension fields, as depicted below.=0A= The first format is used for variable-length extensions, with Header=0A= Extension Type (HET) values between 0 and 127. The second format is used=0A= for fixed length (one 32-bit word) extensions, using HET values from 127=0A= to 255.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.2. [Page 18]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= 0 1 2 3=0A= 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | HET (<=3D127) | HEL | |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +=0A= . .=0A= . Header Extension Content (HEC) .=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= =0A= 0 1 2 3=0A= 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | HET (>=3D128) | Header Extension Content (HEC) |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= =0A= =0A= Figure 5 - Format of additional headers=0A= =0A= =0A= The explanation of each sub-field is the following.=0A= =0A= =0A= Header Extension Type (HET): 8 bits=0A= =0A= The type of the Header Extension. This document defines a number=0A= of possible types. Additional types may be defined in future=0A= version of this specification. HET values from 0 to 127 are used=0A= for variable-length Header Extensions. HET values from 128 to 255=0A= are used for fixed-length 32-bit Header Extensions.=0A= =0A= =0A= Header Extension Length (HEL): 8 bits=0A= =0A= The length of the whole Header Extension field, expressed in=0A= multiples of 32-bit words. This field must be present for=0A= variable-length extensions (HET between 0 and 127) and must not be=0A= present for fixed-length extensions (HET between 128 and 255).=0A= =0A= =0A= Header Extension Content (HEC): variable length=0A= =0A= The content of the Header Extension. The format of this sub-field=0A= depends on the Header Extension type. For fixed-length Header=0A= Extensions, the HEC is 24 bits. For variable-length Header=0A= Extensions, the HEC field has variable size, as specified by the=0A= HEL field. Note that the length of each Header Extension field=0A= must be a multiple of 32 bits. Also note that the total size of=0A= the LCT header, including all Header Extensions and all optional=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.2. [Page 19]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= header fields, cannot exceed 255 32-bit words.=0A= =0A= =0A= Header Extensions are further divided between general LCT extensions and=0A= Protocol Instantiation specific extensions (PI-specific). General LCT=0A= extensions have HET in the ranges 0:63 and 128:191 inclusive. PI-=0A= specific extensions have HET in the ranges 64:127 and 192:255 inclusive.=0A= =0A= General LCT extensions are intended to allow the introduction of=0A= backward-compatible enhancements to LCT without changing the LCT version=0A= number. Non backward-compatible header extensions CANNOT be introduced=0A= without changing the LCT version number.=0A= =0A= PI-specific extensions are reserved for PI-specific use with semantic=0A= and default parsing actions defined by the PI.=0A= =0A= The following general LCT Header Extension types are defined:=0A= =0A= EXT_NOP=3D0 No-Operation extension.=0A= The information present in this extension field must be=0A= ignored by receivers.=0A= =0A= =0A= EXT_AUTH=3D2 Packet authentication extension=0A= Information used to authenticate the sender of the packet.=0A= If present, the format of this Header Extension and its=0A= processing must be communicated out-of-band as part of the=0A= session description.=0A= It is recommended that senders provide some form of packet=0A= authentication. If EXT_AUTH is present, whatever packet=0A= authentication checks that can be performed immediately=0A= upon reception of the packet must be performed before=0A= accepting the packet and performing any congestion=0A= control-related action on it.=0A= Some packet authentication schemes impose a delay of=0A= several seconds between when a packet is received and when=0A= the packet is fully authenticated. Any congestion control=0A= related action that is appropriate must not be postponed=0A= by any such full packet authentication.=0A= =0A= =0A= All senders and receivers implementing LCT must support the EXT_NOP=0A= Header Extension and must recognize EXT_AUTH, but may not be able to=0A= parse its content.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.2. [Page 20]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= 4. Procedures=0A= =0A= =0A= 4.1. Sender Operation=0A= =0A= A sender using LCT must make a session description available to clients=0A= that want to join an LCT session. This information could include, but=0A= is not limited to:=0A= =0A= o The number of LCT channels;=0A= =0A= o The addresses, port numbers and data rates used for each LCT=0A= channel;=0A= =0A= o The formats of any other headers. For example, an FEC header as=0A= described in [6] could be such an other header. Then for example=0A= the information could include the mapping of codepoints used in the=0A= session to FEC codec types and parameters;=0A= =0A= o The format and lengths of the packet payload;=0A= =0A= o The Transport Session ID (TSI) to be used for the session;=0A= =0A= o Whether or not Generic Router Assist (GRA) is being used;=0A= =0A= o The congestion control scheme being used;=0A= =0A= o The mapping of TOI value(s) to objects for the session;=0A= =0A= o Any information that is relevant to each object being transported,=0A= such as when it will be available within the session, for how long,=0A= and the length of the object;=0A= =0A= o The packet authentication scheme being used, and all relevant=0A= information which is necessary for client packet authentication=0A= purposes;=0A= =0A= =0A= Some of the session description information must be obtained by=0A= receivers before they connect to the session. This includes the number=0A= and addresses of the LCT channels, the TSI value for the session, the=0A= formats of any other headers, the congestion control scheme being used=0A= and the packet authentication scheme if it is used. Some of the session=0A= description information may be obtained by receivers while they are=0A= connected to the session, e.g., information relevant to objects being=0A= transported within the session such as their TOI, when they are=0A= available within the session, for how long, and their lengths.=0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 4.1. [Page 21]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= The session description could be in a form such as SDP as defined in=0A= RFC2327, XML metadata, HTTP/Mime headers, etc. It might be carried in a=0A= session announcement protocol such as SAP as defined in RFC2974,=0A= obtained using a proprietary session control protocol, located on a Web=0A= page with scheduling information, or conveyed via E-mail or other out of=0A= band methods. Discussion of session description format, and=0A= distribution of session descriptions is beyond the scope of this=0A= document.=0A= =0A= Within an LCT session, a sender using LCT transmits a sequence of=0A= packets each in a format defined in the session description. Packets=0A= are sent from a sender using one or more LCT channels which together=0A= constitute a session. Transmission rates may be different in different=0A= channels and may vary over time. The specification of the other=0A= building block headers and the packet payload used by a complete=0A= protocol instantiation using LCT is beyond the scope of this document.=0A= This document does not specify the order in which packets are=0A= transmitted, nor the organization of a session into multiple channels.=0A= Although these issues affect the efficiency of the protocol, they do not=0A= affect the correctness nor the inter-operability of LCT between senders=0A= and receivers.=0A= =0A= Multiple objects can be carried within the same LCT session. In this=0A= case, each object must be identified by a unique TOI. Objects may be=0A= transmitted sequentially, or they may be transmitted concurrently. It=0A= is good practice to only send objects concurrently in the same session=0A= if the receivers that participate in that portion of the session have=0A= interest in receiving all the objects. The reason for this is that it=0A= wastes bandwidth and networking resources to have receivers receive data=0A= for objects that they have no interest in.=0A= =0A= Typically, the sender(s) continues to send packets in a session until=0A= the transmission is considered complete. The transmission may be=0A= considered complete when some time has expired, a certain number of=0A= packets have been sent, or some out of band signal (possibly from a=0A= higher level protocol) has indicated completion by a sufficient number=0A= of receivers.=0A= =0A= For the reasons mentioned above, this document does not pose any=0A= restriction on packet sizes. However, network efficiency considerations=0A= recommend that the sender uses as large as possible packet payload size,=0A= but in such a way that packets do not exceed the network's maximum=0A= transmission unit size (MTU), or fragmentation coupled with packet loss=0A= might introduce severe inefficiency in the transmission.=0A= =0A= It is recommended that all packets have the same or very similar sizes,=0A= as this can have a severe impact on the effectiveness of congestion=0A= control schemes such as the ones described in [11] and [1]. A sender of=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 4.1. [Page 22]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= packets using LCT must implement the sender-side part of one of the=0A= congestion control schemes that is in accordance with RFC2357 using the=0A= Congestion Control Information field provided in the LCT header, and the=0A= corresponding receiver congestion control scheme must be communicated=0A= out of band and implemented by any receivers participating in the=0A= session.=0A= =0A= =0A= 4.2. Receiver Operation=0A= =0A= Receivers can operate differently depending on the delivery service=0A= model. For example, for an on demand service model receivers may join a=0A= session, obtain the necessary encoding symbols to reproduce the object,=0A= and then leave the session. As another example, for a streaming service=0A= model a receiver may be continuously joined to a set of LCT channels to=0A= download all objects in a session.=0A= =0A= To be able to participate in a session, a receiver must first obtain the=0A= relevant session description information as listed in Section 4.1.=0A= =0A= If packet authentication information is present in an LCT header, it=0A= should be used as specified in Section 3.2. To be able to be a receiver=0A= in a session, the receiver must be able to process the LCT header. The=0A= receiver must be able to discard, forward, store or process the other=0A= headers and the packet payload. If a receiver is not able to process a=0A= LCT header, it must drop from the session.=0A= =0A= To be able to participate in a session, a receiver must implement the=0A= congestion control protocol specified in the session description using=0A= the Congestion Control Information field provided in the LCT header. If=0A= a receiver is not able to implement the congestion control protocol used=0A= in the session, it must not join the session. When the session is=0A= transmitted on multiple LCT channels, receivers must initially join=0A= channels according to the specified startup behavior of the congestion=0A= control protocol itself. For a layered transmission on multiple=0A= channels, this typically means that a receiver will initially join only=0A= a minimal set of LCT channels, possibly a single one, that in aggregate=0A= are carrying packets at a low rate. This rule has the purpose of=0A= preventing receivers from starting at high data rates.=0A= =0A= Multiple objects can be carried either sequentially or concurrently=0A= within the same LCT session. In this case, each object is identified by=0A= a unique TOI. Note that even if a server stops sending packets for an=0A= old object before starting to transmit packets for a new object, both=0A= the network and the underlying protocol layers can cause some reordering=0A= of packets, especially when sent over different LCT channels, and thus=0A= receivers should not assume that the reception of a packet for a new=0A= object means that there are no more packets in transit for the previous=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 4.2. [Page 23]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= one, at least for some amount of time.=0A= =0A= A receiver may be concurrently joined to multiple LCT sessions from one=0A= or more senders. The receiver must perform congestion control on each=0A= such LCT session. If the congestion control protocol allows the=0A= receiver some flexibility in terms of its actions within a session then=0A= the receiver may make choices to optimize the packet flow performance=0A= across the multiple LCT sessions, as long as the receiver still adheres=0A= to the congestion control rules for each LCT session individually.=0A= =0A= =0A= 5. Security Considerations=0A= =0A= LCT can be subject to denial-of-service attacks by attackers which try=0A= to confuse the congestion control mechanism, or send forged packets to=0A= the session which would prevent successful reconstruction of large=0A= portions of the objects.=0A= =0A= The same exact problems are present in TCP, where an attacker can forge=0A= packets and either slow down or increase the throughput of the session,=0A= or replace parts of the data stream with forged data. If the stream is=0A= carrying compressed or otherwise coded data, even a single forged packet=0A= could also cause incorrect reconstruction of the rest of the data=0A= stream.=0A= =0A= It is therefore recommended that protocol instantiations that use LCT=0A= implement some form of packet authentication to protect themselves=0A= against such attacks.=0A= =0A= =0A= 6. IANA Considerations=0A= =0A= No information in this specification is subject to IANA registration.=0A= =0A= Building blocks used in conjunction with LCT may introduce additional=0A= IANA considerations.=0A= =0A= =0A= 7. Intellectual Property Issues=0A= =0A= =0A= No specific reliability protocol or congestion control protocol is=0A= specified or referenced as mandatory in this document.=0A= =0A= LCT may be used with congestion control protocols and other protocols,=0A= such as reliability protocols, which are proprietary or have pending or=0A= granted patents.=0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 7. [Page 24]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= 8. Acknowledgments=0A= =0A= Thanks to Vincent Roca, Bruce Lueckenhoff, Hayder Radha and Justin=0A= Chapweske for detailed comments on this document.=0A= =0A= =0A= 9. References=0A= =0A= =0A= [1] Byers, J.W., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M.,=0A= Roetter, A., and Shaver, W., "FLID-DL: Congestion Control for Layered=0A= Multicast", Proceedings of Second International Workshop on Networked=0A= Group Communications (NGC 2000), Palo Alto, CA, November 2000.=0A= =0A= [2] Byers, J.W., Luby, M., Mitzenmacher, M., and Rege, A., "A Digital=0A= Fountain Approach to Reliable Distribution of Bulk Data", Proceedings=0A= ACM SIGCOMM '98, Vancouver, Canada, September 1998.=0A= =0A= [3] Gemmell, J., Schooler, E., and Gray, J., "Fcast Multicast File=0A= Distribution", IEEE Network, Vol. 14, No. 1, pp. 58-68, January 2000.=0A= =0A= [4] Holbrook, H. W., "A Channel Model for Multicast," Ph.D.=0A= Dissertation, Stanford University, Department of Computer Science,=0A= Stanford, California, August 2001.=0A= =0A= [5] Luby, M., Gemmell, Vicisano, L., J., Rizzo, L., Handley, M.,=0A= Crowcroft, J., "The use of Forward Error Correction in Reliable=0A= Multicast", Internet Draft draft-ietf-rmt-info-fec-01.txt, October 2001,=0A= a work in progress.=0A= =0A= [6] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M.,=0A= Crowcroft, J., "RMT BB Forward Error Correction Codes", Internet Draft=0A= draft-ietf-rmt-bb-fec-04.txt, October 2001.=0A= =0A= [7] Rizzo, L., "Effective Erasure Codes for Reliable Computer=0A= Communication Protocols", ACM SIGCOMM Computer Communication Review,=0A= Vol.27, No.2, pp.24-36, Apr 1997.=0A= =0A= [8] Perrig, A., Canetti, R., Song, D., Tygar, J.D., "Efficient and=0A= Secure Source Authentication for Multicast", Network and Distributed=0A= System Security Symposium, NDSS 2001, pp. 35-46, February 2001.=0A= =0A= [9] Rizzo, L, and Vicisano, L., "Reliable Multicast Data Distribution=0A= protocol based on software FEC techniques", Proceedings of the Fourth=0A= IEEES Workshop on the Architecture and Implementation of High=0A= Performance Communication Systems, HPCS'97, Chalkidiki Greece, June=0A= 1997.=0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 9. [Page 25]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= [10] Rizzo, L, "PGMCC: A TCP-friendly single-rate multicast congestion=0A= control scheme", Proceedings of SIGCOMM 2000, Stockholm Sweden, August=0A= 2000.=0A= =0A= [11] Vicisano, L., Rizzo, L., Crowcroft, J., "TCP-like Congestion=0A= Control for Layered Multicast Data Transfer", IEEE Infocom '98, San=0A= Francisco, CA, Mar.28-Apr.1 1998.=0A= =0A= =0A= =0A= 10. Authors' Addresses=0A= =0A= Michael Luby=0A= luby@digitalfountain.com=0A= Digital Fountain=0A= 39141 Civic Center Drive=0A= Suite 300=0A= Fremont, CA, USA, 94538=0A= =0A= Jim Gemmell=0A= jgemmell@microsoft.com=0A= Microsoft Research=0A= 301 Howard St., #830=0A= San Francisco, CA, USA, 94105=0A= =0A= Lorenzo Vicisano=0A= lorenzo@cisco.com=0A= cisco Systems, Inc.=0A= 170 West Tasman Dr.,=0A= San Jose, CA, USA, 95134=0A= =0A= Luigi Rizzo=0A= luigi@iet.unipi.it=0A= ACIRI/ICSI,=0A= 1947 Center St, Berkeley, CA, USA, 94704=0A= and=0A= Dip. Ing. dell'Informazione,=0A= Univ. di Pisa=0A= via Diotisalvi 2, 56126 Pisa, Italy=0A= =0A= Mark Handley=0A= mjh@aciri.org=0A= ACIRI,=0A= 1947 Center St,=0A= Berkeley, CA, USA, 94704=0A= =0A= Jon Crowcroft=0A= J.Crowcroft@cs.ucl.ac.uk=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 10. [Page 26]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= Department of Computer Science=0A= University College London=0A= Gower Street,=0A= London WC1E 6BT, UK=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 10. [Page 27]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= 11. Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2001). All Rights Reserved.=0A= =0A= This document and translations of it may be copied and furnished to=0A= others, and derivative works that comment on or otherwise explain it or=0A= assist in its implementation may be prepared, copied, published and=0A= distributed, in whole or in part, without restriction of any kind,=0A= provided that the above copyright notice and this paragraph are included=0A= on all such copies and derivative works. However, this document itself=0A= may not be modified in any way, such as by removing the copyright notice=0A= or references to the Internet Society or other Internet organizations,=0A= except as needed for the purpose of developing Internet standards in=0A= which case the procedures for copyrights defined in the Internet=0A= languages other than English.=0A= =0A= The limited permissions granted above are perpetual and will not be=0A= revoked by the Internet Society or its successors or assigns.=0A= =0A= This document and the information contained herein is provided on an "AS=0A= IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK=0A= FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT not=0A= LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL not=0A= INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR=0A= FITNESS FOR A PARTICULAR PURPOSE."=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 11. [Page 28]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 11. [Page 29]=0A= ------=_NextPart_000_0005_01C157E0.AE079D70 Content-Type: application/postscript; name="draft-ietf-rmt-bb-lct-02.ps" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-rmt-bb-lct-02.ps" %!PS-Adobe-3.0=0A= %%Creator: groff version 1.15=0A= %%CreationDate: Thu Oct 18 10:41:51 2001=0A= %%DocumentNeededResources: font Courier-Bold=0A= %%+ font Times-Bold=0A= %%+ font Times-Roman=0A= %%+ font Courier=0A= %%DocumentSuppliedResources: procset grops 1.15 1=0A= %%Pages: 22=0A= %%PageOrder: Ascend=0A= %%Orientation: Portrait=0A= %%EndComments=0A= %%BeginProlog=0A= %%BeginResource: procset grops 1.15 1=0A= /setpacking where{=0A= pop=0A= currentpacking=0A= true setpacking=0A= }if=0A= /grops 120 dict dup begin=0A= /SC 32 def=0A= /A/show load def=0A= /B{0 SC 3 -1 roll widthshow}bind def=0A= /C{0 exch ashow}bind def=0A= /D{0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /E{0 rmoveto show}bind def=0A= /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def=0A= /G{0 rmoveto 0 exch ashow}bind def=0A= /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /I{0 exch rmoveto show}bind def=0A= /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def=0A= /K{0 exch rmoveto 0 exch ashow}bind def=0A= /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /M{rmoveto show}bind def=0A= /N{rmoveto 0 SC 3 -1 roll widthshow}bind def=0A= /O{rmoveto 0 exch ashow}bind def=0A= /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /Q{moveto show}bind def=0A= /R{moveto 0 SC 3 -1 roll widthshow}bind def=0A= /S{moveto 0 exch ashow}bind def=0A= /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /SF{=0A= findfont exch=0A= [exch dup 0 exch 0 exch neg 0 0]makefont=0A= dup setfont=0A= [exch/setfont cvx]cvx bind def=0A= }bind def=0A= /MF{=0A= findfont=0A= [5 2 roll=0A= 0 3 1 roll=0A= neg 0 0]makefont=0A= dup setfont=0A= [exch/setfont cvx]cvx bind def=0A= }bind def=0A= /level0 0 def=0A= /RES 0 def=0A= /PL 0 def=0A= /LS 0 def=0A= /MANUAL{=0A= statusdict begin/manualfeed true store end=0A= }bind def=0A= /PLG{=0A= gsave newpath clippath pathbbox grestore=0A= exch pop add exch pop=0A= }bind def=0A= /BP{=0A= /level0 save def=0A= 1 setlinecap=0A= 1 setlinejoin=0A= 72 RES div dup scale=0A= LS{=0A= 90 rotate=0A= }{=0A= 0 PL translate=0A= }ifelse=0A= 1 -1 scale=0A= }bind def=0A= /EP{=0A= level0 restore=0A= showpage=0A= }bind def=0A= /DA{=0A= newpath arcn stroke=0A= }bind def=0A= /SN{=0A= transform=0A= .25 sub exch .25 sub exch=0A= round .25 add exch round .25 add exch=0A= itransform=0A= }bind def=0A= /DL{=0A= SN=0A= moveto=0A= SN=0A= lineto stroke=0A= }bind def=0A= /DC{=0A= newpath 0 360 arc closepath=0A= }bind def=0A= /TM matrix def=0A= /DE{=0A= TM currentmatrix pop=0A= translate scale newpath 0 0 .5 0 360 arc closepath=0A= TM setmatrix=0A= }bind def=0A= /RC/rcurveto load def=0A= /RL/rlineto load def=0A= /ST/stroke load def=0A= /MT/moveto load def=0A= /CL/closepath load def=0A= /FL{=0A= currentgray exch setgray fill setgray=0A= }bind def=0A= /BL/fill load def=0A= /LW/setlinewidth load def=0A= /RE{=0A= findfont=0A= dup maxlength 1 index/FontName known not{1 add}if dict begin=0A= {=0A= 1 index/FID ne{def}{pop pop}ifelse=0A= }forall=0A= /Encoding exch def=0A= dup/FontName exch def=0A= currentdict end definefont pop=0A= }bind def=0A= /DEFS 0 def=0A= /EBEGIN{=0A= moveto=0A= DEFS begin=0A= }bind def=0A= /EEND/end load def=0A= /CNT 0 def=0A= /level1 0 def=0A= /PBEGIN{=0A= /level1 save def=0A= translate=0A= div 3 1 roll div exch scale=0A= neg exch neg exch translate=0A= 0 setgray=0A= 0 setlinecap=0A= 1 setlinewidth=0A= 0 setlinejoin=0A= 10 setmiterlimit=0A= []0 setdash=0A= /setstrokeadjust where{=0A= pop=0A= false setstrokeadjust=0A= }if=0A= /setoverprint where{=0A= pop=0A= false setoverprint=0A= }if=0A= newpath=0A= /CNT countdictstack def=0A= userdict begin=0A= /showpage{}def=0A= }bind def=0A= /PEND{=0A= clear=0A= countdictstack CNT sub{end}repeat=0A= level1 restore=0A= }bind def=0A= end def=0A= /setpacking where{=0A= pop=0A= setpacking=0A= }if=0A= %%EndResource=0A= %%IncludeResource: font Courier-Bold=0A= %%IncludeResource: font Times-Bold=0A= %%IncludeResource: font Times-Roman=0A= %%IncludeResource: font Courier=0A= grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72=0A= def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron=0A= /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef=0A= /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef=0A= /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef=0A= /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent=0A= /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen=0A= /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon=0A= /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O=0A= /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex=0A= /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y=0A= /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft=0A= /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl=0A= /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut=0A= /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash=0A= /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen=0A= /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft=0A= /logicalnot/minus/registered/macron/degree/plusminus/twosuperior=0A= /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior=0A= /ordmasculine/guilsinglright/onequarter/onehalf/threequarters=0A= /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE=0A= /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex=0A= /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis=0A= /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn=0A= /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla=0A= /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis=0A= /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash=0A= /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def=0A= /Courier@0 ENC0/Courier RE/Times-Roman@0 ENC0/Times-Roman RE=0A= /Times-Bold@0 ENC0/Times-Bold RE/Courier-Bold@0 ENC0/Courier-Bold RE=0A= %%EndProlog=0A= %%Page: 1 1=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 10/Courier-Bold@0 SF(Internet Engineering Task Force)72 85 Q(RMT WG)=0A= 209.999 E 203.999(INTERNET-DRAFT M.Luby/Digital)72 98 R(Fountain)6 E=0A= 149.999(draft-ietf-rmt-bb-lct-02.ps J.Gemmell/Microsoft)72 111 R=0A= (L.Vicisano/Cisco)407.999 124 Q(L.Rizzo/ACIRI and Univ. Pisa)335.999 137=0A= Q(M.Handley/ACIRI)413.999 150 Q(J. Crowcroft/UCL)407.999 163 Q=0A= (18 October 2001)413.999 176 Q(Expires: April 2002)389.999 189 Q/F1 14=0A= /Times-Bold@0 SF(Lay)205.491 214 Q(er)-.14 E(ed Coding T)-.252 E=0A= (ransport:)-1.036 E 3.5(Am)102.717 227 S(assi)-3.5 E -.14(ve)-.14 G=0A= (ly scalable content deli).14 E -.14(ve)-.14 G(ry transport b).14 E=0A= (uilding block)-.28 E/F2 11/Times-Bold@0 SF(Status of this Document)72=0A= 272 Q/F3 11/Times-Roman@0 SF(This document is an Internet-Draft and is \=0A= in full conformance with all pro)72 288.6 Q(visions of Section 10 of)=0A= -.165 E(RFC2026.)72 301.6 Q(Internet-Drafts are w)72 327.6 Q=0A= (orking documents of the Internet Engineering T)-.11 E(ask F)-.88 E=0A= (orce \(IETF\), its areas,)-.165 E(and its w)72 340.6 Q(orking groups.)=0A= -.11 E(Note that other groups may also distrib)5.5 E(ute w)-.22 E=0A= (orking documents as)-.11 E(Internet-Drafts.)72 353.6 Q=0A= (Internet-Drafts are v)72 379.6 Q=0A= (alid for a maximum of six months and may be updated, replaced, or)-.275=0A= E(obsoleted by other documents at an)72 392.6 Q 2.75(yt)-.165 G 2.75=0A= (ime. It)-2.75 F(is inappropriate to use Internet-Drafts as reference)=0A= 2.75 E(material or to cite them other than as a "w)72 405.6 Q=0A= (ork in progress".)-.11 E=0A= (The list of current Internet-Drafts can be accessed at http://www)72=0A= 431.6 Q(.ietf.or)-.715 E(g/ietf/1id-abstracts.txt)-.198 E 1.76 -.88=0A= (To v)72 457.6 T(ie).88 E 2.75(wt)-.275 G(he list Internet-Draft Shado)=0A= -2.75 E 2.75(wD)-.275 G(irectories, see http://www)-2.75 E(.ietf.or)=0A= -.715 E(g/shado)-.198 E -.715(w.)-.275 G(html.).715 E=0A= (This document is a product of the IETF RMT WG.)72 483.6 Q=0A= (Comments should be addressed to the)5.5 E(authors, or the WG')72 496.6=0A= Q 2.75(sm)-.605 G(ailing list at rmt@lbl.go)-2.75 E -.715(v.)-.165 G F2=0A= (Abstract)267.534 528.6 Q F3(This document describes Layered Coding T)97=0A= 551.2 Q(ransport, a massi)-.385 E -.165(ve)-.275 G(ly scalable reliable)=0A= .165 E(content deli)97 564.2 Q -.165(ve)-.275 G(ry and stream deli).165=0A= E -.165(ve)-.275 G(ry transport, hereafter referred to as LCT).165 E 5.5=0A= (.L)-.814 G(CT can)-5.5 E(be used for multi-rate deli)97 577.2 Q -.165=0A= (ve)-.275 G(ry to lar).165 E(ge sets of recei)-.198 E -.165(ve)-.275 G=0A= 2.75(rs. In).165 F(LCT)2.75 E 2.75(,s)-.814 G(calability and)-2.75 E(co\=0A= ngestion control are supported through the use of layered coding techni\=0A= ques. Coding)97 590.2 Q(techniques can be combined with LCT to pro)97=0A= 603.2 Q(vide support for reliability)-.165 E(.)-.715 E=0A= (Congestion control is recei)97 629.2 Q -.165(ve)-.275 G 2.75(rd).165 G=0A= (ri)-2.75 E -.165(ve)-.275 G(n, and can be achie).165 E -.165(ve)-.275 G=0A= 2.75(db).165 G 2.75(ys)-2.75 G(ending pack)-2.75 E(ets in the)-.11 E=0A= (session to multiple `)97 642.2 Q(`LCT channels')-.814 E(', and ha)-.814=0A= E(ving recei)-.22 E -.165(ve)-.275 G(rs join and lea).165 E .33 -.165=0A= (ve L)-.22 H(CT).165 E=0A= (channels \(thus adjusting their reception rate\) in reaction to netw)97=0A= 655.2 Q(ork conditions in a)-.11 E(manner that is netw)97 668.2 Q=0A= (ork friendly)-.11 E(.)-.715 E(Luby/Gemmell/V)72 769 Q=0A= (icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E 166.856(wcroft [P)-.275 F=0A= (age 1])-.165 E EP=0A= %%Page: 2 2=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E/F1 13/Times-Bold@0 SF -1.196=0A= (Ta)239.126 85 S(ble of Contents)1.196 E/F2 10/Times-Roman@0 SF=0A= (1. Introduction)97 123 Q F0 11(......................)3.56 G F2(3)11.5=0A= E(1.1. Related Documents)107 135 Q F0 11(..................)11.9 G F2(5)=0A= 11.5 E(1.2. En)107 147 Q(vironmental Requirements and Considerations)-.4=0A= E F0 11(..........)3.97 G F2(5)11.5 E(2. General Architecture)97 159 Q=0A= F0 11(...................)10.12 G F2(7)11.5 E(2.1. Deli)107 171 Q -.15=0A= (ve)-.25 G(ry service models).15 E F0 11(.................)7.45 G F2(8)=0A= 11.5 E(2.2. Congestion Control)107 183 Q F0 11(..................)11.88=0A= G F2(9)11.5 E(3. LCT header)97 195 Q F0 11(......................)4.96 G=0A= F2(9)11.5 E(3.1. Def)107 207 Q(ault LCT header format)-.1 E F0 11=0A= (................)8.41 G F2(9)11.5 E(3.2. Header)107 219 Q=0A= (-Extension Fields)-.2 E F0 11(.................)5.3 G F2(13)6.5 E=0A= (4. Procedures)97 231 Q F0 11(......................)8.57 G F2(15)6.5 E=0A= (4.1. Sender Operation)107 243 Q F0 11(...................)6.49 G F2(15)=0A= 6.5 E(4.2. Recei)107 255 Q -.15(ve)-.25 G 2.5(rO).15 G(peration)-2.5 E=0A= F0 11(..................)12.87 G F2(17)6.5 E(5. Security Considerations)=0A= 97 267 Q F0 11(..................)12.17 G F2(17)6.5 E(6. IAN)97 279 Q=0A= 2.5(AC)-.35 G(onsiderations)-2.5 E F0 11(...................)7.11 G F2=0A= (18)6.5 E(7. Intellectual Property Issues)97 291 Q F0 11=0A= (.................)12.88 G F2(18)6.5 E(8. Ackno)97 303 Q(wledgments)-.25=0A= E F0 11(....................)5.76 G F2(18)6.5 E(9. References)97 315 Q=0A= F0 11(......................)8.58 G F2(18)6.5 E(10. Authors' Addresses)=0A= 97 327 Q F0 11(...................)10.1 G F2(19)6.5 E(11. Full Cop)97=0A= 339 Q(yright Statement)-.1 E F0 11(..................)1.42 G F2(21)6.5 E=0A= F0(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A= 166.856(wcroft [P)-.275 F(age 2])-.165 E EP=0A= %%Page: 3 3=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(1.)72 85=0A= Q/F2 14/Times-Bold@0 SF(Intr)5.5 E(oduction)-.252 E F0=0A= (This document describes a massi)72 101.6 Q -.165(ve)-.275 G=0A= (ly scalable reliable content deli).165 E -.165(ve)-.275 G=0A= (ry and stream deli).165 E -.165(ve)-.275 G(ry).165 E=0A= (transport, Layered Coding T)72 114.6 Q=0A= (ransport \(LCT\), for multi-rate content deli)-.385 E -.165(ve)-.275 G=0A= (ry primarily designed to).165 E(be used with the IP multicast netw)72=0A= 127.6 Q(ork service, b)-.11 E=0A= (ut may also be used with other basic underlying)-.22 E(netw)72 140.6 Q=0A= (ork or transport services such as unicast UDP)-.11 E 5.5(.L)-1.221 G=0A= (CT supports both reliable and unreliable)-5.5 E(deli)72 153.6 Q -.165=0A= (ve)-.275 G(ry).165 E(.)-.715 E(LCT is a b)72 179.6 Q=0A= (uilding block as de\214ned in RFC3048.)-.22 E=0A= (Protocol instantiations may be b)5.5 E(uilt by)-.22 E=0A= (combining the LCT frame)72 192.6 Q -.11(wo)-.275 G=0A= (rk with other components.).11 E 2.75(Ac)5.5 G=0A= (omplete protocol instantiation that)-2.75 E(uses LCT must include a co\=0A= ngestion control protocol that is compatible with LCT and that)72 205.6=0A= Q(conforms to RFC2357.)72 218.6 Q 2.75(Ac)5.5 G=0A= (omplete protocol instantiation that uses LCT may include a scalable)=0A= -2.75 E(reliability protocol that is compatible with LCT)72 231.6 Q 2.75=0A= (,i)-.814 G 2.75(tm)-2.75 G=0A= (ay include an session control protocol that is)-2.75 E=0A= (compatible with LCT)72 244.6 Q 2.75(,a)-.814 G=0A= (nd it may include other protocols such as security protocols.)-2.75 E=0A= (LCT is presumed to be used with an underlying netw)72 270.6 Q=0A= (ork or transport service that is a "best ef)-.11 E(fort")-.275 E=0A= (service that does not guarantee pack)72 283.6 Q(et reception, pack)-.11=0A= E(et reception order)-.11 E 2.75(,a)-.44 G(nd which does not ha)-2.75 E=0A= -.165(ve)-.22 G(an)72 296.6 Q 2.75(ys)-.165 G(upport for \215o)-2.75 E=0A= 2.75(wo)-.275 G 2.75(rc)-2.75 G(ongestion control.)-2.75 E -.165(Fo)5.5=0A= G 2.75(re).165 G(xample, the An)-2.915 E=0A= (y-Source Multicast \(ASM\) model)-.165 E=0A= (of IP multicast as de\214ned in RFC1112 is such a "best ef)72 309.6 Q=0A= (fort" netw)-.275 E(ork service.)-.11 E(While the basic)5.5 E=0A= (service pro)72 322.6 Q(vided by RFC1112 is lar)-.165 E=0A= (gely scalable, pro)-.198 E(viding congestion control or reliability)=0A= -.165 E(should be done carefully to a)72 335.6 Q -.22(vo)-.22 G(id se)=0A= .22 E -.165(ve)-.275 G=0A= (re scalability limitations, especially in presence of).165 E=0A= (heterogeneous sets of recei)72 348.6 Q -.165(ve)-.275 G(rs.).165 E=0A= -.165(Pa)72 374.6 S(ck).165 E(ets with LCT headers are carried in LCT c\=0A= hannels. An LCT channel is de\214ned by the)-.11 E(combination of a sen\=0A= der and an address associated with the channel by the sender)72 387.6 Q=0A= 5.5(.A)-.605 G(recei)-2.75 E -.165(ve)-.275 G(r).165 E=0A= (may join a channel to start recei)72 400.6 Q(ving the data pack)-.275 E=0A= (ets sent to the channel by the sender)-.11 E 2.75(,a)-.44 G(nd a)-2.75=0A= E(recei)72 413.6 Q -.165(ve)-.275 G 2.75(rm).165 G(ay lea)-2.75 E .33=0A= -.165(ve a c)-.22 H(hannel to stop recei).165 E(ving data pack)-.275 E=0A= (ets from the channel.)-.11 E(An LCT session consists of a set of logic\=0A= ally grouped LCT channels associated with a single)72 439.6 Q=0A= (sender carrying pack)72 452.6 Q=0A= (ets with LCT headers for one or more objects.)-.11 E=0A= (Congestion control that)5.5 E=0A= (conforms to RFC2357 must be used between recei)72 465.6 Q -.165(ve)=0A= -.275 G(rs and the sender for each LCT session.).165 E=0A= (Congestion control refers to the ability to adapt throughput to the a)=0A= 72 478.6 Q -.275(va)-.22 G(ilable bandwidth on the path).275 E=0A= (from the sender to a recei)72 491.6 Q -.165(ve)-.275 G .88 -.44(r, a)=0A= .165 H(nd to share bandwidth f).44 E(airly with competing \215o)-.11 E=0A= (ws such as TCP)-.275 E(.)-1.221 E(Thus, the total \215o)72 504.6 Q 2.75=0A= (wo)-.275 G 2.75(fp)-2.75 G(ack)-2.75 E(ets \215o)-.11 E=0A= (wing to each recei)-.275 E -.165(ve)-.275 G 2.75(rp).165 G=0A= (articipating in an LCT session must not)-2.75 E(compete unf)72 517.6 Q=0A= (airly with e)-.11 E(xisting \215o)-.165 E 2.75(wa)-.275 G(dapti)-2.75 E=0A= .33 -.165(ve p)-.275 H(rotocols such as TCP).165 E(.)-1.221 E 2.75(Am)72=0A= 543.6 S(ulti-rate or a single-rate congestion control protcol can be us\=0A= ed with LCT)-2.75 E 5.5(.F)-.814 G(or multi-rate)-5.665 E(protocols, a \=0A= session typically consists of more than one channel and the sender send\=0A= s pack)72 556.6 Q(ets to)-.11 E=0A= (the channels in the session at rates that do not depend on the recei)72=0A= 569.6 Q -.165(ve)-.275 G 2.75(rs. Each).165 F(recei)2.75 E -.165(ve)=0A= -.275 G 2.75(ra).165 G(djusts its)-2.75 E(reception rate during its par\=0A= ticipation in the session by joining and lea)72 582.6 Q=0A= (ving channels dynamically)-.22 E(depending on the a)72 595.6 Q -.275=0A= (va)-.22 G=0A= (ilable bandwidth to the sender independent of all other recei).275 E=0A= -.165(ve)-.275 G 2.75(rs. Thus,).165 F(for)2.75 E=0A= (multi-rate protocols, the reception rate of each recei)72 608.6 Q -.165=0A= (ve)-.275 G 2.75(rm).165 G(ay v)-2.75 E=0A= (ary dynamically independent of the)-.275 E(other recei)72 621.6 Q -.165=0A= (ve)-.275 G(rs.).165 E -.165(Fo)72 647.6 S 2.75(rs).165 G(ingle-rate pr\=0A= otocols, a session typically consists of one channel and the sender sen\=0A= ds pack)-2.75 E(ets)-.11 E(to the channel at v)72 660.6 Q=0A= (ariable rates o)-.275 E -.165(ve)-.165 G 2.75(rt).165 G=0A= (ime depending on feedback from recei)-2.75 E -.165(ve)-.275 G=0A= (rs. Each recei).165 E -.165(ve)-.275 G(r).165 E=0A= (remains joined to the channel during its participation in the session.)=0A= 72 673.6 Q(Thus, for single-rate)5.5 E=0A= (protocols, the reception rate of each recei)72 686.6 Q -.165(ve)-.275 G=0A= 2.75(rm).165 G(ay v)-2.75 E(ary dynamically b)-.275 E=0A= (ut in coordination with all)-.22 E(recei)72 699.6 Q -.165(ve)-.275 G=0A= 2.75(rs. Generally).165 F 2.75(,am)-.715 G=0A= (ulti-rate protocol is preferable to a single-rate protocol in a)-2.75 E=0A= (heterogeneous recei)72 712.6 Q -.165(ve)-.275 G 2.75(re).165 G -.44(nv)=0A= -2.75 G(ironment, b).44 E(ut only if it can be achie)-.22 E -.165(ve)=0A= -.275 G 2.75(dw).165 G(ithout sacri\214cing scalability)-2.75 E(.)-.715=0A= E(Some possible multi-rate congestion control protocols are described i\=0A= n [11] and [1]. A possible)72 725.6 Q(Luby/Gemmell/V)72 769 Q=0A= (icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E 117.356(wcroft Section)-.275=0A= F 2.75(1. [P)2.75 F(age 3])-.165 E EP=0A= %%Page: 4 4=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E=0A= (single-rate congestion control protocol is described in [10].)72 85 Q=0A= (Layered coding refers to the ability to produce a coded stream of pack)=0A= 72 101.6 Q(ets that can be partioned)-.11 E=0A= (into an ordered set of layers.)72 114.6 Q(The coding is meant to pro)=0A= 5.5 E(vide some form of reliability)-.165 E 2.75(,a)-.715 G(nd the)-2.75=0A= E(layering is meant to allo)72 127.6 Q 2.75(wt)-.275 G(he recei)-2.75 E=0A= -.165(ve)-.275 G 2.75(re).165 G 2.75(xperience \(in)-2.915 F=0A= (terms of quality of playout, or o)2.75 E -.165(ve)-.165 G(rall).165 E=0A= (transfer speed\) to v)72 140.6 Q(ary in a predictable w)-.275 E=0A= (ay depending on ho)-.11 E 2.75(wm)-.275 G(an)-2.75 E 2.75(yc)-.165 G=0A= (onsecuti)-2.75 E .33 -.165(ve l)-.275 H(ayers of pack).165 E(ets)-.11 E=0A= (the recei)72 153.6 Q -.165(ve)-.275 G 2.75(ri).165 G 2.75(sr)-2.75 G=0A= (ecei)-2.75 E(ving.)-.275 E(Layered coding can be naturally combined wi\=0A= th multi-rate congestion control.)72 179.6 Q -.165(Fo)5.5 G 2.75(re).165=0A= G(xample, the)-2.915 E(sender could send the pack)72 192.6 Q(ets for ea\=0A= ch layer to a separate channel associated with the session, and)-.11 E=0A= (then recei)72 205.6 Q -.165(ve)-.275 G(rs dynamically join and lea).165=0A= E .33 -.165(ve c)-.22 H=0A= (hannels to adjust their reception rate according to the).165 E=0A= (multi-rate congestion control protocol.)72 218.6 Q(Layered coding can \=0A= also be combined with single-rate congestion control.)72 244.6 Q -.165=0A= (Fo)5.5 G 2.75(re).165 G(xample, the)-2.915 E=0A= (sender could dynamically v)72 257.6 Q(ary ho)-.275 E 2.75(wm)-.275 G=0A= (an)-2.75 E 2.75(yl)-.165 G=0A= (ayers are sent to the channel associated with the)-2.75 E=0A= (session as the rate of transmission v)72 270.6 Q=0A= (aries according to the single-rate congestion control protocol.)-.275 E=0A= (The concept of layered coding w)72 296.6 Q=0A= (as \214rst introduced with reference to audio and video streams.)-.11 E=0A= -.165(Fo)72 309.6 S 2.75(re).165 G(xample, the information associated w\=0A= ith a TV broadcast could be partitioned into three)-2.915 E=0A= (layers, corresponding to black and white, color)72 322.6 Q 2.75(,a)-.44=0A= G(nd HDTV quality)-2.75 E 2.75(.R)-.715 G(ecei)-2.75 E -.165(ve)-.275 G=0A= (rs can e).165 E(xperience)-.165 E(dif)72 335.6 Q(ferent quality withou\=0A= t the need for the sender to replicate information in the dif)-.275 E=0A= (ferent layers.)-.275 E=0A= (The concept of layered coding can be naturally e)72 361.6 Q=0A= (xtended to reliable content deli)-.165 E -.165(ve)-.275 G(ry protocols)=0A= .165 E(when F)72 374.6 Q(orw)-.165 E(ard Error Correction \(FEC\) techn\=0A= iques are used for coding the data stream [9] [7] [3])-.11 E=0A= ([11] [2]. By using FEC, the data stream is transformed in such a w)72=0A= 387.6 Q(ay that reconstruction of a data)-.11 E=0A= (object does not depend on the reception of speci\214c data pack)72=0A= 400.6 Q(ets, b)-.11 E(ut only on the number of)-.22 E(dif)72 413.6 Q=0A= (ferent pack)-.275 E(ets recei)-.11 E -.165(ve)-.275 G 2.75(d. As).165 F=0A= 2.75(ar)2.75 G(esult, by increasing the number of layers a recei)-2.75 E=0A= -.165(ve)-.275 G 2.75(ri).165 G 2.75(sr)-2.75 G(ecei)-2.75 E(ving)-.275=0A= E(from, the recei)72 426.6 Q -.165(ve)-.275 G 2.75(rc).165 G=0A= (an reduce the transfer time accordingly)-2.75 E 5.5(.M)-.715 G=0A= (ore details on the use of FEC for)-5.5 E(reliable content deli)72 439.6=0A= Q -.165(ve)-.275 G(ry can be found in [5].).165 E=0A= (Reliable protocols aim at gi)5.5 E(ving guarantees on the)-.275 E=0A= (reliable deli)72 452.6 Q -.165(ve)-.275 G=0A= (ry of data from the sender to the intended recipients.).165 E=0A= (Guarantees v)5.5 E(ary from simple)-.275 E(pack)72 465.6 Q=0A= (et data inte)-.11 E(grity to reliable deli)-.165 E -.165(ve)-.275 G=0A= (ry of a precise cop).165 E 2.75(yo)-.11 G 2.75(fa)-2.75 G 2.75(no)-2.75=0A= G(bject to all intended recipients.)-2.75 E(Se)72 478.6 Q -.165(ve)-.275=0A= G(ral reliable content deli).165 E -.165(ve)-.275 G(ry protocols ha).165=0A= E .33 -.165(ve b)-.22 H(een b).165 E(uilt on top of IP multicast, b)-.22=0A= E(ut scalability)-.22 E -.11(wa)72 491.6 S 2.75(sn).11 G=0A= (ot a design goal for man)-2.75 E 2.75(yo)-.165 G 2.75(ft)-2.75 G(hem.)=0A= -2.75 E -1.1 -.88(Tw o)72 517.6 T(of the k)3.63 E .33 -.165(ey d)-.11 H=0A= (if).165 E(\214culties in scaling reliable content deli)-.275 E -.165=0A= (ve)-.275 G(ry using IP multicast are dealing with).165 E=0A= (the amount of data that \215o)72 530.6 Q(ws from recei)-.275 E -.165=0A= (ve)-.275 G(rs back to the sender).165 E 2.75(,a)-.44 G=0A= (nd the associated response)-2.75 E=0A= (\(generally data retransmissions\) from the sender)72 543.6 Q 5.5(.P)=0A= -.605 G(rotocols that a)-5.5 E -.22(vo)-.22 G(id an).22 E 2.75(ys)-.165=0A= G(uch feedback, and)-2.75 E=0A= (minimize the amount of retransmissions, can be massi)72 556.6 Q -.165=0A= (ve)-.275 G(ly scalable.).165 E(LCT can be used in)5.5 E=0A= (conjunction with FEC codes or a layered codec to achie)72 569.6 Q .33=0A= -.165(ve r)-.275 H(eliability with little or no feedback.).165 E=0A= (Scalability refers to the beha)72 595.6 Q=0A= (vior of the protocol in relation to the number of recei)-.22 E -.165=0A= (ve)-.275 G(rs and).165 E(netw)72 608.6 Q=0A= (ork paths, their heterogeneity)-.11 E 2.75(,a)-.715 G=0A= (nd the ability to accommodate dynamically v)-2.75 E(ariable sets of)=0A= -.275 E(recei)72 621.6 Q -.165(ve)-.275 G 2.75(rs. Scalability).165 F(l\=0A= imitations can come from memory or processing requirements, or from the)=0A= 2.75 E(amount of pack)72 634.6 Q(et traf)-.11 E=0A= (\214c generated by the protocol.)-.275 E=0A= (In turn, such limitations may be a)5.5 E=0A= (consequence of the features that a complete reliable content deli)72=0A= 647.6 Q -.165(ve)-.275 G(ry or stream deli).165 E -.165(ve)-.275 G=0A= (ry protocol).165 E(is e)72 660.6 Q(xpected to pro)-.165 E(vide.)-.165 E=0A= (In this document we present the architecture and abstract LCT header s\=0A= tructure, and describe its)72 686.6 Q(support for congestion control.)72=0A= 699.6 Q(The k)72 725.6 Q .33 -.165(ey w)-.11 H(ords "must", "must not",\=0A= "required", "shall", "shall not", "should", "should not",).055 E=0A= (Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A= 117.356(wcroft Section)-.275 F 2.75(1. [P)2.75 F(age 4])-.165 E EP=0A= %%Page: 5 5=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E("recommended", "may", and "op\=0A= tional" in this document are to be interpreted as described in)72 85 Q=0A= (RFC2119.)72 98 Q/F1 11/Times-Bold@0 SF(1.1.)72 137 Q/F2 13/Times-Bold@0=0A= SF(Related Documents)5.5 E F0(As described in RFC3048, LCT is a b)72=0A= 153.6 Q(uilding block that is intended to be used, in conjunction)-.22 E=0A= (with other b)72 166.6 Q=0A= (uilding blocks, to help specify a protocol instantiation.)-.22 E 2.75=0A= (Ac)5.5 G(ongestion control b)-2.75 E(uilding)-.22 E(block that uses th\=0A= e Congestion Control information \214eld within the LCT header must be \=0A= used by)72 179.6 Q(an)72 192.6 Q 2.75(yp)-.165 G=0A= (rotocol instantiation that uses LCT)-2.75 E 2.75(,a)-.814 G(nd other b)=0A= -2.75 E(uilding blocks may also be used, such as a)-.22 E(reliability b)=0A= 72 205.6 Q(uilding block.)-.22 E 2.75(Am)72 231.6 S=0A= (ore in-depth description of the use of FEC in Reliable Multicast T)=0A= -2.75 E(ransport \(RMT\) protocols)-.385 E(is gi)72 244.6 Q -.165(ve)=0A= -.275 G 2.75(ni).165 G 2.75(n[)-2.75 G(5]. Some of the FEC codecs that \=0A= may be used in conjunction with LCT for reliable)-2.75 E(content deli)72=0A= 257.6 Q -.165(ve)-.275 G(ry are speci\214ed in [6]. The Codepoint \214e\=0A= ld in the LCT header is an opaque \214eld that).165 E=0A= (can be used to carry information related to the encoding of the pack)72=0A= 270.6 Q(et payload.)-.11 E(Implementors of protocol instantiations that\=0A= use LCT must also implement congestion control in)72 296.6 Q=0A= (accordance to RFC2357, where the congestion control is o)72 309.6 Q=0A= -.165(ve)-.165 G 2.75(rt).165 G(he entire session.)-2.75 E=0A= (Some possible)5.5 E(schemes are speci\214ed in [11] and [1]. The Conge\=0A= stion Control Information \214eld in the LCT)72 322.6 Q=0A= (header is an opaque \214eld that is reserv)72 335.6 Q=0A= (ed to carry information related to congestion control.)-.165 E(There m\=0A= ay also be congestion control Header Extension \214elds that carry addi\=0A= tional information)72 348.6 Q(related to congestion control.)72 361.6 Q=0A= (Generic Router Assist may be used in conjunction with LCT)72 387.6 Q(.)=0A= -.814 E(It is recommended that LCT implementors use some pack)72 413.6 Q=0A= (et authentication scheme to protect the)-.11 E=0A= (protocol from attacks. An e)72 426.6 Q=0A= (xample of a possibly suitable scheme is described in [8].)-.165 E F1=0A= (1.2.)72 452.6 Q F2(En)5.5 E(vir)-.52 E(onmental Requir)-.234 E=0A= (ements and Considerations)-.234 E F0=0A= (LCT is intended for congestion controlled deli)72 469.2 Q -.165(ve)=0A= -.275 G(ry of objects and streams \(both reliable content).165 E(deli)72=0A= 482.2 Q -.165(ve)-.275 G(ry and streaming of multimedia information\).)=0A= .165 E(LCT is most applicable for deli)72 508.2 Q -.165(ve)-.275 G=0A= (ry of objects or streams of substantial length, i.e., objects or).165 E=0A= (streams that range in length from hundreds of kilobytes to man)72 521.2=0A= Q 2.75(yg)-.165 G(ig)-2.75 E(abytes, and whose transfer)-.055 E=0A= (time is in the order of tens of seconds or more.)72 534.2 Q=0A= (LCT can be used with both multicast and unicast deli)72 560.2 Q -.165=0A= (ve)-.275 G(ry).165 E 5.5(.L)-.715 G(CT requires connecti)-5.5 E=0A= (vity between a)-.275 E(sender and recei)72 573.2 Q -.165(ve)-.275 G=0A= (rs, b).165 E(ut does not require connecti)-.22 E(vity from recei)-.275=0A= E -.165(ve)-.275 G(rs to a sender).165 E 5.5(.L)-.605 G(CT inherently)=0A= -5.5 E -.11(wo)72 586.2 S(rks with all types of netw).11 E=0A= (orks, including LANs, W)-.11 E=0A= (ANs, Intranets, the Internet, asymmetric)-1.32 E(netw)72 599.2 Q=0A= (orks, wireless netw)-.11 E(orks, and satellite netw)-.11 E 2.75=0A= (orks. Thus,)-.11 F(the inherent ra)2.75 E 2.75(ws)-.165 G=0A= (calability of LCT is)-2.75 E 2.75(unlimited. Ho)72 612.2 R(we)-.275 E=0A= -.165(ve)-.275 G .88 -.44(r, w).165 H=0A= (hen other speci\214c applications are b).44 E(uilt on top of LCT)-.22 E=0A= 2.75(,t)-.814 G(hen these)-2.75 E(applications by their v)72 625.2 Q=0A= (ery nature may limit scalability)-.165 E 5.5(.F)-.715 G(or e)-5.665 E=0A= (xample, if an application requires)-.165 E(recei)72 638.2 Q -.165(ve)=0A= -.275 G(rs to retrie).165 E .33 -.165(ve o)-.275 H(ut of band informati\=0A= on in order to join a session, or an application allo).165 E(ws)-.275 E=0A= (recei)72 651.2 Q -.165(ve)-.275 G(rs to send requests back to the send\=0A= er to report reception statistics, then the scalability of).165 E=0A= (the application is limited by the ability to send, recei)72 664.2 Q=0A= -.165(ve)-.275 G 2.75(,a).165 G(nd process this additional data.)-2.75 E=0A= (LCT requires recei)72 690.2 Q -.165(ve)-.275 G=0A= (rs to be able to uniquely identify and demultiple).165 E 2.75(xp)-.165=0A= G(ack)-2.75 E(ets associated with an)-.11 E(LCT session.)72 703.2 Q=0A= (In particular)5.5 E 2.75(,t)-.44 G(here must be a T)-2.75 E=0A= (ransport Session Identi\214er \(TSI\) associated with)-.385 E=0A= (each LCT session.)72 716.2 Q=0A= (The TSI is scoped by the IP address of the sender)5.5 E 2.75(,a)-.44 G=0A= (nd the IP address of the)-2.75 E(Luby/Gemmell/V)72 769 Q=0A= (icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E 109.106(wcroft Section)-.275=0A= F 2.75(1.2. [P)2.75 F(age 5])-.165 E EP=0A= %%Page: 6 6=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E=0A= (sender together with the TSI must uniquely identify the session.)72 85=0A= Q(If the underlying transport is)5.5 E(UDP as described in RFC768, then\=0A= the 16 bit UDP source port number may serv)72 98 Q 2.75(ea)-.165 G 2.75=0A= (st)-2.75 G(he TSI for)-2.75 E(the session.)72 111 Q(If Generic Router \=0A= Assist \(GRA\) is being used then additional dependencies may be)5.5 E=0A= (introduced by GRA on the TSI \214eld.)72 124 Q(GRA w)5.5 E=0A= (ork is ongoing within the RMT w)-.11 E(orking group at)-.11 E=0A= (this time.)72 137 Q(The TSI v)5.5 E=0A= (alue must be the same in all places it occurs within a pack)-.275 E=0A= 2.75(et. If)-.11 F(there is no)2.75 E(underlying TSI pro)72 150 Q=0A= (vided by the netw)-.165 E(ork, transport or an)-.11 E 2.75(yo)-.165 G=0A= (ther layer)-2.75 E 2.75(,t)-.44 G(hen the TSI must be)-2.75 E=0A= (included in the LCT header)72 163 Q(.)-.605 E(There are currently tw)72=0A= 189 Q 2.75(om)-.11 G(odels of multicast deli)-2.75 E -.165(ve)-.275 G=0A= (ry).165 E 2.75(,t)-.715 G(he An)-2.75 E=0A= (y-Source Multicast \(ASM\) model as)-.165 E(de\214ned in RFC1112 and t\=0A= he Source-Speci\214c Multicast \(SSM\) model as de\214ned in [4]. LCT)72=0A= 202 Q -.11(wo)72 215 S(rks with both multicast models, b).11 E=0A= (ut in a slightly dif)-.22 E(ferent w)-.275 E(ay with some)-.11 E=0A= (what dif)-.275 E(ferent)-.275 E(en)72 228 Q(vironmental concerns.)-.44=0A= E(When using ASM, a sender S sends pack)5.5 E=0A= (ets to a multicast group G, and)-.11 E(the LCT channel address consist\=0A= s of the pair \(S,G\), where S is the IP address of the sender and G)72=0A= 241 Q(is a multicast group address.)72 254 Q=0A= (When using SSM, a sender S sends pack)5.5 E(ets to an SSM channel)-.11=0A= E(\(S,G\), and the LCT channel address coincides with the SSM channel a\=0A= ddress.)72 267 Q 2.75(As)72 293 S=0A= (ender can locally allocate unique SSM channel addresses, and this mak)=0A= -2.75 E(es allocation of LCT)-.11 E(channel addresses easy with SSM.)72=0A= 306 Q 1.76 -.88(To a)5.5 H=0A= (llocate LCT channel addresses using ASM, the sender).88 E(must uniquel\=0A= y chose the ASM multicast group address across the scope of the group, \=0A= and this)72 319 Q(mak)72 332 Q=0A= (es allocation of LCT channel addresses more dif)-.11 E=0A= (\214cult with ASM.)-.275 E=0A= (LCT channels and SSM channels coincide, and thus the recei)72 358 Q=0A= -.165(ve)-.275 G 2.75(rw).165 G(ill only recei)-2.75 E .33 -.165(ve p)=0A= -.275 H(ack).165 E(ets sent to)-.11 E(the requested LCT channel.)72 371=0A= Q -.44(Wi)5.5 G(th ASM, the recei).44 E -.165(ve)-.275 G 2.75(rj).165 G=0A= (oins an LCT channel by joining a multicast)-2.75 E=0A= (group G, and all pack)72 384 Q(ets sent to G, re)-.11 E -.055(ga)-.165=0A= G(rdless of the sender).055 E 2.75(,m)-.44 G(ay be recei)-2.75 E -.165=0A= (ve)-.275 G 2.75(db).165 G 2.75(yt)-2.75 G(he recei)-2.75 E -.165(ve)=0A= -.275 G -.605(r.).165 G(Thus, SSM has compelling security adv)72 397 Q=0A= (antages o)-.275 E -.165(ve)-.165 G 2.75(rA).165 G(SM for pre)-2.75 E=0A= -.165(ve)-.275 G(ntion of denial of service).165 E 2.75(attacks. In)72=0A= 410 R(either case, recei)2.75 E -.165(ve)-.275 G=0A= (rs should use mechanisms to \214lter out pack).165 E(ets from unw)-.11=0A= E(anted)-.11 E(sources.)72 423 Q(LCT also requires recei)72 449 Q -.165=0A= (ve)-.275 G=0A= (rs to obtain Session Description Information, as described in Section)=0A= .165 E(4.1. The session description could be in a form such as SDP as d\=0A= e\214ned in RFC2327, or XML)72 462 Q=0A= (metadata, or HTTP/Mime headers as de\214ned in RFC2068, and distrib)72=0A= 475 Q(uted with SAP as de\214ned in)-.22 E(RFC2974, using HTTP)72 488 Q=0A= 2.75(,o)-1.221 G 2.75(ri)-2.75 G 2.75(no)-2.75 G(ther w)-2.75 E(ays.)=0A= -.11 E(The particular layered encoder and congestion control protocols \=0A= used with LCT ha)72 514 Q .33 -.165(ve a)-.22 H 2.75(ni).165 G(mpact)=0A= -2.75 E(on the performance and applicability of LCT)72 527 Q 5.5(.F)=0A= -.814 G(or e)-5.665 E(xample, some layered encoders used for video)-.165=0A= E(and audio streams can produce a v)72 540 Q=0A= (ery limited number of layers, thus pro)-.165 E(viding a v)-.165 E=0A= (ery coarse)-.165 E(control in the reception rate of pack)72 553 Q=0A= (ets by recei)-.11 E -.165(ve)-.275 G(rs in a session.).165 E=0A= (When LCT is used for reliable)5.5 E(data transfer)72 566 Q 2.75(,s)-.44=0A= G(ome FEC codecs are inherently limited in the size of the object the)=0A= -2.75 E 2.75(yc)-.165 G(an encode,)-2.75 E(and for objects lar)72 579 Q=0A= (ger than this size the reception o)-.198 E -.165(ve)-.165 G=0A= (rhead on the recei).165 E -.165(ve)-.275 G(rs can gro).165 E 2.75(ws)=0A= -.275 G(ubstantially)-2.75 E(.)-.715 E(Some netw)72 605 Q(orks are not \=0A= amenable to some congestion control protocols that could be used with)=0A= -.11 E(LCT)72 618 Q 5.5(.I)-.814 G 2.75(np)-5.5 G(articular)-2.75 E 2.75=0A= (,f)-.44 G(or a satellite or wireless netw)-2.75 E=0A= (ork, there may be no mechanism for recei)-.11 E -.165(ve)-.275 G(rs to)=0A= .165 E(ef)72 631 Q(fecti)-.275 E -.165(ve)-.275 G=0A= (ly reduce their reception rate since there may be a \214x).165 E=0A= (ed transmission rate allocated to the)-.165 E(session.)72 644 Q(Some p\=0A= rotocol instantiations that use LCT may require the generation of feedb\=0A= ack from the)72 670 Q(recei)72 683 Q -.165(ve)-.275 G(rs to the sender)=0A= .165 E 5.5(.F)-.605 G(or e)-5.665 E=0A= (xample, Generic Router Assist may be used to help in passing real-)=0A= -.165 E(time statistics in a scalable manner from recei)72 696 Q -.165=0A= (ve)-.275 G(rs back to the sender).165 E 2.75(.H)-.605 G -.275(ow)-2.75=0A= G -2.365 -.275(ev e).275 H .88 -.44(r, t).275 H(he mechanism).44 E=0A= (for doing this is outside the scope of LCT)72 709 Q(.)-.814 E=0A= (Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A= 109.106(wcroft Section)-.275 F 2.75(1.2. [P)2.75 F(age 6])-.165 E EP=0A= %%Page: 7 7=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(2.)72 85=0A= Q/F2 14/Times-Bold@0 SF(General Ar)5.5 E(chitectur)-.252 E(e)-.252 E F0=0A= (An LCT session comprises a logically related set of one or more LCT ch\=0A= annels originating at a)72 101.6 Q=0A= (single sender that are used for some period of time to carry pack)72=0A= 114.6 Q(ets containing LCT headers)-.11 E(pertaining to the transmissio\=0A= n of one or more objects that can be of interest to recei)72 127.6 Q=0A= -.165(ve)-.275 G(rs.).165 E -.165(Fo)72 153.6 S 2.75(re).165 G=0A= (xample, an LCT session could be used to deli)-2.915 E -.165(ve)-.275 G=0A= 2.75(raT).165 G 2.75(Vp)-2.75 G(rogram using three LCT channels.)-2.75 E=0A= (Recei)72 166.6 Q(ving pack)-.275 E=0A= (ets from the \214rst LCT channel could allo)-.11 E 2.75(wb)-.275 G=0A= (lack and white reception, recei)-2.75 E(ving)-.275 E(the \214rst tw)72=0A= 179.6 Q 2.75(oL)-.11 G=0A= (CT channels could also permit color reception, whereas recei)-2.75 E=0A= (ving all three channels)-.275 E(could allo)72 192.6 Q 2.75(wH)-.275 G=0A= (DTV quality reception.)-2.75 E(Objects in this e)5.5 E=0A= (xample could correspond to indi)-.165 E(vidual TV)-.275 E=0A= (programs being transmitted.)72 205.6 Q(As another e)72 231.6 Q=0A= (xample, a reliable LCT session could be used to reliably deli)-.165 E=0A= -.165(ve)-.275 G 2.75(rh).165 G(ourly-updated)-2.75 E=0A= (weather maps \(objects\) using ten LCT channels at dif)72 244.6 Q=0A= (ferent rates, using FEC coding.)-.275 E 2.75(Ar)5.5 G(ecei)-2.75 E=0A= -.165(ve)-.275 G(r).165 E(may join and concurrently recei)72 257.6 Q .33=0A= -.165(ve p)-.275 H(ack).165 E=0A= (ets from subsets of these channels, until it has enough)-.11 E(pack)72=0A= 270.6 Q(ets in total to reco)-.11 E -.165(ve)-.165 G 2.75(rt).165 G=0A= (he object, then lea)-2.75 E .33 -.165(ve t)-.22 H=0A= (he session \(or remain connected listening for).165 E=0A= (session description information only\) until it is time to recei)72=0A= 283.6 Q .33 -.165(ve t)-.275 H(he ne).165 E(xt object.)-.165 E=0A= (In this case, the)5.5 E(quality metric is the time required to recei)72=0A= 296.6 Q .33 -.165(ve e)-.275 H(ach object.).165 E=0A= (Before joining a session, the recei)72 322.6 Q -.165(ve)-.275 G=0A= (rs must obtain enough of the session description to start the).165 E=0A= 2.75(session. This)72 335.6 R(must include the rele)2.75 E -.275(va)=0A= -.275 G(nt session parameters needed by a recei).275 E -.165(ve)-.275 G=0A= 2.75(rt).165 G 2.75(op)-2.75 G(articipate in)-2.75 E=0A= (the session, including all information rele)72 348.6 Q -.275(va)-.275 G=0A= (nt to congestion control.).275 E(The session description is)5.5 E=0A= (determined by the sender)72 361.6 Q 2.75(,a)-.44 G=0A= (nd is typically communicated to the recei)-2.75 E -.165(ve)-.275 G=0A= (rs out of band. In some).165 E(cases, as described later)72 374.6 Q=0A= 2.75(,p)-.44 G(arts of the session description that are not required to\=0A= initiate a session)-2.75 E=0A= (may be included in the LCT header or communicated to a recei)72 387.6 Q=0A= -.165(ve)-.275 G 2.75(ro).165 G(ut of band after the recei)-2.75 E -.165=0A= (ve)-.275 G(r).165 E(has joined the session.)72 400.6 Q=0A= (An encoder may be used to generate the data that is placed in the pack)=0A= 72 426.6 Q(et payload in order to)-.11 E(pro)72 439.6 Q=0A= (vide reliability)-.165 E 5.5(.A)-.715 G(suitable decoder is used to re\=0A= produce the original information from the)-2.75 E(pack)72 452.6 Q=0A= (et payload.)-.11 E(There may be a reliability header that follo)5.5 E=0A= (ws the LCT header if such an encoder)-.275 E(and decoder is used.)72=0A= 465.6 Q(The reliability header helps to describe the encoding data carr\=0A= ied in the)5.5 E(payload of the pack)72 478.6 Q 2.75(et. The)-.11 F(for\=0A= mat of the reliability header depends on the coding used, and this is)=0A= 2.75 E(ne)72 491.6 Q(gotiated out-of-band.)-.165 E(As an e)5.5 E=0A= (xample, one of the FEC headers described in [6] could be used.)-.165 E=0A= -.165(Fo)72 517.6 S 2.75(rL).165 G(CT)-2.75 E 2.75(,w)-.814 G=0A= (hen multi-rate congestion control is used, congestion control is achie)=0A= -2.75 E -.165(ve)-.275 G 2.75(db).165 G 2.75(ys)-2.75 G(ending)-2.75 E=0A= (pack)72 530.6 Q(ets associated with a gi)-.11 E -.165(ve)-.275 G 2.75=0A= (ns).165 G(ession to se)-2.75 E -.165(ve)-.275 G(ral LCT channels.).165=0A= E(Indi)5.5 E(vidual recei)-.275 E -.165(ve)-.275 G(rs).165 E=0A= (dynamically join one or more of these channels, according to the netw)=0A= 72 543.6 Q(ork congestion as seen by)-.11 E(the recei)72 556.6 Q -.165=0A= (ve)-.275 G 3.96 -.605(r. L).165 H=0A= (CT headers include an opaque \214eld which must be used to con).605 E=0A= .33 -.165(vey c)-.44 H(ongestion).165 E=0A= (control information to the recei)72 569.6 Q -.165(ve)-.275 G 2.75=0A= (rs. The).165 F(actual congestion control scheme to use with LCT is)2.75=0A= E(ne)72 582.6 Q(gotiated out-of-band.)-.165 E(Some e)5.5 E=0A= (xamples of congestion control protocols that may be suitable for)-.165=0A= E(content deli)72 595.6 Q -.165(ve)-.275 G(ry are described in [11] and\=0A= [1]. Other congestion controls may be suitable when).165 E=0A= (LCT is used for a streaming application.)72 608.6 Q(LCT can be used wi\=0A= th other congestion control protocols such as the one described in [11]\=0A= , or)72 634.6 Q=0A= (Generic Router Assist schemes where the selection of which pack)72=0A= 647.6 Q(ets to forw)-.11 E(ard is performed by)-.11 E=0A= (routers. This latter approach potentially allo)72 660.6 Q=0A= (ws for \214ner grain congestion control and a f)-.275 E(aster)-.11 E=0A= (reaction to netw)72 673.6 Q(ork congestion, b)-.11 E=0A= (ut requires changes to the router infrastructure.)-.22 E 1.76 -.88=0A= (We d)5.5 H 2.75(on).88 G(ot)-2.75 E=0A= (discuss this approach further in this document.)72 686.6 Q=0A= (Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A= 117.356(wcroft Section)-.275 F 2.75(2. [P)2.75 F(age 7])-.165 E EP=0A= %%Page: 8 8=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(2.1.)72=0A= 85 Q/F2 13/Times-Bold@0 SF(Deli)5.5 E -.13(ve)-.13 G(ry ser).13 E=0A= (vice models)-.13 E F0(LCT can support se)72 101.6 Q -.165(ve)-.275 G=0A= (ral dif).165 E(ferent deli)-.275 E -.165(ve)-.275 G=0A= (ry service models. T).165 E .22 -.11(wo e)-.88 H=0A= (xamples are brie\215y described)-.055 E(here.)72 114.6 Q F1(Push ser)72=0A= 153.6 Q(vice model.)-.11 E F0(One w)72 170.2 Q=0A= (ay a push service model can be used for reliable content deli)-.11 E=0A= -.165(ve)-.275 G(ry is to deli).165 E -.165(ve)-.275 G 2.75(ras).165 G=0A= (eries of)-2.75 E 2.75(objects. F)72 183.2 R(or e)-.165 E=0A= (xample, a recei)-.165 E -.165(ve)-.275 G 2.75(rc).165 G=0A= (ould join the session and dynamically adapt the number of LCT)-2.75 E=0A= (channels the recei)72 196.2 Q -.165(ve)-.275 G 2.75(ri).165 G 2.75(sj)=0A= -2.75 G(oined to until enough pack)-2.75 E(ets ha)-.11 E .33 -.165(ve b)=0A= -.22 H(een recei).165 E -.165(ve)-.275 G 2.75(dt).165 G 2.75(or)-2.75 G=0A= (econstruct an)-2.75 E=0A= (object. After reconstructing the object the recei)72 209.2 Q -.165(ve)=0A= -.275 G 2.75(rm).165 G(ay stay in the session and w)-2.75 E(ait for the)=0A= -.11 E(transmission of the ne)72 222.2 Q(xt object.)-.165 E=0A= (The push model is particularly attracti)72 248.2 Q .33 -.165(ve i)-.275=0A= H 2.75(ns).165 G(atellite netw)-2.75 E(orks and wireless netw)-.11 E=0A= 2.75(orks. In)-.11 F(these)2.75 E=0A= (cases, a session may consist of one \214x)72 261.2 Q=0A= (ed rate LCT channel.)-.165 E F1(On-demand content deli)72 300.2 Q -.11=0A= (ve)-.11 G(ry model.).11 E F0 -.165(Fo)72 316.8 S 2.75(ra).165 G 2.75=0A= (no)-2.75 G(n-demand content deli)-2.75 E -.165(ve)-.275 G=0A= (ry service model, senders typically transmit for some gi).165 E -.165=0A= (ve)-.275 G 2.75(nt).165 G(ime)-2.75 E=0A= (period selected to be long enough to allo)72 329.8 Q 2.75(wa)-.275 G=0A= (ll the intended recei)-2.75 E -.165(ve)-.275 G=0A= (rs to join the session and).165 E(reco)72 342.8 Q -.165(ve)-.165 G 2.75=0A= (rt).165 G(he object.)-2.75 E -.165(Fo)5.5 G 2.75(re).165 G=0A= (xample a popular softw)-2.915 E=0A= (are update might be transmitted using LCT for)-.11 E(se)72 355.8 Q=0A= -.165(ve)-.275 G(ral days, e).165 E -.165(ve)-.275 G 2.75(nt).165 G=0A= (hough a recei)-2.75 E -.165(ve)-.275 G 2.75(rm).165 G=0A= (ay be able to complete the do)-2.75 E(wnload in one hour total of)-.275=0A= E(connection time, perhaps spread o)72 368.8 Q -.165(ve)-.165 G 2.75(rs)=0A= .165 G -2.365 -.275(ev e)-2.75 H(ral interv).275 E(als of time.)-.275 E=0A= (In this case the recei)72 394.8 Q -.165(ve)-.275 G=0A= (rs join the session, and dynamically adapt the number of LCT channels)=0A= .165 E(the)72 407.8 Q 2.75(ys)-.165 G=0A= (ubscribe to \(and the reception quality\) according to the a)-2.75 E=0A= -.275(va)-.22 G(ilable bandwidth. Recei).275 E -.165(ve)-.275 G(rs then)=0A= .165 E(drop from the session when the)72 420.8 Q 2.75(yh)-.165 G -2.475=0A= -.22(av e)-2.75 H(recei)2.97 E -.165(ve)-.275 G 2.75(de).165 G=0A= (nough pack)-2.75 E(ets to reco)-.11 E -.165(ve)-.165 G 2.75(rt).165 G=0A= (he object.)-2.75 E(As an e)72 446.8 Q=0A= (xample, assume that an object is 50 MB.)-.165 E=0A= (The sender could send 1 KB pack)5.5 E(ets to the \214rst)-.11 E=0A= (LCT channel at 50 pack)72 459.8 Q(ets per second, so that recei)-.11 E=0A= -.165(ve)-.275 G(rs using just this LCT channel could).165 E(complete r\=0A= eception of the object in 1,000 seconds in absence of loss, and w)72=0A= 472.8 Q(ould be able to)-.11 E(complete reception e)72 485.8 Q -.165(ve)=0A= -.275 G 2.75(ni).165 G 2.75(np)-2.75 G=0A= (resence of some substantial amount of losses with the use of coding)=0A= -2.75 E(for reliability)72 498.8 Q 5.5(.F)-.715 G(urthermore, the sende\=0A= r could use a number of LCT channels such that the)-5.5 E(aggre)72 511.8=0A= Q -.055(ga)-.165 G(te rate of 1 KB pack).055 E=0A= (ets to all LCT channels is 1,000 pack)-.11 E=0A= (ets per second, so that a recei)-.11 E -.165(ve)-.275 G(r).165 E(could\=0A= be able to complete reception of the object in as little 50 seconds \(\=0A= assuming no loss and that)72 524.8 Q=0A= (the congestion control mechanism immediately con)72 537.8 Q -.165(ve)=0A= -.44 G -.198(rg).165 G(es to the use of all LCT channels\).).198 E F1=0A= (Other ser)72 576.8 Q(vice models.)-.11 E F0(There are man)72 606.4 Q=0A= 2.75(yo)-.165 G(ther deli)-2.75 E -.165(ve)-.275 G=0A= (ry service models that LCT can be used for that are not co).165 E -.165=0A= (ve)-.165 G(red).165 E(abo)72 619.4 Q -.165(ve)-.165 G 5.5(.A).165 G=0A= 2.75(se)-5.5 G(xamples, a li)-2.915 E .33 -.165(ve s)-.275 H=0A= (treaming or an on-demand archi).165 E -.275(va)-.275 G 2.75(lc).275 G=0A= (ontent streaming service model.)-2.75 E(The description of the man)72=0A= 632.4 Q 2.75(yp)-.165 G(otential applications, the appropriate deli)=0A= -2.75 E -.165(ve)-.275 G(ry service model, and).165 E(the additional me\=0A= chanisms to support such functionalities when combined with LCT is be)72=0A= 645.4 Q(yond)-.165 E(the scope of this document.)72 658.4 Q=0A= (This document only attempts to describe the minimal common)5.5 E=0A= (scalable elements to these di)72 671.4 Q -.165(ve)-.275 G=0A= (rse applications using LCT as the deli).165 E -.165(ve)-.275 G=0A= (ry transport.).165 E(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66=0A= E(y/Cro)-.165 E 109.106(wcroft Section)-.275 F 2.75(2.1. [P)2.75 F=0A= (age 8])-.165 E EP=0A= %%Page: 9 9=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(2.2.)72=0A= 85 Q/F2 13/Times-Bold@0 SF(Congestion Contr)5.5 E(ol)-.234 E F0(The spe\=0A= ci\214c congestion control protocol to be used for LCT sessions depends\=0A= on the type of)72 101.6 Q(content to be deli)72 114.6 Q -.165(ve)-.275=0A= G(red. While the general beha).165 E=0A= (vior of the congestion control protocol is to reduce)-.22 E(the throug\=0A= hput in presence of congestion and gradually increase it in the absence\=0A= of congestion,)72 127.6 Q(the actual dynamic beha)72 140.6 Q=0A= (vior \(e.g. response to single losses\) can v)-.22 E(ary)-.275 E(.)=0A= -.715 E=0A= (Some possible congestion control protocols for reliable content deli)72=0A= 166.6 Q -.165(ve)-.275 G(ry using LCT are described).165 E=0A= (in [11] and [1]. Dif)72 179.6 Q(ferent deli)-.275 E -.165(ve)-.275 G=0A= (ry service models might require dif).165 E(ferent congestion control)=0A= -.275 E(protocols.)72 192.6 Q F1(3.)72 231.6 Q/F3 14/Times-Bold@0 SF=0A= (LCT header)5.5 E F0 -.165(Pa)72 248.2 S(ck).165 E=0A= (ets sent to an LCT session must include an "LCT header".)-.11 E=0A= (The LCT header format described)5.5 E(belo)72 261.2 Q 2.75(wi)-.275 G=0A= 2.75(st)-2.75 G(he def)-2.75 E(ault format, and this is the format that\=0A= is recommended for use by protocol)-.11 E=0A= (instantiations to ensure a uniform format across dif)72 274.2 Q=0A= (ferent protocol instantiations.)-.275 E(Other LCT)5.5 E=0A= (header formats may be used by protocol instantiations, b)72 287.2 Q=0A= (ut if the def)-.22 E(ault LCT header format is not)-.11 E=0A= (used by a protocol insantiation that uses LCT)72 300.2 Q 2.75(,t)-.814=0A= G(hen the protocol instantiation must specify the)-2.75 E(lengths and p\=0A= ositions within the LCT header it uses of all \214elds described in the\=0A= def)72 313.2 Q(ault LCT)-.11 E(header)72 326.2 Q(.)-.605 E(Other b)72=0A= 352.2 Q(uilding blocks may describe some of the same \214elds as descri\=0A= bed for the LCT header)-.22 E 5.5(.I)-.605 G 2.75(ti)-5.5 G(s)-2.75 E=0A= (recommended that protocol instantiations using multiple b)72 365.2 Q=0A= (uilding blocks include shared \214elds at)-.22 E=0A= (most once in each pack)72 378.2 Q 2.75(et. Thus,)-.11 F(for e)2.75 E=0A= (xample, if another b)-.165 E(uilding block is used with LCT that)-.22 E=0A= (includes the optional Expected Residual T)72 391.2 Q=0A= (ime \214eld, then the Expected Residual T)-.385 E(ime \214eld should)=0A= -.385 E(be carried in each pack)72 404.2 Q(et at most once.)-.11 E=0A= (The position of the LCT header within a pack)72 430.2 Q=0A= (et must be speci\214ed by an)-.11 E 2.75(yp)-.165 G=0A= (rotocol instantiation)-2.75 E(that uses LCT)72 443.2 Q(.)-.814 E F1=0A= (3.1.)72 482.2 Q F2(Default LCT header f)5.5 E(ormat)-.325 E F0(The def)=0A= 72 498.8 Q(ault LCT header is of v)-.11 E(ariable size, which is speci\=0A= \214ed by a length \214eld in the third byte of)-.275 E(the header)72=0A= 511.8 Q 5.5(.I)-.605 G 2.75(nt)-5.5 G(he LCT header)-2.75 E 2.75(,a)-.44=0A= G(ll inte)-2.75 E(ger \214elds are carried in "big-endian" or "netw)=0A= -.165 E(ork order")-.11 E=0A= (format, that is, most signi\214cant byte \(octet\) \214rst.)72 524.8 Q=0A= (Bits designated as "padding" or "reserv)5.5 E(ed" \(r\))-.165 E=0A= (must by set to 0 by senders and ignored by recei)72 537.8 Q -.165(ve)=0A= -.275 G 2.75(rs. Unless).165 F(otherwise noted, numeric constants)2.75 E=0A= (in this speci\214cation are in decimal \(base 10\).)72 550.8 Q=0A= (The format of the def)72 576.8 Q=0A= (ault LCT header is depicted in Figure 1.)-.11 E(Luby/Gemmell/V)72 769 Q=0A= (icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E 109.106(wcroft Section)-.275=0A= F 2.75(3.1. [P)2.75 F(age 9])-.165 E EP=0A= %%Page: 10 10=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E/F1 8/Courier@0 SF 91.2(0123)=0A= 81.6 85 S 4.8(01234567890123456789012345678901)81.6 98 S=0A= (+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A= 111 Q 14.4(|V|)76.8 124 S 4.8(C| r |H|S|)-14.4 F 4.8(O|)4.8 G 9.6=0A= (T|R|A|B| HDR_LEN)-4.8 F 4.8(|C)24 G(odepoint \(CP\)|)-4.8 E=0A= (+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A= 137 Q 62.4(|C)76.8 150 S(ongestion Control Information \(CCI\))-62.4 E=0A= (|)67.2 E=0A= (+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A= 163 Q 91.2(|C)76.8 176 S(CI continued \(if C =3D 1\))-91.2 E(|)96 E=0A= (+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A= 189 Q 9.6(|T)76.8 202 S=0A= (ransport Session Identifier \(TSI, length =3D 32*S+16*H bits\))-9.6 E(|)=0A= 9.6 E 124.8(|.)76.8 215 S 158.4(.. |)-124.8 F 302.4(++)76.8 228 S 14.4=0A= (|T)76.8 241 S=0A= (ransport Object Identifier \(TOI, length =3D 32*O+16*H bits\))-14.4 E(|)=0A= 9.6 E 124.8(|.)76.8 254 S 158.4(.. |)-124.8 F=0A= (+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A= 267 Q 72(|S)76.8 280 S(ender Current Time \(SCT, if T =3D 1\))-72 = E(|)62.4=0A= E(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A= 293 Q 67.2(|E)76.8 306 S(xpected Residual Time \(ERT, if R =3D 1\))-67.2 = E=0A= (|)52.8 E=0A= (+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A= 319 Q 76.8(|H)76.8 332 S(eader Extensions \(if applicable\))-76.8 E(|)=0A= 67.2 E 302.4(||)76.8 345 S=0A= (+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A= 358 Q/F2 10/Times-Roman@0 SF(Figure 1 - Def)72 397 Q=0A= (ault LCT header format)-.1 E F0=0A= (The function and length of each \214eld in the def)72 426.6 Q=0A= (ault LCT header is the follo)-.11 E 2.75(wing. Fields)-.275 F(mark)2.75=0A= E(ed)-.11 E(as "1" mean that the corresponding bits must be set to "1" \=0A= by the sender)72 439.6 Q 5.5(.F)-.605 G(ields mark)-5.5 E(ed as "r" or)=0A= -.11 E=0A= ("0" mean that the corresponding bits must be set to "0" by the sender)=0A= 72 452.6 Q(.)-.605 E(LCT v)83 482.2 Q(ersion number \(V\): 4 bits)-.165=0A= E(Indicates the LCT v)105 498.8 Q(ersion number)-.165 E 5.5(.T)-.605 G=0A= (he LCT v)-5.5 E(ersion number for this speci\214cation is 0.)-.165 E=0A= (Congestion control \215ag \(C\): 1 bit)83 528.4 Q(C=3D0 indicates the = Co\=0A= ngestion Control Information \(CCI\) \214eld is 32-bits in length.)105=0A= 545 Q(C=3D1 indicates the CCI \214eld is 64-bits in length.)105 558 Q=0A= (Reserv)83 587.6 Q(ed \(r\): 3 bits)-.165 E(Reserv)105 604.2 Q=0A= (ed for future use. A sender must set these bits to zero and a recei)=0A= -.165 E -.165(ve)-.275 G 2.75(rm).165 G(ust ignore)-2.75 E(these bits.)=0A= 105 617.2 Q(Half-w)83 646.8 Q(ord \215ag \(H\): 1 bit)-.11 E=0A= (The TSI and the T)105 663.4 Q=0A= (OI \214elds are both multiples of 32-bits plus 16*H bits in length.)=0A= -.198 E(This)5.5 E(allo)105 676.4 Q(ws the TSI and T)-.275 E=0A= (OI \214eld lengths to be multiples of a half-w)-.198 E=0A= (ord \(16 bits\), while)-.11 E(ensuring that the aggre)105 689.4 Q -.055=0A= (ga)-.165 G(te length of the TSI and T).055 E=0A= (OI \214elds is a multiple of 32-bits.)-.198 E(Luby/Gemmell/V)72 769 Q=0A= (icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E 103.606(wcroft Section)-.275=0A= F 2.75(3.1. [P)2.75 F(age 10])-.165 E EP=0A= %%Page: 11 11=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E -.385(Tr)83 85 S=0A= (ansport Session Identi\214er \215ag \(S\): 1 bit).385 E=0A= (This is the number of full 32-bit w)105 101.6 Q=0A= (ords in the TSI \214eld.)-.11 E(The TSI \214eld is 32*S + 16*H bits)5.5=0A= E(in length, i.e. the length is either 0 bits, 16 bits, 32 bits, or 48 \=0A= bits.)105 114.6 Q -.385(Tr)83 144.2 S=0A= (ansport Object Identi\214er \215ag \(O\): 2 bits).385 E=0A= (This is the number of full 32-bit w)105 160.8 Q(ords in the T)-.11 E=0A= (OI \214eld.)-.198 E(The T)5.5 E(OI \214eld is 32*O + 16*H)-.198 E(bits\=0A= in length, i.e., the length is either 0 bits, 16 bits, 32 bits, 48 bit\=0A= s, 64 bits, 80 bits, 96)105 173.8 Q(bits, or 112 bits.)105 186.8 Q=0A= (Sender Current T)83 216.4 Q(ime present \215ag \(T\): 1 bit)-.385 E=0A= 2.75(T=3D0i)105 233 S(ndicates that the Sender Current T)-2.75 E=0A= (ime \(SCT\) \214eld is not present.)-.385 E 2.75(T=3D1i)105 246 S=0A= (ndicates that the SCT \214eld is present.)-2.75 E=0A= (The SCT is inserted by senders to indicate to recei)105 259 Q -.165(ve)=0A= -.275 G(rs ho).165 E 2.75(wl)-.275 G(ong the session has been in)-2.75 E=0A= (progress.)105 272 Q(Expected Residual T)83 301.6 Q=0A= (ime present \215ag \(R\): 1 bit)-.385 E 2.75(R=3D0i)105 318.2 S=0A= (ndicates that the Expected Residual T)-2.75 E(ime \(ER)-.385 E=0A= (T\) \214eld is not present.)-.66 E 2.75(R=3D1i)105 331.2 S=0A= (ndicates that the ER)-2.75 E 2.75<548c>-.66 G(eld is present.)-2.75 E=0A= (The ER)105 344.2 Q 2.75(Ti)-.66 G 2.75(si)-2.75 G=0A= (nserted by senders to indicate to recei)-2.75 E -.165(ve)-.275 G(rs ho)=0A= .165 E 2.75(wm)-.275 G(uch longer the session /)-2.75 E=0A= (object transmission will continue.)105 357.2 Q=0A= (Senders must not set R =3D 1 when the ER)105 370.2 Q 2.75(Tf)-.66 G=0A= (or the session is more than 2^32-1 time units)-2.75 E(\(approximately \=0A= 49 days\), where time is measured in units of milliseconds.)105 383.2 Q=0A= (Close Session \215ag \(A\): 1 bit)83 412.8 Q(Normally)105 429.4 Q 2.75=0A= (,Ai)-.715 G 2.75(ss)-2.75 G(et to 0.)-2.75 E=0A= (The sender may set A to 1 when termination of transmission of)5.5 E=0A= (pack)105 442.4 Q(ets for the session is imminent.)-.11 E 2.75(Am)5.5 G=0A= (ay be set to 1 in just the last pack)-2.75 E(et transmitted)-.11 E=0A= (for the session, or A may be set to 1 in the last fe)105 455.4 Q 2.75=0A= (ws)-.275 G(econds of pack)-2.75 E(ets transmitted for the)-.11 E 2.75=0A= (session. Once)105 468.4 R(the sender sets A to 1 in one pack)2.75 E=0A= (et, the sender should set A to 1 in all)-.11 E(subsequent pack)105=0A= 481.4 Q(ets until termination of transmission of pack)-.11 E=0A= (ets for the session.)-.11 E(A)5.5 E(recei)105 494.4 Q -.165(ve)-.275 G=0A= 2.75(dp).165 G(ack)-2.75 E(et with A set to 1 indicates to a recei)-.11=0A= E -.165(ve)-.275 G 2.75(rt).165 G(hat the sender will immediately)-2.75=0A= E(stop sending pack)105 507.4 Q(ets for the session.)-.11 E=0A= (When a recei)5.5 E -.165(ve)-.275 G 2.75(rr).165 G(ecei)-2.75 E -.165=0A= (ve)-.275 G 2.75(sap).165 G(ack)-2.75 E(et with A set to 1 the)-.11 E=0A= (recei)105 520.4 Q -.165(ve)-.275 G 2.75(rs).165 G=0A= (hould assume that no more pack)-2.75 E=0A= (ets will be sent to the session.)-.11 E=0A= (Close Object \215ag \(B\): 1 bit)83 550 Q(Normally)105 566.6 Q 2.75=0A= (,Bi)-.715 G 2.75(ss)-2.75 G(et to 0.)-2.75 E=0A= (The sender may set B to 1 when termination of transmission of)5.5 E=0A= (pack)105 579.6 Q(ets for an object is imminent.)-.11 E(If the T)5.5 E=0A= (OI \214eld is in use and B is set to 1 then)-.198 E=0A= (termination of transmission for the object identi\214ed by the T)105=0A= 592.6 Q(OI \214eld is imminent.)-.198 E(If the)5.5 E -.198(TO)105 605.6=0A= S 2.75<498c>.198 G(eld is not in use and B is set to 1 then termination\=0A= of transmission for the one object)-2.75 E=0A= (in the session identi\214ed by out of band information is imminent.)105=0A= 618.6 Q 2.75(Bm)5.5 G(ay be set to 1 in just)-2.75 E(the last pack)105=0A= 631.6 Q=0A= (et transmitted for the object, or B may be set to 1 in the last fe)-.11=0A= E 2.75(ws)-.275 G(econds)-2.75 E(pack)105 644.6 Q=0A= (ets transmitted for the object.)-.11 E=0A= (Once the sender sets B to 1 in one pack)5.5 E(et for a)-.11 E=0A= (particular object, the sender should set B to 1 in all subsequent pack)=0A= 105 657.6 Q(ets for the object until)-.11 E=0A= (termination of transmission of pack)105 670.6 Q(ets for the object.)=0A= -.11 E 2.75(Ar)5.5 G(ecei)-2.75 E -.165(ve)-.275 G 2.75(dp).165 G(ack)=0A= -2.75 E(et with B set to 1)-.11 E(indicates to a recei)105 683.6 Q -.165=0A= (ve)-.275 G 2.75(rt).165 G=0A= (hat the sender will immediately stop sending pack)-2.75 E=0A= (ets for the object.)-.11 E(When a recei)105 696.6 Q -.165(ve)-.275 G=0A= 2.75(rr).165 G(ecei)-2.75 E -.165(ve)-.275 G 2.75(sap).165 G(ack)-2.75 E=0A= (et with B set to 1 then it should assume that no more)-.11 E(pack)105=0A= 709.6 Q(ets will be sent for the object to the session.)-.11 E=0A= (Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A= 103.606(wcroft Section)-.275 F 2.75(3.1. [P)2.75 F(age 11])-.165 E EP=0A= %%Page: 12 12=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E=0A= (LCT header length \(HDR_LEN\): 8 bits)83 85 Q -.88(To)105 101.6 S=0A= (tal length of the LCT header in units of 32-bit w).88 E 2.75(ords. The)=0A= -.11 F(length of the LCT header)2.75 E(must be a multiple of 32-bits.)=0A= 105 114.6 Q=0A= (This \214eld can be used to directly access the portion of the)5.5 E=0A= (pack)105 127.6 Q(et be)-.11 E(yond the LCT header)-.165 E 2.75(,i)-.44=0A= G(.e., to the \214rst other header if it e)-2.75 E=0A= (xists, or to the pack)-.165 E(et)-.11 E(payload if it e)105 140.6 Q=0A= (xists and there is no other header)-.165 E 2.75(,o)-.44 G 2.75(rt)-2.75=0A= G 2.75(ot)-2.75 G(he end of the pack)-2.75 E(et if there are no)-.11 E=0A= (other headers or pack)105 153.6 Q(et payload.)-.11 E=0A= (Codepoint \(CP\): 8 bits)83 183.2 Q=0A= (An opaque identi\214er which is passed to the pack)105 199.8 Q=0A= (et payload decoder to con)-.11 E .33 -.165(vey i)-.44 H(nformation).165=0A= E(on the codec being used for the pack)105 212.8 Q=0A= (et payload. The mapping between the codepoint and)-.11 E(the actual co\=0A= dec is de\214ned on a per session basis and communicated out-of-band as\=0A= part of)105 225.8 Q(the session description information.)105 238.8 Q=0A= (The use of the CP \214eld is similar to the P)5.5 E(ayload T)-.165 E=0A= (ype)-.88 E(\(PT\) \214eld in R)105 251.8 Q=0A= (TP headers as described in RFC1889.)-.66 E=0A= (Congestion Control Information \(CCI\): 32 or 64 bits)83 281.4 Q=0A= (Used to carry congestion control information.)105 298 Q -.165(Fo)5.5 G=0A= 2.75(re).165 G(xample, the congestion control)-2.915 E(information coul\=0A= d include layer numbers, logical channel numbers, and sequence)105 311 Q=0A= (numbers. This \214eld is opaque for the purpose of this speci\214catio\=0A= n.)105 324 Q(This \214eld must be 32 bits if C=3D0.)105 337 Q=0A= (This \214eld must be 64 bits if C=3D1.)105 350 Q -.385(Tr)83 379.6 S=0A= (ansport Session Identi\214er \(TSI\): 0, 16, 32 or 48 bits).385 E(The \=0A= TSI uniquely identi\214es a session among all sessions from a particula\=0A= r sender)105 396.2 Q 5.5(.T)-.605 G(he)-5.5 E=0A= (TSI is scoped by the IP address of the sender)105 409.2 Q 2.75(,a)-.44=0A= G(nd thus the IP address of the sender and the)-2.75 E=0A= (TSI together uniquely identify the session.)105 422.2 Q=0A= (Although a TSI in conjunction with the IP)5.5 E=0A= (address of the sender must al)105 435.2 Q -.11(wa)-.11 G=0A= (ys uniquely identify a session, whether or not the TSI is).11 E=0A= (incuded in the LCT header depends on what is used as the TSI v)105=0A= 448.2 Q 2.75(alue. If)-.275 F(the underlying)2.75 E(transport is UDP)105=0A= 461.2 Q 2.75(,t)-1.221 G(hen the 16 bit UDP source port number may serv)=0A= -2.75 E 2.75(ea)-.165 G 2.75(st)-2.75 G(he TSI for the)-2.75 E 2.75=0A= (session. If)105 474.2 R(Generic Router Assist \(GRA\) is being used th\=0A= en additional dependencies may)2.75 E=0A= (be introduced by GRA on the TSI \214eld.)105 487.2 Q(If the TSI v)5.5 E=0A= (alue appears multiple times in a)-.275 E(pack)105 500.2 Q=0A= (et then all occurrences must be the same v)-.11 E 2.75(alue. If)-.275 F=0A= (there is no underlying TSI)2.75 E(pro)105 513.2 Q(vided by the netw)=0A= -.165 E(ork, transport or an)-.11 E 2.75(yo)-.165 G(ther layer)-2.75 E=0A= 2.75(,t)-.44 G(hen the TSI must be included in the)-2.75 E(LCT header)=0A= 105 526.2 Q(.)-.605 E(The TSI must be unique among all sessions serv)105=0A= 552.2 Q(ed by the sender during the period when)-.165 E=0A= (the session is acti)105 565.2 Q -.165(ve)-.275 G 2.75(,a).165 G=0A= (nd for a lar)-2.75 E(ge period of time preceding and follo)-.198 E=0A= (wing when the)-.275 E(session is acti)105 578.2 Q -.165(ve)-.275 G 5.5=0A= (.A).165 G(primary purpose of the TSI is to pre)-2.75 E -.165(ve)-.275 G=0A= (nt recei).165 E -.165(ve)-.275 G(rs from inadv).165 E(ertently)-.165 E=0A= (accepting pack)105 591.2 Q=0A= (ets from a sender that belong to sessions other than sessions recei)=0A= -.11 E -.165(ve)-.275 G(rs are).165 E(subscribed to.)105 604.2 Q -.165=0A= (Fo)5.5 G 2.75(re).165 G(xample, suppose a session is deacti)-2.915 E=0A= -.275(va)-.275 G(ted and then another session is).275 E(acti)105 617.2 Q=0A= -.275(va)-.275 G(ted by a sender and the tw).275 E 2.75(os)-.11 G=0A= (essions use an o)-2.75 E -.165(ve)-.165 G(rlapping set of channels.)=0A= .165 E 2.75(Ar)5.5 G(ecei)-2.75 E -.165(ve)-.275 G(r).165 E(that connec\=0A= ts and remains connected to the \214rst session during this sender acti)=0A= 105 630.2 Q(vity could)-.275 E(possibly accept pack)105 643.2 Q(ets fro\=0A= m the second session as belonging to the \214rst session if the TSI)-.11=0A= E(for the tw)105 656.2 Q 2.75(os)-.11 G(essions were identical.)-2.75 E=0A= (The mapping of TSI \214eld v)5.5 E(alues to sessions must be)-.275 E=0A= (done out of band.)105 669.2 Q=0A= (The length of the TSI \214eld is 32*S + 16*H bits.)105 682.2 Q=0A= (Note that the aggre)5.5 E -.055(ga)-.165 G(te lengths of the).055 E=0A= (TSI \214eld plus the T)105 695.2 Q=0A= (OI \214eld is a multiple of 32 bits.)-.198 E(Luby/Gemmell/V)72 769 Q=0A= (icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E 103.606(wcroft Section)-.275=0A= F 2.75(3.1. [P)2.75 F(age 12])-.165 E EP=0A= %%Page: 13 13=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E -.385(Tr)83 85 S=0A= (ansport Object Identi\214er \(T).385 E=0A= (OI\): 0, 16, 32, 48, 64, 80, 96 or 112 bits.)-.198 E=0A= (This \214eld indicates which object within the session this pack)105=0A= 101.6 Q(et pertains to.)-.11 E -.165(Fo)5.5 G 2.75(re).165 G(xample, a)=0A= -2.915 E=0A= (sender might send a number of \214les in the same session, using T)105=0A= 114.6 Q(OI=3D0 for the \214rst \214le,)-.198 E -.198(TO)105 127.6 S=0A= (I=3D1 for the second one, etc. As another e).198 E(xample, the T)-.165 E=0A= (OI may be a unique global)-.198 E=0A= (identi\214er of the object that is being transmitted from se)105 140.6=0A= Q -.165(ve)-.275 G(ral senders concurrently).165 E 2.75(,a)-.715 G=0A= (nd the)-2.75 E -.198(TO)105 153.6 S 2.75(Iv).198 G(alue may be the oup\=0A= tut of a hash function applied to the object. The mapping of T)-3.025 E=0A= (OI)-.198 E(\214eld v)105 166.6 Q=0A= (alues to objects must be done out of band.)-.275 E(The T)5.5 E=0A= (OI \214eld must be used in all)-.198 E(pack)105 179.6 Q(ets if more th\=0A= an one object is to be transmitted in a session, i.e. the T)-.11 E=0A= (OI \214eld is either)-.198 E(present in all the pack)105 192.6 Q=0A= (ets of a session or is ne)-.11 E -.165(ve)-.275 G 2.75(rp).165 G=0A= (resent.)-2.75 E(The length of the T)105 205.6 Q=0A= (OI \214eld is 32*O + 16*H bits.)-.198 E(Note that the aggre)5.5 E -.055=0A= (ga)-.165 G(te lengths of the).055 E(TSI \214eld plus the T)105 218.6 Q=0A= (OI \214eld is a multiple of 32 bits.)-.198 E(Sender Current T)83 248.2=0A= Q(ime \(SCT\): 0 or 32 bits)-.385 E(This \214eld represents the current\=0A= clock at the sender at the time this pack)105 264.8 Q(et w)-.11 E=0A= (as transmitted,)-.11 E(measured in units of 1ms and computed modulo 2^\=0A= 32 units from the start of the session.)105 277.8 Q=0A= (This \214eld must not be present if T=3D0 and must be present if = T=3D1.)105=0A= 290.8 Q(Expected Residual T)83 320.4 Q(ime \(ER)-.385 E=0A= (T\): 0 or 32 bits)-.66 E(This \214eld represents the sender e)105 337 Q=0A= (xpected residual transmission time for the current session)-.165 E(or \=0A= for the transmission of the current object, measured in units of 1ms. I\=0A= f the pack)105 350 Q(et)-.11 E(containing the ER)105 363 Q 2.75<548c>=0A= -.66 G(eld also contains the T)-2.75 E(OI \214eld, then ER)-.198 E 2.75=0A= (Tr)-.66 G(efers to the object)-2.75 E(corresponding to the T)105 376 Q=0A= (OI \214eld, otherwise it refers to the session.)-.198 E=0A= (This \214eld must not be present if R=3D0 and must be present if = R=3D1.)105=0A= 389 Q/F1 11/Times-Bold@0 SF(3.2.)72 428 Q/F2 13/Times-Bold@0 SF(Header)=0A= 5.5 E(-Extension Fields)-.481 E F0(Header Extensions are used in LCT to\=0A= accommodate optional header \214elds that are not al)72 444.6 Q -.11=0A= (wa)-.11 G(ys).11 E(used or ha)72 457.6 Q .33 -.165(ve v)-.22 H=0A= (ariable size.)-.11 E(Examples of the use of Header Extensions include:)=0A= 5.5 E 11(oE)77.5 474.2 S(xtended-size v)-11 E(ersions of already e)-.165=0A= E(xisting header \214elds.)-.165 E 11(oS)77.5 490.8 S(ender and Recei)=0A= -11 E -.165(ve)-.275 G 2.75(ra).165 G(uthentication information.)-2.75 E=0A= (The presence of Header Extensions can be inferred by the LCT header le\=0A= ngth \(HDR_LEN\): if)72 520.4 Q(HDR_LEN is lar)72 533.4 Q(ger than the \=0A= length of the standard header then the remaining header space is)-.198 E=0A= (tak)72 546.4 Q(en by Header Extension \214elds.)-.11 E=0A= (If present, Header Extensions must be processed to ensure that the)72=0A= 576 Q 2.75(ya)-.165 G(re recognized before)-2.75 E(performing an)72 589=0A= Q 2.75(yc)-.165 G=0A= (ongestion control procedure or otherwise accepting a pack)-2.75 E=0A= (et. The def)-.11 E(ault action)-.11 E(for unrecognized header e)72 602=0A= Q(xtensions is to ignore them. This allo)-.165 E=0A= (ws the future introduction of)-.275 E(backw)72 615 Q=0A= (ard-compatible enhancements to LCT without changing the LCT v)-.11 E=0A= (ersion number)-.165 E 5.5(.N)-.605 G(on)-5.5 E(backw)72 628 Q=0A= (ard-compatible header e)-.11 E(xtensions CANNO)-.165 E 2.75(Tb)-.44 G=0A= 2.75(ei)-2.75 G(ntroduced without changing the LCT)-2.75 E -.165(ve)72=0A= 641 S(rsion number).165 E(.)-.605 E(Protocol instantiation may o)72 667=0A= Q -.165(ve)-.165 G(rride this def).165 E(ault beha)-.11 E=0A= (vior for PI-speci\214c e)-.22 E(xtensions \(see belo)-.165 E(w\).)-.275=0A= E(There are tw)72 693 Q 2.75(of)-.11 G=0A= (ormats for Header Extension \214elds, as depicted belo)-2.75 E 1.43=0A= -.715(w. T)-.275 H(he \214rst format is used for).715 E -.275(va)72 706=0A= S(riable-length e).275 E(xtensions, with Header Extension T)-.165 E=0A= (ype \(HET\) v)-.88 E(alues between 0 and 127. The)-.275 E=0A= (second format is used for \214x)72 719 Q(ed length \(one 32-bit w)-.165=0A= E(ord\) e)-.11 E(xtensions, using HET v)-.165 E(alues from 127)-.275 E=0A= (Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A= 103.606(wcroft Section)-.275 F 2.75(3.2. [P)2.75 F(age 13])-.165 E EP=0A= %%Page: 14 14=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E(to 255.)72 85 Q/F1 8/Courier@0=0A= SF 91.2(0123)81.6 124 S 4.8(01234567890123456789012345678901)81.6 137 S=0A= (+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A= 150 Q 9.6(|H)76.8 163 S(ET \(<=3D127\))-9.6 E 33.6(|H)9.6 G 19.2(EL |)=0A= -33.6 F(|)148.8 E 144(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +)76.8 176 R=0A= 302.4(..)76.8 189 S 67.2(.H)76.8 202 S(eader Extension Content \(HEC\))=0A= -67.2 E(.)91.2 E=0A= (+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A= 215 Q 91.2(0123)81.6 241 S 4.8(01234567890123456789012345678901)81.6 254=0A= S(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A= 267 Q 9.6(|H)76.8 280 S(ET \(>=3D128\))-9.6 E 33.6(|H)9.6 G=0A= (eader Extension Content \(HEC\))-33.6 E(|)48 E=0A= (+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A= 293 Q/F2 10/Times-Roman@0 SF(Figure 5 - F)72 332 Q=0A= (ormat of additional headers)-.15 E F0(The e)72 361.6 Q=0A= (xplanation of each sub-\214eld is the follo)-.165 E(wing.)-.275 E=0A= (Header Extension T)83 391.2 Q(ype \(HET\): 8 bits)-.88 E(The type of t\=0A= he Header Extension. This document de\214nes a number of possible types\=0A= .)105 407.8 Q(Additional types may be de\214ned in future v)105 420.8 Q=0A= (ersion of this speci\214cation. HET v)-.165 E(alues from 0)-.275 E=0A= (to 127 are used for v)105 433.8 Q=0A= (ariable-length Header Extensions. HET v)-.275 E=0A= (alues from 128 to 255 are)-.275 E(used for \214x)105 446.8 Q=0A= (ed-length 32-bit Header Extensions.)-.165 E=0A= (Header Extension Length \(HEL\): 8 bits)83 476.4 Q=0A= (The length of the whole Header Extension \214eld, e)105 493 Q=0A= (xpressed in multiples of 32-bit w)-.165 E(ords.)-.11 E=0A= (This \214eld must be present for v)105 506 Q(ariable-length e)-.275 E=0A= (xtensions \(HET between 0 and 127\) and)-.165 E=0A= (must not be present for \214x)105 519 Q(ed-length e)-.165 E=0A= (xtensions \(HET between 128 and 255\).)-.165 E=0A= (Header Extension Content \(HEC\): v)83 548.6 Q(ariable length)-.275 E(\=0A= The content of the Header Extension. The format of this sub-\214eld dep\=0A= ends on the Header)105 565.2 Q(Extension type.)105 578.2 Q -.165(Fo)5.5=0A= G 2.75<728c>.165 G -.165(xe)-2.75 G=0A= (d-length Header Extensions, the HEC is 24 bits.).165 E -.165(Fo)5.5 G=0A= 2.75(rv).165 G(ariable-)-3.025 E=0A= (length Header Extensions, the HEC \214eld has v)105 591.2 Q=0A= (ariable size, as speci\214ed by the HEL \214eld.)-.275 E(Note that the\=0A= length of each Header Extension \214eld must be a multiple of 32 bits.)=0A= 105 604.2 Q(Also)5.5 E(note that the total size of the LCT header)105=0A= 617.2 Q 2.75(,i)-.44 G(ncluding all Header Extensions and all optional)=0A= -2.75 E(header \214elds, cannot e)105 630.2 Q(xceed 255 32-bit w)-.165 E=0A= (ords.)-.11 E(Header Extensions are further di)72 659.8 Q=0A= (vided between general LCT e)-.275 E=0A= (xtensions and Protocol Instantiation)-.165 E(speci\214c e)72 672.8 Q=0A= (xtensions \(PI-speci\214c\).)-.165 E(General LCT e)5.5 E(xtensions ha)=0A= -.165 E .33 -.165(ve H)-.22 H(ET in the ranges 0:63 and).165 E=0A= (128:191 inclusi)72 685.8 Q -.165(ve)-.275 G 5.5(.P).165 G=0A= (I-speci\214c e)-5.5 E(xtensions ha)-.165 E .33 -.165(ve H)-.22 H=0A= (ET in the ranges 64:127 and 192:255 inclusi).165 E -.165(ve)-.275 G(.)=0A= .165 E(General LCT e)72 711.8 Q(xtensions are intended to allo)-.165 E=0A= 2.75(wt)-.275 G(he introduction of backw)-2.75 E(ard-compatible)-.11 E=0A= (enhancements to LCT without changing the LCT v)72 724.8 Q=0A= (ersion number)-.165 E 5.5(.N)-.605 G(on backw)-5.5 E(ard-compatible)=0A= -.11 E(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A= 103.606(wcroft Section)-.275 F 2.75(3.2. [P)2.75 F(age 14])-.165 E EP=0A= %%Page: 15 15=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E(header e)72 85 Q=0A= (xtensions CANNO)-.165 E 2.75(Tb)-.44 G 2.75(ei)-2.75 G=0A= (ntroduced without changing the LCT v)-2.75 E(ersion number)-.165 E(.)=0A= -.605 E(PI-speci\214c e)72 111 Q(xtensions are reserv)-.165 E=0A= (ed for PI-speci\214c use with semantic and def)-.165 E=0A= (ault parsing actions)-.11 E(de\214ned by the PI.)72 124 Q(The follo)72=0A= 150 Q(wing general LCT Header Extension types are de\214ned:)-.275 E=0A= 13.662(EXT_NOP=3D0 No-Operation)72 166.6 R -.165(ex)2.75 G(tension.).165 = E=0A= (The information present in this e)149 179.6 Q=0A= (xtension \214eld must be ignored by recei)-.165 E -.165(ve)-.275 G(rs.)=0A= .165 E(EXT_A)72 209.2 Q 5.72(UTH=3D2 P)-.605 F(ack)-.165 E=0A= (et authentication e)-.11 E(xtension)-.165 E=0A= (Information used to authenticate the sender of the pack)149 222.2 Q=0A= 2.75(et. If)-.11 F(present, the format)2.75 E(of this Header Extension \=0A= and its processing must be communicated out-of-band)149 235.2 Q=0A= (as part of the session description.)149 248.2 Q=0A= (It is recommended that senders pro)149 261.2 Q(vide some form of pack)=0A= -.165 E(et authentication.)-.11 E(If)5.5 E(EXT_A)149 274.2 Q=0A= (UTH is present, whate)-.605 E -.165(ve)-.275 G 2.75(rp).165 G(ack)-2.75=0A= E(et authentication checks that can be)-.11 E=0A= (performed immediately upon reception of the pack)149 287.2 Q=0A= (et must be performed before)-.11 E(accepting the pack)149 300.2 Q=0A= (et and performing an)-.11 E 2.75(yc)-.165 G=0A= (ongestion control-related action on it.)-2.75 E(Some pack)149 313.2 Q=0A= (et authentication schemes impose a delay of se)-.11 E -.165(ve)-.275 G=0A= (ral seconds between).165 E(when a pack)149 326.2 Q(et is recei)-.11 E=0A= -.165(ve)-.275 G 2.75(da).165 G(nd when the pack)-2.75 E=0A= (et is fully authenticated.)-.11 E(An)5.5 E(y)-.165 E(congestion contro\=0A= l related action that is appropriate must not be postponed by)149 339.2=0A= Q(an)149 352.2 Q 2.75(ys)-.165 G(uch full pack)-2.75 E=0A= (et authentication.)-.11 E(All senders and recei)72 381.8 Q -.165(ve)=0A= -.275 G=0A= (rs implementing LCT must support the EXT_NOP Header Extension and).165=0A= E(must recognize EXT_A)72 394.8 Q(UTH, b)-.605 E=0A= (ut may not be able to parse its content.)-.22 E/F1 11/Times-Bold@0 SF=0A= (4.)72 433.8 Q/F2 14/Times-Bold@0 SF(Pr)5.5 E(ocedur)-.252 E(es)-.252 E=0A= F1(4.1.)72 472.8 Q/F3 13/Times-Bold@0 SF(Sender Operation)5.5 E F0 2.75=0A= (As)72 489.4 S(ender using LCT must mak)-2.75 E 2.75(eas)-.11 G=0A= (ession description a)-2.75 E -.275(va)-.22 G(ilable to clients that w)=0A= .275 E(ant to join an LCT)-.11 E 2.75(session. This)72 502.4 R=0A= (information could include, b)2.75 E(ut is not limited to:)-.22 E 11(oT)=0A= 77.5 519 S(he number of LCT channels;)-11 E 11(oT)77.5 535.6 S=0A= (he addresses, port numbers and data rates used for each LCT channel;)=0A= -11 E 11(oT)77.5 552.2 S(he formats of an)-11 E 2.75(yo)-.165 G=0A= (ther headers.)-2.75 E -.165(Fo)5.5 G 2.75(re).165 G=0A= (xample, an FEC header as described in [6] could be)-2.915 E=0A= (such an other header)94 565.2 Q 5.5(.T)-.605 G(hen for e)-5.5 E=0A= (xample the information could include the mapping of)-.165 E=0A= (codepoints used in the session to FEC codec types and parameters;)94=0A= 578.2 Q 11(oT)77.5 594.8 S(he format and lengths of the pack)-11 E=0A= (et payload;)-.11 E 11(oT)77.5 611.4 S(he T)-11 E=0A= (ransport Session ID \(TSI\) to be used for the session;)-.385 E 11(oW)=0A= 77.5 628 S(hether or not Generic Router Assist \(GRA\) is being used;)=0A= -11 E 11(oT)77.5 644.6 S(he congestion control scheme being used;)-11 E=0A= 11(oT)77.5 661.2 S(he mapping of T)-11 E(OI v)-.198 E=0A= (alue\(s\) to objects for the session;)-.275 E 11(oA)77.5 677.8 S .33=0A= -.165(ny i)-11 H(nformation that is rele).165 E -.275(va)-.275 G=0A= (nt to each object being transported, such as when it will be).275 E=0A= -.22(av)94 690.8 S(ailable within the session, for ho)-.055 E 2.75(wl)=0A= -.275 G(ong, and the length of the object;)-2.75 E 11(oT)77.5 707.4 S=0A= (he pack)-11 E(et authentication scheme being used, and all rele)-.11 E=0A= -.275(va)-.275 G(nt information which is).275 E=0A= (necessary for client pack)94 720.4 Q(et authentication purposes;)-.11 E=0A= (Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A= 103.606(wcroft Section)-.275 F 2.75(4.1. [P)2.75 F(age 15])-.165 E EP=0A= %%Page: 16 16=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E=0A= (Some of the session description information must be obtained by recei)=0A= 72 85 Q -.165(ve)-.275 G(rs before the).165 E 2.75(yc)-.165 G(onnect to)=0A= -2.75 E(the session.)72 98 Q=0A= (This includes the number and addresses of the LCT channels, the TSI v)=0A= 5.5 E(alue for the)-.275 E(session, the formats of an)72 111 Q 2.75(yo)=0A= -.165 G(ther headers, the congestion control scheme being used and the)=0A= -2.75 E(pack)72 124 Q(et authentication scheme if it is used.)-.11 E=0A= (Some of the session description information may be)5.5 E=0A= (obtained by recei)72 137 Q -.165(ve)-.275 G(rs while the).165 E 2.75=0A= (ya)-.165 G(re connected to the session, e.g., information rele)-2.75 E=0A= -.275(va)-.275 G(nt to objects).275 E=0A= (being transported within the session such as their T)72 150 Q=0A= (OI, when the)-.198 E 2.75(ya)-.165 G(re a)-2.75 E -.275(va)-.22 G=0A= (ilable within the session,).275 E(for ho)72 163 Q 2.75(wl)-.275 G=0A= (ong, and their lengths.)-2.75 E(The session description could be in a \=0A= form such as SDP as de\214ned in RFC2327, XML metadata,)72 189 Q(HTTP/M\=0A= ime headers, etc. It might be carried in a session announcement protoco\=0A= l such as SAP as)72 202 Q(de\214ned in RFC2974, obtained using a propri\=0A= etary session control protocol, located on a W)72 215 Q(eb page)-.88 E=0A= (with scheduling information, or con)72 228 Q -.165(vey)-.44 G=0A= (ed via E-mail or other out of band methods.).165 E(Discussion of)5.5 E=0A= (session description format, and distrib)72 241 Q=0A= (ution of session descriptions is be)-.22 E(yond the scope of this)-.165=0A= E(document.)72 254 Q -.44(Wi)72 280 S=0A= (thin an LCT session, a sender using LCT transmits a sequence of pack)=0A= .44 E(ets each in a format)-.11 E(de\214ned in the session description.)=0A= 72 293 Q -.165(Pa)5.5 G(ck).165 E=0A= (ets are sent from a sender using one or more LCT)-.11 E=0A= (channels which together constitute a session.)72 306 Q -.385(Tr)5.5 G=0A= (ansmission rates may be dif).385 E(ferent in dif)-.275 E(ferent)-.275 E=0A= (channels and may v)72 319 Q(ary o)-.275 E -.165(ve)-.165 G 2.75(rt).165=0A= G 2.75(ime. The)-2.75 F(speci\214cation of the other b)2.75 E=0A= (uilding block headers and the)-.22 E(pack)72 332 Q=0A= (et payload used by a complete protocol instantiation using LCT is be)=0A= -.11 E(yond the scope of this)-.165 E 2.75(document. This)72 345 R=0A= (document does not specify the order in which pack)2.75 E=0A= (ets are transmitted, nor the)-.11 E(or)72 358 Q -.055(ga)-.198 G=0A= (nization of a session into multiple channels. Although these issues af)=0A= .055 E(fect the ef)-.275 E(\214cienc)-.275 E 2.75(yo)-.165 G 2.75(ft)=0A= -2.75 G(he)-2.75 E(protocol, the)72 371 Q 2.75(yd)-.165 G 2.75(on)-2.75=0A= G(ot af)-2.75 E(fect the correctness nor the inter)-.275 E=0A= (-operability of LCT between senders and)-.22 E(recei)72 384 Q -.165(ve)=0A= -.275 G(rs.).165 E=0A= (Multiple objects can be carried within the same LCT session.)72 410 Q=0A= (In this case, each object must be)5.5 E(identi\214ed by a unique T)72=0A= 423 Q 2.75(OI. Objects)-.198 F(may be transmitted sequentially)2.75 E=0A= 2.75(,o)-.715 G 2.75(rt)-2.75 G(he)-2.75 E 2.75(ym)-.165 G=0A= (ay be transmitted)-2.75 E(concurrently)72 436 Q 5.5(.I)-.715 G 2.75(ti)=0A= -5.5 G 2.75(sg)-2.75 G(ood practice to only send objects concurrently i\=0A= n the same session if the)-2.75 E(recei)72 449 Q -.165(ve)-.275 G=0A= (rs that participate in that portion of the session ha).165 E .33 -.165=0A= (ve i)-.22 H(nterest in recei).165 E(ving all the objects.)-.275 E=0A= (The reason for this is that it w)72 462 Q(astes bandwidth and netw)-.11=0A= E(orking resources to ha)-.11 E .33 -.165(ve r)-.22 H(ecei).165 E -.165=0A= (ve)-.275 G(rs recei).165 E -.165(ve)-.275 G(data for objects that the)=0A= 72 475 Q 2.75(yh)-.165 G -2.475 -.22(av e)-2.75 H(no interest in.)2.97 E=0A= -.88(Ty)72 501 S(pically).88 E 2.75(,t)-.715 G=0A= (he sender\(s\) continues to send pack)-2.75 E=0A= (ets in a session until the transmission is considered)-.11 E 2.75=0A= (complete. The)72 514 R=0A= (transmission may be considered complete when some time has e)2.75 E=0A= (xpired, a certain)-.165 E(number of pack)72 527 Q(ets ha)-.11 E .33=0A= -.165(ve b)-.22 H=0A= (een sent, or some out of band signal \(possibly from a higher le).165 E=0A= -.165(ve)-.275 G(l).165 E(protocol\) has indicated completion by a suf)=0A= 72 540 Q(\214cient number of recei)-.275 E -.165(ve)-.275 G(rs.).165 E=0A= -.165(Fo)72 566 S 2.75(rt).165 G(he reasons mentioned abo)-2.75 E -.165=0A= (ve)-.165 G 2.75(,t).165 G(his document does not pose an)-2.75 E 2.75=0A= (yr)-.165 G(estriction on pack)-2.75 E(et sizes.)-.11 E(Ho)72 579 Q(we)=0A= -.275 E -.165(ve)-.275 G .88 -.44(r, n).165 H(etw).44 E(ork ef)-.11 E=0A= (\214cienc)-.275 E 2.75(yc)-.165 G=0A= (onsiderations recommend that the sender uses as lar)-2.75 E=0A= (ge as possible)-.198 E(pack)72 592 Q(et payload size, b)-.11 E=0A= (ut in such a w)-.22 E(ay that pack)-.11 E(ets do not e)-.11 E=0A= (xceed the netw)-.165 E(ork')-.11 E 2.75(sm)-.605 G(aximum)-2.75 E=0A= (transmission unit size \(MTU\), or fragmentation coupled with pack)72=0A= 605 Q(et loss might introduce se)-.11 E -.165(ve)-.275 G(re).165 E(inef)=0A= 72 618 Q(\214cienc)-.275 E 2.75(yi)-.165 G 2.75(nt)-2.75 G=0A= (he transmission.)-2.75 E(It is recommended that all pack)72 644 Q=0A= (ets ha)-.11 E .33 -.165(ve t)-.22 H(he same or v).165 E=0A= (ery similar sizes, as this can ha)-.165 E .33 -.165(ve a s)-.22 H=0A= -2.365 -.275(ev e).165 H(re).275 E(impact on the ef)72 657 Q(fecti)-.275=0A= E -.165(ve)-.275 G(ness of congestion control schemes such as the ones \=0A= described in [11] and).165 E 2.75([1]. A)72 670 R(sender of pack)2.75 E=0A= (ets using LCT must implement the sender)-.11 E=0A= (-side part of one of the congestion)-.22 E(control schemes that is in \=0A= accordance with RFC2357 using the Congestion Control Information)72 683=0A= Q(\214eld pro)72 696 Q(vided in the LCT header)-.165 E 2.75(,a)-.44 G=0A= (nd the corresponding recei)-2.75 E -.165(ve)-.275 G 2.75(rc).165 G=0A= (ongestion control scheme must)-2.75 E=0A= (be communicated out of band and implemented by an)72 709 Q 2.75(yr)=0A= -.165 G(ecei)-2.75 E -.165(ve)-.275 G(rs participating in the session.)=0A= .165 E(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A= 103.606(wcroft Section)-.275 F 2.75(4.1. [P)2.75 F(age 16])-.165 E EP=0A= %%Page: 17 17=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(4.2.)72=0A= 85 Q/F2 13/Times-Bold@0 SF(Recei)5.5 E -.13(ve)-.13 G 3.25(rO).13 G=0A= (peration)-3.25 E F0(Recei)72 101.6 Q -.165(ve)-.275 G=0A= (rs can operate dif).165 E(ferently depending on the deli)-.275 E -.165=0A= (ve)-.275 G(ry service model.).165 E -.165(Fo)5.5 G 2.75(re).165 G=0A= (xample, for an)-2.915 E(on demand service model recei)72 114.6 Q -.165=0A= (ve)-.275 G=0A= (rs may join a session, obtain the necessary encoding symbols to).165 E=0A= (reproduce the object, and then lea)72 127.6 Q .33 -.165(ve t)-.22 H=0A= (he session.).165 E(As another e)5.5 E(xample, for a streaming service)=0A= -.165 E(model a recei)72 140.6 Q -.165(ve)-.275 G 2.75(rm).165 G=0A= (ay be continuously joined to a set of LCT channels to do)-2.75 E=0A= (wnload all objects in a)-.275 E(session.)72 153.6 Q 1.76 -.88(To b)72=0A= 179.6 T 2.75(ea).88 G(ble to participate in a session, a recei)-2.75 E=0A= -.165(ve)-.275 G 2.75(rm).165 G(ust \214rst obtain the rele)-2.75 E=0A= -.275(va)-.275 G(nt session description).275 E=0A= (information as listed in Section 4.1.)72 192.6 Q(If pack)72 209.2 Q=0A= (et authentication information is present in an LCT header)-.11 E 2.75=0A= (,i)-.44 G 2.75(ts)-2.75 G(hould be used as speci\214ed in)-2.75 E=0A= (Section 3.2.)72 222.2 Q 1.76 -.88(To b)5.5 H 2.75(ea).88 G=0A= (ble to be a recei)-2.75 E -.165(ve)-.275 G 2.75(ri).165 G 2.75(nas)=0A= -2.75 G(ession, the recei)-2.75 E -.165(ve)-.275 G 2.75(rm).165 G=0A= (ust be able to process the LCT)-2.75 E(header)72 235.2 Q 5.5(.T)-.605 G=0A= (he recei)-5.5 E -.165(ve)-.275 G 2.75(rm).165 G=0A= (ust be able to discard, forw)-2.75 E=0A= (ard, store or process the other headers and the)-.11 E(pack)72 248.2 Q=0A= (et payload.)-.11 E(If a recei)5.5 E -.165(ve)-.275 G 2.75(ri).165 G=0A= 2.75(sn)-2.75 G(ot able to process a LCT header)-2.75 E 2.75(,i)-.44 G=0A= 2.75(tm)-2.75 G(ust drop from the session.)-2.75 E 1.76 -.88(To b)72=0A= 274.2 T 2.75(ea).88 G(ble to participate in a session, a recei)-2.75 E=0A= -.165(ve)-.275 G 2.75(rm).165 G=0A= (ust implement the congestion control protocol)-2.75 E(speci\214ed in t\=0A= he session description using the Congestion Control Information \214eld\=0A= pro)72 287.2 Q(vided in the)-.165 E(LCT header)72 300.2 Q 2.75(.I)-.605=0A= G 2.75(far)-2.75 G(ecei)-2.75 E -.165(ve)-.275 G 2.75(ri).165 G 2.75(sn)=0A= -2.75 G=0A= (ot able to implement the congestion control protocol used in the)-2.75=0A= E(session, it must not join the session.)72 313.2 Q=0A= (When the session is transmitted on multiple LCT channels,)5.5 E(recei)=0A= 72 326.2 Q -.165(ve)-.275 G(rs must initially join channels according t\=0A= o the speci\214ed startup beha).165 E(vior of the congestion)-.22 E=0A= (control protocol itself. F)72 339.2 Q(or a layered transmission on mul\=0A= tiple channels, this typically means that a)-.165 E(recei)72 352.2 Q=0A= -.165(ve)-.275 G 2.75(rw).165 G(ill initially join only a minimal set o\=0A= f LCT channels, possibly a single one, that in)-2.75 E(aggre)72 365.2 Q=0A= -.055(ga)-.165 G(te are carrying pack).055 E(ets at a lo)-.11 E 2.75(wr)=0A= -.275 G 2.75(ate. This)-2.75 F(rule has the purpose of pre)2.75 E -.165=0A= (ve)-.275 G(nting recei).165 E -.165(ve)-.275 G(rs).165 E=0A= (from starting at high data rates.)72 378.2 Q(Multiple objects can be c\=0A= arried either sequentially or concurrently within the same LCT session.)=0A= 72 404.2 Q(In this case, each object is identi\214ed by a unique T)72=0A= 417.2 Q 2.75(OI. Note)-.198 F(that e)2.75 E -.165(ve)-.275 G 2.75(ni)=0A= .165 G 2.75(fas)-2.75 G(erv)-2.75 E(er stops sending)-.165 E(pack)72=0A= 430.2 Q(ets for an old object before starting to transmit pack)-.11 E=0A= (ets for a ne)-.11 E 2.75(wo)-.275 G(bject, both the netw)-2.75 E(ork)=0A= -.11 E=0A= (and the underlying protocol layers can cause some reordering of pack)72=0A= 443.2 Q(ets, especially when sent)-.11 E -.165(ove)72 456.2 S 2.75(rd)=0A= .165 G(if)-2.75 E(ferent LCT channels, and thus recei)-.275 E -.165(ve)=0A= -.275 G(rs should not assume that the reception of a pack).165 E(et)-.11=0A= E(for a ne)72 469.2 Q 2.75(wo)-.275 G=0A= (bject means that there are no more pack)-2.75 E=0A= (ets in transit for the pre)-.11 E(vious one, at least for)-.275 E=0A= (some amount of time.)72 482.2 Q 2.75(Ar)72 508.2 S(ecei)-2.75 E -.165=0A= (ve)-.275 G 2.75(rm).165 G(ay be concurrently joined to multiple LCT se\=0A= ssions from one or more senders. The)-2.75 E(recei)72 521.2 Q -.165(ve)=0A= -.275 G 2.75(rm).165 G=0A= (ust perform congestion control on each such LCT session.)-2.75 E=0A= (If the congestion control)5.5 E(protocol allo)72 534.2 Q(ws the recei)=0A= -.275 E -.165(ve)-.275 G 2.75(rs).165 G(ome \215e)-2.75 E=0A= (xibility in terms of its actions within a session then the)-.165 E=0A= (recei)72 547.2 Q -.165(ve)-.275 G 2.75(rm).165 G(ay mak)-2.75 E 2.75=0A= (ec)-.11 G(hoices to optimize the pack)-2.75 E(et \215o)-.11 E 2.75(wp)=0A= -.275 G(erformance across the multiple LCT)-2.75 E=0A= (sessions, as long as the recei)72 560.2 Q -.165(ve)-.275 G 2.75(rs).165=0A= G(till adheres to the congestion control rules for each LCT session)=0A= -2.75 E(indi)72 573.2 Q(vidually)-.275 E(.)-.715 E F1(5.)72 612.2 Q/F3=0A= 14/Times-Bold@0 SF(Security Considerations)5.5 E F0=0A= (LCT can be subject to denial-of-service attacks by attack)72 628.8 Q=0A= (ers which try to confuse the congestion)-.11 E=0A= (control mechanism, or send for)72 641.8 Q(ged pack)-.198 E=0A= (ets to the session which w)-.11 E(ould pre)-.11 E -.165(ve)-.275 G=0A= (nt successful).165 E(reconstruction of lar)72 654.8 Q=0A= (ge portions of the objects.)-.198 E(The same e)72 680.8 Q=0A= (xact problems are present in TCP)-.165 E 2.75(,w)-1.221 G=0A= (here an attack)-2.75 E(er can for)-.11 E(ge pack)-.198 E=0A= (ets and either slo)-.11 E(w)-.275 E(do)72 693.8 Q(wn or increase the t\=0A= hroughput of the session, or replace parts of the data stream with for)=0A= -.275 E(ged)-.198 E=0A= (data. If the stream is carrying compressed or otherwise coded data, e)=0A= 72 706.8 Q -.165(ve)-.275 G 2.75(nas).165 G(ingle for)-2.75 E(ged pack)=0A= -.198 E(et)-.11 E(could also cause incorrect reconstruction of the rest\=0A= of the data stream.)72 719.8 Q(Luby/Gemmell/V)72 769 Q=0A= (icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E 111.856(wcroft Section)-.275=0A= F 2.75(5. [P)2.75 F(age 17])-.165 E EP=0A= %%Page: 18 18=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E(It is therefore recommended t\=0A= hat protocol instantiations that use LCT implement some form of)72 85 Q=0A= (pack)72 98 Q(et authentication to protect themselv)-.11 E(es ag)-.165 E=0A= (ainst such attacks.)-.055 E/F1 11/Times-Bold@0 SF(6.)72 137 Q/F2 14=0A= /Times-Bold@0 SF(IAN)5.5 E 3.5(AC)-.28 G(onsiderations)-3.5 E F0=0A= (No information in this speci\214cation is subject to IAN)72 153.6 Q=0A= 2.75(Ar)-.385 G -.165(eg)-2.75 G(istration.).165 E(Building blocks used\=0A= in conjunction with LCT may introduce additional IAN)72 179.6 Q 2.75=0A= (Ac)-.385 G(onsiderations.)-2.75 E F1(7.)72 218.6 Q F2(Intellectual Pr)=0A= 5.5 E(operty Issues)-.252 E F0(No speci\214c reliability protocol or co\=0A= ngestion control protocol is speci\214ed or referenced as)72 248.2 Q=0A= (mandatory in this document.)72 261.2 Q(LCT may be used with congestion\=0A= control protocols and other protocols, such as reliability)72 287.2 Q=0A= (protocols, which are proprietary or ha)72 300.2 Q .33 -.165(ve p)-.22 H=0A= (ending or granted patents.).165 E F1(8.)72 339.2 Q F2(Ackno)5.5 E=0A= (wledgments)-.14 E F0(Thanks to V)72 355.8 Q(incent Roca, Bruce Lueck)=0A= -.66 E(enhof)-.11 E(f, Hayder Radha and Justin Chapwesk)-.275 E 2.75(ef)=0A= -.11 G(or detailed)-2.75 E(comments on this document.)72 368.8 Q F1(9.)=0A= 72 407.8 Q F2(Refer)5.5 E(ences)-.252 E F0([1] Byers, J.W)72 437.4 Q=0A= (., Frumin, M., Horn, G., Luby)-1.012 E 2.75(,M)-.715 G(., Mitzenmacher)=0A= -2.75 E 2.75(,M)-.44 G(., Roetter)-2.75 E 2.75(,A)-.44 G(., and Sha)=0A= -2.75 E -.165(ve)-.22 G .88 -.44(r, W).165 H(.,)-.572 E("FLID-DL: Conge\=0A= stion Control for Layered Multicast", Proceedings of Second Internation\=0A= al)72 450.4 Q -.88(Wo)72 463.4 S(rkshop on Netw).88 E(ork)-.11 E=0A= (ed Group Communications \(NGC 2000\), P)-.11 E(alo Alto, CA, No)-.165 E=0A= -.165(ve)-.165 G(mber 2000.).165 E([2] Byers, J.W)72 489.4 Q(., Luby)=0A= -1.012 E 2.75(,M)-.715 G(., Mitzenmacher)-2.75 E 2.75(,M)-.44 G=0A= (., and Re)-2.75 E(ge, A., "A Digital F)-.165 E(ountain Approach to)=0A= -.165 E(Reliable Distrib)72 502.4 Q(ution of Bulk Data", Proceedings A)=0A= -.22 E(CM SIGCOMM '98, V)-.44 E(ancouv)-1.221 E(er)-.165 E 2.75(,C)-.44=0A= G(anada,)-2.75 E(September 1998.)72 515.4 Q([3] Gemmell, J., Schooler)72=0A= 541.4 Q 2.75(,E)-.44 G(., and Gray)-2.75 E 2.75(,J)-.715 G=0A= (., "Fcast Multicast File Distrib)-2.75 E(ution", IEEE Netw)-.22 E(ork,)=0A= -.11 E -1.419(Vo)72 554.4 S(l. 14, No. 1, pp. 58-68, January 2000.)1.419=0A= E([4] Holbrook, H. W)72 580.4 Q=0A= (., "A Channel Model for Multicast," Ph.D. Dissertation, Stanford Uni)=0A= -1.012 E -.165(ve)-.275 G(rsity).165 E(,)-.715 E=0A= (Department of Computer Science, Stanford, California, August 2001.)72=0A= 593.4 Q([5] Luby)72 619.4 Q 2.75(,M)-.715 G(., Gemmell, V)-2.75 E=0A= (icisano, L., J., Rizzo, L., Handle)-.66 E 1.43 -.715(y, M)-.165 H=0A= (., Cro).715 E(wcroft, J., "The use of)-.275 E -.165(Fo)72 632.4 S(rw)=0A= .165 E(ard Error Correction in Reliable Multicast", Internet Draft draf\=0A= t-ietf-rmt-info-fec-01.txt,)-.11 E(October 2001, a w)72 645.4 Q=0A= (ork in progress.)-.11 E([6] Luby)72 671.4 Q 2.75(,M)-.715 G=0A= (., Gemmell, J., V)-2.75 E(icisano, L., Rizzo, L., Handle)-.66 E 1.43=0A= -.715(y, M)-.165 H(., Cro).715 E(wcroft, J., "RMT BB)-.275 E -.165(Fo)72=0A= 684.4 S(rw).165 E(ard Error Correction Codes", Internet Draft draft-iet\=0A= f-rmt-bb-fec-04.txt, October 2001.)-.11 E([7] Rizzo, L., "Ef)72 710.4 Q=0A= (fecti)-.275 E .33 -.165(ve E)-.275 H=0A= (rasure Codes for Reliable Computer Communication Protocols", A).165 E=0A= (CM)-.44 E(SIGCOMM Computer Communication Re)72 723.4 Q(vie)-.275 E 1.43=0A= -.715(w, V)-.275 H(ol.27, No.2, pp.24-36, Apr 1997.)-.704 E=0A= (Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A= 111.856(wcroft Section)-.275 F 2.75(9. [P)2.75 F(age 18])-.165 E EP=0A= %%Page: 19 19=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E=0A= ([8] Perrig, A., Canetti, R., Song, D., T)72 85 Q(yg)-.88 E(ar)-.055 E=0A= 2.75(,J)-.44 G(.D., "Ef)-2.75 E=0A= (\214cient and Secure Source Authentication for)-.275 E=0A= (Multicast", Netw)72 98 Q(ork and Distrib)-.11 E=0A= (uted System Security Symposium, NDSS 2001, pp. 35-46,)-.22 E=0A= (February 2001.)72 111 Q([9] Rizzo, L, and V)72 137 Q=0A= (icisano, L., "Reliable Multicast Data Distrib)-.66 E=0A= (ution protocol based on softw)-.22 E(are)-.11 E=0A= (FEC techniques", Proceedings of the F)72 150 Q(ourth IEEES W)-.165 E=0A= (orkshop on the Architecture and)-.88 E(Implementation of High Performa\=0A= nce Communication Systems, HPCS'97, Chalkidiki Greece,)72 163 Q=0A= (June 1997.)72 176 Q([10] Rizzo, L, "PGMCC: A TCP-friendly single-rate \=0A= multicast congestion control scheme",)72 202 Q=0A= (Proceedings of SIGCOMM 2000, Stockholm Sweden, August 2000.)72 215 Q=0A= ([11] V)72 241 Q(icisano, L., Rizzo, L., Cro)-.66 E=0A= (wcroft, J., "TCP-lik)-.275 E 2.75(eC)-.11 G=0A= (ongestion Control for Layered Multicast)-2.75 E(Data T)72 254 Q=0A= (ransfer", IEEE Infocom '98, San Francisco, CA, Mar)-.385 E(.28-Apr)=0A= -.605 E(.1 1998.)-.605 E/F1 11/Times-Bold@0 SF(10.)72 306 Q/F2 14=0A= /Times-Bold@0 SF -.7(Au)5.5 G(thors' Addr).7 E(esses)-.252 E F0=0A= (Michael Luby)80.25 322.6 Q(luby@digitalfountain.com)80.25 335.6 Q=0A= (Digital F)80.25 348.6 Q(ountain)-.165 E(39141 Ci)80.25 361.6 Q=0A= (vic Center Dri)-.275 E -.165(ve)-.275 G(Suite 300)80.25 374.6 Q=0A= (Fremont, CA, USA, 94538)80.25 387.6 Q(Jim Gemmell)80.25 413.6 Q=0A= (jgemmell@microsoft.com)80.25 426.6 Q(Microsoft Research)80.25 439.6 Q=0A= (301 Ho)80.25 452.6 Q -.11(wa)-.275 G(rd St., #830).11 E=0A= (San Francisco, CA, USA, 94105)80.25 465.6 Q(Lorenzo V)80.25 491.6 Q=0A= (icisano)-.66 E(lorenzo@cisco.com)80.25 504.6 Q(cisco Systems, Inc.)=0A= 80.25 517.6 Q(170 W)80.25 530.6 Q(est T)-.88 E(asman Dr)-.88 E(.,)-.605=0A= E(San Jose, CA, USA, 95134)80.25 543.6 Q(Luigi Rizzo)80.25 569.6 Q=0A= (luigi@iet.unipi.it)80.25 582.6 Q -.44(AC)80.25 595.6 S(IRI/ICSI,).44 E=0A= (1947 Center St, Berk)80.25 608.6 Q(ele)-.11 E 1.43 -.715(y, C)-.165 H=0A= (A, USA, 94704).715 E(and)80.25 621.6 Q(Dip. Ing. dell'Informazione,)=0A= 80.25 634.6 Q(Uni)80.25 647.6 Q 1.43 -.715(v. d)-.275 H 2.75(iP).715 G=0A= (isa)-2.75 E(via Diotisalvi 2, 56126 Pisa, Italy)80.25 660.6 Q=0A= (Mark Handle)80.25 686.6 Q(y)-.165 E(mjh@aciri.or)80.25 699.6 Q(g)-.198=0A= E -.44(AC)80.25 712.6 S(IRI,).44 E(1947 Center St,)80.25 725.6 Q=0A= (Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A= 106.356(wcroft Section)-.275 F 2.75(10. [P)2.75 F(age 19])-.165 E EP=0A= %%Page: 20 20=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E(Berk)80.25 85 Q(ele)-.11 E=0A= 1.43 -.715(y, C)-.165 H(A, USA, 94704).715 E(Jon Cro)80.25 111 Q(wcroft)=0A= -.275 E(J.Cro)80.25 124 Q(wcroft@cs.ucl.ac.uk)-.275 E=0A= (Department of Computer Science)80.25 137 Q(Uni)80.25 150 Q -.165(ve)=0A= -.275 G(rsity Colle).165 E(ge London)-.165 E(Go)80.25 163 Q(wer Street,)=0A= -.275 E(London WC1E 6BT)80.25 176 Q 2.75(,U)-.814 G(K)-2.75 E=0A= (Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A= 106.356(wcroft Section)-.275 F 2.75(10. [P)2.75 F(age 20])-.165 E EP=0A= %%Page: 21 21=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(11.)72=0A= 85 Q/F2 14/Times-Bold@0 SF(Full Copyright Statement)5.5 E F0(Cop)72=0A= 101.6 Q(yright \(C\) The Internet Society \(2001\).)-.11 E=0A= (All Rights Reserv)5.5 E(ed.)-.165 E(This document and translations of \=0A= it may be copied and furnished to others, and deri)72 118.2 Q -.275(va)=0A= -.275 G(ti).275 E .33 -.165(ve w)-.275 H(orks).055 E=0A= (that comment on or otherwise e)72 131.2 Q=0A= (xplain it or assist in its implementation may be prepared, copied,)=0A= -.165 E(published and distrib)72 144.2 Q=0A= (uted, in whole or in part, without restriction of an)-.22 E 2.75(yk)=0A= -.165 G(ind, pro)-2.75 E(vided that the)-.165 E(abo)72 157.2 Q .33 -.165=0A= (ve c)-.165 H(op).165 E(yright notice and this paragraph are included o\=0A= n all such copies and deri)-.11 E -.275(va)-.275 G(ti).275 E .33 -.165=0A= (ve w)-.275 H(orks.).055 E(Ho)72 170.2 Q(we)-.275 E -.165(ve)-.275 G .88=0A= -.44(r, t).165 H(his document itself may not be modi\214ed in an).44 E=0A= 2.75(yw)-.165 G(ay)-2.86 E 2.75(,s)-.715 G(uch as by remo)-2.75 E=0A= (ving the)-.165 E(cop)72 183.2 Q(yright notice or references to the Int\=0A= ernet Society or other Internet or)-.11 E -.055(ga)-.198 G(nizations, e)=0A= .055 E(xcept as)-.165 E(needed for the purpose of de)72 196.2 Q -.165=0A= (ve)-.275 G(loping Internet standards in which case the procedures for)=0A= .165 E(cop)72 209.2 Q=0A= (yrights de\214ned in the Internet languages other than English.)-.11 E=0A= (The limited permissions granted abo)72 225.8 Q .33 -.165(ve a)-.165 H=0A= (re perpetual and will not be re).165 E -.22(vo)-.275 G -.11(ke).22 G=0A= 2.75(db).11 G 2.75(yt)-2.75 G(he Internet)-2.75 E=0A= (Society or its successors or assigns.)72 238.8 Q=0A= (This document and the information contained herein is pro)72 255.4 Q=0A= (vided on an "AS IS" basis and THE)-.165 E=0A= (INTERNET SOCIETY AND THE INTERNET ENGINEERING T)72 268.4 Q=0A= (ASK FORCE DISCLAIMS)-1.023 E(ALL W)72 281.4 Q=0A= (ARRANTIES, EXPRESS OR IMPLIED, INCLUDING B)-1.32 E(UT not LIMITED T)=0A= -.11 E 2.75(OA)-.198 G(NY)-2.75 E -1.32(WA)72 294.4 S(RRANTY THA)1.32 E=0A= 2.75(TT)-1.221 G(HE USE OF THE INFORMA)-2.75 E=0A= (TION HEREIN WILL not INFRINGE ANY)-1.221 E(RIGHTS OR ANY IMPLIED W)72=0A= 307.4 Q(ARRANTIES OF MERCHANT)-1.32 E(ABILITY OR FITNESS FOR A)-1.023 E=0A= -1.012(PA)72 320.4 S -.66(RT)1.012 G(ICULAR PURPOSE.").66 E=0A= (Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A= 106.356(wcroft Section)-.275 F 2.75(11. [P)2.75 F(age 21])-.165 E EP=0A= %%Page: 22 22=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E(Luby/Gemmell/V)72 769 Q=0A= (icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E 106.356(wcroft Section)-.275=0A= F 2.75(11. [P)2.75 F(age 22])-.165 E EP=0A= %%Trailer=0A= end=0A= %%EOF=0A= ------=_NextPart_000_0005_01C157E0.AE079D70-- >From owner-rmt@listserv.lbl.gov Thu Oct 18 14:25:37 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9ILMO704317; Thu, 18 Oct 2001 14:22: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 (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9ILMNp04313 for ; Thu, 18 Oct 2001 14:22:23 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9ILMMW25087 for ; Thu, 18 Oct 2001 14:22:22 -0700 (PDT) Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9ILMKb25055 for ; Thu, 18 Oct 2001 14:22:20 -0700 (PDT) Received: (qmail 23806 invoked from network); 18 Oct 2001 21:22:13 -0000 Received: from mail.intranet (10.1.1.37) by mx.digitalfountain.com with SMTP; 18 Oct 2001 21:22:13 -0000 Received: from bozz (dhcp-10-1-2-180.intranet [10.1.2.180]) by mail.intranet (8.9.3/8.9.3) with SMTP id OAA31456; Thu, 18 Oct 2001 14:21:47 -0700 X-Authentication-Warning: mail.intranet: Host dhcp-10-1-2-180.intranet [10.1.2.180] claimed to be bozz From: "Michael Luby" To: "Internet-Drafts@Ietf. Org" , "Rmt@Lbl. Gov" Cc: "Michael Luby" Subject: draft-ietf-rmt-pi-alc-03.txt Date: Thu, 18 Oct 2001 14:27:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000A_01C157E0.F961EDC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C157E0.F961EDC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please post this draft on the IETF Internet Drafts archive. This is an update of an existing WG draft (RMT). This also serves as a last call before moving this towards RFC status. Please send any comments or concerns to the RMT list by Monday, October 22. Thanks, Mike Luby ------=_NextPart_000_000A_01C157E0.F961EDC0 Content-Type: text/plain; name="draft-ietf-rmt-pi-alc-03.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-rmt-pi-alc-03.txt" Internet Engineering Task Force RMT WG=0A= INTERNET-DRAFT M.Luby/Digital Fountain=0A= draft-ietf-rmt-pi-alc-03.txt J.Gemmell/Microsoft=0A= L.Vicisano/Cisco=0A= L.Rizzo/ACIRI and Univ. Pisa=0A= J. Crowcroft/UCL=0A= 18 October 2001=0A= Expires: April 2002=0A= =0A= =0A= Asynchronous Layered Coding:=0A= A massively scalable reliable content delivery protocol instantiation=0A= =0A= =0A= =0A= Status of this Document=0A= =0A= This document is an Internet-Draft and is in full conformance with all=0A= provisions of Section 10 of RFC2026.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering Task=0A= Force (IETF), its areas, and its working groups. Note that other groups=0A= may also distribute working documents as Internet-Drafts.=0A= =0A= Internet-Drafts are valid for a maximum of six months and may be=0A= updated, replaced, or obsoleted by other documents at any time. It is=0A= inappropriate to use Internet-Drafts as reference material or to cite=0A= them other than as a "work in progress".=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt=0A= =0A= To view the list Internet-Draft Shadow Directories, see=0A= http://www.ietf.org/shadow.html.=0A= =0A= This document is a product of the IETF RMT WG. Comments should be=0A= addressed to the authors, or the WG's mailing list at rmt@lbl.gov.=0A= =0A= =0A= Abstract=0A= =0A= =0A= This document describes the Asynchronous Layered Coding=0A= protocol, a massively scalable reliable content delivery=0A= protocol, hereafter referred to as ALC. ALC can be used for=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft [Page 1]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= multi-rate reliable delivery of content to large sets of=0A= receivers. This specification of ALC uses version 0 of the=0A= LCT building block specified in [4] augmented with a multi-=0A= rate congestion control building block that is compliant with=0A= RFC2357 such as one of the congestion control building blocks=0A= described [6] and [1]. ALC achieves reliability based on FEC=0A= codecs as generally described in [2], and in particular uses=0A= the FEC building block described in [3].=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft [Page 2]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= Table of Contents=0A= =0A= =0A= 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4=0A= 1.1. Related Documents. . . . . . . . . . . . . . . . . . 5=0A= 1.2. Environmental Requirements and Considerations. . . . 6=0A= 2. General Architecture. . . . . . . . . . . . . . . . . . 7=0A= 2.1. Delivery service models. . . . . . . . . . . . . . . 7=0A= 2.2. Congestion Control . . . . . . . . . . . . . . . . . 8=0A= 3. Packet format used by the ALC protocol. . . . . . . . . 8=0A= 3.1. Specific packet format . . . . . . . . . . . . . . . 9=0A= 3.2. Packet header field definitions. . . . . . . . . . . 10=0A= 4. Procedures. . . . . . . . . . . . . . . . . . . . . . . 10=0A= 4.1. Sender Operation . . . . . . . . . . . . . . . . . . 10=0A= 4.2. Receiver Operation . . . . . . . . . . . . . . . . . 11=0A= 5. Security Considerations . . . . . . . . . . . . . . . . 11=0A= 6. IANA Considerations . . . . . . . . . . . . . . . . . . 11=0A= 7. Intellectual Property Issues. . . . . . . . . . . . . . 12=0A= 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 12=0A= 9. References. . . . . . . . . . . . . . . . . . . . . . . 12=0A= 10. Authors' Addresses . . . . . . . . . . . . . . . . . . 13=0A= 11. Full Copyright Statement . . . . . . . . . . . . . . . 14=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft [Page 3]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= 1. Introduction=0A= =0A= This document describes a massively scalable reliable content delivery=0A= protocol, Asynchronous Layered Coding (ALC), for multi-rate reliable=0A= content delivery. ALC is a protocol instantiation as defined in=0A= RFC3048. This specification of ALC uses version 0 of the LCT building=0A= block specified in [4]. Like the LCT building block, the ALC protocol is=0A= primarily designed to be used with the IP multicast network service, but=0A= may also be used with other basic underlying network services such as=0A= unicast IP.=0A= =0A= All ALC packets in a session use the default LCT header to convey, among=0A= others, session and layering information. ALC uses FEC codes to provide=0A= reliability as generally described in [2], and in particular ALC uses=0A= the FEC building block described in [3]. Thus, all packets in a session=0A= contain an FEC payload ID in a format that is compliant with the FEC=0A= building block. Overall, a packet includes the default LCT header,=0A= followed by the FEC Payload ID, followed by the packet payload.=0A= =0A= Although ALC is a transport protocol, no IP protocol identifier is=0A= reserved for it and this specification defines ALC as UDP payload, in=0A= accordance with the RMT-WG guidelines. The ALC header hence follows an=0A= UDP header in an IP packet. Future versions of this specification, or=0A= companion documents may extend ALC to use the IP network layer service=0A= directly. Note that this specification does not make any assumption on=0A= the presence of UDP.=0A= =0A= A crucial point is that ALC strongly relies on FEC codecs in the sense=0A= that there is no request for retransmission of individual packets from=0A= receivers that miss packets in order to assure reliable reception of an=0A= object, and the packets and their rate of transmission out of the sender=0A= can be independent of the number and the individual reception=0A= experiences of the receivers. In some delivery service models it is=0A= appropriate that receivers send out of band messages to the sender to=0A= provide guaranteed delivery of content. For example, in a push reliable=0A= delivery model receivers may send messages to a sender to continue the=0A= session if receivers have not yet received enough packets to recover the=0A= content or to terminate the session when receivers have received enough=0A= packets to recover the content. To be able to track usage of the=0A= system, receivers may also send messages out of band to the sender that=0A= contain statistics on their reception experience. ALC, however, does not=0A= require nor specify such messages, with the aim of avoiding unnecessary=0A= limitation to the scalability of the basic ALC protocol.=0A= =0A= The LCT building block provides support for congestion control, and the=0A= ALC protocol uses this support. In particular, to take full advantage=0A= of the scalability features of ALC, the congestion control building=0A= block used by ALC must be a multi-rate congestion control scheme that=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 1. [Page 4]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= requires no receiver feedback to the sender and must use the Congestion=0A= Control Information field within the LCT header to convey packet by=0A= packet congestion control information to receivers. Possible congestion=0A= control building blocks that could be used with ALC are described in [6]=0A= and [1]. A sender sends packets in the session to several LCT channels=0A= at potentially different rates. Then, individual receivers can adjust=0A= their reception rate within a session by adjusting which set of LCT=0A= channels they are joined to at each point in time depending on the=0A= available bandwidth between the receiver and the sender, but independent=0A= of other receivers.=0A= =0A= Receivers may join and leave a session asynchronously at their=0A= discretion.=0A= =0A= Note also that the congestion control building block used by ALC must=0A= conform with RFC2357.=0A= =0A= ALC has the following properties when multicast is used to deliver=0A= packets:=0A= =0A= =0A= o To each receiver, it appears as if though there is a dedicated session=0A= from the sender to the receiver, where the reception rate adjusts to=0A= congestion along the path from sender to receiver.=0A= =0A= o To the sender, there is no difference in load or outgoing rate if one=0A= receiver is joined to the session or a million (or any number of)=0A= receivers are joined to the session, independent of when the receivers=0A= join and leave.=0A= =0A= o On each link in the network, the packet traffic from the session and=0A= its reaction to competing traffic is the same whether there is one=0A= receiver or a million receivers beyond the link.=0A= =0A= Thus, ALC provides a massively scalable content delivery system that=0A= is network friendly.=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in RFC2119.=0A= =0A= =0A= 1.1. Related Documents=0A= =0A= This specification of ALC must use version 0 of the LCT building block=0A= as specified in [4]. A more in-depth description of the use of FEC=0A= codecs in reliable content delivery protocols is given in [2]. All=0A= packets in a session must contain an FEC Payload ID in a format that is=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 1.1. [Page 5]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= compliant with the FEC building block described in [3]. Implementors of=0A= ALC must also implement a multi-rate feedback-free congestion control=0A= building block that is in accordance to RFC2357, where the congestion=0A= control is over the entire session. Some possible schemes are specified=0A= in [6] and [1]. Congestion control must be integrated into ALC through=0A= the support provided in the LCT building block.=0A= =0A= It is recommended that ALC implementors use some packet authentication=0A= scheme to protect the protocol from attacks. An example of a possibly=0A= suitable scheme is described in [5]. Packet authentication in ALC, if=0A= used, is to be integrated through the support provided in the LCT=0A= building block.=0A= =0A= =0A= 1.2. Environmental Requirements and Considerations=0A= =0A= ALC is intended for mult-rate congestion controlled delivery of objects,=0A= i.e., reliable content delivery.=0A= =0A= This specification defines ALC as payload of the UDP transport protocol=0A= (RFC768).=0A= =0A= All of the environmental requirements and considerations that apply to=0A= the LCT building block and to the FEC building block also apply to ALC.=0A= =0A= In particular, LCT requires the ability by receivers to uniquely=0A= identify and demultiplex packets associated with an LCT session, and ALC=0A= inherits this requirement. To this purpose, a Transport Session=0A= Identifier (TSI) must be associated with each session. The TSI is scoped=0A= by the IP address of the sender, and the IP address of the sender=0A= together with the TSI must uniquely identify the session. It is=0A= recommended that the TSI field in the LCT header is used to convey the=0A= ALC TSI. If the TSI is not present in the LCT header, then 16-bit UDP=0A= source port is used as TSI.=0A= =0A= If Generic Router Assist (GRA) is being used then additional=0A= dependencies may be introduced by GRA on the TSI field. Generic Router=0A= Assist is a current topic of discussion within the RMT working group.=0A= If a TSI value appears more than once in a packet then all occurrences=0A= of the value must be equal.=0A= =0A= If, in future specification, there is no underlying TSI provided by the=0A= network, transport or any other layer, then the use of the TSI in the=0A= LCT header must be mandatory.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 1.2. [Page 6]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= 2. General Architecture=0A= =0A= ALC protocol uses the FEC codecs in the form described in [3] combined=0A= with the LCT building block as described in [4]. Thus, the terminology=0A= used in the description of the LCT building block and the FEC building=0A= block are inherited by the ALC protocol and this terminology is used=0A= below. In particular, the definition of a session for the ALC protocol=0A= is the same as it is for the LCT building block.=0A= =0A= There is a one-to-one mapping between ALC sessions and LCT sessions.=0A= =0A= An ALC packet consists of the default LCT header, followed by the FEC=0A= Payload ID, followed by the packet payload. The packet payload is as=0A= described in [3]. If Generic Router Assist (GRA) is being used, then=0A= additional constraints may be introduced on the LCT header.=0A= =0A= The ALC header immediately follows a UDP header.=0A= =0A= The out of band information used by the ALC protocol consists of all the=0A= out of band information required for both the LCT building block and for=0A= the FEC building block. The possible means for acquiring this out of=0A= band information is the same as for the LCT building block and the FEC=0A= building block, and in particular is outside the scope of the ALC=0A= protocol.=0A= =0A= =0A= 2.1. Delivery service models=0A= =0A= ALC can support several different delivery service models. Two examples=0A= are briefly described here.=0A= =0A= =0A= Push service model.=0A= =0A= One way a push service model can be used for reliable content delivery=0A= is to deliver a series of objects. For example, a receiver could join=0A= the session and dynamically adapt the number of LCT channels the=0A= receiver is joined to until enough packets have been received to=0A= reconstruct an object. After reconstructing the object the receiver may=0A= stay in the session and wait for the transmission of the next object.=0A= =0A= The push model is particularly attractive in satellite networks and=0A= wireless networks. In these cases, a session may consist of one fixed=0A= rate LCT channel.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 2.1. [Page 7]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= On-demand content delivery model.=0A= =0A= For an on-demand content delivery service model, senders typically=0A= transmit for some given time period selected to be long enough to allow=0A= all the intended receivers to join the session and recover a single=0A= object. For example a popular software update might be transmitted=0A= using ALC for several days, even though a receiver may be able to=0A= complete the download in one hour total of connection time, perhaps=0A= spread over several intervals of time.=0A= =0A= In this case the receivers join the session at any point in time when it=0A= is active and dynamically adapt the number of LCT channels they=0A= subscribe to according to the available bandwidth using a multi-rate=0A= congestion control building block. Receivers leave the session when they=0A= have received enough packets to recover the object.=0A= =0A= =0A= Other service models.=0A= =0A= =0A= There may be other delivery service models that can be supported by ALC.=0A= The description of the potential applications, the appropriate delivery=0A= service model, and the additional mechanisms to support such=0A= functionalities when combined with ALC is beyond the scope of this=0A= document.=0A= =0A= =0A= 2.2. Congestion Control=0A= =0A= A multi-rate congestion control building block that is feedback-free,=0A= that is suitable for reliable content delivery, and that conforms to=0A= RFC2357 is to be used by ALC. An example of such a congestion control=0A= building block is described in [6] and [1]. While the general behavior=0A= of the congestion control building block is to reduce transmission rate=0A= in the presence of congestion and gradually increase the rate in the=0A= absence of congestion, the actual dynamic behavior (e.g. response to=0A= single losses) can vary.=0A= =0A= The congestion control building block must use the Congestion Control=0A= Information field carried in the LCT header of each packet. Congestion=0A= control must be applied to all packets within a session independently of=0A= which information about which object is carried in each packet.=0A= =0A= =0A= 3. Packet format used by the ALC protocol=0A= =0A= The packet format used by the ALC protocol is the UDP header followed by=0A= the default LCT header followed by the FEC Payload ID followed by the=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 3. [Page 8]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= packet payload. The packet payload is as described in [3], i.e., it=0A= contains encoding information about the object. If Generic Router=0A= Assist (GRA) is being used, then additional information may be required=0A= in the packet headers, and an additional specification may be needed.=0A= =0A= The version number of ALC specified in this document is 0. This=0A= coincides with version 0 of the LCT building block [4] used in this=0A= specification. The LCT version number field should be interpreted as=0A= the ALC version number field.=0A= =0A= Some instances of sessions may require the generation of feedback from=0A= the receivers to the sender. However, the mechanism for doing this is=0A= outside the scope of ALC.=0A= =0A= =0A= 3.1. Specific packet format=0A= =0A= The packet format used for ALC protocol is depicted in Figure 1.=0A= =0A= =0A= 0 1 2 3=0A= 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | Default LCT header |=0A= | |=0A= = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=0A= | FEC Payload ID |=0A= | |=0A= = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=0A= | ALC payload |=0A= | |=0A= | |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= =0A= =0A= Figure 1 - Packet format for the ALC protocol=0A= =0A= The length of the Default LCT header is explicitly encoded in the=0A= header itself (see=0A= [4]) , while the length of the FEC Payload ID is implicitly defined by = the=0A= FEC Encoding ID (see=0A= [3]) , that is communicated out of band and, possibly, through the = Codepoint=0A= field in the LCT header. The rest of the datagram is made of ALC=0A= payload.=0A= =0A= In some special cases an ALC source may need to produce ALC packets=0A= that do not contain any payload. This may be required, for example, to=0A= signal the end of a session or to convey congestion control=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 3.1. [Page 9]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= information. These data-less packets do not contain the FEC Payload ID=0A= either, but only the LCT header fields. The total datagram length,=0A= conveyed by outer protocol headers (e.g. the IP or UDP header),=0A= enables receivers to detect the absence of the ALC payload and FEC=0A= Payload ID.=0A= =0A= =0A= 3.2. Packet header field definitions=0A= =0A= The description of the fields and their functions within the default LCT=0A= header can be found in [4]. The information that needs to be=0A= communicated out of band for the LCT building block and the possible=0A= mechanisms for achieving this are described in [4].=0A= =0A= The description of the fields and their functions within the FEC Payload=0A= ID can be found in [3]. The information that needs to be communicated=0A= out of band for the FEC codecs and the possible mechanisms for achieving=0A= this are described in [3]. The mechanisms for communicating the out of=0A= band information needed for the LCT building block, including the=0A= mapping between the Codepoint field values in the default LCT header and=0A= the interpretations of the values, may be the same as those used for=0A= communicating the out of band information needed for the FEC building=0A= block, with the exception that portions of the information needed for=0A= FEC building blocks may be communicated through the use of the Codepoint=0A= field in the default LCT header.=0A= =0A= Multiple objects may be transmitted in the same session. The Transport=0A= Object Identifier (TOI) field in the LCT header must be used to identify=0A= the different objects, and the FEC Payload ID and the packet payload=0A= must correspond to the object identified by the TOI in the LCT header.=0A= =0A= If the FEC encoding scheme varies among different objects transmitted in=0A= the same session, the Codepoint field in the LCT header must be used to=0A= convey, in each packet, the association between the ALC payload and the=0A= tuple . This allows the receiver to=0A= parse the FEC Payload ID field and to select the appropriate decoder=0A= class without having to interpret the TOI field.=0A= =0A= =0A= 4. Procedures=0A= =0A= =0A= 4.1. Sender Operation=0A= =0A= The sender operation when using the ALC protocol includes all the points=0A= made about the sender operation when using the LCT building block as=0A= described in [4], and the FEC building block as described in [3]. The=0A= following description highlights some of the additional considerations=0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 4.1. [Page 10]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= to be taken into account with respect to the ALC protocol.=0A= =0A= A sender using the ALC protocol must make available all applicable=0A= information regarding the session. This information includes:=0A= =0A= o Any information needed by the LCT building block;=0A= =0A= o The congestion control building block being used within the LCT=0A= building block;=0A= =0A= o The mapping between values of the Codepoint field in the default LCT=0A= header and interpretations of these values;=0A= =0A= o Any information needed for the FEC building block, including the FEC=0A= Object Transmission Information;=0A= =0A= o If used, the packet authentication scheme being used within the LCT=0A= building block, and all relevant information which is necessary for=0A= packet authentication purposes.=0A= =0A= =0A= 4.2. Receiver Operation=0A= =0A= The receiver operation when using the ALC protocol includes all the=0A= points made about the receiver operation that pertain to reliable=0A= content delivery when using the LCT building block as described in [4],=0A= and that pertain to using the FEC building block as described in [3].=0A= The following description highlights some of the additional=0A= considerations to be taken into account with respect to the ALC=0A= protocol.=0A= =0A= When a receiver receives a packet, the receiver must process the default=0A= LCT header (excluding the Codepoint field) as described in [4] before=0A= processing any other fields of the packet.=0A= =0A= =0A= 5. Security Considerations=0A= =0A= The same security consideration that apply to the LCT building block and=0A= to the FEC building block also apply to the ALC protocol. In addition,=0A= any security considerations that apply to the congestion control=0A= building block used by the ALC protocol within the LCT building block=0A= also apply.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 5. [Page 11]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= 6. IANA Considerations=0A= =0A= No information in this specification is directly subject to IANA=0A= registration. However, building blocks components used by the ALC=0A= protocol may introduce additional IANA considerations. In particular,=0A= the FEC building block used by the ALC protocol does require IANA=0A= registration of the FEC codecs used.=0A= =0A= =0A= 7. Intellectual Property Issues=0A= =0A= =0A= No specific reliability building block or congestion control building=0A= block is specified or referenced as mandatory in this document.=0A= =0A= ALC may be used with congestion control building blocks and other=0A= building blocks which contain proprietary elements, or have pending or=0A= granted patents.=0A= =0A= =0A= 8. Acknowledgments=0A= =0A= =0A= Thanks to Vincent Roca and Justin Chapweske for their detailed comments=0A= on this draft.=0A= =0A= =0A= 9. References=0A= =0A= [1] Byers, J.W., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M.,=0A= Roetter, A., and Shaver, W., "FLID-DL: Congestion Control for Layered=0A= Multicast", Proceedings of Second International Workshop on Networked=0A= Group Communications (NGC 2000), Palo Alto, CA, November 2000.=0A= =0A= [2] Luby, M., Gemmell, Vicisano, L., J., Rizzo, L., Handley, M.,=0A= Crowcroft, J., "The use of Forward Error Correction in Reliable=0A= Multicast", Internet Draft draft-ietf-rmt-info-fec-01.txt, October 2001,=0A= a work in progress.=0A= =0A= [3] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M.,=0A= Crowcroft, J., "RMT BB Forward Error Correction Codes", Internet Draft=0A= draft-ietf-rmt-bb-fec-04.txt, October 2001.=0A= =0A= [4] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M.,=0A= Crowcroft, J., "Layered Coding Transport: A massively scalable content=0A= delivery transport", Internet Draft draft-ietf-rmt-bb-lct-02.txt,=0A= October 2001.=0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 9. [Page 12]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= [5] Perrig, A., Canetti, R., Song, D., Tygar, J.D., "Efficient and=0A= Secure Source Authentication for Multicast", Network and Distributed=0A= System Security Symposium, NDSS 2001, pp. 35-46, February 2001.=0A= =0A= [6] Vicisano, L., Rizzo, L., Crowcroft, J., "TCP-like Congestion Control=0A= for Layered Multicast Data Transfer", IEEE Infocom '98, San Francisco,=0A= CA, Mar.28-Apr.1 1998.=0A= =0A= =0A= =0A= 10. Authors' Addresses=0A= =0A= Michael Luby=0A= luby@digitalfountain.com=0A= Digital Fountain=0A= 39141 Civic Center Drive=0A= Suite 300=0A= Fremont, CA, USA, 94538=0A= =0A= Jim Gemmell=0A= jgemmell@microsoft.com=0A= Microsoft Research=0A= 301 Howard St., #830=0A= San Francisco, CA, USA, 94105=0A= =0A= Lorenzo Vicisano=0A= lorenzo@cisco.com=0A= cisco Systems, Inc.=0A= 170 West Tasman Dr.,=0A= San Jose, CA, USA, 95134=0A= =0A= Luigi Rizzo=0A= luigi@iet.unipi.it=0A= Dip. Ing. dell'Informazione,=0A= Univ. di Pisa=0A= via Diotisalvi 2, 56126 Pisa, Italy=0A= =0A= Jon Crowcroft=0A= J.Crowcroft@cs.ucl.ac.uk=0A= Department of Computer Science=0A= University College London=0A= Gower Street,=0A= London WC1E 6BT, UK=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 10. [Page 13]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= 11. Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2001). All Rights Reserved.=0A= =0A= This document and translations of it may be copied and furnished to=0A= others, and derivative works that comment on or otherwise explain it or=0A= assist in its implementation may be prepared, copied, published and=0A= distributed, in whole or in part, without restriction of any kind,=0A= provided that the above copyright notice and this paragraph are included=0A= on all such copies and derivative works. However, this document itself=0A= may not be modified in any way, such as by removing the copyright notice=0A= or references to the Internet Society or other Internet organizations,=0A= except as needed for the purpose of developing Internet standards in=0A= which case the procedures for copyrights defined in the Internet=0A= languages other than English.=0A= =0A= The limited permissions granted above are perpetual and will not be=0A= revoked by the Internet Society or its successors or assigns.=0A= =0A= This document and the information contained herein is provided on an "AS=0A= IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK=0A= FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT=0A= LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT=0A= INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR=0A= FITNESS FOR A PARTICULAR PURPOSE."=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 11. [Page 14]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 11. [Page 15]=0A= ------=_NextPart_000_000A_01C157E0.F961EDC0 Content-Type: application/postscript; name="draft-ietf-rmt-pi-alc-03.ps" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-rmt-pi-alc-03.ps" %!PS-Adobe-3.0=0A= %%Creator: groff version 1.15=0A= %%CreationDate: Thu Oct 18 10:45:53 2001=0A= %%DocumentNeededResources: font Courier-Bold=0A= %%+ font Times-Bold=0A= %%+ font Times-Roman=0A= %%+ font Courier=0A= %%DocumentSuppliedResources: procset grops 1.15 1=0A= %%Pages: 12=0A= %%PageOrder: Ascend=0A= %%Orientation: Portrait=0A= %%EndComments=0A= %%BeginProlog=0A= %%BeginResource: procset grops 1.15 1=0A= /setpacking where{=0A= pop=0A= currentpacking=0A= true setpacking=0A= }if=0A= /grops 120 dict dup begin=0A= /SC 32 def=0A= /A/show load def=0A= /B{0 SC 3 -1 roll widthshow}bind def=0A= /C{0 exch ashow}bind def=0A= /D{0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /E{0 rmoveto show}bind def=0A= /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def=0A= /G{0 rmoveto 0 exch ashow}bind def=0A= /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /I{0 exch rmoveto show}bind def=0A= /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def=0A= /K{0 exch rmoveto 0 exch ashow}bind def=0A= /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /M{rmoveto show}bind def=0A= /N{rmoveto 0 SC 3 -1 roll widthshow}bind def=0A= /O{rmoveto 0 exch ashow}bind def=0A= /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /Q{moveto show}bind def=0A= /R{moveto 0 SC 3 -1 roll widthshow}bind def=0A= /S{moveto 0 exch ashow}bind def=0A= /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /SF{=0A= findfont exch=0A= [exch dup 0 exch 0 exch neg 0 0]makefont=0A= dup setfont=0A= [exch/setfont cvx]cvx bind def=0A= }bind def=0A= /MF{=0A= findfont=0A= [5 2 roll=0A= 0 3 1 roll=0A= neg 0 0]makefont=0A= dup setfont=0A= [exch/setfont cvx]cvx bind def=0A= }bind def=0A= /level0 0 def=0A= /RES 0 def=0A= /PL 0 def=0A= /LS 0 def=0A= /MANUAL{=0A= statusdict begin/manualfeed true store end=0A= }bind def=0A= /PLG{=0A= gsave newpath clippath pathbbox grestore=0A= exch pop add exch pop=0A= }bind def=0A= /BP{=0A= /level0 save def=0A= 1 setlinecap=0A= 1 setlinejoin=0A= 72 RES div dup scale=0A= LS{=0A= 90 rotate=0A= }{=0A= 0 PL translate=0A= }ifelse=0A= 1 -1 scale=0A= }bind def=0A= /EP{=0A= level0 restore=0A= showpage=0A= }bind def=0A= /DA{=0A= newpath arcn stroke=0A= }bind def=0A= /SN{=0A= transform=0A= .25 sub exch .25 sub exch=0A= round .25 add exch round .25 add exch=0A= itransform=0A= }bind def=0A= /DL{=0A= SN=0A= moveto=0A= SN=0A= lineto stroke=0A= }bind def=0A= /DC{=0A= newpath 0 360 arc closepath=0A= }bind def=0A= /TM matrix def=0A= /DE{=0A= TM currentmatrix pop=0A= translate scale newpath 0 0 .5 0 360 arc closepath=0A= TM setmatrix=0A= }bind def=0A= /RC/rcurveto load def=0A= /RL/rlineto load def=0A= /ST/stroke load def=0A= /MT/moveto load def=0A= /CL/closepath load def=0A= /FL{=0A= currentgray exch setgray fill setgray=0A= }bind def=0A= /BL/fill load def=0A= /LW/setlinewidth load def=0A= /RE{=0A= findfont=0A= dup maxlength 1 index/FontName known not{1 add}if dict begin=0A= {=0A= 1 index/FID ne{def}{pop pop}ifelse=0A= }forall=0A= /Encoding exch def=0A= dup/FontName exch def=0A= currentdict end definefont pop=0A= }bind def=0A= /DEFS 0 def=0A= /EBEGIN{=0A= moveto=0A= DEFS begin=0A= }bind def=0A= /EEND/end load def=0A= /CNT 0 def=0A= /level1 0 def=0A= /PBEGIN{=0A= /level1 save def=0A= translate=0A= div 3 1 roll div exch scale=0A= neg exch neg exch translate=0A= 0 setgray=0A= 0 setlinecap=0A= 1 setlinewidth=0A= 0 setlinejoin=0A= 10 setmiterlimit=0A= []0 setdash=0A= /setstrokeadjust where{=0A= pop=0A= false setstrokeadjust=0A= }if=0A= /setoverprint where{=0A= pop=0A= false setoverprint=0A= }if=0A= newpath=0A= /CNT countdictstack def=0A= userdict begin=0A= /showpage{}def=0A= }bind def=0A= /PEND{=0A= clear=0A= countdictstack CNT sub{end}repeat=0A= level1 restore=0A= }bind def=0A= end def=0A= /setpacking where{=0A= pop=0A= setpacking=0A= }if=0A= %%EndResource=0A= %%IncludeResource: font Courier-Bold=0A= %%IncludeResource: font Times-Bold=0A= %%IncludeResource: font Times-Roman=0A= %%IncludeResource: font Courier=0A= grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72=0A= def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron=0A= /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef=0A= /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef=0A= /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef=0A= /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent=0A= /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen=0A= /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon=0A= /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O=0A= /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex=0A= /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y=0A= /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft=0A= /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl=0A= /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut=0A= /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash=0A= /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen=0A= /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft=0A= /logicalnot/minus/registered/macron/degree/plusminus/twosuperior=0A= /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior=0A= /ordmasculine/guilsinglright/onequarter/onehalf/threequarters=0A= /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE=0A= /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex=0A= /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis=0A= /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn=0A= /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla=0A= /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis=0A= /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash=0A= /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def=0A= /Courier@0 ENC0/Courier RE/Times-Roman@0 ENC0/Times-Roman RE=0A= /Times-Bold@0 ENC0/Times-Bold RE/Courier-Bold@0 ENC0/Courier-Bold RE=0A= %%EndProlog=0A= %%Page: 1 1=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 10/Courier-Bold@0 SF(Internet Engineering Task Force)72 85 Q(RMT WG)=0A= 209.999 E 203.999(INTERNET-DRAFT M.Luby/Digital)72 98 R(Fountain)6 E=0A= 149.999(draft-ietf-rmt-pi-alc-03.ps J.Gemmell/Microsoft)72 111 R=0A= (L.Vicisano/Cisco)407.999 124 Q(L.Rizzo/ACIRI and Univ. Pisa)335.999 137=0A= Q(J. Crowcroft/UCL)407.999 150 Q(18 October 2001)413.999 163 Q=0A= (Expires: April 2002)389.999 176 Q/F1 14/Times-Bold@0 SF(Asynchr)193.038=0A= 201 Q(onous Lay)-.252 E(er)-.14 E(ed Coding:)-.252 E 3.5(Am)87.289 214 S=0A= (assi)-3.5 E -.14(ve)-.14 G(ly scalable r).14 E(eliable content deli)=0A= -.252 E -.14(ve)-.14 G(ry pr).14 E(otocol instantiation)-.252 E/F2 11=0A= /Times-Bold@0 SF(Status of this Document)72 259 Q/F3 11/Times-Roman@0 SF=0A= (This document is an Internet-Draft and is in full conformance with all\=0A= pro)72 275.6 Q(visions of Section 10 of)-.165 E(RFC2026.)72 288.6 Q=0A= (Internet-Drafts are w)72 314.6 Q=0A= (orking documents of the Internet Engineering T)-.11 E(ask F)-.88 E=0A= (orce \(IETF\), its areas,)-.165 E(and its w)72 327.6 Q(orking groups.)=0A= -.11 E(Note that other groups may also distrib)5.5 E(ute w)-.22 E=0A= (orking documents as)-.11 E(Internet-Drafts.)72 340.6 Q=0A= (Internet-Drafts are v)72 366.6 Q=0A= (alid for a maximum of six months and may be updated, replaced, or)-.275=0A= E(obsoleted by other documents at an)72 379.6 Q 2.75(yt)-.165 G 2.75=0A= (ime. It)-2.75 F(is inappropriate to use Internet-Drafts as reference)=0A= 2.75 E(material or to cite them other than as a "w)72 392.6 Q=0A= (ork in progress".)-.11 E=0A= (The list of current Internet-Drafts can be accessed at http://www)72=0A= 418.6 Q(.ietf.or)-.715 E(g/ietf/1id-abstracts.txt)-.198 E 1.76 -.88=0A= (To v)72 444.6 T(ie).88 E 2.75(wt)-.275 G(he list Internet-Draft Shado)=0A= -2.75 E 2.75(wD)-.275 G(irectories, see http://www)-2.75 E(.ietf.or)=0A= -.715 E(g/shado)-.198 E -.715(w.)-.275 G(html.).715 E=0A= (This document is a product of the IETF RMT WG.)72 470.6 Q=0A= (Comments should be addressed to the)5.5 E(authors, or the WG')72 483.6=0A= Q 2.75(sm)-.605 G(ailing list at rmt@lbl.go)-2.75 E -.715(v.)-.165 G F2=0A= (Abstract)267.534 515.6 Q F3(This document describes the Asynchronous L\=0A= ayered Coding protocol, a massi)97 538.2 Q -.165(ve)-.275 G(ly).165 E=0A= (scalable reliable content deli)97 551.2 Q -.165(ve)-.275 G=0A= (ry protocol, hereafter referred to as ALC.).165 E(ALC can be)5.5 E=0A= (used for multi-rate reliable deli)97 564.2 Q -.165(ve)-.275 G=0A= (ry of content to lar).165 E(ge sets of recei)-.198 E -.165(ve)-.275 G=0A= 2.75(rs. This).165 F(speci\214cation of ALC uses v)97 577.2 Q=0A= (ersion 0 of the LCT b)-.165 E(uilding block speci\214ed in [4])-.22 E=0A= (augmented with a multi-rate congestion control b)97 590.2 Q=0A= (uilding block that is compliant with)-.22 E=0A= (RFC2357 such as one of the congestion control b)97 603.2 Q=0A= (uilding blocks described [6] and [1].)-.22 E(ALC achie)97 616.2 Q -.165=0A= (ve)-.275 G 2.75(sr).165 G=0A= (eliability based on FEC codecs as generally described in [2], and in)=0A= -2.75 E(particular uses the FEC b)97 629.2 Q=0A= (uilding block described in [3].)-.22 E(Luby/Gemmell/V)72 769 Q=0A= (icisano/Rizzo/Cro)-.66 E 207.017(wcroft [P)-.275 F(age 1])-.165 E EP=0A= %%Page: 2 2=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E/F1 13/Times-Bold@0 SF -1.196=0A= (Ta)239.126 85 S(ble of Contents)1.196 E/F2 10/Times-Roman@0 SF=0A= (1. Introduction)97 123 Q F0 11(......................)3.56 G F2(3)11.5=0A= E(1.1. Related Documents)107 135 Q F0 11(..................)11.9 G F2(4)=0A= 11.5 E(1.2. En)107 147 Q(vironmental Requirements and Considerations)-.4=0A= E F0 11(..........)3.97 G F2(4)11.5 E(2. General Architecture)97 159 Q=0A= F0 11(...................)10.12 G F2(5)11.5 E(2.1. Deli)107 171 Q -.15=0A= (ve)-.25 G(ry service models).15 E F0 11(.................)7.45 G F2(5)=0A= 11.5 E(2.2. Congestion Control)107 183 Q F0 11(..................)11.88=0A= G F2(6)11.5 E(3. P)97 195 Q(ack)-.15 E=0A= (et format used by the ALC protocol)-.1 E F0 11(..............)1.05 G F2=0A= (6)11.5 E(3.1. Speci\214c pack)107 207 Q(et format)-.1 E F0 11=0A= (..................).62 G F2(6)11.5 E(3.2. P)107 219 Q(ack)-.15 E=0A= (et header \214eld de\214nitions)-.1 E F0 11(...............)11.18 G F2=0A= (7)11.5 E(4. Procedures)97 231 Q F0 11(......................)8.57 G F2=0A= (8)11.5 E(4.1. Sender Operation)107 243 Q F0 11(...................)6.49=0A= G F2(8)11.5 E(4.2. Recei)107 255 Q -.15(ve)-.25 G 2.5(rO).15 G(peration)=0A= -2.5 E F0 11(..................)12.87 G F2(8)11.5 E=0A= (5. Security Considerations)97 267 Q F0 11(..................)12.17 G F2=0A= (8)11.5 E(6. IAN)97 279 Q 2.5(AC)-.35 G(onsiderations)-2.5 E F0 11=0A= (...................)7.11 G F2(9)11.5 E(7. Intellectual Property Issues)=0A= 97 291 Q F0 11(.................)12.88 G F2(9)11.5 E(8. Ackno)97 303 Q=0A= (wledgments)-.25 E F0 11(....................)5.76 G F2(9)11.5 E=0A= (9. References)97 315 Q F0 11(......................)8.58 G F2(9)11.5 E=0A= (10. Authors' Addresses)97 327 Q F0 11(...................)10.1 G F2(10)=0A= 6.5 E(11. Full Cop)97 339 Q(yright Statement)-.1 E F0 11=0A= (..................)1.42 G F2(11)6.5 E F0(Luby/Gemmell/V)72 769 Q=0A= (icisano/Rizzo/Cro)-.66 E 207.017(wcroft [P)-.275 F(age 2])-.165 E EP=0A= %%Page: 3 3=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(1.)72 85=0A= Q/F2 14/Times-Bold@0 SF(Intr)5.5 E(oduction)-.252 E F0=0A= (This document describes a massi)72 101.6 Q -.165(ve)-.275 G=0A= (ly scalable reliable content deli).165 E -.165(ve)-.275 G=0A= (ry protocol, Asynchronous).165 E=0A= (Layered Coding \(ALC\), for multi-rate reliable content deli)72 114.6 Q=0A= -.165(ve)-.275 G(ry).165 E 5.5(.A)-.715 G=0A= (LC is a protocol instantiation)-5.5 E=0A= (as de\214ned in RFC3048. This speci\214cation of ALC uses v)72 127.6 Q=0A= (ersion 0 of the LCT b)-.165 E(uilding block)-.22 E=0A= (speci\214ed in [4]. Lik)72 140.6 Q 2.75(et)-.11 G(he LCT b)-2.75 E=0A= (uilding block, the ALC protocol is primarily designed to be used)-.22 E=0A= (with the IP multicast netw)72 153.6 Q(ork service, b)-.11 E=0A= (ut may also be used with other basic underlying netw)-.22 E(ork)-.11 E=0A= (services such as unicast IP)72 166.6 Q(.)-1.221 E(All ALC pack)72 192.6=0A= Q(ets in a session use the def)-.11 E(ault LCT header to con)-.11 E=0A= -.165(vey)-.44 G 2.75(,a)-.55 G(mong others, session and)-2.75 E=0A= (layering information.)72 205.6 Q(ALC uses FEC codes to pro)5.5 E=0A= (vide reliability as generally described in [2],)-.165 E=0A= (and in particular ALC uses the FEC b)72 218.6 Q=0A= (uilding block described in [3]. Thus, all pack)-.22 E(ets in a session)=0A= -.11 E=0A= (contain an FEC payload ID in a format that is compliant with the FEC b)=0A= 72 231.6 Q(uilding block.)-.22 E(Ov)5.5 E(erall, a)-.165 E(pack)72 244.6=0A= Q(et includes the def)-.11 E(ault LCT header)-.11 E 2.75(,f)-.44 G(ollo)=0A= -2.75 E(wed by the FEC P)-.275 E(ayload ID, follo)-.165 E=0A= (wed by the pack)-.275 E(et)-.11 E(payload.)72 257.6 Q(Although ALC is \=0A= a transport protocol, no IP protocol identi\214er is reserv)72 283.6 Q=0A= (ed for it and this)-.165 E(speci\214cation de\214nes ALC as UDP payloa\=0A= d, in accordance with the RMT)72 296.6 Q(-WG guidelines. The)-1.012 E=0A= (ALC header hence follo)72 309.6 Q(ws an UDP header in an IP pack)-.275=0A= E(et. Future v)-.11 E(ersions of this speci\214cation,)-.165 E=0A= (or companion documents may e)72 322.6 Q(xtend ALC to use the IP netw)=0A= -.165 E(ork layer service directly)-.11 E 2.75(.N)-.715 G(ote that)-2.75=0A= E(this speci\214cation does not mak)72 335.6 Q 2.75(ea)-.11 G .33 -.165=0A= (ny a)-2.75 H(ssumption on the presence of UDP).165 E(.)-1.221 E 2.75=0A= (Ac)72 361.6 S(rucial point is that ALC strongly relies on FEC codecs i\=0A= n the sense that there is no request for)-2.75 E(retransmission of indi)=0A= 72 374.6 Q(vidual pack)-.275 E(ets from recei)-.11 E -.165(ve)-.275 G=0A= (rs that miss pack).165 E(ets in order to assure reliable)-.11 E=0A= (reception of an object, and the pack)72 387.6 Q=0A= (ets and their rate of transmission out of the sender can be)-.11 E=0A= (independent of the number and the indi)72 400.6 Q(vidual reception e)=0A= -.275 E(xperiences of the recei)-.165 E -.165(ve)-.275 G 2.75(rs. In)=0A= .165 F(some)2.75 E(deli)72 413.6 Q -.165(ve)-.275 G=0A= (ry service models it is appropriate that recei).165 E -.165(ve)-.275 G=0A= (rs send out of band messages to the sender to).165 E(pro)72 426.6 Q=0A= (vide guaranteed deli)-.165 E -.165(ve)-.275 G(ry of content.).165 E=0A= -.165(Fo)5.5 G 2.75(re).165 G(xample, in a push reliable deli)-2.915 E=0A= -.165(ve)-.275 G(ry model recei).165 E -.165(ve)-.275 G(rs).165 E=0A= (may send messages to a sender to continue the session if recei)72 439.6=0A= Q -.165(ve)-.275 G(rs ha).165 E .33 -.165(ve n)-.22 H(ot yet recei).165=0A= E -.165(ve)-.275 G 2.75(de).165 G(nough)-2.75 E(pack)72 452.6 Q=0A= (ets to reco)-.11 E -.165(ve)-.165 G 2.75(rt).165 G=0A= (he content or to terminate the session when recei)-2.75 E -.165(ve)=0A= -.275 G(rs ha).165 E .33 -.165(ve r)-.22 H(ecei).165 E -.165(ve)-.275 G=0A= 2.75(de).165 G(nough)-2.75 E(pack)72 465.6 Q(ets to reco)-.11 E -.165=0A= (ve)-.165 G 2.75(rt).165 G(he content.)-2.75 E 1.76 -.88(To b)5.5 H 2.75=0A= (ea).88 G(ble to track usage of the system, recei)-2.75 E -.165(ve)-.275=0A= G(rs may also send).165 E(messages out of band to the sender that conta\=0A= in statistics on their reception e)72 478.6 Q(xperience. ALC,)-.165 E=0A= (ho)72 491.6 Q(we)-.275 E -.165(ve)-.275 G .88 -.44(r, d).165 H=0A= (oes not require nor specify such messages, with the aim of a).44 E -.22=0A= (vo)-.22 G(iding unnecessary).22 E=0A= (limitation to the scalability of the basic ALC protocol.)72 504.6 Q=0A= (The LCT b)72 530.6 Q(uilding block pro)-.22 E=0A= (vides support for congestion control, and the ALC protocol uses this)=0A= -.165 E 2.75(support. In)72 543.6 R(particular)2.75 E 2.75(,t)-.44 G=0A= 2.75(ot)-2.75 G(ak)-2.75 E 2.75(ef)-.11 G(ull adv)-2.75 E=0A= (antage of the scalability features of ALC, the congestion)-.275 E=0A= (control b)72 556.6 Q(uilding block used by ALC must be a multi-rate co\=0A= ngestion control scheme that requires)-.22 E(no recei)72 569.6 Q -.165=0A= (ve)-.275 G 2.75(rf).165 G(eedback to the sender and must use the Conge\=0A= stion Control Information \214eld within)-2.75 E(the LCT header to con)=0A= 72 582.6 Q .33 -.165(vey p)-.44 H(ack).165 E(et by pack)-.11 E=0A= (et congestion control information to recei)-.11 E -.165(ve)-.275 G 2.75=0A= (rs. Possible).165 F(congestion control b)72 595.6 Q(uilding blocks tha\=0A= t could be used with ALC are described in [6] and [1]. A)-.22 E=0A= (sender sends pack)72 608.6 Q(ets in the session to se)-.11 E -.165(ve)=0A= -.275 G(ral LCT channels at potentially dif).165 E(ferent rates. Then,)=0A= -.275 E(indi)72 621.6 Q(vidual recei)-.275 E -.165(ve)-.275 G(rs can ad\=0A= just their reception rate within a session by adjusting which set of LC\=0A= T).165 E(channels the)72 634.6 Q 2.75(ya)-.165 G=0A= (re joined to at each point in time depending on the a)-2.75 E -.275(va)=0A= -.22 G(ilable bandwidth between).275 E(the recei)72 647.6 Q -.165(ve)=0A= -.275 G 2.75(ra).165 G(nd the sender)-2.75 E 2.75(,b)-.44 G=0A= (ut independent of other recei)-2.97 E -.165(ve)-.275 G(rs.).165 E=0A= (Recei)72 673.6 Q -.165(ve)-.275 G(rs may join and lea).165 E .33 -.165=0A= (ve a s)-.22 H(ession asynchronously at their discretion.).165 E=0A= (Note also that the congestion control b)72 699.6 Q=0A= (uilding block used by ALC must conform with RFC2357.)-.22 E=0A= (ALC has the follo)72 725.6 Q=0A= (wing properties when multicast is used to deli)-.275 E -.165(ve)-.275 G=0A= 2.75(rp).165 G(ack)-2.75 E(ets:)-.11 E(Luby/Gemmell/V)72 769 Q=0A= (icisano/Rizzo/Cro)-.66 E 157.517(wcroft Section)-.275 F 2.75(1. [P)2.75=0A= F(age 3])-.165 E EP=0A= %%Page: 4 4=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E 5.5(oT)72 85 S 2.75(oe)-6.38 G=0A= (ach recei)-2.75 E -.165(ve)-.275 G .88 -.44(r, i).165 H 2.75(ta).44 G(\=0A= ppears as if though there is a dedicated session from the sender to the)=0A= -2.75 E(recei)83 98 Q -.165(ve)-.275 G .88 -.44(r, w).165 H(here the re\=0A= ception rate adjusts to congestion along the path from sender to recei)=0A= .44 E -.165(ve)-.275 G -.605(r.).165 G 5.5(oT)72 114.6 S 2.75(ot)-6.38 G=0A= (he sender)-2.75 E 2.75(,t)-.44 G(here is no dif)-2.75 E=0A= (ference in load or outgoing rate if one recei)-.275 E -.165(ve)-.275 G=0A= 2.75(ri).165 G 2.75(sj)-2.75 G(oined to the)-2.75 E=0A= (session or a million \(or an)83 127.6 Q 2.75(yn)-.165 G=0A= (umber of\) recei)-2.75 E -.165(ve)-.275 G=0A= (rs are joined to the session, independent of when).165 E(the recei)83=0A= 140.6 Q -.165(ve)-.275 G(rs join and lea).165 E -.165(ve)-.22 G(.).165 E=0A= 5.5(oO)72 157.2 S 2.75(ne)-5.5 G(ach link in the netw)-2.75 E=0A= (ork, the pack)-.11 E(et traf)-.11 E=0A= (\214c from the session and its reaction to competing)-.275 E(traf)83=0A= 170.2 Q(\214c is the same whether there is one recei)-.275 E -.165(ve)=0A= -.275 G 2.75(ro).165 G 2.75(ram)-2.75 G(illion recei)-2.75 E -.165(ve)=0A= -.275 G(rs be).165 E(yond the link.)-.165 E(Thus, ALC pro)83 196.2 Q=0A= (vides a massi)-.165 E -.165(ve)-.275 G(ly scalable content deli).165 E=0A= -.165(ve)-.275 G(ry system that is netw).165 E(ork friendly)-.11 E(.)=0A= -.715 E(The k)83 222.2 Q .33 -.165(ey w)-.11 H(ords "MUST", "MUST NO)=0A= .055 E(T", "REQ)-.44 E(UIRED", "SHALL", "SHALL NO)-.11 E(T",)-.44 E=0A= ("SHOULD", "SHOULD NO)83 235.2 Q(T", "RECOMMENDED", "MA)-.44 E=0A= (Y", and "OPTION)-1.155 E(AL" in this)-.385 E=0A= (document are to be interpreted as described in RFC2119.)83 248.2 Q/F1=0A= 11/Times-Bold@0 SF(1.1.)72 287.2 Q/F2 13/Times-Bold@0 SF=0A= (Related Documents)5.5 E F0(This speci\214cation of ALC must use v)72=0A= 303.8 Q(ersion 0 of the LCT b)-.165 E=0A= (uilding block as speci\214ed in [4].)-.22 E(A)5.5 E(more in-depth desc\=0A= ription of the use of FEC codecs in reliable content deli)72 316.8 Q=0A= -.165(ve)-.275 G(ry protocols is gi).165 E -.165(ve)-.275 G(n).165 E=0A= (in [2]. All pack)72 329.8 Q(ets in a session must contain an FEC P)-.11=0A= E(ayload ID in a format that is compliant with)-.165 E(the FEC b)72=0A= 342.8 Q(uilding block described in [3].)-.22 E=0A= (Implementors of ALC must also implement a multi-rate)5.5 E=0A= (feedback-free congestion control b)72 355.8 Q=0A= (uilding block that is in accordance to RFC2357, where the)-.22 E=0A= (congestion control is o)72 368.8 Q -.165(ve)-.165 G 2.75(rt).165 G=0A= (he entire session.)-2.75 E=0A= (Some possible schemes are speci\214ed in [6] and [1].)5.5 E=0A= (Congestion control must be inte)72 381.8 Q=0A= (grated into ALC through the support pro)-.165 E(vided in the LCT)-.165=0A= E -.22(bu)72 394.8 S(ilding block.).22 E=0A= (It is recommended that ALC implementors use some pack)72 420.8 Q=0A= (et authentication scheme to protect the)-.11 E=0A= (protocol from attacks. An e)72 433.8 Q=0A= (xample of a possibly suitable scheme is described in [5]. P)-.165 E=0A= (ack)-.165 E(et)-.11 E(authentication in ALC, if used, is to be inte)72=0A= 446.8 Q(grated through the support pro)-.165 E(vided in the LCT)-.165 E=0A= -.22(bu)72 459.8 S(ilding block.).22 E F1(1.2.)72 498.8 Q F2(En)5.5 E=0A= (vir)-.52 E(onmental Requir)-.234 E(ements and Considerations)-.234 E F0=0A= (ALC is intended for mult-rate congestion controlled deli)72 515.4 Q=0A= -.165(ve)-.275 G(ry of objects, i.e., reliable content).165 E(deli)72=0A= 528.4 Q -.165(ve)-.275 G(ry).165 E(.)-.715 E(This speci\214cation de\=0A= \214nes ALC as payload of the UDP transport protocol \(RFC768\).)72=0A= 554.4 Q(All of the en)72 580.4 Q=0A= (vironmental requirements and considerations that apply to the LCT b)=0A= -.44 E(uilding block)-.22 E(and to the FEC b)72 593.4 Q=0A= (uilding block also apply to ALC.)-.22 E(In particular)72 619.4 Q 2.75=0A= (,L)-.44 G(CT requires the ability by recei)-2.75 E -.165(ve)-.275 G=0A= (rs to uniquely identify and demultiple).165 E 2.75(xp)-.165 G(ack)-2.75=0A= E(ets)-.11 E=0A= (associated with an LCT session, and ALC inherits this requirement.)72=0A= 632.4 Q 1.76 -.88(To t)5.5 H(his purpose, a T).88 E(ransport)-.385 E(Se\=0A= ssion Identi\214er \(TSI\) must be associated with each session. The TS\=0A= I is scoped by the IP address)72 645.4 Q(of the sender)72 658.4 Q 2.75=0A= (,a)-.44 G(nd the IP address of the sender together with the TSI must u\=0A= niquely identify the)-2.75 E 2.75(session. It)72 671.4 R=0A= (is recommended that the TSI \214eld in the LCT header is used to con)=0A= 2.75 E .33 -.165(vey t)-.44 H(he ALC TSI.).165 E=0A= (If the TSI is not present in the LCT header)72 684.4 Q 2.75(,t)-.44 G=0A= (hen 16-bit UDP source port is used as TSI.)-2.75 E(If Generic Router A\=0A= ssist \(GRA\) is being used then additional dependencies may be introdu\=0A= ced by)72 710.4 Q(GRA on the TSI \214eld.)72 723.4 Q=0A= (Generic Router Assist is a current topic of discussion within the RMT)=0A= 5.5 E(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66 E 149.267=0A= (wcroft Section)-.275 F 2.75(1.2. [P)2.75 F(age 4])-.165 E EP=0A= %%Page: 5 5=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E -.11(wo)72 85 S(rking group.)=0A= .11 E(If a TSI v)5.5 E(alue appears more than once in a pack)-.275 E=0A= (et then all occurrences of the)-.11 E -.275(va)72 98 S=0A= (lue must be equal.).275 E=0A= (If, in future speci\214cation, there is no underlying TSI pro)72 124 Q=0A= (vided by the netw)-.165 E(ork, transport or an)-.11 E(y)-.165 E=0A= (other layer)72 137 Q 2.75(,t)-.44 G=0A= (hen the use of the TSI in the LCT header must be mandatory)-2.75 E(.)=0A= -.715 E/F1 11/Times-Bold@0 SF(2.)72 176 Q/F2 14/Times-Bold@0 SF=0A= (General Ar)5.5 E(chitectur)-.252 E(e)-.252 E F0(ALC protocol uses the \=0A= FEC codecs in the form described in [3] combined with the LCT b)72 192.6=0A= Q(uilding)-.22 E(block as described in [4]. Thus, the terminology used \=0A= in the description of the LCT b)72 205.6 Q(uilding block)-.22 E=0A= (and the FEC b)72 218.6 Q(uilding block are inherited by the ALC protoc\=0A= ol and this terminology is used belo)-.22 E -.715(w.)-.275 G=0A= (In particular)72 231.6 Q 2.75(,t)-.44 G(he de\214nition of a session f\=0A= or the ALC protocol is the same as it is for the LCT)-2.75 E -.22(bu)72=0A= 244.6 S(ilding block.).22 E=0A= (There is a one-to-one mapping between ALC sessions and LCT sessions.)72=0A= 270.6 Q(An ALC pack)72 296.6 Q(et consists of the def)-.11 E=0A= (ault LCT header)-.11 E 2.75(,f)-.44 G(ollo)-2.75 E(wed by the FEC P)=0A= -.275 E(ayload ID, follo)-.165 E(wed by)-.275 E(the pack)72 309.6 Q=0A= (et payload.)-.11 E(The pack)5.5 E=0A= (et payload is as described in [3]. If Generic Router Assist \(GRA\) is)=0A= -.11 E(being used, then additional constraints may be introduced on the\=0A= LCT header)72 322.6 Q(.)-.605 E(The ALC header immediately follo)72=0A= 348.6 Q(ws a UDP header)-.275 E(.)-.605 E(The out of band information u\=0A= sed by the ALC protocol consists of all the out of band information)72=0A= 374.6 Q(required for both the LCT b)72 387.6 Q=0A= (uilding block and for the FEC b)-.22 E(uilding block.)-.22 E=0A= (The possible means for)5.5 E=0A= (acquiring this out of band information is the same as for the LCT b)72=0A= 400.6 Q(uilding block and the FEC)-.22 E -.22(bu)72 413.6 S(ilding bloc\=0A= k, and in particular is outside the scope of the ALC protocol.).22 E F1=0A= (2.1.)72 452.6 Q/F3 13/Times-Bold@0 SF(Deli)5.5 E -.13(ve)-.13 G(ry ser)=0A= .13 E(vice models)-.13 E F0(ALC can support se)72 469.2 Q -.165(ve)-.275=0A= G(ral dif).165 E(ferent deli)-.275 E -.165(ve)-.275 G=0A= (ry service models. T).165 E .22 -.11(wo e)-.88 H=0A= (xamples are brie\215y described)-.055 E(here.)72 482.2 Q F1(Push ser)72=0A= 521.2 Q(vice model.)-.11 E F0(One w)72 537.8 Q=0A= (ay a push service model can be used for reliable content deli)-.11 E=0A= -.165(ve)-.275 G(ry is to deli).165 E -.165(ve)-.275 G 2.75(ras).165 G=0A= (eries of)-2.75 E 2.75(objects. F)72 550.8 R(or e)-.165 E=0A= (xample, a recei)-.165 E -.165(ve)-.275 G 2.75(rc).165 G=0A= (ould join the session and dynamically adapt the number of LCT)-2.75 E=0A= (channels the recei)72 563.8 Q -.165(ve)-.275 G 2.75(ri).165 G 2.75(sj)=0A= -2.75 G(oined to until enough pack)-2.75 E(ets ha)-.11 E .33 -.165(ve b)=0A= -.22 H(een recei).165 E -.165(ve)-.275 G 2.75(dt).165 G 2.75(or)-2.75 G=0A= (econstruct an)-2.75 E=0A= (object. After reconstructing the object the recei)72 576.8 Q -.165(ve)=0A= -.275 G 2.75(rm).165 G(ay stay in the session and w)-2.75 E(ait for the)=0A= -.11 E(transmission of the ne)72 589.8 Q(xt object.)-.165 E=0A= (The push model is particularly attracti)72 615.8 Q .33 -.165(ve i)-.275=0A= H 2.75(ns).165 G(atellite netw)-2.75 E(orks and wireless netw)-.11 E=0A= 2.75(orks. In)-.11 F(these)2.75 E=0A= (cases, a session may consist of one \214x)72 628.8 Q=0A= (ed rate LCT channel.)-.165 E F1(On-demand content deli)72 667.8 Q -.11=0A= (ve)-.11 G(ry model.).11 E F0 -.165(Fo)72 684.4 S 2.75(ra).165 G 2.75=0A= (no)-2.75 G(n-demand content deli)-2.75 E -.165(ve)-.275 G=0A= (ry service model, senders typically transmit for some gi).165 E -.165=0A= (ve)-.275 G 2.75(nt).165 G(ime)-2.75 E=0A= (period selected to be long enough to allo)72 697.4 Q 2.75(wa)-.275 G=0A= (ll the intended recei)-2.75 E -.165(ve)-.275 G=0A= (rs to join the session and).165 E(reco)72 710.4 Q -.165(ve)-.165 G 2.75=0A= (ras).165 G(ingle object.)-2.75 E -.165(Fo)5.5 G 2.75(re).165 G=0A= (xample a popular softw)-2.915 E=0A= (are update might be transmitted using ALC)-.11 E(for se)72 723.4 Q=0A= -.165(ve)-.275 G(ral days, e).165 E -.165(ve)-.275 G 2.75(nt).165 G=0A= (hough a recei)-2.75 E -.165(ve)-.275 G 2.75(rm).165 G=0A= (ay be able to complete the do)-2.75 E(wnload in one hour total)-.275 E=0A= (Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66 E 149.267=0A= (wcroft Section)-.275 F 2.75(2.1. [P)2.75 F(age 5])-.165 E EP=0A= %%Page: 6 6=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E=0A= (of connection time, perhaps spread o)72 85 Q -.165(ve)-.165 G 2.75(rs)=0A= .165 G -2.365 -.275(ev e)-2.75 H(ral interv).275 E(als of time.)-.275 E=0A= (In this case the recei)72 111 Q -.165(ve)-.275 G=0A= (rs join the session at an).165 E 2.75(yp)-.165 G=0A= (oint in time when it is acti)-2.75 E .33 -.165(ve a)-.275 H=0A= (nd dynamically).165 E(adapt the number of LCT channels the)72 124 Q=0A= 2.75(ys)-.165 G(ubscribe to according to the a)-2.75 E -.275(va)-.22 G=0A= (ilable bandwidth using a).275 E(multi-rate congestion control b)72 137=0A= Q(uilding block. Recei)-.22 E -.165(ve)-.275 G(rs lea).165 E .33 -.165=0A= (ve t)-.22 H(he session when the).165 E 2.75(yh)-.165 G -2.475 -.22=0A= (av e)-2.75 H(recei)2.97 E -.165(ve)-.275 G(d).165 E(enough pack)72 150=0A= Q(ets to reco)-.11 E -.165(ve)-.165 G 2.75(rt).165 G(he object.)-2.75 E=0A= /F1 11/Times-Bold@0 SF(Other ser)72 189 Q(vice models.)-.11 E F0=0A= (There may be other deli)72 218.6 Q -.165(ve)-.275 G=0A= (ry service models that can be supported by ALC.).165 E=0A= (The description of)5.5 E=0A= (the potential applications, the appropriate deli)72 231.6 Q -.165(ve)=0A= -.275 G(ry service model, and the additional mechanisms).165 E=0A= (to support such functionalities when combined with ALC is be)72 244.6 Q=0A= (yond the scope of this document.)-.165 E F1(2.2.)72 283.6 Q/F2 13=0A= /Times-Bold@0 SF(Congestion Contr)5.5 E(ol)-.234 E F0 2.75(Am)72 300.2 S=0A= (ulti-rate congestion control b)-2.75 E=0A= (uilding block that is feedback-free, that is suitable for reliable)-.22=0A= E(content deli)72 313.2 Q -.165(ve)-.275 G(ry).165 E 2.75(,a)-.715 G=0A= (nd that conforms to RFC2357 is to be used by ALC.)-2.75 E(An e)5.5 E=0A= (xample of such a)-.165 E(congestion control b)72 326.2 Q=0A= (uilding block is described in [6] and [1]. While the general beha)-.22=0A= E(vior of the)-.22 E(congestion control b)72 339.2 Q(uilding block is t\=0A= o reduce transmission rate in the presence of congestion and)-.22 E(gra\=0A= dually increase the rate in the absence of congestion, the actual dynam\=0A= ic beha)72 352.2 Q(vior \(e.g.)-.22 E(response to single losses\) can v)=0A= 72 365.2 Q(ary)-.275 E(.)-.715 E(The congestion control b)72 391.2 Q(ui\=0A= lding block must use the Congestion Control Information \214eld carried)=0A= -.22 E(in the LCT header of each pack)72 404.2 Q 2.75(et. Congestion)=0A= -.11 F(control must be applied to all pack)2.75 E(ets within a)-.11 E(s\=0A= ession independently of which information about which object is carried\=0A= in each pack)72 417.2 Q(et.)-.11 E F1(3.)72 456.2 Q/F3 14/Times-Bold@0=0A= SF -.14(Pa)5.5 G(ck).14 E(et f)-.14 E(ormat used by the ALC pr)-.35 E=0A= (otocol)-.252 E F0(The pack)72 472.8 Q=0A= (et format used by the ALC protocol is the UDP header follo)-.11 E=0A= (wed by the def)-.275 E(ault LCT)-.11 E(header follo)72 485.8 Q=0A= (wed by the FEC P)-.275 E(ayload ID follo)-.165 E(wed by the pack)-.275=0A= E(et payload.)-.11 E(The pack)5.5 E(et payload is)-.11 E(as described i\=0A= n [3], i.e., it contains encoding information about the object.)72 498.8=0A= Q(If Generic Router)5.5 E(Assist \(GRA\) is being used, then additional\=0A= information may be required in the pack)72 511.8 Q(et headers,)-.11 E=0A= (and an additional speci\214cation may be needed.)72 524.8 Q(The v)72=0A= 550.8 Q(ersion number of ALC speci\214ed in this document is 0.)-.165 E=0A= (This coincides with v)5.5 E(ersion 0 of the)-.165 E(LCT b)72 563.8 Q=0A= (uilding block [4] used in this speci\214cation.)-.22 E(The LCT v)5.5 E=0A= (ersion number \214eld should be)-.165 E(interpreted as the ALC v)72=0A= 576.8 Q(ersion number \214eld.)-.165 E(Some instances of sessions may r\=0A= equire the generation of feedback from the recei)72 602.8 Q -.165(ve)=0A= -.275 G(rs to the).165 E(sender)72 615.8 Q 5.5(.H)-.605 G -.275(ow)-5.5=0A= G -2.365 -.275(ev e).275 H .88 -.44(r, t).275 H=0A= (he mechanism for doing this is outside the scope of ALC.).44 E F1(3.1.)=0A= 72 654.8 Q F2(Speci\214c pack)5.5 E(et f)-.13 E(ormat)-.325 E F0=0A= (The pack)72 671.4 Q=0A= (et format used for ALC protocol is depicted in Figure 1.)-.11 E=0A= (Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66 E 149.267=0A= (wcroft Section)-.275 F 2.75(3.1. [P)2.75 F(age 6])-.165 E EP=0A= %%Page: 7 7=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E/F1 8/Courier@0 SF 91.2(0123)=0A= 81.6 85 S 4.8(01234567890123456789012345678901)81.6 98 S=0A= (+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A= 111 Q 100.8(|D)76.8 124 S(efault LCT header)-100.8 E(|)115.2 E 302.4(||)=0A= 76.8 137 S=0A= (+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+)76.8=0A= 150 Q 110.4(|F)76.8 163 S(EC Payload ID)-110.4 E(|)124.8 E 302.4(||)76.8=0A= 176 = S(+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+)=0A= 76.8 189 Q 115.2(|A)76.8 202 S(LC payload)-115.2 E(|)134.4 E 302.4(||)=0A= 76.8 215 S 302.4(||)76.8 228 S=0A= (+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A= 241 Q/F2 10/Times-Roman@0 SF(Figure 1 - P)72 280 Q(ack)-.15 E=0A= (et format for the ALC protocol)-.1 E(The length of the Def)72 306 Q=0A= (ault LCT header is e)-.1 E(xplicitly encoded in the)-.15 E=0A= (header itself \(see)72 319 Q([4]\) , while the length of the FEC P)72=0A= 332 Q(ayload ID is implicitly de\214ned by the)-.15 E=0A= (FEC Encoding ID \(see)72 345 Q=0A= ([3]\) , that is communicated out of band and, possibly)72 358 Q 2.5(,t)=0A= -.65 G(hrough the Codepoint)-2.5 E(\214eld in the LCT header)72 371 Q 5=0A= (.T)-.55 G(he rest of the datagram is made of ALC)-5 E(payload.)72 384 Q=0A= (In some special cases an ALC source may need to produce ALC pack)72 410=0A= Q(ets)-.1 E(that do not contain an)72 423 Q 2.5(yp)-.15 G=0A= (ayload. This may be required, for e)-2.5 E(xample, to)-.15 E=0A= (signal the end of a session or to con)72 436 Q .3 -.15(vey c)-.4 H=0A= (ongestion control).15 E(information. These data-less pack)72 449 Q=0A= (ets do not contain the FEC P)-.1 E(ayload ID)-.15 E(either)72 462 Q 2.5=0A= (,b)-.4 G(ut only the LCT header \214elds. The total datagram length,)=0A= -2.7 E(con)72 475 Q -.15(vey)-.4 G=0A= (ed by outer protocol headers \(e.g. the IP or UDP header\),).15 E=0A= (enables recei)72 488 Q -.15(ve)-.25 G=0A= (rs to detect the absence of the ALC payload and FEC).15 E -.15(Pa)72=0A= 501 S(yload ID.).15 E/F3 11/Times-Bold@0 SF(3.2.)72 540 Q/F4 13=0A= /Times-Bold@0 SF -.13(Pa)5.5 G(ck).13 E(et header \214eld de\214nitions)=0A= -.13 E F0=0A= (The description of the \214elds and their functions within the def)72=0A= 556.6 Q(ault LCT header can be found in)-.11 E([4]. The information tha\=0A= t needs to be communicated out of band for the LCT b)72 569.6 Q=0A= (uilding block and)-.22 E(the possible mechanisms for achie)72 582.6 Q=0A= (ving this are described in [4].)-.275 E=0A= (The description of the \214elds and their functions within the FEC P)72=0A= 599.2 Q(ayload ID can be found in [3].)-.165 E(The information that nee\=0A= ds to be communicated out of band for the FEC codecs and the possible)72=0A= 612.2 Q(mechanisms for achie)72 625.2 Q(ving this are described in [3].\=0A= The mechanisms for communicating the out)-.275 E=0A= (of band information needed for the LCT b)72 638.2 Q=0A= (uilding block, including the mapping between the)-.22 E=0A= (Codepoint \214eld v)72 651.2 Q(alues in the def)-.275 E=0A= (ault LCT header and the interpretations of the v)-.11 E=0A= (alues, may be the)-.275 E(same as those used for communicating the out\=0A= of band information needed for the FEC b)72 664.2 Q(uilding)-.22 E=0A= (block, with the e)72 677.2 Q=0A= (xception that portions of the information needed for FEC b)-.165 E=0A= (uilding blocks may be)-.22 E=0A= (communicated through the use of the Codepoint \214eld in the def)72=0A= 690.2 Q(ault LCT header)-.11 E(.)-.605 E=0A= (Multiple objects may be transmitted in the same session.)72 716.2 Q=0A= (The T)5.5 E(ransport Object Identi\214er \(T)-.385 E(OI\))-.198 E=0A= (Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66 E 149.267=0A= (wcroft Section)-.275 F 2.75(3.2. [P)2.75 F(age 7])-.165 E EP=0A= %%Page: 8 8=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E=0A= (\214eld in the LCT header must be used to identify the dif)72 85 Q=0A= (ferent objects, and the FEC P)-.275 E(ayload ID)-.165 E(and the pack)72=0A= 98 Q(et payload must correspond to the object identi\214ed by the T)-.11=0A= E(OI in the LCT header)-.198 E(.)-.605 E(If the FEC encoding scheme v)72=0A= 124 Q(aries among dif)-.275 E=0A= (ferent objects transmitted in the same session, the)-.275 E=0A= (Codepoint \214eld in the LCT header must be used to con)72 137 Q -.165=0A= (vey)-.44 G 2.75(,i)-.55 G 2.75(ne)-2.75 G(ach pack)-2.75 E=0A= (et, the association)-.11 E(between the ALC payload and the tuple . This allo)72 150 Q(ws)-.275 E=0A= (the recei)72 163 Q -.165(ve)-.275 G 2.75(rt).165 G 2.75(op)-2.75 G=0A= (arse the FEC P)-2.75 E=0A= (ayload ID \214eld and to select the appropriate decoder class without)=0A= -.165 E(ha)72 176 Q(ving to interpret the T)-.22 E(OI \214eld.)-.198 E=0A= /F1 11/Times-Bold@0 SF(4.)72 215 Q/F2 14/Times-Bold@0 SF(Pr)5.5 E=0A= (ocedur)-.252 E(es)-.252 E F1(4.1.)72 254 Q/F3 13/Times-Bold@0 SF=0A= (Sender Operation)5.5 E F0(The sender operation when using the ALC prot\=0A= ocol includes all the points made about the sender)72 270.6 Q=0A= (operation when using the LCT b)72 283.6 Q=0A= (uilding block as described in [4], and the FEC b)-.22 E=0A= (uilding block as)-.22 E(described in [3]. The follo)72 296.6 Q(wing de\=0A= scription highlights some of the additional considerations to be)-.275 E=0A= (tak)72 309.6 Q(en into account with respect to the ALC protocol.)-.11 E=0A= 2.75(As)72 335.6 S(ender using the ALC protocol must mak)-2.75 E 2.75=0A= (ea)-.11 G -.275(va)-2.97 G(ilable all applicable information re).275 E=0A= -.055(ga)-.165 G(rding the).055 E 2.75(session. This)72 348.6 R=0A= (information includes:)2.75 E 11(oA)77.5 365.2 S .33 -.165(ny i)-11 H=0A= (nformation needed by the LCT b).165 E(uilding block;)-.22 E 11(oT)77.5=0A= 381.8 S(he congestion control b)-11 E=0A= (uilding block being used within the LCT b)-.22 E(uilding block;)-.22 E=0A= 11(oT)77.5 398.4 S(he mapping between v)-11 E=0A= (alues of the Codepoint \214eld in the def)-.275 E(ault LCT header and)=0A= -.11 E(interpretations of these v)94 411.4 Q(alues;)-.275 E 11(oA)77.5=0A= 428 S .33 -.165(ny i)-11 H(nformation needed for the FEC b).165 E=0A= (uilding block, including the FEC Object T)-.22 E(ransmission)-.385 E=0A= (Information;)94 441 Q 11(oI)77.5 457.6 S 2.75(fu)-11 G(sed, the pack)=0A= -2.75 E(et authentication scheme being used within the LCT b)-.11 E=0A= (uilding block, and all)-.22 E(rele)94 470.6 Q -.275(va)-.275 G=0A= (nt information which is necessary for pack).275 E=0A= (et authentication purposes.)-.11 E F1(4.2.)72 509.6 Q F3(Recei)5.5 E=0A= -.13(ve)-.13 G 3.25(rO).13 G(peration)-3.25 E F0(The recei)72 526.2 Q=0A= -.165(ve)-.275 G 2.75(ro).165 G(peration when using the ALC protocol in\=0A= cludes all the points made about the)-2.75 E(recei)72 539.2 Q -.165(ve)=0A= -.275 G 2.75(ro).165 G(peration that pertain to reliable content deli)=0A= -2.75 E -.165(ve)-.275 G(ry when using the LCT b).165 E=0A= (uilding block as)-.22 E=0A= (described in [4], and that pertain to using the FEC b)72 552.2 Q=0A= (uilding block as described in [3]. The)-.22 E(follo)72 565.2 Q(wing de\=0A= scription highlights some of the additional considerations to be tak)=0A= -.275 E(en into account)-.11 E(with respect to the ALC protocol.)72=0A= 578.2 Q(When a recei)72 604.2 Q -.165(ve)-.275 G 2.75(rr).165 G(ecei)=0A= -2.75 E -.165(ve)-.275 G 2.75(sap).165 G(ack)-2.75 E(et, the recei)-.11=0A= E -.165(ve)-.275 G 2.75(rm).165 G(ust process the def)-2.75 E=0A= (ault LCT header \(e)-.11 E(xcluding)-.165 E=0A= (the Codepoint \214eld\) as described in [4] before processing an)72=0A= 617.2 Q 2.75(yo)-.165 G(ther \214elds of the pack)-2.75 E(et.)-.11 E F1=0A= (5.)72 656.2 Q F2(Security Considerations)5.5 E F0=0A= (The same security consideration that apply to the LCT b)72 672.8 Q=0A= (uilding block and to the FEC b)-.22 E(uilding)-.22 E=0A= (block also apply to the ALC protocol.)72 685.8 Q(In addition, an)5.5 E=0A= 2.75(ys)-.165 G(ecurity considerations that apply to the)-2.75 E=0A= (congestion control b)72 698.8 Q=0A= (uilding block used by the ALC protocol within the LCT b)-.22 E=0A= (uilding block also)-.22 E(apply)72 711.8 Q(.)-.715 E(Luby/Gemmell/V)72=0A= 769 Q(icisano/Rizzo/Cro)-.66 E 157.517(wcroft Section)-.275 F 2.75=0A= (5. [P)2.75 F(age 8])-.165 E EP=0A= %%Page: 9 9=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(6.)72 85=0A= Q/F2 14/Times-Bold@0 SF(IAN)5.5 E 3.5(AC)-.28 G(onsiderations)-3.5 E F0=0A= (No information in this speci\214cation is directly subject to IAN)72=0A= 101.6 Q 2.75(Ar)-.385 G -.165(eg)-2.75 G 2.75(istration. Ho).165 F(we)=0A= -.275 E -.165(ve)-.275 G .88 -.44(r, b).165 H(uilding).22 E(blocks comp\=0A= onents used by the ALC protocol may introduce additional IAN)72 114.6 Q=0A= 2.75(Ac)-.385 G 2.75(onsiderations. In)-2.75 F(particular)72 127.6 Q=0A= 2.75(,t)-.44 G(he FEC b)-2.75 E=0A= (uilding block used by the ALC protocol does require IAN)-.22 E 2.75(Ar)=0A= -.385 G -.165(eg)-2.75 G(istration of).165 E(the FEC codecs used.)72=0A= 140.6 Q F1(7.)72 179.6 Q F2(Intellectual Pr)5.5 E(operty Issues)-.252 E=0A= F0(No speci\214c reliability b)72 209.2 Q=0A= (uilding block or congestion control b)-.22 E=0A= (uilding block is speci\214ed or)-.22 E=0A= (referenced as mandatory in this document.)72 222.2 Q=0A= (ALC may be used with congestion control b)72 248.2 Q=0A= (uilding blocks and other b)-.22 E(uilding blocks which)-.22 E=0A= (contain proprietary elements, or ha)72 261.2 Q .33 -.165(ve p)-.22 H=0A= (ending or granted patents.).165 E F1(8.)72 300.2 Q F2(Ackno)5.5 E=0A= (wledgments)-.14 E F0(Thanks to V)72 329.8 Q=0A= (incent Roca and Justin Chapwesk)-.66 E 2.75(ef)-.11 G=0A= (or their detailed comments on this draft.)-2.75 E F1(9.)72 368.8 Q F2=0A= (Refer)5.5 E(ences)-.252 E F0([1] Byers, J.W)72 385.4 Q=0A= (., Frumin, M., Horn, G., Luby)-1.012 E 2.75(,M)-.715 G(., Mitzenmacher)=0A= -2.75 E 2.75(,M)-.44 G(., Roetter)-2.75 E 2.75(,A)-.44 G(., and Sha)=0A= -2.75 E -.165(ve)-.22 G .88 -.44(r, W).165 H(.,)-.572 E("FLID-DL: Conge\=0A= stion Control for Layered Multicast", Proceedings of Second Internation\=0A= al)72 398.4 Q -.88(Wo)72 411.4 S(rkshop on Netw).88 E(ork)-.11 E=0A= (ed Group Communications \(NGC 2000\), P)-.11 E(alo Alto, CA, No)-.165 E=0A= -.165(ve)-.165 G(mber 2000.).165 E([2] Luby)72 437.4 Q 2.75(,M)-.715 G=0A= (., Gemmell, V)-2.75 E(icisano, L., J., Rizzo, L., Handle)-.66 E 1.43=0A= -.715(y, M)-.165 H(., Cro).715 E(wcroft, J., "The use of)-.275 E -.165=0A= (Fo)72 450.4 S(rw).165 E(ard Error Correction in Reliable Multicast", I\=0A= nternet Draft draft-ietf-rmt-info-fec-01.txt,)-.11 E(October 2001, a w)=0A= 72 463.4 Q(ork in progress.)-.11 E([3] Luby)72 489.4 Q 2.75(,M)-.715 G=0A= (., Gemmell, J., V)-2.75 E(icisano, L., Rizzo, L., Handle)-.66 E 1.43=0A= -.715(y, M)-.165 H(., Cro).715 E(wcroft, J., "RMT BB)-.275 E -.165(Fo)72=0A= 502.4 S(rw).165 E(ard Error Correction Codes", Internet Draft draft-iet\=0A= f-rmt-bb-fec-04.txt, October 2001.)-.11 E([4] Luby)72 528.4 Q 2.75(,M)=0A= -.715 G(., Gemmell, J., V)-2.75 E(icisano, L., Rizzo, L., Handle)-.66 E=0A= 1.43 -.715(y, M)-.165 H(., Cro).715 E(wcroft, J., "Layered Coding)-.275=0A= E -.385(Tr)72 541.4 S(ansport: A massi).385 E -.165(ve)-.275 G=0A= (ly scalable content deli).165 E -.165(ve)-.275 G=0A= (ry transport", Internet Draft draft-ietf-rmt-bb-).165 E=0A= (lct-02.txt, October 2001.)72 554.4 Q=0A= ([5] Perrig, A., Canetti, R., Song, D., T)72 580.4 Q(yg)-.88 E(ar)-.055=0A= E 2.75(,J)-.44 G(.D., "Ef)-2.75 E=0A= (\214cient and Secure Source Authentication for)-.275 E=0A= (Multicast", Netw)72 593.4 Q(ork and Distrib)-.11 E=0A= (uted System Security Symposium, NDSS 2001, pp. 35-46,)-.22 E=0A= (February 2001.)72 606.4 Q([6] V)72 632.4 Q(icisano, L., Rizzo, L., Cro)=0A= -.66 E(wcroft, J., "TCP-lik)-.275 E 2.75(eC)-.11 G=0A= (ongestion Control for Layered Multicast)-2.75 E(Data T)72 645.4 Q=0A= (ransfer", IEEE Infocom '98, San Francisco, CA, Mar)-.385 E(.28-Apr)=0A= -.605 E(.1 1998.)-.605 E(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66=0A= E 157.517(wcroft Section)-.275 F 2.75(9. [P)2.75 F(age 9])-.165 E EP=0A= %%Page: 10 10=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(10.)72=0A= 85 Q/F2 14/Times-Bold@0 SF -.7(Au)5.5 G(thors' Addr).7 E(esses)-.252 E=0A= F0(Michael Luby)80.25 101.6 Q(luby@digitalfountain.com)80.25 114.6 Q=0A= (Digital F)80.25 127.6 Q(ountain)-.165 E(39141 Ci)80.25 140.6 Q=0A= (vic Center Dri)-.275 E -.165(ve)-.275 G(Suite 300)80.25 153.6 Q=0A= (Fremont, CA, USA, 94538)80.25 166.6 Q(Jim Gemmell)80.25 192.6 Q=0A= (jgemmell@microsoft.com)80.25 205.6 Q(Microsoft Research)80.25 218.6 Q=0A= (301 Ho)80.25 231.6 Q -.11(wa)-.275 G(rd St., #830).11 E=0A= (San Francisco, CA, USA, 94105)80.25 244.6 Q(Lorenzo V)80.25 270.6 Q=0A= (icisano)-.66 E(lorenzo@cisco.com)80.25 283.6 Q(cisco Systems, Inc.)=0A= 80.25 296.6 Q(170 W)80.25 309.6 Q(est T)-.88 E(asman Dr)-.88 E(.,)-.605=0A= E(San Jose, CA, USA, 95134)80.25 322.6 Q(Luigi Rizzo)80.25 348.6 Q=0A= (luigi@iet.unipi.it)80.25 361.6 Q(Dip. Ing. dell'Informazione,)80.25=0A= 374.6 Q(Uni)80.25 387.6 Q 1.43 -.715(v. d)-.275 H 2.75(iP).715 G(isa)=0A= -2.75 E(via Diotisalvi 2, 56126 Pisa, Italy)80.25 400.6 Q(Jon Cro)80.25=0A= 426.6 Q(wcroft)-.275 E(J.Cro)80.25 439.6 Q(wcroft@cs.ucl.ac.uk)-.275 E=0A= (Department of Computer Science)80.25 452.6 Q(Uni)80.25 465.6 Q -.165=0A= (ve)-.275 G(rsity Colle).165 E(ge London)-.165 E(Go)80.25 478.6 Q=0A= (wer Street,)-.275 E(London WC1E 6BT)80.25 491.6 Q 2.75(,U)-.814 G(K)=0A= -2.75 E(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66 E 146.517=0A= (wcroft Section)-.275 F 2.75(10. [P)2.75 F(age 10])-.165 E EP=0A= %%Page: 11 11=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(11.)72=0A= 85 Q/F2 14/Times-Bold@0 SF(Full Copyright Statement)5.5 E F0(Cop)72=0A= 101.6 Q(yright \(C\) The Internet Society \(2001\).)-.11 E=0A= (All Rights Reserv)5.5 E(ed.)-.165 E(This document and translations of \=0A= it may be copied and furnished to others, and deri)72 118.2 Q -.275(va)=0A= -.275 G(ti).275 E .33 -.165(ve w)-.275 H(orks).055 E=0A= (that comment on or otherwise e)72 131.2 Q=0A= (xplain it or assist in its implementation may be prepared, copied,)=0A= -.165 E(published and distrib)72 144.2 Q=0A= (uted, in whole or in part, without restriction of an)-.22 E 2.75(yk)=0A= -.165 G(ind, pro)-2.75 E(vided that the)-.165 E(abo)72 157.2 Q .33 -.165=0A= (ve c)-.165 H(op).165 E(yright notice and this paragraph are included o\=0A= n all such copies and deri)-.11 E -.275(va)-.275 G(ti).275 E .33 -.165=0A= (ve w)-.275 H(orks.).055 E(Ho)72 170.2 Q(we)-.275 E -.165(ve)-.275 G .88=0A= -.44(r, t).165 H(his document itself may not be modi\214ed in an).44 E=0A= 2.75(yw)-.165 G(ay)-2.86 E 2.75(,s)-.715 G(uch as by remo)-2.75 E=0A= (ving the)-.165 E(cop)72 183.2 Q(yright notice or references to the Int\=0A= ernet Society or other Internet or)-.11 E -.055(ga)-.198 G(nizations, e)=0A= .055 E(xcept as)-.165 E(needed for the purpose of de)72 196.2 Q -.165=0A= (ve)-.275 G(loping Internet standards in which case the procedures for)=0A= .165 E(cop)72 209.2 Q=0A= (yrights de\214ned in the Internet languages other than English.)-.11 E=0A= (The limited permissions granted abo)72 225.8 Q .33 -.165(ve a)-.165 H=0A= (re perpetual and will not be re).165 E -.22(vo)-.275 G -.11(ke).22 G=0A= 2.75(db).11 G 2.75(yt)-2.75 G(he Internet)-2.75 E=0A= (Society or its successors or assigns.)72 238.8 Q=0A= (This document and the information contained herein is pro)72 255.4 Q=0A= (vided on an "AS IS" basis and THE)-.165 E=0A= (INTERNET SOCIETY AND THE INTERNET ENGINEERING T)72 268.4 Q=0A= (ASK FORCE DISCLAIMS)-1.023 E(ALL W)72 281.4 Q=0A= (ARRANTIES, EXPRESS OR IMPLIED, INCLUDING B)-1.32 E(UT NO)-.11 E 2.75=0A= (TL)-.44 G(IMITED T)-2.75 E 2.75(OA)-.198 G(NY)-2.75 E -1.32(WA)72 294.4=0A= S(RRANTY THA)1.32 E 2.75(TT)-1.221 G(HE USE OF THE INFORMA)-2.75 E=0A= (TION HEREIN WILL NO)-1.221 E 2.75(TI)-.44 G(NFRINGE)-2.75 E=0A= (ANY RIGHTS OR ANY IMPLIED W)72 307.4 Q(ARRANTIES OF MERCHANT)-1.32 E=0A= (ABILITY OR FITNESS)-1.023 E(FOR A P)72 320.4 Q(AR)-1.012 E=0A= (TICULAR PURPOSE.")-.66 E(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66=0A= E 146.517(wcroft Section)-.275 F 2.75(11. [P)2.75 F(age 11])-.165 E EP=0A= %%Page: 12 12=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E(Luby/Gemmell/V)72 769 Q=0A= (icisano/Rizzo/Cro)-.66 E 146.517(wcroft Section)-.275 F 2.75(11. [P)=0A= 2.75 F(age 12])-.165 E EP=0A= %%Trailer=0A= end=0A= %%EOF=0A= ------=_NextPart_000_000A_01C157E0.F961EDC0-- >From owner-rmt@listserv.lbl.gov Thu Oct 18 14:27:40 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9ILORf04351; Thu, 18 Oct 2001 14:24:27 -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.11.2/8.11.2) with ESMTP id f9ILOPp04343 for ; Thu, 18 Oct 2001 14:24:25 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9ILOOm27258 for ; Thu, 18 Oct 2001 14:24:24 -0700 (PDT) Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9ILOMb27222 for ; Thu, 18 Oct 2001 14:24:23 -0700 (PDT) Received: (qmail 23849 invoked from network); 18 Oct 2001 21:24:17 -0000 Received: from mail.intranet (10.1.1.37) by mx.digitalfountain.com with SMTP; 18 Oct 2001 21:24:17 -0000 Received: from bozz (dhcp-10-1-2-180.intranet [10.1.2.180]) by mail.intranet (8.9.3/8.9.3) with SMTP id OAA31638; Thu, 18 Oct 2001 14:23:51 -0700 X-Authentication-Warning: mail.intranet: Host dhcp-10-1-2-180.intranet [10.1.2.180] claimed to be bozz From: "Michael Luby" To: "Internet-Drafts@Ietf. Org" , "Rmt@Lbl. Gov" Cc: "Michael Luby" Subject: draft-ietf-rmt-bb-fec-04.txt Date: Thu, 18 Oct 2001 14:29:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000F_01C157E1.43555B10" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C157E1.43555B10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please post this draft on the IETF Internet Drafts archive. This is an update of an existing WG draft (RMT). This also serves as a last call before moving this towards RFC status. Please send any comments or concerns to the RMT list by Monday, October 22. Thanks, Mike Luby ------=_NextPart_000_000F_01C157E1.43555B10 Content-Type: text/plain; name="draft-ietf-rmt-bb-fec-04.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-rmt-bb-fec-04.txt" Internet Engineering Task Force RMT WG=0A= INTERNET-DRAFT M.Luby/Digital Fountain=0A= draft-ietf-rmt-bb-fec-04.txt L.Vicisano/Cisco=0A= J.Gemmell/Microsoft=0A= L.Rizzo/ACIRI and Univ. Pisa=0A= M.Handley/ACIRI=0A= J. Crowcroft/UCL=0A= 18 October 2001=0A= Expires: April 2002=0A= =0A= =0A= RMT BB Forward Error Correction Codes=0A= =0A= This document is an Internet-Draft and is in full conformance with all=0A= provisions of Section 10 of RFC2026.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering Task=0A= Force (IETF), its areas, and its working groups. Note that other groups=0A= may also distribute working documents as Internet-Drafts.=0A= =0A= Internet-Drafts are valid for a maximum of six months and may be=0A= updated, replaced, or obsoleted by other documents at any time. It is=0A= inappropriate to use Internet-Drafts as reference material or to cite=0A= them other than as a "work in progress".=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt=0A= =0A= To view the list Internet-Draft Shadow Directories, see=0A= http://www.ietf.org/shadow.html.=0A= =0A= This document is a product of the IETF RMT WG. Comments should be=0A= addressed to the authors, or the WG's mailing list at rmt@isi.edu.=0A= =0A= =0A= Abstract=0A= =0A= =0A= This memo describes the abstract packet formats and IANA=0A= registration procedures for use of Forward Error Correction=0A= (FEC) codes within the context of reliable IP multicast=0A= transport. This memo should be read in conjunction with and=0A= uses the terminology of the companion memo [1], which=0A= describes the use of Forward Error Correction (FEC) codes=0A= within the context of reliable IP multicast transport and=0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft [Page 1]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= provides an introduction to some commonly used FEC codes.=0A= =0A= =0A= 1. FEC Abstract Packet Fields and Out-of-Band Information=0A= =0A= This section describes FEC information that is either to be sent out-of-=0A= band or in packets. The FEC information is associated with transmission=0A= of data about a particular object. There are three classes of packets=0A= that may contain FEC information: data packets, session-control packets=0A= and feedback packets. They generally contain different kinds of FEC=0A= information. Note that some protocols may not use session-control or=0A= feedback packets.=0A= =0A= Data packets may sometimes serve as session-control packets as well;=0A= both data and session-control packets generally travel downstream from=0A= the sender towards receivers and are sent to a multicast channel or to a=0A= specific receiver using unicast.=0A= =0A= As a general rule, feedback packets travel upstream from receivers to=0A= the sender. Sometimes, however, they might be sent to a multicast=0A= channel or to another receiver or to some intermediate node or=0A= neighboring router that provides recovery services.=0A= =0A= This document specifies the FEC information that must be carried in data=0A= packets and the other FEC information that must be communicated either=0A= out-of-band or in data packets. This document does not specify out-of-=0A= band methods nor does it specify the way out-of-band FEC information is=0A= associated with FEC information carried in data packets. These methods=0A= must be specified in a complete protocol instantiation that uses the FEC=0A= building block. FEC information is classified as follows:=0A= =0A= =0A= 1) FEC Encoding ID=0A= =0A= Identifies the FEC encoder being used and allows receivers to=0A= select the appropriate FEC decoder. The value of the FEC Encoding=0A= ID MUST be the same for all transmission of data related to a=0A= particular object, but MAY vary across different transmissions of=0A= data about different objects, even if transmitted to the same set=0A= of multicast channels and/or using a single upper-layer session.=0A= The FEC encoding ID is subject to IANA registration.=0A= =0A= 2) FEC Encoding Name=0A= =0A= Provides a more specific identification of the FEC encoder being=0A= used for an Under-Specified FEC scheme. This value is not used=0A= for Fully-Specified FEC schemes. (See Section 1.1 for the=0A= definition of Under-Specified and Fully-Specified FEC schemes.)=0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1. [Page 2]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= The FEC encoding name is scoped by the FEC encoding ID, and is=0A= subject to IANA registration.=0A= =0A= 3) FEC payload ID=0A= =0A= Identifies the encoding symbol(s) in the payload of the packet.=0A= The fields in the FEC Payload ID depend on the encoder being used=0A= (e.g. in Block and Expandable FEC codes this may be the=0A= combination of block number and encoding symbol ID).=0A= =0A= 4) FEC Object Transmission Information=0A= =0A= This is information regarding the encoding of a specific object=0A= needed by the FEC decoder (e.g. for Block and Expandable FEC codes=0A= this may be the combination of the source block lengths and the=0A= object length). This might also include specific parameters of=0A= the FEC encoder.=0A= =0A= =0A= The FEC Encoding ID, FEC Encoding Name (for Under-Specified FEC schemes)=0A= and the FEC Object Transmission Information can be sent to a receiver=0A= within the data packet headers, within session control packets, or by=0A= some other means. In any case, the means for communicating this to a=0A= receiver is out of the scope of this document. The FEC Payload ID MUST=0A= be included in the data packet header fields, as it provides a=0A= description of the data contained in the packet.=0A= =0A= Within the context of FEC repair schemes, feedback packets are=0A= (optionally) used to request FEC retransmission. The FEC-related=0A= information present in feedback packets usually contains an FEC Block ID=0A= that defines the block that is being repaired, and the number of Repair=0A= Symbols requested. Although this is the most common case, variants are=0A= possible in which the receivers provide more specific information about=0A= the Repair Symbols requested (e.g. an index range or a list of symbols=0A= accepted). It is also possible to include multiple of these requests in=0A= a single feedback packet.=0A= =0A= This document does not provide any detail about feedback schemes used in=0A= combination with FEC nor the format of FEC information in feedback=0A= packets. If feedback packets are used in a complete protocol=0A= instantiation, these details must be provided in the protocol=0A= instantiation specification.=0A= =0A= =0A= 1.1. FEC Encoding ID and FEC Encoding Name=0A= =0A= =0A= The FEC Encoding ID is a numeric index that identifies a specific FEC=0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1.1. [Page 3]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= scheme OR a class of encoding schemes that share the same FEC Payload ID=0A= format.=0A= =0A= An FEC scheme is a Fully-Specified FEC scheme if the encoding scheme is=0A= formally and fully specified, in a way that independent implementors can=0A= implement both encoder and decoder from a specification that is an IETF=0A= RFC. The FEC Encoding ID uniquely identifies a Fully-Specified FEC=0A= scheme. Companion documents of this specification may specify Fully-=0A= Specified FEC schemes and associate them with FEC Encoding ID values.=0A= These documents MUST also specify a format for the FEC Payload ID and=0A= specify the information in the FEC Object Transmission Information.=0A= =0A= It is possible that a FEC scheme cannot be a Fully-Specified FEC scheme,=0A= because a specification is simply not available or that a party exists=0A= that owns the encoding scheme and is not willing to disclose the=0A= algorithm or specification. We refer to such an FEC encoding schemes as=0A= an Under-Specified FEC scheme. The following holds for an Under-=0A= Specified FEC scheme:=0A= =0A= o The format of the FEC Payload ID and the specific information in the=0A= FEC Object Transmission Information MUST be defined for the Under-=0A= Specified FEC scheme.=0A= =0A= o A value for the FEC Encoding ID MUST be reserved and associated with=0A= the format of the FEC Payload ID and the specific information in the=0A= FEC Object Transmission Information. An already reserved FEC=0A= Encoding ID value MUST be reused if it is associated with the same=0A= format of FEC Payload ID and the same information in the FEC Object=0A= Transmission Information as the ones needed for the new Under-=0A= Specified FEC scheme.=0A= =0A= o A value for the FEC Encoding Name MUST be reserved.=0A= =0A= =0A= An Under-specified FEC scheme is fully identified by the tuple (FEC=0A= Encoding ID, FEC Encoding Name). The tuple MUST identify a single scheme=0A= that has at least one implementation. The party that owns this tuple=0A= MUST be able to provide information on how to obtain the Under-Specified=0A= FEC scheme identified by the tuple, e.g. a pointer to a publicly=0A= available reference-implementation or the name and contacts of a company=0A= that sells it, either separately or embedded in another product.=0A= =0A= Different Under-Specified FEC schemes that share the same FEC Encoding=0A= ID -- but have different FEC Encoding Names -- also share the same=0A= format of FEC Payload ID and specify the same information in the FEC=0A= Object Transmission Information.=0A= =0A= This specification reserves the range 0-127 for the values of FEC=0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1.1. [Page 4]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= Encoding IDs for Fully-Specified FEC schemes and the range 128-255 for=0A= the values of Under-Specified FEC schemes.=0A= =0A= =0A= 1.2. FEC Payload ID and FEC Object Transmission Information=0A= =0A= =0A= A document that specifies an FEC scheme and reserves a value of FEC=0A= Encoding ID MUST define a packet format for the FEC Payload ID and=0A= specify the information in the FEC Object Transmission Information=0A= according to the needs of the encoding scheme. This applies to documents=0A= that reserve values of FEC Encoding IDs for both Fully-Specified and=0A= Under-Specified FEC schemes.=0A= =0A= The packet format definition for the FEC Payload ID MUST specify the=0A= meaning and layout of the fields down to the level of specific bits.=0A= The FEC Payload ID MUST have a length that is a multiple of a 4-byte=0A= word. This requirement facilitates the alignment of packet fields in=0A= protocol instantiations.=0A= =0A= =0A= 2. Preassigned FEC Encoding IDs=0A= =0A= This section specifies the FEC Encoding ID and the associated FEC=0A= Payload ID format and the specific information in the FEC Object=0A= Transmission Information for a number of known Under-Specified FEC=0A= schemes. Under-specified FEC schemes that use the same FEC Payload ID=0A= format and specific information in the FEC Object Transmission=0A= Information as for one of the FEC Encoding IDs specified in this section=0A= MUST use the corresponding FEC Encoding ID. Other FEC Encoding IDs may=0A= be specified for other Under-Specified FEC schemes in companion=0A= documents.=0A= =0A= =0A= 2.1. Small Block, Large Block and Expandable FEC Codes=0A= =0A= This subsection reserves the FEC Encoding ID value 128 for the Under-=0A= Specified FEC schemes described in [1] that are called Small Block FEC=0A= codes, Large Block FEC codes and Expandable FEC codes.=0A= =0A= The FEC Payload ID is composed of a Source Block Number and an Encoding=0A= Symbol ID structured as follows:=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.1. [Page 5]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= 0 1 2 3=0A= 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | Source Block Number |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | Encoding Symbol ID |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= =0A= =0A= The Source Block Number idenfities from which source block of the object=0A= the encoding symbol(s) in the payload are generated. These blocks are=0A= numbered consecutively from 0 to N-1, where N is the number of source=0A= blocks in the object.=0A= =0A= The Encoding Symbol ID identifies which specific encoding symbol(s)=0A= generated from the source block are carried in the packet payload. The=0A= exact details of the correspondence between Encoding Symbol IDs and the=0A= encoding symbol(s) in the packet payload are dependent on the particular=0A= encoding algorithm used as identified by the Fec Encoding ID and by the=0A= FEC Encoding Name, and these details may be proprietary.=0A= =0A= The FEC Object Transmission Information has the following specific=0A= information:=0A= =0A= =0A= o The total length of the object in bytes.=0A= =0A= o The number of source blocks that the object is partitioned into, and=0A= the length of each source block in bytes.=0A= =0A= =0A= =0A= 2.2. Small Block Systematic FEC Codes=0A= =0A= This subsection reserves the FEC Encoding ID value 129 for the Under-=0A= Specified FEC schemes described in [1] that are called Small Block=0A= Systematic FEC codes. For Small Block Systematic FEC codes, each source=0A= block is of length at most 65536 bytes.=0A= =0A= Although these codes can generally be accommodated by the FEC Encoding=0A= ID described in Section 2.1, a specific FEC Encoding ID is defined for=0A= Small Block Systematic FEC codes to allow more flexibility and to retain=0A= header compactness. The small source block length and small exapansion=0A= factor that often characterize systematic codes may require that the=0A= data source changes frequently the source block length. To allow the=0A= dynamic variation of the source block length and to communicate it to=0A= the receivers with low overhead, the block length is included in the FEC=0A= Payload ID.=0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.2. [Page 6]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= The FEC Payload ID is composed of the Source Block Number, Source Block=0A= Length and the Encoding Symbol ID:=0A= =0A= =0A= 0 1 2 3=0A= 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | Source Block Number |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | Source Block Length | Encoding Symbol ID |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= =0A= =0A= The Source Block Number idenfities from which source block of the object=0A= the encoding symbol(s) in the payload are generated. These blocks are=0A= numbered consecutively from 0 to N-1, where N is the number of source=0A= blocks in the object.=0A= =0A= The Source Block Length is the length in units of source symbols of the=0A= source block identified by the Source Block Number.=0A= =0A= The Encoding Symbol ID identifies which specific encoding symbol(s)=0A= generated from the source block are carried in the packet payload. The=0A= exact details of the correspondence between Encoding Symbol IDs and the=0A= encoding symbol(s) in the packet payload are dependent on the particular=0A= encoding algorithm used as identified by the Fec Encoding ID and by the=0A= FEC Encoding Name, and these details may be proprietary.=0A= =0A= The FEC Object Transmission Information has the following specific=0A= information:=0A= =0A= =0A= o The total length of the object in bytes.=0A= =0A= o The maximum length in bytes of the encoding symbols that can be=0A= generated for any source block. This field is provided to allow=0A= receivers to preallocate buffer space that is suitable for decoding=0A= to recover any source block.=0A= =0A= o The length in bytes of a source symbol.=0A= =0A= =0A= =0A= 3. IANA Considerations=0A= =0A= Values of FEC Encoding IDs and FEC Encoding Names are subject to IANA=0A= registration. FEC Encoding IDs and FEC Encoding Names are hierarchical:=0A= FEC Encoding IDs scope ranges of FEC Encoding Names. Only FEC Encoding=0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 3. [Page 7]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= IDs that correspond to Under-Specified FEC schemes scope a corresponding=0A= set of FEC Encoding Names.=0A= =0A= The FEC Encoding ID is a numeric non-negative index. In this document,=0A= the range of values for FEC Encoding IDs is 0 and 255. Values from 0 to=0A= 127 are reserved for Fully-Specified FEC schemes, as described in more=0A= detail in Section 1.1. The assignment of a FEC Encoding ID in this range=0A= can only be granted if the requestor can provide such a specification=0A= published as an IETF RFC, as described in more detail in Section 1.1.=0A= Values from 128 to 255 are reserved for Under-Specified FEC schemes, as=0A= described in more detail in Section 1.1. This specification already=0A= assigns the values 128 and 129, as described in Section 2.=0A= =0A= Values of FEC Encoding IDs can only be assigned if the required format=0A= for the FEC Payload ID and the specific information in the FEC Object=0A= Transmission Information are specified in an IETF RFC.=0A= =0A= Each FEC Encoding ID assigned to an Under-Specified FEC scheme scopes an=0A= independent range of FEC Encoding Names (i.e. the same value of FEC=0A= Encoding Name can be reused for different FEC Encoding IDs). An FEC=0A= Encoding Name is a numeric non-negative index.=0A= =0A= Under the scope of a FEC Encoding ID, FEC Encoding Names are assigned on=0A= a First Come First Served base to requestors that are able to provide=0A= point of contact information and a pointer to publicly accessible=0A= documentation describing the Under-Specified FEC scheme and ways to=0A= obtain it (e.g. a pointer to a publicly available reference-=0A= implementation or the name and contacts of a company that sells it,=0A= either separately or embedded in another product). The requestor is=0A= responsible for keeping this information up to date.=0A= =0A= =0A= 4. Acknowledgments=0A= =0A= Brian Adamson contributed to this document by shaping Section 2.2 and=0A= providing general feedback. We also wish to thank Vincent Roca and=0A= Justin Chapweske for their comments.=0A= =0A= =0A= 5. References=0A= =0A= =0A= [1] Luby, M., Vicisano, Gemmell, J., L., Rizzo, L., Handley, M.,=0A= Crowcroft, J., "The use of Forward Error Correction in Reliable=0A= Multicast", Internet draft draft-ietf-rmt-info-fec-01.txt, October 2001.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 5. [Page 8]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= 6. Authors' Addresses=0A= =0A= Michael Luby=0A= luby@digitalfountain.com=0A= Digital Fountain, Inc.=0A= 39141 Civic Center Drive=0A= Suite 300=0A= Fremont, CA 94538=0A= =0A= Lorenzo Vicisano=0A= lorenzo@cisco.com=0A= cisco Systems, Inc.=0A= 170 West Tasman Dr.,=0A= San Jose, CA, USA, 95134=0A= =0A= Jim Gemmell=0A= jgemmell@microsoft.com=0A= Microsoft Research=0A= 301 Howard St., #830=0A= San Francisco, CA, USA, 94105=0A= =0A= Luigi Rizzo=0A= luigi@iet.unipi.it=0A= ACIRI, 1947 Center St., Berkeley CA 94704=0A= and=0A= Dip. di Ing. dell'Informazione=0A= Universita` di Pisa=0A= via Diotisalvi 2, 56126 Pisa, Italy=0A= =0A= Mark Handley=0A= mjh@aciri.org=0A= ACIRI=0A= 1947 Center St.=0A= Berkeley CA, USA, 94704=0A= =0A= Jon Crowcroft=0A= J.Crowcroft@cs.ucl.ac.uk=0A= Department of Computer Science=0A= University College London=0A= Gower Street,=0A= London WC1E 6BT, UK=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 6. [Page 9]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= 7. Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2001). All Rights Reserved.=0A= =0A= This document and translations of it may be copied and furnished to=0A= others, and derivative works that comment on or otherwise explain it or=0A= assist in its implementation may be prepared, copied, published and=0A= distributed, in whole or in part, without restriction of any kind,=0A= provided that the above copyright notice and this paragraph are included=0A= on all such copies and derivative works. However, this document itself=0A= may not be modified in any way, such as by removing the copyright notice=0A= or references to the Internet Society or other Internet organizations,=0A= except as needed for the purpose of developing Internet standards in=0A= which case the procedures for copyrights defined in the Internet=0A= languages other than English.=0A= =0A= The limited permissions granted above are perpetual and will not be=0A= revoked by the Internet Society or its successors or assigns.=0A= =0A= This document and the information contained herein is provided on an "AS=0A= IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK=0A= FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT=0A= LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT=0A= INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR=0A= FITNESS FOR A PARTICULAR PURPOSE."=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 7. [Page 10]=0A= =0C=0A= INTERNET-DRAFT Expires: April 2002 October 2001=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 7. [Page 11]=0A= ------=_NextPart_000_000F_01C157E1.43555B10 Content-Type: application/postscript; name="draft-ietf-rmt-bb-fec-04.ps" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-rmt-bb-fec-04.ps" %!PS-Adobe-3.0=0A= %%Creator: groff version 1.15=0A= %%CreationDate: Thu Oct 18 10:38:55 2001=0A= %%DocumentNeededResources: font Courier-Bold=0A= %%+ font Times-Bold=0A= %%+ font Times-Roman=0A= %%+ font Courier=0A= %%DocumentSuppliedResources: procset grops 1.15 1=0A= %%Pages: 9=0A= %%PageOrder: Ascend=0A= %%Orientation: Portrait=0A= %%EndComments=0A= %%BeginProlog=0A= %%BeginResource: procset grops 1.15 1=0A= /setpacking where{=0A= pop=0A= currentpacking=0A= true setpacking=0A= }if=0A= /grops 120 dict dup begin=0A= /SC 32 def=0A= /A/show load def=0A= /B{0 SC 3 -1 roll widthshow}bind def=0A= /C{0 exch ashow}bind def=0A= /D{0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /E{0 rmoveto show}bind def=0A= /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def=0A= /G{0 rmoveto 0 exch ashow}bind def=0A= /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /I{0 exch rmoveto show}bind def=0A= /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def=0A= /K{0 exch rmoveto 0 exch ashow}bind def=0A= /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /M{rmoveto show}bind def=0A= /N{rmoveto 0 SC 3 -1 roll widthshow}bind def=0A= /O{rmoveto 0 exch ashow}bind def=0A= /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /Q{moveto show}bind def=0A= /R{moveto 0 SC 3 -1 roll widthshow}bind def=0A= /S{moveto 0 exch ashow}bind def=0A= /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A= /SF{=0A= findfont exch=0A= [exch dup 0 exch 0 exch neg 0 0]makefont=0A= dup setfont=0A= [exch/setfont cvx]cvx bind def=0A= }bind def=0A= /MF{=0A= findfont=0A= [5 2 roll=0A= 0 3 1 roll=0A= neg 0 0]makefont=0A= dup setfont=0A= [exch/setfont cvx]cvx bind def=0A= }bind def=0A= /level0 0 def=0A= /RES 0 def=0A= /PL 0 def=0A= /LS 0 def=0A= /MANUAL{=0A= statusdict begin/manualfeed true store end=0A= }bind def=0A= /PLG{=0A= gsave newpath clippath pathbbox grestore=0A= exch pop add exch pop=0A= }bind def=0A= /BP{=0A= /level0 save def=0A= 1 setlinecap=0A= 1 setlinejoin=0A= 72 RES div dup scale=0A= LS{=0A= 90 rotate=0A= }{=0A= 0 PL translate=0A= }ifelse=0A= 1 -1 scale=0A= }bind def=0A= /EP{=0A= level0 restore=0A= showpage=0A= }bind def=0A= /DA{=0A= newpath arcn stroke=0A= }bind def=0A= /SN{=0A= transform=0A= .25 sub exch .25 sub exch=0A= round .25 add exch round .25 add exch=0A= itransform=0A= }bind def=0A= /DL{=0A= SN=0A= moveto=0A= SN=0A= lineto stroke=0A= }bind def=0A= /DC{=0A= newpath 0 360 arc closepath=0A= }bind def=0A= /TM matrix def=0A= /DE{=0A= TM currentmatrix pop=0A= translate scale newpath 0 0 .5 0 360 arc closepath=0A= TM setmatrix=0A= }bind def=0A= /RC/rcurveto load def=0A= /RL/rlineto load def=0A= /ST/stroke load def=0A= /MT/moveto load def=0A= /CL/closepath load def=0A= /FL{=0A= currentgray exch setgray fill setgray=0A= }bind def=0A= /BL/fill load def=0A= /LW/setlinewidth load def=0A= /RE{=0A= findfont=0A= dup maxlength 1 index/FontName known not{1 add}if dict begin=0A= {=0A= 1 index/FID ne{def}{pop pop}ifelse=0A= }forall=0A= /Encoding exch def=0A= dup/FontName exch def=0A= currentdict end definefont pop=0A= }bind def=0A= /DEFS 0 def=0A= /EBEGIN{=0A= moveto=0A= DEFS begin=0A= }bind def=0A= /EEND/end load def=0A= /CNT 0 def=0A= /level1 0 def=0A= /PBEGIN{=0A= /level1 save def=0A= translate=0A= div 3 1 roll div exch scale=0A= neg exch neg exch translate=0A= 0 setgray=0A= 0 setlinecap=0A= 1 setlinewidth=0A= 0 setlinejoin=0A= 10 setmiterlimit=0A= []0 setdash=0A= /setstrokeadjust where{=0A= pop=0A= false setstrokeadjust=0A= }if=0A= /setoverprint where{=0A= pop=0A= false setoverprint=0A= }if=0A= newpath=0A= /CNT countdictstack def=0A= userdict begin=0A= /showpage{}def=0A= }bind def=0A= /PEND{=0A= clear=0A= countdictstack CNT sub{end}repeat=0A= level1 restore=0A= }bind def=0A= end def=0A= /setpacking where{=0A= pop=0A= setpacking=0A= }if=0A= %%EndResource=0A= %%IncludeResource: font Courier-Bold=0A= %%IncludeResource: font Times-Bold=0A= %%IncludeResource: font Times-Roman=0A= %%IncludeResource: font Courier=0A= grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72=0A= def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron=0A= /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef=0A= /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef=0A= /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef=0A= /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent=0A= /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen=0A= /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon=0A= /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O=0A= /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex=0A= /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y=0A= /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft=0A= /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl=0A= /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut=0A= /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash=0A= /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen=0A= /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft=0A= /logicalnot/minus/registered/macron/degree/plusminus/twosuperior=0A= /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior=0A= /ordmasculine/guilsinglright/onequarter/onehalf/threequarters=0A= /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE=0A= /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex=0A= /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis=0A= /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn=0A= /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla=0A= /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis=0A= /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash=0A= /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def=0A= /Courier@0 ENC0/Courier RE/Times-Roman@0 ENC0/Times-Roman RE=0A= /Times-Bold@0 ENC0/Times-Bold RE/Courier-Bold@0 ENC0/Courier-Bold RE=0A= %%EndProlog=0A= %%Page: 1 1=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 10/Courier-Bold@0 SF(Internet Engineering Task Force)72 85 Q(RMT WG)=0A= 209.999 E 203.999(INTERNET-DRAFT M.Luby/Digital)72 98 R(Fountain)6 E=0A= 167.999(draft-ietf-rmt-bb-fec-04.ps L.Vicisano/Cisco)72 111 R=0A= (J.Gemmell/Microsoft)389.999 124 Q(L.Rizzo/ACIRI and Univ. Pisa)335.999=0A= 137 Q(M.Handley/ACIRI)413.999 150 Q(J. Crowcroft/UCL)407.999 163 Q=0A= (18 October 2001)413.999 176 Q(Expires: April 2002)389.999 189 Q/F1 14=0A= /Times-Bold@0 SF(RMT BB F)159.144 214 Q(orward Err)-.35 E(or Corr)-.252=0A= E(ection Codes)-.252 E/F2 11/Times-Roman@0 SF(This document is an Inter\=0A= net-Draft and is in full conformance with all pro)72 233 Q=0A= (visions of Section 10 of)-.165 E(RFC2026.)72 246 Q=0A= (Internet-Drafts are w)72 272 Q=0A= (orking documents of the Internet Engineering T)-.11 E(ask F)-.88 E=0A= (orce \(IETF\), its areas,)-.165 E(and its w)72 285 Q(orking groups.)=0A= -.11 E(Note that other groups may also distrib)5.5 E(ute w)-.22 E=0A= (orking documents as)-.11 E(Internet-Drafts.)72 298 Q=0A= (Internet-Drafts are v)72 324 Q=0A= (alid for a maximum of six months and may be updated, replaced, or)-.275=0A= E(obsoleted by other documents at an)72 337 Q 2.75(yt)-.165 G 2.75=0A= (ime. It)-2.75 F(is inappropriate to use Internet-Drafts as reference)=0A= 2.75 E(material or to cite them other than as a "w)72 350 Q=0A= (ork in progress".)-.11 E=0A= (The list of current Internet-Drafts can be accessed at http://www)72=0A= 376 Q(.ietf.or)-.715 E(g/ietf/1id-abstracts.txt)-.198 E 1.76 -.88(To v)=0A= 72 402 T(ie).88 E 2.75(wt)-.275 G(he list Internet-Draft Shado)-2.75 E=0A= 2.75(wD)-.275 G(irectories, see http://www)-2.75 E(.ietf.or)-.715 E=0A= (g/shado)-.198 E -.715(w.)-.275 G(html.).715 E=0A= (This document is a product of the IETF RMT WG.)72 428 Q=0A= (Comments should be addressed to the)5.5 E(authors, or the WG')72 441 Q=0A= 2.75(sm)-.605 G(ailing list at rmt@isi.edu.)-2.75 E/F3 11/Times-Bold@0=0A= SF(Abstract)267.534 473 Q F2(This memo describes the abstract pack)97=0A= 495.6 Q(et formats and IAN)-.11 E 2.75(Ar)-.385 G -.165(eg)-2.75 G=0A= (istration procedures).165 E(for use of F)97 508.6 Q(orw)-.165 E=0A= (ard Error Correction \(FEC\) codes within the conte)-.11 E=0A= (xt of reliable IP)-.165 E(multicast transport.)97 521.6 Q=0A= (This memo should be read in conjunction with and uses the)5.5 E=0A= (terminology of the companion memo [1], which describes the use of F)97=0A= 534.6 Q(orw)-.165 E(ard Error)-.11 E=0A= (Correction \(FEC\) codes within the conte)97 547.6 Q=0A= (xt of reliable IP multicast transport and)-.165 E(pro)97 560.6 Q=0A= (vides an introduction to some commonly used FEC codes.)-.165 E F3(1.)72=0A= 599.6 Q F1(FEC Abstract P)5.5 E(ack)-.14 E=0A= (et Fields and Out-of-Band Inf)-.14 E(ormation)-.35 E F2(This section d\=0A= escribes FEC information that is either to be sent out-of-band or in pa\=0A= ck)72 616.2 Q 2.75(ets. The)-.11 F(FEC information is associated with t\=0A= ransmission of data about a particular object.)72 629.2 Q=0A= (There are three)5.5 E(classes of pack)72 642.2 Q=0A= (ets that may contain FEC information: data pack)-.11 E=0A= (ets, session-control pack)-.11 E(ets and)-.11 E(feedback pack)72 655.2=0A= Q 2.75(ets. The)-.11 F 2.75(yg)-.165 G(enerally contain dif)-2.75 E=0A= (ferent kinds of FEC information.)-.275 E(Note that some)5.5 E=0A= (protocols may not use session-control or feedback pack)72 668.2 Q(ets.)=0A= -.11 E(Data pack)72 694.2 Q(ets may sometimes serv)-.11 E 2.75(ea)-.165=0A= G 2.75(ss)-2.75 G(ession-control pack)-2.75 E=0A= (ets as well; both data and session-)-.11 E(control pack)72 707.2 Q=0A= (ets generally tra)-.11 E -.165(ve)-.22 G 2.75(ld).165 G -.275(ow)-2.75=0A= G(nstream from the sender to).275 E -.11(wa)-.275 G(rds recei).11 E=0A= -.165(ve)-.275 G(rs and are sent to a).165 E=0A= (multicast channel or to a speci\214c recei)72 720.2 Q -.165(ve)-.275 G=0A= 2.75(ru).165 G(sing unicast.)-2.75 E(Luby/V)72 769 Q=0A= (icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E 117.356=0A= (wcroft Section)-.275 F 2.75(1. [P)2.75 F(age 1])-.165 E EP=0A= %%Page: 2 2=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E=0A= (As a general rule, feedback pack)72 85 Q(ets tra)-.11 E -.165(ve)-.22 G=0A= 2.75(lu).165 G(pstream from recei)-2.75 E -.165(ve)-.275 G=0A= (rs to the sender).165 E 2.75(.S)-.605 G(ometimes,)-2.75 E(ho)72 98 Q=0A= (we)-.275 E -.165(ve)-.275 G .88 -.44(r, t).165 H(he).44 E 2.75(ym)-.165=0A= G(ight be sent to a multicast channel or to another recei)-2.75 E -.165=0A= (ve)-.275 G 2.75(ro).165 G 2.75(rt)-2.75 G 2.75(os)-2.75 G=0A= (ome intermediate)-2.75 E(node or neighboring router that pro)72 111 Q=0A= (vides reco)-.165 E -.165(ve)-.165 G(ry services.).165 E(This document \=0A= speci\214es the FEC information that must be carried in data pack)72 137=0A= Q(ets and the other)-.11 E(FEC information that must be communicated ei\=0A= ther out-of-band or in data pack)72 150 Q(ets. This)-.11 E(document doe\=0A= s not specify out-of-band methods nor does it specify the w)72 163 Q=0A= (ay out-of-band FEC)-.11 E=0A= (information is associated with FEC information carried in data pack)72=0A= 176 Q 2.75(ets. These)-.11 F(methods must be)2.75 E=0A= (speci\214ed in a complete protocol instantiation that uses the FEC b)72=0A= 189 Q(uilding block. FEC information)-.22 E(is classi\214ed as follo)72=0A= 202 Q(ws:)-.275 E 7.337(1\) FEC)74.75 231.6 R(Encoding ID)2.75 E=0A= (Identi\214es the FEC encoder being used and allo)105 248.2 Q(ws recei)=0A= -.275 E -.165(ve)-.275 G(rs to select the appropriate FEC).165 E=0A= (decoder)105 261.2 Q 5.5(.T)-.605 G(he v)-5.5 E=0A= (alue of the FEC Encoding ID MUST be the same for all transmission of)=0A= -.275 E(data related to a particular object, b)105 274.2 Q(ut MA)-.22 E=0A= 2.75(Yv)-1.155 G(ary across dif)-3.025 E(ferent transmissions of data)=0A= -.275 E(about dif)105 287.2 Q(ferent objects, e)-.275 E -.165(ve)-.275 G=0A= 2.75(ni).165 G 2.75(ft)-2.75 G=0A= (ransmitted to the same set of multicast channels and/or)-2.75 E=0A= (using a single upper)105 300.2 Q(-layer session.)-.22 E=0A= (The FEC encoding ID is subject to IAN)5.5 E 2.75(Ar)-.385 G -.165(eg)=0A= -2.75 G(istration.).165 E 7.337(2\) FEC)74.75 316.8 R(Encoding Name)2.75=0A= E(Pro)105 333.4 Q(vides a more speci\214c identi\214cation of the FEC e\=0A= ncoder being used for an Under)-.165 E(-)-.22 E(Speci\214ed FEC scheme.)=0A= 105 346.4 Q(This v)5.5 E=0A= (alue is not used for Fully-Speci\214ed FEC schemes.)-.275 E(\(See)5.5 E=0A= (Section 1.1 for the de\214nition of Under)105 359.4 Q=0A= (-Speci\214ed and Fully-Speci\214ed FEC schemes.\))-.22 E(The)5.5 E(FEC\=0A= encoding name is scoped by the FEC encoding ID, and is subject to IAN)=0A= 105 372.4 Q(A)-.385 E(re)105 385.4 Q(gistration.)-.165 E 7.337(3\) FEC)=0A= 74.75 402 R(payload ID)2.75 E=0A= (Identi\214es the encoding symbol\(s\) in the payload of the pack)105=0A= 418.6 Q 2.75(et. The)-.11 F(\214elds in the FEC)2.75 E -.165(Pa)105=0A= 431.6 S(yload ID depend on the encoder being used \(e.g. in Block and E\=0A= xpandable FEC codes).165 E=0A= (this may be the combination of block number and encoding symbol ID\).)=0A= 105 444.6 Q 7.337(4\) FEC)74.75 461.2 R(Object T)2.75 E=0A= (ransmission Information)-.385 E(This is information re)105 477.8 Q=0A= -.055(ga)-.165 G=0A= (rding the encoding of a speci\214c object needed by the FEC decoder)=0A= .055 E(\(e.g. for Block and Expandable FEC codes this may be the combin\=0A= ation of the source)105 490.8 Q(block lengths and the object length\).)=0A= 105 503.8 Q(This might also include speci\214c parameters of the)5.5 E=0A= (FEC encoder)105 516.8 Q(.)-.605 E=0A= (The FEC Encoding ID, FEC Encoding Name \(for Under)72 546.4 Q=0A= (-Speci\214ed FEC schemes\) and the FEC)-.22 E(Object T)72 559.4 Q=0A= (ransmission Information can be sent to a recei)-.385 E -.165(ve)-.275 G=0A= 2.75(rw).165 G(ithin the data pack)-2.75 E(et headers, within)-.11 E=0A= (session control pack)72 572.4 Q(ets, or by some other means.)-.11 E=0A= (In an)5.5 E 2.75(yc)-.165 G(ase, the means for communicating this)-2.75=0A= E(to a recei)72 585.4 Q -.165(ve)-.275 G 2.75(ri).165 G 2.75(so)-2.75 G=0A= (ut of the scope of this document.)-2.75 E(The FEC P)5.5 E=0A= (ayload ID MUST be included in the)-.165 E(data pack)72 598.4 Q=0A= (et header \214elds, as it pro)-.11 E=0A= (vides a description of the data contained in the pack)-.165 E(et.)-.11=0A= E -.44(Wi)72 624.4 S(thin the conte).44 E=0A= (xt of FEC repair schemes, feedback pack)-.165 E=0A= (ets are \(optionally\) used to request FEC)-.11 E 2.75=0A= (retransmission. The)72 637.4 R=0A= (FEC-related information present in feedback pack)2.75 E=0A= (ets usually contains an)-.11 E(FEC Block ID that de\214nes the block t\=0A= hat is being repaired, and the number of Repair Symbols)72 650.4 Q=0A= (requested. Although this is the most common case, v)72 663.4 Q=0A= (ariants are possible in which the recei)-.275 E -.165(ve)-.275 G(rs)=0A= .165 E(pro)72 676.4 Q(vide more speci\214c information about the Repair\=0A= Symbols requested \(e.g. an inde)-.165 E 2.75(xr)-.165 G(ange or a)=0A= -2.75 E(list of symbols accepted\). It is also possible to include mult\=0A= iple of these requests in a single)72 689.4 Q(feedback pack)72 702.4 Q=0A= (et.)-.11 E(Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)=0A= -.165 E 117.356(wcroft Section)-.275 F 2.75(1. [P)2.75 F(age 2])-.165 E=0A= EP=0A= %%Page: 3 3=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E(This document does not pro)72=0A= 85 Q(vide an)-.165 E 2.75(yd)-.165 G=0A= (etail about feedback schemes used in combination with)-2.75 E=0A= (FEC nor the format of FEC information in feedback pack)72 98 Q 2.75=0A= (ets. If)-.11 F(feedback pack)2.75 E(ets are used in a)-.11 E=0A= (complete protocol instantiation, these details must be pro)72 111 Q=0A= (vided in the protocol instantiation)-.165 E(speci\214cation.)72 124 Q=0A= /F1 11/Times-Bold@0 SF(1.1.)72 163 Q/F2 13/Times-Bold@0 SF=0A= (FEC Encoding ID and FEC Encoding Name)5.5 E F0=0A= (The FEC Encoding ID is a numeric inde)72 192.6 Q 2.75(xt)-.165 G=0A= (hat identi\214es a speci\214c FEC scheme OR a class of)-2.75 E=0A= (encoding schemes that share the same FEC P)72 205.6 Q=0A= (ayload ID format.)-.165 E(An FEC scheme is a Fully-Speci\214ed FEC sch\=0A= eme if the encoding scheme is formally and fully)72 231.6 Q=0A= (speci\214ed, in a w)72 244.6 Q(ay that independent implementors can im\=0A= plement both encoder and decoder from)-.11 E 2.75(as)72 257.6 S=0A= (peci\214cation that is an IETF RFC.)-2.75 E=0A= (The FEC Encoding ID uniquely identi\214es a Fully-Speci\214ed)5.5 E=0A= (FEC scheme.)72 270.6 Q(Companion documents of this speci\214cation may\=0A= specify Fully-Speci\214ed FEC)5.5 E=0A= (schemes and associate them with FEC Encoding ID v)72 283.6 Q=0A= (alues. These documents MUST also specify)-.275 E 2.75(af)72 296.6 S=0A= (ormat for the FEC P)-2.75 E=0A= (ayload ID and specify the information in the FEC Object T)-.165 E=0A= (ransmission)-.385 E(Information.)72 309.6 Q(It is possible that a FEC \=0A= scheme cannot be a Fully-Speci\214ed FEC scheme, because a speci\214cat\=0A= ion)72 335.6 Q(is simply not a)72 348.6 Q -.275(va)-.22 G=0A= (ilable or that a party e).275 E(xists that o)-.165 E=0A= (wns the encoding scheme and is not willing to)-.275 E=0A= (disclose the algorithm or speci\214cation. W)72 361.6 Q 2.75(er)-.88 G=0A= (efer to such an FEC encoding schemes as an Under)-2.75 E(-)-.22 E=0A= (Speci\214ed FEC scheme.)72 374.6 Q(The follo)5.5 E=0A= (wing holds for an Under)-.275 E(-Speci\214ed FEC scheme:)-.22 E 11(oT)=0A= 77.5 391.2 S(he format of the FEC P)-11 E=0A= (ayload ID and the speci\214c information in the FEC Object)-.165 E=0A= -.385(Tr)94 404.2 S=0A= (ansmission Information MUST be de\214ned for the Under).385 E=0A= (-Speci\214ed FEC scheme.)-.22 E 11(oA)77.5 420.8 S -.275(va)-8.25 G=0A= (lue for the FEC Encoding ID MUST be reserv).275 E=0A= (ed and associated with the format of the)-.165 E(FEC P)94 433.8 Q=0A= (ayload ID and the speci\214c information in the FEC Object T)-.165 E=0A= (ransmission Information.)-.385 E(An already reserv)94 446.8 Q=0A= (ed FEC Encoding ID v)-.165 E=0A= (alue MUST be reused if it is associated with the)-.275 E=0A= (same format of FEC P)94 459.8 Q=0A= (ayload ID and the same information in the FEC Object T)-.165 E=0A= (ransmission)-.385 E(Information as the ones needed for the ne)94 472.8=0A= Q 2.75(wU)-.275 G(nder)-2.75 E(-Speci\214ed FEC scheme.)-.22 E 11(oA)=0A= 77.5 489.4 S -.275(va)-8.25 G=0A= (lue for the FEC Encoding Name MUST be reserv).275 E(ed.)-.165 E=0A= (An Under)72 519 Q(-speci\214ed FEC scheme is fully identi\214ed by the\=0A= tuple \(FEC Encoding ID, FEC)-.22 E(Encoding Name\). The tuple MUST id\=0A= entify a single scheme that has at least one implementation.)72 532 Q=0A= (The party that o)72 545 Q(wns this tuple MUST be able to pro)-.275 E=0A= (vide information on ho)-.165 E 2.75(wt)-.275 G 2.75(oo)-2.75 G=0A= (btain the Under)-2.75 E(-)-.22 E(Speci\214ed FEC scheme identi\214ed b\=0A= y the tuple, e.g. a pointer to a publicly a)72 558 Q -.275(va)-.22 G=0A= (ilable reference-).275 E=0A= (implementation or the name and contacts of a compan)72 571 Q 2.75(yt)=0A= -.165 G(hat sells it, either separately or embedded)-2.75 E=0A= (in another product.)72 584 Q(Dif)72 610 Q(ferent Under)-.275 E=0A= (-Speci\214ed FEC schemes that share the same FEC Encoding ID -- b)-.22=0A= E(ut ha)-.22 E -.165(ve)-.22 G(dif)72 623 Q=0A= (ferent FEC Encoding Names -- also share the same format of FEC P)-.275=0A= E(ayload ID and specify the)-.165 E=0A= (same information in the FEC Object T)72 636 Q(ransmission Information.)=0A= -.385 E(This speci\214cation reserv)72 662 Q=0A= (es the range 0-127 for the v)-.165 E=0A= (alues of FEC Encoding IDs for Fully-)-.275 E=0A= (Speci\214ed FEC schemes and the range 128-255 for the v)72 675 Q=0A= (alues of Under)-.275 E(-Speci\214ed FEC schemes.)-.22 E(Luby/V)72 769 Q=0A= (icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E 109.106=0A= (wcroft Section)-.275 F 2.75(1.1. [P)2.75 F(age 3])-.165 E EP=0A= %%Page: 4 4=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(1.2.)72=0A= 85 Q/F2 13/Times-Bold@0 SF(FEC P)5.5 E(ayload ID and FEC Object T)-.13 E=0A= (ransmission Inf)-.962 E(ormation)-.325 E F0 2.75(Ad)97 114.6 S=0A= (ocument that speci\214es an FEC scheme and reserv)-2.75 E(es a v)-.165=0A= E(alue of FEC Encoding ID MUST)-.275 E(de\214ne a pack)72 127.6 Q=0A= (et format for the FEC P)-.11 E=0A= (ayload ID and specify the information in the FEC Object)-.165 E -.385=0A= (Tr)72 140.6 S(ansmission Information according to the needs of the enc\=0A= oding scheme. This applies to).385 E(documents that reserv)72 153.6 Q=0A= 2.75(ev)-.165 G=0A= (alues of FEC Encoding IDs for both Fully-Speci\214ed and Under)-3.025 E=0A= (-Speci\214ed)-.22 E(FEC schemes.)72 166.6 Q(The pack)72 192.6 Q=0A= (et format de\214nition for the FEC P)-.11 E=0A= (ayload ID MUST specify the meaning and layout of)-.165 E=0A= (the \214elds do)72 205.6 Q(wn to the le)-.275 E -.165(ve)-.275 G 2.75=0A= (lo).165 G 2.75(fs)-2.75 G(peci\214c bits.)-2.75 E(The FEC P)5.5 E=0A= (ayload ID MUST ha)-.165 E .33 -.165(ve a l)-.22 H(ength that is a).165=0A= E(multiple of a 4-byte w)72 218.6 Q 2.75(ord. This)-.11 F(requirement f)=0A= 2.75 E(acilitates the alignment of pack)-.11 E(et \214elds in protocol)=0A= -.11 E(instantiations.)72 231.6 Q F1(2.)72 270.6 Q/F3 14/Times-Bold@0 SF=0A= (Pr)5.5 E(eassigned FEC Encoding IDs)-.252 E F0=0A= (This section speci\214es the FEC Encoding ID and the associated FEC P)=0A= 72 287.2 Q(ayload ID format and the)-.165 E=0A= (speci\214c information in the FEC Object T)72 300.2 Q=0A= (ransmission Information for a number of kno)-.385 E(wn Under)-.275 E(-)=0A= -.22 E(Speci\214ed FEC schemes.)72 313.2 Q(Under)5.5 E=0A= (-speci\214ed FEC schemes that use the same FEC P)-.22 E=0A= (ayload ID format)-.165 E=0A= (and speci\214c information in the FEC Object T)72 326.2 Q=0A= (ransmission Information as for one of the FEC)-.385 E(Encoding IDs spe\=0A= ci\214ed in this section MUST use the corresponding FEC Encoding ID.)72=0A= 339.2 Q(Other)5.5 E(FEC Encoding IDs may be speci\214ed for other Under)=0A= 72 352.2 Q(-Speci\214ed FEC schemes in companion)-.22 E(documents.)72=0A= 365.2 Q F1(2.1.)72 404.2 Q F2(Small Block, Lar)5.5 E=0A= (ge Block and Expandable FEC Codes)-.13 E F0(This subsection reserv)72=0A= 420.8 Q(es the FEC Encoding ID v)-.165 E(alue 128 for the Under)-.275 E=0A= (-Speci\214ed FEC schemes)-.22 E=0A= (described in [1] that are called Small Block FEC codes, Lar)72 433.8 Q=0A= (ge Block FEC codes and Expandable)-.198 E(FEC codes.)72 446.8 Q=0A= (The FEC P)72 472.8 Q(ayload ID is composed of a Source Block Number an\=0A= d an Encoding Symbol ID)-.165 E(structured as follo)72 485.8 Q(ws:)-.275=0A= E/F4 8/Courier@0 SF 91.2(0123)76.8 524.8 S 4.8=0A= (01234567890123456789012345678901)76.8 537.8 S=0A= (+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)72=0A= 550.8 Q 100.8(|S)72 563.8 S(ource Block Number)-100.8 E(|)110.4 E=0A= (+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)72=0A= 576.8 Q 105.6(|E)72 589.8 S(ncoding Symbol ID)-105.6 E(|)110.4 E=0A= (+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)72=0A= 602.8 Q F0(The Source Block Number iden\214ties from which source block\=0A= of the object the encoding)72 632.4 Q=0A= (symbol\(s\) in the payload are generated.)72 645.4 Q=0A= (These blocks are numbered consecuti)5.5 E -.165(ve)-.275 G=0A= (ly from 0 to N-1,).165 E=0A= (where N is the number of source blocks in the object.)72 658.4 Q(The E\=0A= ncoding Symbol ID identi\214es which speci\214c encoding symbol\(s\) ge\=0A= nerated from the source)72 684.4 Q(block are carried in the pack)72=0A= 697.4 Q(et payload.)-.11 E(The e)5.5 E=0A= (xact details of the correspondence between)-.165 E=0A= (Encoding Symbol IDs and the encoding symbol\(s\) in the pack)72 710.4 Q=0A= (et payload are dependent on the)-.11 E(particular encoding algorithm u\=0A= sed as identi\214ed by the Fec Encoding ID and by the FEC)72 723.4 Q=0A= (Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A= 109.106(wcroft Section)-.275 F 2.75(2.1. [P)2.75 F(age 4])-.165 E EP=0A= %%Page: 5 5=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E=0A= (Encoding Name, and these details may be proprietary)72 85 Q(.)-.715 E=0A= (The FEC Object T)72 111 Q(ransmission Information has the follo)-.385 E=0A= (wing speci\214c information:)-.275 E 11(oT)77.5 140.6 S=0A= (he total length of the object in bytes.)-11 E 11(oT)77.5 157.2 S(he nu\=0A= mber of source blocks that the object is partitioned into, and the leng\=0A= th of each source)-11 E(block in bytes.)94 170.2 Q/F1 11/Times-Bold@0 SF=0A= (2.2.)72 212.8 Q/F2 13/Times-Bold@0 SF(Small Block Systematic FEC Codes)=0A= 5.5 E F0(This subsection reserv)72 229.4 Q(es the FEC Encoding ID v)=0A= -.165 E(alue 129 for the Under)-.275 E(-Speci\214ed FEC schemes)-.22 E=0A= (described in [1] that are called Small Block Systematic FEC codes.)72=0A= 242.4 Q -.165(Fo)5.5 G 2.75(rS).165 G(mall Block Systematic)-2.75 E=0A= (FEC codes, each source block is of length at most 65536 bytes.)72 255.4=0A= Q(Although these codes can generally be accommodated by the FEC Encodin\=0A= g ID described in)72 281.4 Q(Section 2.1, a speci\214c FEC Encoding ID \=0A= is de\214ned for Small Block Systematic FEC codes to)72 294.4 Q(allo)72=0A= 307.4 Q 2.75(wm)-.275 G(ore \215e)-2.75 E(xibility and to retain header\=0A= compactness. The small source block length and small)-.165 E -.165(ex)=0A= 72 320.4 S(apansion f).165 E(actor that often characterize systematic c\=0A= odes may require that the data source)-.11 E=0A= (changes frequently the source block length. T)72 333.4 Q 2.75(oa)-.88 G=0A= (llo)-2.75 E 2.75(wt)-.275 G(he dynamic v)-2.75 E=0A= (ariation of the source block)-.275 E=0A= (length and to communicate it to the recei)72 346.4 Q -.165(ve)-.275 G=0A= (rs with lo).165 E 2.75(wo)-.275 G -.165(ve)-2.915 G=0A= (rhead, the block length is included in).165 E(the FEC P)72 359.4 Q=0A= (ayload ID.)-.165 E(The FEC P)72 385.4 Q=0A= (ayload ID is composed of the Source Block Number)-.165 E 2.75(,S)-.44 G=0A= (ource Block Length and the)-2.75 E(Encoding Symbol ID:)72 398.4 Q/F3 8=0A= /Courier@0 SF 91.2(0123)76.8 437.4 S 4.8=0A= (01234567890123456789012345678901)76.8 450.4 S=0A= (+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)72=0A= 463.4 Q 100.8(|S)72 476.4 S(ource Block Number)-100.8 E(|)110.4 E=0A= (+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)72=0A= 489.4 Q 28.8(|S)72 502.4 S(ource Block Length)-28.8 E 33.6(|E)28.8 G=0A= (ncoding Symbol ID)-33.6 E(|)28.8 E=0A= (+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)72=0A= 515.4 Q F0(The Source Block Number iden\214ties from which source block\=0A= of the object the encoding)72 545 Q=0A= (symbol\(s\) in the payload are generated.)72 558 Q=0A= (These blocks are numbered consecuti)5.5 E -.165(ve)-.275 G=0A= (ly from 0 to N-1,).165 E=0A= (where N is the number of source blocks in the object.)72 571 Q(The Sou\=0A= rce Block Length is the length in units of source symbols of the source\=0A= block identi\214ed)72 597 Q(by the Source Block Number)72 610 Q(.)-.605=0A= E(The Encoding Symbol ID identi\214es which speci\214c encoding symbol\=0A= \(s\) generated from the source)72 636 Q(block are carried in the pack)=0A= 72 649 Q(et payload.)-.11 E(The e)5.5 E=0A= (xact details of the correspondence between)-.165 E=0A= (Encoding Symbol IDs and the encoding symbol\(s\) in the pack)72 662 Q=0A= (et payload are dependent on the)-.11 E(particular encoding algorithm u\=0A= sed as identi\214ed by the Fec Encoding ID and by the FEC)72 675 Q=0A= (Encoding Name, and these details may be proprietary)72 688 Q(.)-.715 E=0A= (The FEC Object T)72 714 Q(ransmission Information has the follo)-.385 E=0A= (wing speci\214c information:)-.275 E(Luby/V)72 769 Q=0A= (icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E 109.106=0A= (wcroft Section)-.275 F 2.75(2.2. [P)2.75 F(age 5])-.165 E EP=0A= %%Page: 6 6=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E 11(oT)77.5 85 S=0A= (he total length of the object in bytes.)-11 E 11(oT)77.5 101.6 S(he ma\=0A= ximum length in bytes of the encoding symbols that can be generated for\=0A= an)-11 E 2.75(ys)-.165 G(ource)-2.75 E 2.75(block. This)94 114.6 R=0A= (\214eld is pro)2.75 E(vided to allo)-.165 E 2.75(wr)-.275 G(ecei)-2.75=0A= E -.165(ve)-.275 G(rs to preallocate b).165 E(uf)-.22 E=0A= (fer space that is suitable for)-.275 E(decoding to reco)94 127.6 Q=0A= -.165(ve)-.165 G 2.75(ra).165 G .33 -.165(ny s)-2.75 H(ource block.).165=0A= E 11(oT)77.5 144.2 S(he length in bytes of a source symbol.)-11 E/F1 11=0A= /Times-Bold@0 SF(3.)72 186.8 Q/F2 14/Times-Bold@0 SF(IAN)5.5 E 3.5(AC)=0A= -.28 G(onsiderations)-3.5 E F0 -1.221(Va)72 203.4 S=0A= (lues of FEC Encoding IDs and FEC Encoding Names are subject to IAN)=0A= 1.221 E 2.75(Ar)-.385 G -.165(eg)-2.75 G(istration. FEC).165 E(Encoding\=0A= IDs and FEC Encoding Names are hierarchical: FEC Encoding IDs scope ra\=0A= nges of)72 216.4 Q(FEC Encoding Names.)72 229.4 Q=0A= (Only FEC Encoding IDs that correspond to Under)5.5 E(-Speci\214ed FEC)=0A= -.22 E(schemes scope a corresponding set of FEC Encoding Names.)72 242.4=0A= Q(The FEC Encoding ID is a numeric non-ne)72 268.4 Q -.055(ga)-.165 G=0A= (ti).055 E .33 -.165(ve i)-.275 H(nde).165 E=0A= (x. In this document, the range of v)-.165 E(alues for)-.275 E=0A= (FEC Encoding IDs is 0 and 255.)72 281.4 Q -1.221(Va)5.5 G=0A= (lues from 0 to 127 are reserv)1.221 E(ed for Fully-Speci\214ed FEC)=0A= -.165 E(schemes, as described in more detail in Section 1.1. The assign\=0A= ment of a FEC Encoding ID in this)72 294.4 Q=0A= (range can only be granted if the requestor can pro)72 307.4 Q=0A= (vide such a speci\214cation published as an IETF)-.165 E=0A= (RFC, as described in more detail in Section 1.1. V)72 320.4 Q=0A= (alues from 128 to 255 are reserv)-1.221 E(ed for Under)-.165 E(-)-.22 E=0A= (Speci\214ed FEC schemes, as described in more detail in Section 1.1. T\=0A= his speci\214cation already)72 333.4 Q(assigns the v)72 346.4 Q=0A= (alues 128 and 129, as described in Section 2.)-.275 E -1.221(Va)72 363=0A= S(lues of FEC Encoding IDs can only be assigned if the required format \=0A= for the FEC P)1.221 E(ayload ID)-.165 E=0A= (and the speci\214c information in the FEC Object T)72 376 Q=0A= (ransmission Information are speci\214ed in an IETF)-.385 E(RFC.)72 389=0A= Q(Each FEC Encoding ID assigned to an Under)72 415 Q=0A= (-Speci\214ed FEC scheme scopes an independent range)-.22 E=0A= (of FEC Encoding Names \(i.e. the same v)72 428 Q=0A= (alue of FEC Encoding Name can be reused for dif)-.275 E(ferent)-.275 E=0A= (FEC Encoding IDs\). An FEC Encoding Name is a numeric non-ne)72 441 Q=0A= -.055(ga)-.165 G(ti).055 E .33 -.165(ve i)-.275 H(nde).165 E(x.)-.165 E=0A= (Under the scope of a FEC Encoding ID, FEC Encoding Names are assigned \=0A= on a First Come First)72 467 Q(Serv)72 480 Q=0A= (ed base to requestors that are able to pro)-.165 E=0A= (vide point of contact information and a pointer to)-.165 E=0A= (publicly accessible documentation describing the Under)72 493 Q=0A= (-Speci\214ed FEC scheme and w)-.22 E(ays to)-.11 E=0A= (obtain it \(e.g. a pointer to a publicly a)72 506 Q -.275(va)-.22 G=0A= (ilable reference-implementation or the name and contacts).275 E=0A= (of a compan)72 519 Q 2.75(yt)-.165 G(hat sells it, either separately o\=0A= r embedded in another product\). The requestor is)-2.75 E=0A= (responsible for k)72 532 Q(eeping this information up to date.)-.11 E=0A= F1(4.)72 571 Q F2(Ackno)5.5 E(wledgments)-.14 E F0=0A= (Brian Adamson contrib)72 587.6 Q=0A= (uted to this document by shaping Section 2.2 and pro)-.22 E=0A= (viding general)-.165 E(feedback. W)72 600.6 Q 2.75(ea)-.88 G=0A= (lso wish to thank V)-2.75 E(incent Roca and Justin Chapwesk)-.66 E 2.75=0A= (ef)-.11 G(or their comments.)-2.75 E F1(5.)72 639.6 Q F2(Refer)5.5 E=0A= (ences)-.252 E F0([1] Luby)72 669.2 Q 2.75(,M)-.715 G(., V)-2.75 E=0A= (icisano, Gemmell, J., L., Rizzo, L., Handle)-.66 E 1.43 -.715(y, M)=0A= -.165 H 2.75(., Cro).715 F(wcroft, J., "The use of)-.275 E -.165(Fo)72=0A= 682.2 S(rw).165 E(ard Error Correction in Reliable Multicast", Internet\=0A= draft draft-ietf-rmt-info-fec-01.txt,)-.11 E(October 2001.)72 695.2 Q=0A= (Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A= 117.356(wcroft Section)-.275 F 2.75(5. [P)2.75 F(age 6])-.165 E EP=0A= %%Page: 7 7=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(6.)72 85=0A= Q/F2 14/Times-Bold@0 SF -.7(Au)5.5 G(thors' Addr).7 E(esses)-.252 E F0=0A= (Michael Luby)80.25 101.6 Q(luby@digitalfountain.com)80.25 114.6 Q=0A= (Digital F)80.25 127.6 Q(ountain, Inc.)-.165 E(39141 Ci)80.25 140.6 Q=0A= (vic Center Dri)-.275 E -.165(ve)-.275 G(Suite 300)80.25 153.6 Q=0A= (Fremont, CA)80.25 166.6 Q(94538)5.5 E(Lorenzo V)80.25 192.6 Q(icisano)=0A= -.66 E(lorenzo@cisco.com)80.25 205.6 Q(cisco Systems, Inc.)80.25 218.6 Q=0A= (170 W)80.25 231.6 Q(est T)-.88 E(asman Dr)-.88 E(.,)-.605 E=0A= (San Jose, CA, USA, 95134)80.25 244.6 Q(Jim Gemmell)80.25 270.6 Q=0A= (jgemmell@microsoft.com)80.25 283.6 Q(Microsoft Research)80.25 296.6 Q=0A= (301 Ho)80.25 309.6 Q -.11(wa)-.275 G(rd St., #830).11 E=0A= (San Francisco, CA, USA, 94105)80.25 322.6 Q(Luigi Rizzo)80.25 348.6 Q=0A= (luigi@iet.unipi.it)80.25 361.6 Q -.44(AC)80.25 374.6 S=0A= (IRI, 1947 Center St., Berk).44 E(ele)-.11 E 2.75(yC)-.165 G 2.75(A9)=0A= -2.75 G(4704)-2.75 E(and)80.25 387.6 Q(Dip. di Ing. dell'Informazione)=0A= 80.25 400.6 Q(Uni)80.25 413.6 Q -.165(ve)-.275 G(rsita` di Pisa).165 E=0A= (via Diotisalvi 2, 56126 Pisa, Italy)80.25 426.6 Q(Mark Handle)80.25=0A= 452.6 Q(y)-.165 E(mjh@aciri.or)80.25 465.6 Q(g)-.198 E -.44(AC)80.25=0A= 478.6 S(IRI).44 E(1947 Center St.)80.25 491.6 Q(Berk)80.25 504.6 Q(ele)=0A= -.11 E 2.75(yC)-.165 G(A, USA, 94704)-2.75 E(Jon Cro)80.25 530.6 Q=0A= (wcroft)-.275 E(J.Cro)80.25 543.6 Q(wcroft@cs.ucl.ac.uk)-.275 E=0A= (Department of Computer Science)80.25 556.6 Q(Uni)80.25 569.6 Q -.165=0A= (ve)-.275 G(rsity Colle).165 E(ge London)-.165 E(Go)80.25 582.6 Q=0A= (wer Street,)-.275 E(London WC1E 6BT)80.25 595.6 Q 2.75(,U)-.814 G(K)=0A= -2.75 E(Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165=0A= E 117.356(wcroft Section)-.275 F 2.75(6. [P)2.75 F(age 7])-.165 E EP=0A= %%Page: 8 8=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(7.)72 85=0A= Q/F2 14/Times-Bold@0 SF(Full Copyright Statement)5.5 E F0(Cop)72 101.6 Q=0A= (yright \(C\) The Internet Society \(2001\).)-.11 E(All Rights Reserv)=0A= 5.5 E(ed.)-.165 E(This document and translations of it may be copied an\=0A= d furnished to others, and deri)72 118.2 Q -.275(va)-.275 G(ti).275 E=0A= .33 -.165(ve w)-.275 H(orks).055 E(that comment on or otherwise e)72=0A= 131.2 Q=0A= (xplain it or assist in its implementation may be prepared, copied,)=0A= -.165 E(published and distrib)72 144.2 Q=0A= (uted, in whole or in part, without restriction of an)-.22 E 2.75(yk)=0A= -.165 G(ind, pro)-2.75 E(vided that the)-.165 E(abo)72 157.2 Q .33 -.165=0A= (ve c)-.165 H(op).165 E(yright notice and this paragraph are included o\=0A= n all such copies and deri)-.11 E -.275(va)-.275 G(ti).275 E .33 -.165=0A= (ve w)-.275 H(orks.).055 E(Ho)72 170.2 Q(we)-.275 E -.165(ve)-.275 G .88=0A= -.44(r, t).165 H(his document itself may not be modi\214ed in an).44 E=0A= 2.75(yw)-.165 G(ay)-2.86 E 2.75(,s)-.715 G(uch as by remo)-2.75 E=0A= (ving the)-.165 E(cop)72 183.2 Q(yright notice or references to the Int\=0A= ernet Society or other Internet or)-.11 E -.055(ga)-.198 G(nizations, e)=0A= .055 E(xcept as)-.165 E(needed for the purpose of de)72 196.2 Q -.165=0A= (ve)-.275 G(loping Internet standards in which case the procedures for)=0A= .165 E(cop)72 209.2 Q=0A= (yrights de\214ned in the Internet languages other than English.)-.11 E=0A= (The limited permissions granted abo)72 225.8 Q .33 -.165(ve a)-.165 H=0A= (re perpetual and will not be re).165 E -.22(vo)-.275 G -.11(ke).22 G=0A= 2.75(db).11 G 2.75(yt)-2.75 G(he Internet)-2.75 E=0A= (Society or its successors or assigns.)72 238.8 Q=0A= (This document and the information contained herein is pro)72 255.4 Q=0A= (vided on an "AS IS" basis and THE)-.165 E=0A= (INTERNET SOCIETY AND THE INTERNET ENGINEERING T)72 268.4 Q=0A= (ASK FORCE DISCLAIMS)-1.023 E(ALL W)72 281.4 Q=0A= (ARRANTIES, EXPRESS OR IMPLIED, INCLUDING B)-1.32 E(UT NO)-.11 E 2.75=0A= (TL)-.44 G(IMITED T)-2.75 E 2.75(OA)-.198 G(NY)-2.75 E -1.32(WA)72 294.4=0A= S(RRANTY THA)1.32 E 2.75(TT)-1.221 G(HE USE OF THE INFORMA)-2.75 E=0A= (TION HEREIN WILL NO)-1.221 E 2.75(TI)-.44 G(NFRINGE)-2.75 E=0A= (ANY RIGHTS OR ANY IMPLIED W)72 307.4 Q(ARRANTIES OF MERCHANT)-1.32 E=0A= (ABILITY OR FITNESS)-1.023 E(FOR A P)72 320.4 Q(AR)-1.012 E=0A= (TICULAR PURPOSE.")-.66 E(Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)=0A= -.66 E(y/Cro)-.165 E 117.356(wcroft Section)-.275 F 2.75(7. [P)2.75 F=0A= (age 8])-.165 E EP=0A= %%Page: 9 9=0A= %%BeginPageSetup=0A= BP=0A= %%EndPageSetup=0A= /F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A= (April 2002)2.75 E(October 2001)112.127 E(Luby/V)72 769 Q=0A= (icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E 117.356=0A= (wcroft Section)-.275 F 2.75(7. [P)2.75 F(age 9])-.165 E EP=0A= %%Trailer=0A= end=0A= %%EOF=0A= ------=_NextPart_000_000F_01C157E1.43555B10-- >From owner-rmt@listserv.lbl.gov Thu Oct 18 16:13:04 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9IN8uY10816; Thu, 18 Oct 2001 16:08: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.11.2/8.11.2) with ESMTP id f9IN8sp10812 for ; Thu, 18 Oct 2001 16:08:54 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9IN8sB25440 for ; Thu, 18 Oct 2001 16:08:54 -0700 (PDT) Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9IN8rb25434 for ; Thu, 18 Oct 2001 16:08:53 -0700 (PDT) Received: (qmail 24867 invoked from network); 18 Oct 2001 23:08:47 -0000 Received: from mail.intranet (10.1.1.37) by mx.digitalfountain.com with SMTP; 18 Oct 2001 23:08:47 -0000 Received: from magnemite (dhcp-10-1-2-226.intranet [10.1.2.226]) by mail.intranet (8.9.3/8.9.3) with SMTP id QAA06749; Thu, 18 Oct 2001 16:08:21 -0700 X-Authentication-Warning: mail.intranet: Host dhcp-10-1-2-226.intranet [10.1.2.226] claimed to be magnemite From: "Michael Luby" To: "Rmt@Lbl. Gov" Cc: "Michael Luby" Subject: IETF drafts FEC INFO 01, LCT BB 02, ALC PI 03, FEC BB 04 Date: Thu, 18 Oct 2001 16:12:35 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-rmt@lbl.gov Precedence: bulk RMTers, Being new to the game, I obviously didn't follow the procedure that was meant to happen (see email below). The last call for these 4 drafts will be in two weeks, ending Thursday, November 1, after which we intend to submit the drafts as Experimental RFCs. Sorry about the confusion. Mike -----Original Message----- From: Lorenzo Vicisano [mailto:lorenzo@cisco.com] Sent: Thursday, October 18, 2001 3:52 PM To: luby@digitalfountain.com Cc: lorenzo@cisco.com Subject: WG last call ? Hi Mike, my intention was to post the drafts to the list, leave 'till monday for people to comment, and if there were no comments, post the drafts to the IETF directory and call "last call". doing the first 2 steps at the same time (post to the list and to the IETF) is fine (in the worst case we will have to resubmit). But the last call implies allowing two weeks for people to comment before submitting as an RFC.. now this collides with the deadline of Monday that you have specified.. could you please clarify this to the rmt list (no need to send to internet-drafts) saying that the last-call is 2 weeks (ending Nov 1st) after which we intend to submit the drafts as Experimental RFC. thanks, Lorenzo >From owner-rmt@listserv.lbl.gov Thu Oct 18 18:46:12 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9J1eUk16201; Thu, 18 Oct 2001 18:40: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.11.2/8.11.2) with ESMTP id f9J1eTp16197 for ; Thu, 18 Oct 2001 18:40:29 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9J1eSp09223 for ; Thu, 18 Oct 2001 18:40:28 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9J1eRW09206 for ; Thu, 18 Oct 2001 18:40:27 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id SAA09418; Thu, 18 Oct 2001 18:40:24 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id SAA01734; Thu, 18 Oct 2001 18:40:22 -0700 (MST)] Received: from arc.corp.mot.com (marcia.arc.corp.mot.com [10.238.80.74]) by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id f9J1eKX14599; Fri, 19 Oct 2001 11:40:20 +1000 (EST) Message-ID: <3BCF847D.4F60F316@arc.corp.mot.com> Date: Fri, 19 Oct 2001 11:40:13 +1000 From: Roger Kermode Organization: Motorola X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list@iet.org, rmt-list Subject: RMT Changes.. new email list, new web site Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Dear Everyone, As part of the ongoing efforts to help manage the ietf lists the rmt list is changing from rmt-list@lbl.gov to rmt-list@ietf.org All current members of the lbl.gov list have been subscribed to the new ietf list and the archive will be moving there shortly as well. Please use the new list for all future emails To help us move forward I've also put together a web site for rmt that supplements the ietf one. On it you will find more details about where we are with drafts beyond that of their existence or expiration. the new site can be found at http://rmt.motlabs.com cheers, Roger >From owner-rmt@listserv.lbl.gov Thu Oct 18 18:55:38 2001 Received: (from majordom@localhost) by listserv.lbl.gov (8.11.2/8.11.2) id f9J1qCo16251; Thu, 18 Oct 2001 18:52: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.11.2/8.11.2) with ESMTP id f9J1qBp16247 for ; Thu, 18 Oct 2001 18:52:11 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9J1qAB15585 for ; Thu, 18 Oct 2001 18:52:10 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9J1q9W15576 for ; Thu, 18 Oct 2001 18:52:09 -0700 (PDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id SAA25894 for ; Thu, 18 Oct 2001 18:52:08 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id SAA18238 for ; Thu, 18 Oct 2001 18:52:07 -0700 (MST)] Received: from arc.corp.mot.com (marcia.arc.corp.mot.com [10.238.80.74]) by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id f9J1q5X15687; Fri, 19 Oct 2001 11:52:05 +1000 (EST) Message-ID: <3BCF873D.81DDD7AB@arc.corp.mot.com> Date: Fri, 19 Oct 2001 11:51:57 +1000 From: Roger Kermode Organization: Motorola X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt@lbl.gov, rmt@ietf.org Subject: CORRECTION: Changes...new email list, new web site Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Dear Everyone, As part of the ongoing efforts to help manage the ietf lists the rmt list is changing from rmt@lbl.gov to rmt@ietf.org All current members of the lbl.gov list have been subscribed to the new ietf.org list and the archive will be moving there shortly as well. Please use the new list for all future emails To help us move forward I've also put together a web site for rmt that supplements the ietf one. On it you will find more details about where we are with drafts beyond that of their existence or expiration. the new site can be found at http://rmt.motlabs.com cheers, Roger