RMT Working Group B. Adamson/Newlink INTERNET-DRAFT C. Bormann/Tellique draft-ietf-rmt-pi-norm-00.txt S. Floyd/ACIRI Expires: May 2001 M. Handley/ACIRI J. Macker/NRL November 2000 NACK-Oriented Reliable Multicast Protocol (NORM) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other docu- ments at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This document describes the messages and procedures of the Nega- tive-acknowledgement (NACK) oriented reliable multicast (NORM). This revision of the document represents an initial outline of the protocol description. The document requires refinement in a number of areas to be considered complete. At this time, the document describes the high level details of the reliable multicast bulk transfer service model this protocol hopes to fulfill and the gen- eral message types and mechanisms which will be used to accomplish those goals. Adamson, Borman, et al. Expires May 2001 [Page 1]
Internet Draft NORM Protocol November 2000 1.0 Protocol Design Goals NORM is designed to provide end-to-end reliable transport of data from sender(s) to a group of receivers over a multicast-capable network. The primary design goal of NORM is to provide for effi- cient, scalable, and robust bulk data (e.g. computer files, trans- mission of persistent data) transfer adaptable (preferably in an automated fashion) across heterogeneous networks and topologies. The protocol is capable of operating in an end-to-end fashion with no assistance from intermediate systems beyond basic IP multicast group management and forwarding services. However, an additional design goal will be compatibility with other reliable multicast "building blocks" [REF RMT Building Block Guidelines] to take advantage of additional network capabilities when available. Thus, while the techniques utilized in NORM are principally applicable to "flat" network distribution, they might also be applied to a given level of a hierarchical (e.g. tree-based) multicast distribution system if so desired. NORM can make use of reciprocal (among senders and receivers) multicast routing when available but will also be capable of efficient operation in asymmetric multicast topologies [REF single source multicast, etc]. Group communication scalability requirements leads to adaptation of negative acknowledgement (NACK) based protocol schemes [REF.]. NORM is a protocol centered around the use of selective NACKs to request repairs of missing data. NORM also uses NACK suppression methods and dynamic event timers to reduce retransmission requests and avoid congestion within the network. When used in pure multi- cast session operation, both NACKs and repair transmissions are multicast to the group to aid in feedback and control message sup- pression. This feature and additional message aggregation func- tionality reduce the likelihood of multicast control message implo- sion. NORM also dynamically measures the greatest group roundtrip time (GRTT) between sources and the set of multicast receivers to further improve the efficiency of the protocol state timers and probabilistic backoff algorithms. This allows NORM to scale well while maintaining reliable data delivery transport with low latency relative to the network topology over which it is operating. NORM also provides for the use of packet-level forward error correction (FEC) techniques for efficient multicast repair and optional proac- tive transmission robustness. Another aspect of the NORM protocol design is providing support for distributed multicast session participation with minimal coordina- tion among sources and receivers. The protocol allows sources and receivers to dynamically join and leave multicast sessions at will with minimal overhead for control information and timing synchro- nization among participants. To accommodate this capability, NORM Adamson, Borman, et al. Expires May 2001 [Page 2]
Internet Draft NORM Protocol November 2000 protocol message headers contain some common information allowing receivers to easily synchronize to sources throughout the lifetime of a defined session. These common headers also include support for collection of transmission timing information (e.g., round trip delays) that allows NORM to adapt itself to a wide range of dynamic network conditions with little or no pre-configuration. The proto- col is purposely designed to be tolerant of inaccurate timing esti- mations or lossy conditions which may occur many networks includin mobile and wireless. The protocol is also designed to exhibit con- vergence even under cases of heavy packet loss and large queueing or transmission delays. While the various features of NORM are designed to provide some measure of general purpose utility, it is important to emphasize the understanding that "no one size fits all" in the reliable mul- ticast transport arena. There are numerous engineering tradeoffs involved in reliable multicast transport design and this requires an increased awareness of application and network architecture con- siderations. Performance requirements affecting design can include: group size, heterogeneity (e.g., capacity and/or delay), asymmetric delivery, data ordering, delivery delay, group dynamics, mobility, congestion control, and transport across low capacity connections. NORM contains various protocol parameters to accommo- date many of these differing requirements, but there is an assumed model of bulk transfer transport service that drives the trade-offs resulting in the protocol described here. 1.1 NORM Transport Service Model An instance of the NORM protocol (NormSession) is defined within the context of one or more senders and receivers mutually communi- cating with prdefined IP addresses and host port(s). While point- to-point (unicast) NormSessions may be established between a pair of protocol participants (NormNodes), it is anticipated the proto- col will be used for multicast data distribution and that partici- pating nodes will communicate on a common IP multicast group address and port number which has been chosen via other means (e.g. MBONE session directory tools, administrative coordination, SIP signalling, etc). Note that the protocol provides for an optional mechanism for receiver nodes to use unicast addressing to provide feedback to senders in networks where this is required (e.g. Single Source Multicast Routing, asymmetric topologies, etc). The protocol design is principally driven with the assumption of a single sender transmitting bulk data content to a group of receivers. However, the protocol does provide for multiple senders to coexist within the context of a NormSession. In initial imple- mentations of this protocol, it is anticipated that multiple Adamson, Borman, et al. Expires May 2001 [Page 3]
Internet Draft NORM Protocol November 2000 senders will transmit independently of one another and receivers will maintain state as necessary for each independent sender. In future iterations of this document, it is possible that some aspects of protocol operation (e.g. round-trip time collection) will provide for alternate modes allowing more efficient perfor- mance for applications requiring multiple senders. NORM provides for three types of bulk data content objects (NormOb- jects) to be reliably transported. These types include static com- puter memory data content (NORM_OBJECT_DATA), computer storage files (NORM_OBJECT_FILE), and non-finite streams of continuous data content (NORM_OBJECT_STREAM). The distinction between NORM_OBJECT_DATA and NORM_OBJECT_FILE is simply to provide a "hint" to receivers in NormSessions serving multiple types of content as to what type of storage should be allocated for received content (i.e. memory or file storage). Other than that distinction, the two are identical, providing for reliable transport of finite units of content. The use of the NORM_OBJECT_STREAM type is at the application's discretion and conceivably be used to carry static data or file content also. Reliable stream service also opens up other possibilities such as reliable messaging or other unbounded, perhaps dynamically produced content. The NORM_OBJECT_STREAM pro- vides for reliable transport analogous to that of the Transmission Control Protocol (TCP) although NORM receivers will be able to begin receiving stream content at any point in time (The applica- bility of this feature will depend upon the application). The static data and file services are anticpated to be useful for mul- ticast-based cache applications with the ability to reliably pro- vide transmission/repair of a large set of static data. Other types of static data/file "casting" services might make use of these transport object types, too. The NORM protocol allows for a small amount of "out-of-band" data (NORM_INFO) to be attached to the data content objects transmitted by the sender. This readily- available "out-of-band" data allows multicast receivers to quickly and efficiently determine the nature of the bulk content (data, file, or stream) being transmitted to allow application-level con- trol of the receiver node's participation in the current transport activity. This allows the protocol to be flexible with minimal pre-coordination among senders and receivers. NORM does _not_ provide for global or application-level identifica- tion of data content within in its message headers (It should be noted that the NORM_INFO out-of-band data mechanism can be lever- aged by the application for this purpose if desired, or identifica- tion could alternatively be embedded within the data content). NORM identifies data content objects (NormObjects) with transport identifiers which are applicable while the sender is transmitting and/or repairing the given object. These transport data content Adamson, Borman, et al. Expires May 2001 [Page 4]
Internet Draft NORM Protocol November 2000 identifiers are assigned in a montonically increasing fashion by each NORM sender during the course of a NormSession. Each sender maintains its transport identifier assignments independently so NormObjects are uniquely identified during transport by the con- catenation of the sender's session-unique identifier (NormNodeId) and the assigned NormObject transport identifier (NormTransportId). The NormTransportIds are assigned from a large (32 bit?) numeric space in increasing order and may be reassigned for long-lived ses- sions. The NORM protocol provides mechanisms so that the sender application may terminate transmission of data content and inform the group of this in an efficient. Other similar protocol control mechanisms (e.g. session termination, receiver synchronization, etc) are specified so that reliable multicast application variants may construct different, complete bulk transfer communication mod- els to meet their goals. In summary, the NORM protocol's goal is to provide reliable trans- port of data content objects (including a potentially mixed set of types) to the receiver set from one or more senders. The senders will queue and transmit content in the form of static data or files and/or non-finite, ongoing stream types. The sender will provide for repair transmission of this content in response to NACK mes- sages received from the receiver group. Mechanisms for "out-of- band" information and other session management mechanisms are also specified for use by applications to form a complete reliable mul- ticast transport solutions for a range different purposes. 2.0 Protocol Definition 2.1 Assumptions A NORM protocol instantiation (NormSession) is defined by the con- text of participants communicating connectionless (e.g. User Data- gram Protocol (UDP)) packets over an Internet Protocol (IP) network on a common, pre-determined network address and host port number. Generally, the participants exchange packets on an IP multicast group address, but unicast transport may also be established or applied as an adjunct to multicast delivery. Currently the protocol uses a single multicast address for transmissions associated with a given NORM session. However, in the future, it is possible that multiple multicast addresses might be employed to segregate sepa- rate degrees of repair information to different groups of receivers experiencing different packet loss characteristics with respect to a given sender. This capability is under ongoing investigation in the research community [REF]. For multicast operation, the NORM protocol assumes basic IP multicast forwarding service is available at least from the sender(s) to the receiver set. However, the Adamson, Borman, et al. Expires May 2001 [Page 5]
Internet Draft NORM Protocol November 2000 protocol also supports asymmetry where receiver participants may transmit back to sender participants via unicast routing instead of broadcasting to the session multicast address. Each participant (NormNode) within an NormSession is assumed to have an preselected unique XX-bit (TBD) identifier (NormNodeId). NormNodes MUST have uniquely assigned identifiers within a single NormSession to distinquish between possible multiple senders and to distinguish feedback information from different receivers. The protocol does not preclude multiple sender nodes actively transmit- ting within the context of a single NORM session (i.e. many- to- many operation), but any type of interactive coordination among these senders is assumed to be controlled by a higher protocol layer (perhaps using some of the optional NORM mechanisms later specified to perform this coordination). Unique data content transmitted within a NormSession uses sender- assigned identifiers (NormObjectTransportIds) which are valid and applicable only during the actual _transport_ of the particular portion of data content (i.e. for as long as the sender is trans- mitting and providing repair of the indicated data content). Any globally unique identification of transported data content must be assigned and processed by the higher level application using the NORM transport service. 2.2 General Protocol Operation A NORM sender primarily generates messages of type NORM_DATA which carry the data content and related FEC parity-based repair informa- tion for the bulk data/file or stream objects being transferred. Parity content is by default sent only on in response to receiver repair requests (NACKs) and thus normally imposes no additional protocol overhead. However, the transport of an object can be optionally configured to proactively transmit some amount of parity packets along with the original data content to potentially enhance performance (e.g., improved delay) at the cost of additional over- head with initial data transmission. This configuration may be sensible for certain network conditions and can allow for robust, asymmetric multicast (e.g., unidirectional routing, satellite, cable) [REF] with minimal receiver feedback, or, in some cases, none. A sender message of type NORM_INFO is also defined and is used to carry any optional "out-of-band" context information for a given transport object. Because of its simple, nature content of NORM_INFO messages can be NACKed and repaired with a slightly lower delay process than NORM's general FEC-encoded data content. NORM_INFO may serve special purposes for some buld transfer, Adamson, Borman, et al. Expires May 2001 [Page 6]
Internet Draft NORM Protocol November 2000 reliable multicast applications where receivers join the group mid- stream and need to ascertain contextual information on the current content being transmitted. The NACK process for NORM_INFO will be described later. The sender also generates messages of type NORM_CMD to perform cer- tain protocol operations such as congestion control, end-of-trans- mission flushing, round trip time estimation, receiver synchroniza- tion, and optional positive acknowledgement requests or application defined commands. The transmission of NORM_CMD messages from the sender is accomplished by one of three different processes. These include single, best effort unreliable transmission of the command, repeated redundant transmission of the command, and positively acknowledged commands. The transmission technique used for a given command depends upon the function of the command. Several core commands are defined for basic protocol operation. Additionally, implementations may wish to consider providing the option of appli- cation-defined commands which can take advantage of these transmis- sion methodologies available for command. These transmission methodologies make use of information available to the protocol engine (e.g. round-trip timing, transmission rate, etc) to perform efficiently. An NORM receiver generates messages of type NORM_NACK or NORM_ACK in response to transmissions of data and commands from a sender. The NORM_NACK messages are generated to request repair of detected data transmission losses. Receivers generally detect losses by tracking the sequence of transmission from a sender. Sequencing information is embedded in the transmitted data packets and end-of- transmission commands from the sender. NORM_ACK messages are gen- erated in response to certain commands transmitted by the sender. In the general (and most scalable) protocol mode, receivers do not transmit any NORM_ACK messages. However, in order to meet poten- tial user requirements for positive data acknowledgement, and to collect more detailed information for potential multicast conges- tion control algorithms, NORM_ACK messages are defined and poten- tially used. NORM_ACK messages are also generated by a small sub- set of receivers when NORM dynamic end-to-end congestion control is in operation. NORM allows for reliable transfer of three different types of data content. These include the type NORM_OBJECT_DATA which are static, persistent blocks of data content maintained in the sender's appli- cation memory storage and the type NORM_OBJECT_FILE which corre- sponds to data stored in the sender's non-volatile file system. Both of these types represent "NormObjects" of finite size which are encapsulated for transmission and are temporarily yet uniquely identified with the given sender's NormNodeId and a temporarily Adamson, Borman, et al. Expires May 2001 [Page 7]
Internet Draft NORM Protocol November 2000 unique NormObjectTransportId. The third type of All transmissions by individual senders and receivers are subject to rate control governed by a peak transmission rate set for each participant by the application. This can be used to limit the quantity of multicast data transmitted by the group. When NORM's congestion control algorithm is enabled the rate for senders is automatically adjusted. And even when congestion control is enabled, it may be desirable in some cases to establish minimum and maximum bounds for the rate adjustment depending upon the applica- tion. 2.3 Message Type and Header Definitions (TBD) This section will explicitly define the format and header content of protocol messages used by NORM. NORM Message Types Sender Messages: NORM_DATA This is expected to be the predominant message type transmitted by NORM senders. These messages will contain data content for objects of type NORM_OBJECT_DATA, NORM_OBJECT_FILE, and NORM_OBJECT_STREAM. A goal of the protocol design is to provide for parallel transmis- sion of different streams and data/file sets. NORM_DATA messages will generally consist of original data content of the application data being transmitted. The content size of these messages will a maximum of NormSegmentSize which is constant for the duration of a given sender's term of participation in the session. Senders advertise their NormSegmentSize in applicable messages which they transmit. This allows receivers to allocate appropriate buffering resources and to determine other information in order to properly process received data messaging. The NORM_DATA message type will also be used to convey FEC parity repair content for NormObjects sent. NORM_INFO The NORM_INFO message is used to convey optional "out-of-band" con- text information for objects transmitted. Each NormObject may have an independent unit of NORM_INFO associated with it. NORM_DATA messages contain a flag to indicate the availability of NORM_INFO for a given NormObject. NORM receivers may NACK for retransmission of NORM_INFO when they have not received it for a given NormObject. Adamson, Borman, et al. Expires May 2001 [Page 8]
Internet Draft NORM Protocol November 2000 The size of the NORM_INFO content is limited to that of a single NormSegmentSize for the given sender. This atomic nature allows the NORM_INFO to be rapidly and efficiently repaired within the NORM transmission process. NORM_CMD NORM_CMD messages are transmitted by senders to perform a number of different protocol functions. This includes round-trip timing col- lection, potential congestion control functions, synchronization of receiver NACKing "windows", notification of sender status and other core protocol functions. A core set of NORM_CMD messages will be enumerated. A range of command types will remain undefined for potential application-specific usage. Some NORM_CMD types (possi- bly including application-defined commands) may have some dynamic content attached. This content will be limited to a single Norm- SegmentSize to retain the atomic nature of commands. Core commands will be discussed in detail later in this document. Receiver Messages: NORM_NACK The principal purpose of NORM_NACK messages will be for receivers to request repair of content via negative acknowledgement upon detection of incomplete data. NORM_NACKs will be transmitted according to the rules of NACK generation and suppression of the NORM NACK process. A goal for the content of these messages is to use a format which can be potentially used by compatible intermedi- ate systems [REF Generic Router Assist Building Block] to provide assistance in promoting protocol scalability and efficiency when available. NORM_NACK messages generated will also contain addi- tional content to provide feedback to sender(s) for purposes of round-trip timing collection, congestion control, etc. NORM_ACK The basic operation of NORM transport will _not_ rely on the use NORM_ACK (positive acknowledgement) messages. However, some appli- cations may benefit from some limited form of positive acknowledge- ment for certain functions. A simple, scalable positive acknowl- edgement scheme is defined which can be leveraged by protocol implementations when appropriate. 3.0 Detailed Protocol Operation (TBD) This section describes the detailed interactions of senders and receivers participating in a NORM session. Candidate Adamson, Borman, et al. Expires May 2001 [Page 9]
Internet Draft NORM Protocol November 2000 subsections: 3.1 Sender Initialization and Transmission (TBD) Describes how a sender becomes active within the group, transmits data content and how it may potentially go inactive or leave the group. 3.2 Receiver Initialization and Reception (TBD) Describes how a receiver joins the group, begins receiving data content and any requirements on dynamically leaving and poten- tially rejoining the group. 3.3 Receiver NACK Process (TBD) Describes receiver criteria by which/when it chooses to transmit NACK-based repair requests and the content of the these messages. 3.3.1 NACK initiation 3.3.2 NACK content 3.4 Sender NACK Processing and Repair Transmission (TBD) Describes how the sender accumulates NACK repair requests and transmits repair information in response to these requests. 3.5 Additional Protocol Mechanisms (TBD) Describes any other protocol mechanisms running periperally or embedded as part of other protocol messaging. 3.5.1 Round-trip time collection 3.5.2 Congestion control operation 3.5.3 Other (e.g. optional scalable, positive acknowledgements, asymmet- ric feedback, performance reporting, etc) 4.0 Security Considerations (TBD) 5.0 Suggested Use Adamson, Borman, et al. Expires May 2001 [Page 10]
Internet Draft NORM Protocol November 2000 (TBD) 6.0 References (TBD) 7.0 Authors' Addresses Brian Adamson adamson@itd.nrl.navy.mil Newlink Global Engineering Corporation 8580 Cinder Bed Road, Suite 1000 Newington, VA, USA, 22122 Carsten Bormann cabo@tellique.de Tellique Kommunikationstechnik GmbH Gustav-Meyer-Allee 25 Geb ude 12 D-13355 Berlin, Germany Sally Floyd floyd@aciri.org 1947 Center Street, Suite 600 Berkeley, CA 94704 Mark Handley mjh@aciri.org 1947 Center Street, Suite 600 Berkeley, CA 94704 Joe Macker macker@itd.nrl.navy.mil Naval Research Laboratory Washington, DC, USA, 20375 Adamson, Borman, et al. Expires May 2001 [Page 11]
