Internet Engineering Task Force RMT WG INTERNET-DRAFT M.Luby/Digital Fountain draft-ietf-rmt-pi-alc-02.txt J.Gemmell/Microsoft L.Vicisano/Cisco L.Rizzo/ACIRI and Univ. Pisa J. Crowcroft/UCL 20 July 2001 Expires: January 2002 Asynchronous Layered Coding: A massively scalable reliably content delivery protocol Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are valid for a maximum of six months and MAY be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as a "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This document is a product of the IETF RMT WG. Comments should be addressed to the authors, or the WG's mailing list at rmt@lbl.gov. Abstract This document describes the Asynchronous Layered Coding protocol, a massively scalable reliable content delivery protocol, hereafter referred to as ALC. ALC can be used for Luby/Gemmell/Vicisano/Rizzo/Crowcroft [Page 1]
INTERNET-DRAFT Expires: January 2002 July 2001 multi-rate reliable delivery of content to large sets of receivers. ALC uses the LCT transport described in [3] augmented with a congestion control protocol that is compliant with RFC2387 such as one of the layered congestion control protocols described [4]. ALC achieves reliability based on FEC codecs as generally described in [1], and in particular based on the details provided in the FEC building block described in [2]. Luby/Gemmell/Vicisano/Rizzo/Crowcroft [Page 2]
INTERNET-DRAFT Expires: January 2002 July 2001 Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 1.1. Related Documents. . . . . . . . . . . . . . . . . . 5 1.2. Environmental Requirements and Considerations. . . . 5 2. General Architecture. . . . . . . . . . . . . . . . . . 6 2.1. Delivery service models. . . . . . . . . . . . . . . 6 2.2. Congestion Control . . . . . . . . . . . . . . . . . 7 3. Type of packets used by the ALC protocol. . . . . . . . 7 3.1. Packet format for the ALC protocol . . . . . . . . . 8 3.2. Packet header fields for the ALC protocol. . . . . . 8 4. Procedures. . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Sender Operation . . . . . . . . . . . . . . . . . . 9 4.2. Receiver Operation . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . 10 7. Intellectual Property Issues. . . . . . . . . . . . . . 10 8. Authors' Addresses. . . . . . . . . . . . . . . . . . . 11 9. Full Copyright Statement. . . . . . . . . . . . . . . . 13 Luby/Gemmell/Vicisano/Rizzo/Crowcroft [Page 3]
INTERNET-DRAFT Expires: January 2002 July 2001 1. Introduction This document describes a massively scalable reliable content delivery protocol, Asynchronous Layered Coding (ALC), for multi-rate reliable content delivery. ALC is a protocol instantiation as defined in RFC3048. ALC uses the LCT transport [3]. Thus, like the LCT transport, the ALC protocol is primarily designed to be used with the IP multicast network service, but MAY also be used with other basic underlying network or transport services such as unicast UDP. ALC uses FEC codes to provide reliability as generally described in [1], i.e. all packets in a session contain FEC coded information in formats that are compliant with the FEC building block described in [2]. A crucial point is that ALC strongly relies on FEC codecs in the sense that there is no request for retransmission of individual packets from receivers that miss packets in order to assure reliable reception of an object, and the packets and their rate of transmission out of the sender can be independent of the number and the individual reception experiences of the receivers. In some delivery service models it is appropriate that receivers send out of band messages to the sender to provide guaranteed delivery of content. For example, in a push reliable delivery model receivers may send messages to a sender to continue the session if receivers have not yet received enough packets to recover the content or to terminate the session when receivers have received enough packets to recover the content. To be able to track usage of the system, receivers may 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 basic ALC protocol. The LCT transport provides support for congestion control, and the ALC protocol uses this support. The congestion control protocol must conform with RFC 2357. It is recommended that the congestion control protocol used for ALC be a multi-rate protocol, as described in [4]. In this case, a sender sends packets in the session to several LCT channels at potentially different rates. Then, individual receivers can adjust their reception rate within a session by adjusting which set of LCT channels they are joined to at each point in time depending on the available bandwidth between the receiver and the sender, but independent of other receivers. A single rate congestion control protocol can also be used, but this may limit the scalability of the session in terms of the number of receivers that can concurrently participate. Receiver may join and leave a session asynchronously at their discretion. An ALC packet thus consists of an LCT packet header, an FEC packet header, optional by additional parameters and packet payload. Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 1. [Page 4]
INTERNET-DRAFT Expires: January 2002 July 2001 ALC has the following properties when the LCT transport uses multicast to deliver packets: o To each receiver, it appears as if though there is a dedicated session from the sender to the receiver, where the reception rate adjusts to congestion along the path from sender to receiver. 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. 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. Thus, ALC provides a massively scalable content delivery system that is network friendly. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. 1.1. Related Documents The LCT transport that ALC MUST use is described in [3]. A more in- depth description of the use of FEC codecs in reliable content delivery protocols is given in [1]. All packets in a session MUST contain FEC coded information in formats that are compliant with the FEC building block described in [2]. Implementors of ALC MUST also implement a congestion control protocol in accordance to RFC2357, where the congestion control is over the entire session. Some possible schemes are specified in [4]. Congestion control MUST be integrated into ALC through the support provided in the LCT transport. It is RECOMMENDED that ALC implementors use some authentication scheme to protect the protocol from attacks. An example of a possibly suitable scheme is described in [5]. Authentication in ALC, if used, is to be integrated through the support provided in the LCT transport. 1.2. Environmental Requirements and Considerations ALC is intended for congestion controlled, multi-rate delivery of objects, i.e., reliable content delivery. Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 1.2. [Page 5]
INTERNET-DRAFT Expires: January 2002 July 2001 All of the environmental requirements and considerations that apply to the LCT transport and to the FEC building block also apply to ALC. 2. General Architecture ALC protocol consists basically of using FEC codecs in the form described in [2] with the LCT transport as described in [3]. Thus, the terminology used in the description of the LCT transport and the FEC building block are inherited by the ALC protocol and this terminology is used below. In particular, the definition of a session for the ALC protocol is the same as it is for the LCT transport. Packets used within the ALC protocol are specialized versions of LCT packets. In particular, a packet consists of an LCT packet header, an FEC payload ID, optional additional parameters as appropriate, and the packet payload. From the point of view of the LCT transport, the FEC payload ID, the additional parameters if present, and the packet payload are all part of the LCT packet payload. The out of band information used by the ALC protocol consists of the out of band all information required for both the LCT transport and for the FEC building block. The possible means for acquiring this out of band information is the same as for the LCT transport and the FEC building block, and in particular is outside the scope of the ALC protocol. Congestion control for the ALC protocol MUST conform to RFC 2387, and MUST be provided through the mechanisms provided by the LCT transport. Although it is not mandatory, ALC is most scalable when multi-rate congestion control is used that does not require feedback from receivers to the sender, and thus use of a mult-rate congestion control as described in [4] is RECOMMENDED. 2.1. Delivery service models ALC can support several different delivery service models. Two examples are briefly described here. Push service model. One way a push service model can be used for reliable content delivery is to deliver a series of objects. For example, a receiver could join the session and dynamically adapt the number of LCT channels the receiver is joined to until enough packets have been received to reconstruct an object. After reconstructing the object the receiver may stay in the session and wait for the transmission of the next object. Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 2.1. [Page 6]
INTERNET-DRAFT Expires: January 2002 July 2001 The push model is particularly attractive in satellite networks and wireless networks. In these cases, a session may consist of one fixed rate LCT channel. On-demand content delivery model. For an on-demand content delivery service model, senders typically transmit for some given time period selected to be long enough to allow all the intended receivers to join the session and recover a single object. For example a popular software update might be transmitted 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. In this case the receivers join the session at any point in time when it is active and dynamically adapt the number of LCT channels they subscribe to according to the available bandwidth using a multi-rate congestion control protocol. Receivers leave the session when they have received enough packets to recover the object. Other service models. There may be other delivery service models that can be supported by ALC. The description of the potential applications, the appropriate delivery service model, and the additional mechanisms to support such functionalities when combined with ALC is beyond the scope of this document. 2.2. Congestion Control The specific congestion control protocol to be used for ALC sessions should be suitable for reliable content delivery. While the general behavior of the congestion control protocol is to reduce the throughput in presence of congestion and gradually increase it in the absence of congestion, the actual dynamic behavior (e.g. response to single losses) can vary. Some possible multi-rate congestion control protocols for reliable content delivery using LCT are described in [4]. 3. Type of packets used by the ALC protocol The type of packet used by the ALC protocol is a specialized version of an LCT packet. LCT packets are sent by senders to LCT channels. Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 3. [Page 7]
INTERNET-DRAFT Expires: January 2002 July 2001 Some instances of sessions MAY require the generation of feedback from the receivers to the sender. However, the mechanism for doing this is outside the scope of ALC. 3.1. Packet format for the ALC protocol The packet format used for ALC protocol is depicted in Figure 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LCT packet header | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | FEC Payload ID | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Additional parameters | | (optional) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Payload | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 - Packet format for ALC protocol 3.2. Packet header fields for the ALC protocol The description of the fields and their functions within the LCT packet header can be found in [3]. The information that needs to be communicated out of band for the LCT transport and the possible mechanisms for achieving this are described in [3]. The description of the fields and their functions within the FEC payload ID can be found in [2], with the exception that the FEC Encoding Flag value, if applicable, MAY be communicated via the value of the Codepoint field within LCT packet header. The information that needs to be communicated out of band for the FEC codecs and the possible mechanisms for achieving this are described in [2]. The mechanisms for communicating the out of band information needed for the LCT transport, including the mapping between the Codepoint field values in the LCT packet header and the interpretations of the values, MAY be the same as those used for communicating the out of band information needed for the Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 3.2. [Page 8]
INTERNET-DRAFT Expires: January 2002 July 2001 FEC building block, with the exception that portions of the information needed for FEC building blocks may be communicated either through the use of the Codepoint field in the LCT packet header, or through the Additional Parameters fields that follow the FEC payload ID. The fields and formats of the optional Additional Parameters fields MUST be communicated to the receivers out of band. The particular Additional Parameters fields that may appear in packets MUST be communicated out of band. The specification of which Additional Parameters fields that appear in a packet MUST be communicated via the value of the Codepoint field in the LCT packet header, and the mapping between Codepoint field values and the Additional Parameters fields that appear in a packet MUST be communicated out of band. It is RECOMMENDED that the format of any Additonal Parameters fields adhere to the format of Header-Extension Fields defined for the LCT transport in [3]. 4. Procedures 4.1. Sender Operation The sender operation when using the ALC protocol includes all the points made about the sender operation when using the LCT transport as described in [3], and the FEC building block as described in [2]. The following description highlights some of the additional considerations to be taken into account with respect to the ALC protocol. Before a session starts, a sender using the ALC protocol MUST make available all applicable information regarding the session. This information includes: o Any information needed by the LCT transport; o The congestion control protocol being used within the LCT transport; o The mapping between values of the Codepoint field in the LCT packet header and interpretations of these values; o Any information needed for the FEC building block; o If used, the authentication scheme being used within the LCT transport, and all relevant information which is necessary for sender authentication purposes; Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 4.1. [Page 9]
INTERNET-DRAFT Expires: January 2002 July 2001 4.2. Receiver Operation The receiver operation when using the ALC protocol includes all the points made about the receiver operation that pertain to reliable content delivery when using the LCT transport as described in [3], and that pertain to using the FEC building block as described in [2]. The following description highlights some of the additional considerations to be taken into account with respect to the ALC protocol. When a receiver receives a packet, the receiver MUST process the LCT packet header (excluding the Codepoint field) as described in [3] before processing any other fields of the packet. 5. Security Considerations The same security consideration that apply to the LCT transport and to the FEC building block also apply to the ALC protocol. In addition, any security considerations that apply to the congestion control protocol used by the ALC protocol within the LCT transport also apply. 6. IANA Considerations No information in this specification is directly subject to IANA registration. However, building blocks components used by the ALC protcol may introduce additional IANA considerations. In particular, the FEC building block used by the ALC protocol does require IANA registration of the FEC codecs used. 7. Intellectual Property Issues No specific reliability protocol or congestion control protocol is specified or referenced as mandatory in this document. ALC MAY be used with congestion control protocols and other protocols which are proprietary, or have pending or granted patents. [1] Luby, M., Gemmell, Vicisano, L., J., Rizzo, L., Handley, M., Crowcroft, J., "The use of Forward Error Correction in Reliable Multicast", Internet Draft draft-ietf-rmt-info-fec-00.txt, November 2000, a work in progress. [2] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M., Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 7. [Page 10]
INTERNET-DRAFT Expires: January 2002 July 2001 Crowcroft, J., "RMT BB Forward Error Correction Codes", Internet Draft draft-ietf-rmt-bb-fec-03.txt, July 2001. [3] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M., Crowcroft, J., "Layered Coding Transport: A massively scalable content delivery transport", Internet Draft draft-ietf-rmt-bb-lct-01.txt, July 2001. [4] Luby, M., Vicisano, L., Haken, A., "RMT BB Layered congestion control", draft-ietf-rmt-bb-lcc-00.txt, November 2000, a work in progress. [5] Perrig, A., Canetti, R., Briscoe, B., Tygar, D., Song, D., "TESLA: Multicast Source Authentication Transform", draft-irtf-smug- tesla-00.txt, November, 2000, a work in progress. 8. Authors' Addresses Michael Luby luby@digitalfountain.com Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA, USA, 94538 Jim Gemmell jgemmell@microsoft.com Microsoft Research 301 Howard St., #830 San Francisco, CA, USA, 94105 Lorenzo Vicisano lorenzo@cisco.com cisco Systems, Inc. 170 West Tasman Dr., San Jose, CA, USA, 95134 Luigi Rizzo luigi@iet.unipi.it Dip. Ing. dell'Informazione, Univ. di Pisa via Diotisalvi 2, 56126 Pisa, Italy Jon Crowcroft J.Crowcroft@cs.ucl.ac.uk Department of Computer Science Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 8. [Page 11]
INTERNET-DRAFT Expires: January 2002 July 2001 University College London Gower Street, London WC1E 6BT, UK Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 8. [Page 12]
INTERNET-DRAFT Expires: January 2002 July 2001 9. 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 Section 9. [Page 13]
INTERNET-DRAFT Expires: January 2002 July 2001 Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 9. [Page 14]
