From owner-rmt@listserv.lbl.gov Tue Jul 11 08:24:06 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27646 for ; Tue, 11 Jul 2000 08:24:05 -0400 (EDT) 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-Disposition: inline; filename="draft-ietf-rmt-author-guidelines-00.txt" Content-Transfer-Encoding: 7bit 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-Description: Card for Roger Kermode Content-Disposition: attachment; filename="rkermode.vcf" Content-Transfer-Encoding: 7bit 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 05:38:59 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14434 for ; Wed, 12 Jul 2000 05:38:58 -0400 (EDT) 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 07:35:42 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17002 for ; Wed, 12 Jul 2000 07:35:42 -0400 (EDT) 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 12:29:30 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01028 for ; Wed, 12 Jul 2000 12:29:29 -0400 (EDT) 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 Content-Transfer-Encoding: 8bit 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 15:47:00 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11087 for ; Wed, 12 Jul 2000 15:47:00 -0400 (EDT) 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 Content-Transfer-Encoding: 8bit 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 20:59:30 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19394 for ; Wed, 12 Jul 2000 20:59:30 -0400 (EDT) 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 Content-Transfer-Encoding: 7bit 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 21:13:53 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19664 for ; Wed, 12 Jul 2000 21:13:52 -0400 (EDT) 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 21:25:38 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20194 for ; Thu, 13 Jul 2000 21:25:36 -0400 (EDT) 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 Sat Jul 15 03:18:50 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14906 for ; Sat, 15 Jul 2000 03:18:49 -0400 (EDT) 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 08:03:43 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20662 for ; Mon, 17 Jul 2000 08:03:43 -0400 (EDT) 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 11:01:00 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16421 for ; Mon, 17 Jul 2000 11:00:59 -0400 (EDT) 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 14:30:05 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09346 for ; Mon, 17 Jul 2000 14:30:04 -0400 (EDT) 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 Content-Transfer-Encoding: 7bit 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 07:13:14 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27668 for ; Tue, 18 Jul 2000 07:13:13 -0400 (EDT) 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 07:23:59 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02126 for ; Tue, 18 Jul 2000 07:23:59 -0400 (EDT) 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 15:28:47 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03594 for ; Tue, 18 Jul 2000 15:28:47 -0400 (EDT) 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 Tue Jul 18 15:29:50 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04201 for ; Tue, 18 Jul 2000 15:29:49 -0400 (EDT) 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 Wed Jul 19 07:33:12 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14673 for ; Wed, 19 Jul 2000 07:33:11 -0400 (EDT) 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 07:43:48 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12989 for ; Thu, 20 Jul 2000 07:43:47 -0400 (EDT) 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 12:09:04 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01428 for ; Thu, 20 Jul 2000 12:09:04 -0400 (EDT) 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 03:43:21 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21675 for ; Fri, 21 Jul 2000 03:43:21 -0400 (EDT) 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 20:20:30 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25927 for ; Sun, 23 Jul 2000 20:20:30 -0400 (EDT) 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 07:26:56 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24136 for ; Mon, 24 Jul 2000 07:26:55 -0400 (EDT) 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 07:30:45 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25406 for ; Mon, 24 Jul 2000 07:30:44 -0400 (EDT) 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 10:10:42 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02655 for ; Mon, 24 Jul 2000 10:10:42 -0400 (EDT) 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 12:29:33 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13311 for ; Mon, 24 Jul 2000 12:29:33 -0400 (EDT) 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 14:57:02 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16171 for ; Wed, 26 Jul 2000 14:57:00 -0400 (EDT) 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 14:56:28 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24628 for ; Mon, 31 Jul 2000 14:56:27 -0400 (EDT) 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 16:37:49 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12745 for ; Mon, 31 Jul 2000 16:37:48 -0400 (EDT) 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 Content-Transfer-Encoding: 7bit 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