draft-ietf-rmt-bb-lct-00.txt   draft-ietf-rmt-bb-lct-01.txt 
Internet Engineering Task Force RMT WG Internet Engineering Task Force RMT WG
INTERNET-DRAFT M.Luby/Digital Fountain INTERNET-DRAFT M.Luby/Digital Fountain
draft-ietf-rmt-bb-lct-00.txt J.Gemmell/Microsoft draft-ietf-rmt-bb-lct-01.txt J.Gemmell/Microsoft
L.Vicisano/Cisco L.Vicisano/Cisco
L.Rizzo/ACIRI and Univ. Pisa L.Rizzo/ACIRI and Univ. Pisa
M.Handley/ACIRI M.Handley/ACIRI
J. Crowcroft/UCL J. Crowcroft/UCL
17 November 2000 19 July 2001
Expires: May 2001 Expires: January 2002
Layered Coding Transport: Layered Coding Transport:
A massively scalable multicast protocol A massively scalable content delivery transport
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
Internet-Drafts are valid for a maximum of six months and may be 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 updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite inappropriate to use Internet-Drafts as reference material or to cite
them other than as a "work in progress". them other than as a "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document is a product of the IETF RMT WG. Comments should be 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. addressed to the authors, or the WG's mailing list at rmt@lbl.gov.
Abstract Abstract
This document describes Layered Coding Transport, a massively This document describes Layered Coding Transport, a massively
scalable multicast protocol, hereafter referred to as LCT. scalable reliable content delivery and stream delivery
^L ^L
LCT can be used for multi-rate content delivery (for both transport, hereafter referred to as LCT. LCT can be used for
reliable bulk data transfer and unreliable data streams) to multi-rate delivery to large sets of receivers. In LCT,
large sets of receivers. In LCT, scalability and congestion scalability and congestion control are supported through the
control are supported through the use of layered coding use of layered coding techniques. Coding techniques can be
techniques. When LCT is used for reliable data transfer, the combined with LCT to provide support for reliability.
coding also provides support for reliability.
Congestion control is receiver driven, and is achieved by Congestion control is receiver driven, and is achieved by
sending packets in the session to multiple ``LCT groups'', and sending packets in the session to multiple ``LCT channels'',
having receivers join and leave LCT groups (thus adjusting and having receivers join and leave LCT channels (thus
their reception rate) in reaction to network conditions in a adjusting their reception rate) in reaction to network
manner that is network friendly. conditions in a manner that is network friendly.
^L ^L
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4
1.1. Related Documents. . . . . . . . . . . . . . . . . . 5 1.1. Related Documents. . . . . . . . . . . . . . . . . . 6
1.2. Environmental Requirements . . . . . . . . . . . . . 6 1.2. Environmental Requirements and Considerations. . . . 6
2. General Architecture. . . . . . . . . . . . . . . . . . 8 2. General Architecture. . . . . . . . . . . . . . . . . . 8
2.1. Delivery service models. . . . . . . . . . . . . . . 9 2.1. Delivery service models. . . . . . . . . . . . . . . 10
2.2. Congestion Control . . . . . . . . . . . . . . . . . 10 2.2. Congestion Control . . . . . . . . . . . . . . . . . 11
3. Packet Formats. . . . . . . . . . . . . . . . . . . . . 11 3. LCT packets . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Data-Packet format . . . . . . . . . . . . . . . . . 11 3.1. LCT packet format. . . . . . . . . . . . . . . . . . 12
3.2. Request-Packet format. . . . . . . . . . . . . . . . 12 3.2. LCT packet header fields . . . . . . . . . . . . . . 13
3.3. LCT Packet header fields . . . . . . . . . . . . . . 13 3.3. Header-Extension Fields. . . . . . . . . . . . . . . 16
3.4. Transmission Extensions. . . . . . . . . . . . . . . 15
3.5. Header-Extension Fields. . . . . . . . . . . . . . . 16
4. Procedures. . . . . . . . . . . . . . . . . . . . . . . 19 4. Procedures. . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Sender Operation . . . . . . . . . . . . . . . . . . 19 4.1. Sender Operation . . . . . . . . . . . . . . . . . . 19
4.2. Receiver Operation . . . . . . . . . . . . . . . . . 21 4.2. Receiver Operation . . . . . . . . . . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . 23 5. Security Considerations . . . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . 22
7. Intellectual Property Issues. . . . . . . . . . . . . . 23 7. Intellectual Property Issues. . . . . . . . . . . . . . 22
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 24 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 23
9. Authors' Addresses. . . . . . . . . . . . . . . . . . . 25 9. Authors' Addresses. . . . . . . . . . . . . . . . . . . 24
10. Full Copyright Statement . . . . . . . . . . . . . . . 27 10. Full Copyright Statement . . . . . . . . . . . . . . . 26
^L ^L
1. Introduction 1. Introduction
This document describes a massively scalable protocol, Layered Coding This document describes a massively scalable reliable content delivery
Transport (LCT), for multi-rate content delivery using IP multicast. LCT and stream delivery transport, Layered Coding Transport (LCT), for
supports both reliable and unreliable data transfer, and supports a multi-rate content delivery primarily designed to be used with the IP
congestion control mechanism which conformings to RFC2357. multicast network service, but MAY also be used with other basic
underlying network or transport services such as unicast UDP. LCT
supports both reliable and unreliable delivery, and supports congestion
control mechanisms which conform to RFC2357.
IP multicast [5] is a "best effort" service and does not guarantee LCT is a building block as defined in RFC3048. Complete protocol
packet reception, or reception order. Also it does not provide any instantiations MAY be built by combining the LCT framework with other
support for flow or congestion control. While the basic service provided components. A complete protocol instantiation that uses LCT MUST
by IP multicast is largely scalable, adding features such as congestion include a congestion control protocol that is compatible with LCT and
control or reliability on top of it might cause severe scalability that conforms to RFC2357. A complete protocol instantiation that uses
limitations, especially in presence of heterogeneous sets of receivers. LCT MAY include a scalable reliability protocol that is compatible with
LCT, it MAY include an session control protocol that is compatible with
LCT, and it MAY include other protocols such as security protocols.
Scalability refers to the behaviour of the protocol in relation to the LCT is presumed to be used with an underlying network or transport
service that is a "best effort" service that does not guarantee packet
reception, packet reception order, and which does not have any support
for flow or congestion control. For example, the Any-Source Multicast
(ASM) model of IP multicast as defined in RFC1112 is such a "best
effort" network service. While the basic service provided by RFC1112 is
largely scalable, providing congestion control or reliability should be
done carefully to avoid severe scalability limitations, especially in
presence of heterogeneous sets of receivers.
Scalability refers to the behavior of the protocol in relation to the
number of receivers and network paths, their heterogeneity, and the number of receivers and network paths, their heterogeneity, and the
ability to accommodate dynamically variable groups. Scalability ability to accommodate dynamically variable sets of receivers.
limitations can come from memory or processing requirement, or from the Scalability limitations can come from memory or processing requirements,
amount of traffic generated by the protocol. In turn, such limitations or from the amount of packet traffic generated by the protocol. In
derive from the features that a multicast transport protocol is expected turn, such limitations may be a consequence of the features that a
to provide. complete reliable content delivery or stream delivery protocol is
expected to provide.
Congestion control refers to the ability of the protocol to adapt its Congestion control refers to the ability of the protocol to adapt its
throughput to the available bandwidth on the path to the receivers, and throughput to the available bandwidth on the path to the receivers, and
to share bandwidth fairly with competing flows such as TCP. It is to share bandwidth fairly with competing flows such as TCP. It is
required that protocols implement some form of congestion control so REQUIRED that protocols implement some form of congestion control on
that they not compete unfairly with existing and adaptive protocols such each session so that they not compete unfairly with existing and
as TCP. adaptive protocols such as TCP.
Multi-rate protocols aim at splitting the set of receivers into multiple For multi-rate protocols, the sender typically sends packets at a
subsets, according to the available bandwidth each one has to the constant aggregate rate to multiple channels, but individual receivers
source. Conversely, single-rate multicast protocols make all receivers adjust which portion of these packets they attempt to receive by
in a session experience the same throughput. The partitioning of
receivers can be done statically or adaptively. ^L
adjusting which set of channels they are joined to at each point in time
depending on the available bandwidth between the receiver and the
sender, but independent of all other receivers. Thus, for multi-rate
protocols, the packet reception rate of each receiver may vary
dynamically according to the available bandwidth between each receiver
and the sender, independent of the other receivers. For single-rate
protocols, the sender typically sends packets to one channel at variable
rates over time depending on feedback from receivers, and all receivers
attempt to receive all packets transmitted by the sender at all points
in time. Thus, for single-rate protocols, the packet reception rate of
all receivers may vary dynamically over time in exactly the same way
dependent on the feedback of other receivers to the sender. Generally,
a multi-rate protocol is preferable to a single-rate protocol in a
heterogeneous receiver environment, but only if it can be achieved
without sacrificing scalability.
Layered coding refers to the ability to produce a coded stream that can Layered coding refers to the ability to produce a coded stream that can
be split into multiple substreams (transmitted over different multicast be split into multiple layers that can be sent to different channels.
groups). The coded stream can be generated either from a fixed piece of The coded stream can be generated either from a fixed piece of content,
content, or from an ongoing data stream, and has the property that the or from an ongoing data stream, and has the property that the quality
quality experienced by a receiver (in terms of quality of playout, or experienced by a receiver (in terms of quality of playout, or overall
overall transfer speed) is proportional to how many of the substreams transfer speed) is proportional to how many of the layers the receiver
the receiver is joined. Layered congestion control that is compliant is joined to. LCT MAY be combined with a reliability protocol such as
with RFC 2357 must be used by receivers to dynamically adjust their the general class of protocols described in [7]. LCT MUST be combined
reception rate by appropriately joining and or leaving groups carrying with a congestion control protocol that is compliant with RFC2357, and
the substreams. this MAY be either single-rate or multi-rate congestion control over the
entire session. It is most compelling to use LCT in conjunction with a
layered congestion control protocol such as the class of protocols
described in [9], and specified in [9], which are multi-rate congestion
control protocols.
The concept of layered coding was first introduced with reference to The concept of layered coding was first introduced with reference to
audio and video streams. For example, the information associated with a audio and video streams. For example, the information associated with a
TV broadcast can be partitioned into three layers, corresponding to
^L
TV broadcast can be thought as made of three layers, corresponding to
black and white, color, and HDTV quality. Receivers can experience black and white, color, and HDTV quality. Receivers can experience
different quality without the need for the sender to replicate different quality without the need for the sender to replicate
information in the different layers. information in the different layers.
The concept of layered coding can be naturally extended to reliable bulk The concept of layered coding can be naturally extended to reliable
data transfer protocols when Forward Error Correction (FEC) techniques content delivery protocols when Forward Error Correction (FEC)
are used for coding the data stream [15] [16] [7] [17] [18] [3]. By techniques are used for coding the data stream [12] [10] [3] [14] [15]
using FEC, the data stream is transformed in such a way that [1]. By using FEC, the data stream is transformed in such a way that
reconstruction of a data object does not depend on the reception of reconstruction of a data object does not depend on the reception of
specific data packets, but only on the number of different packets specific data packets, but only on the number of different packets
received. As a result, by increasing the number of groups it is received. As a result, by increasing the number of layers a receiver is
receiving from, a receiver can reduce the transfer time accordingly. receiving from, the receiver can reduce the transfer time accordingly.
More details on the use of FEC for reliable multicast can be found in More details on the use of FEC for reliable content delivery can be
[11]. Reliable protocols aim at giving guarantees on the reliable found in [6]. Reliable protocols aim at giving guarantees on the
delivery of data from the source to the intended recipients. Guarantees
vary from simple data integrity to strict ordering and atomic delivery. ^L
Several reliable multicast protocols have been built on top of IP
reliable delivery of data from the sender to the intended recipients.
Guarantees vary from simple packet data integrity to reliable delivery
of a precise copy of a data object to all intended recipients. Several
reliable content delivery protocols have been built on top of IP
multicast, but scalability was not a design goal for many of them. In multicast, but scalability was not a design goal for many of them. In
some cases, scalability is achieved by introducing changes to routers or some cases, scalability is achieved by introducing changes to routers or
other infrastructure [PGM], an approach which has an impact on near term other infrastructure (see for example [13] ), an approach which has an
deployment. impact on near term deployment across the Internet.
Two of the key difficulties in scaling reliable multicast are dealing Two of the key difficulties in scaling reliable content delivery using
with the amount of data that flows from receivers back to the sender, IP multicast are dealing with the amount of data that flows from
and the associated response (generally data retransmissions) from the receivers back to the sender, and the associated response (generally
sender. Protocols that avoid any such feedback, and minimize the amount data retransmissions) from the sender. Protocols that avoid any such
of retransmissions, can be massively scalable. LCT relies on the feedback, and minimize the amount of retransmissions, can be massively
availability of a layered codec to achieve reliability with little or no scalable. LCT relies on the availability of FEC codes or a layered
feedback. codec to achieve reliability with little or no feedback.
In this document we present the architecture of LCT, and illustrate its In this document we present the architecture and abstract LCT packet
support for multi-rate congestion control. structure, and illustrate its support for multi-rate layered congestion
control.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [2]. document are to be interpreted as described in RFC2119.
1.1. Related Documents 1.1. Related Documents
A more in-depth description of the use of FEC in Reliable Multicast A more in-depth description of the use of FEC in Reliable Multicast
Transport (RMT) protocols is given in [11]. Some of the FEC codecs that Transport (RMT) protocols is given in [6]. Some of the FEC codecs that
may be used by LCT for reliable bulk data transfer are specified in MAY be used by LCT for reliable content delivery are specified in [7].
[12]. LCT reserves opaque header fields that can be used to transport LCT reserves opaque header fields that can be used to transport
information related to the payload encoding. information related to the payload encoding.
Implementors of LCT MUST also implement congestion control in accordance Implementors of LCT MUST also implement congestion control in accordance
to RFC2357 [13]. One possible scheme is specified in [1]. LCT reserves to RFC2357, where the congestion control is over the entire session.
Some possible schemes are specified in [9]. LCT reserves opaque header
fields that can be used by the congestion control scheme to transport
information related to congestion control.
^L It is RECOMMENDED that LCT implementors use some authentication scheme
to protect the protocol from attacks. An example of a possibly suitable
scheme is described in [11].
opaque header fields that can be used by the congestion control scheme 1.2. Environmental Requirements and Considerations
to transport information related to congestion control.
It is recommended that LCT implementors use some authentication scheme LCT is intended for congestion controlled, multi-rate delivery of
to protect the protocol from attacks. Suitable schemes are discussed in objects and streams (both reliable content delivery and streaming of
[]
1.2. Environmental Requirements ^L
LCT is intended for congestion controlled, multi-rate delivery of
objects (both reliable bulk data transfer and unreliable streaming of
multimedia information). multimedia information).
LCT is most applicable for delivery of objects of substantial length, LCT is most applicable for delivery of objects or streams of substantial
i.e., objects that range in length from hundreds of kilobytes to many length, i.e., objects or streams that range in length from hundreds of
gigabytes, and whose transfer time is in the order of tens of seconds or kilobytes to many gigabytes, and whose transfer time is in the order of
more. tens of seconds or more.
LCT is directly applicable to all multicast enabled networks, including LCT is directly applicable to all multicast enabled networks, including
asymmetric networks, wireless networks, and satellite networks. Thus, asymmetric networks, wireless networks, and satellite networks. Thus,
the inherent raw scalability of LCT is unlimited. However, when other the inherent raw scalability of LCT is unlimited. However, when other
specific applications are built on top of LCT, then these applications specific applications are built on top of LCT, then these applications
by their very nature may limit scalability. For example, if an by their very nature may limit scalability. For example, if an
application requires receivers to retrieve out of band information in application requires receivers to retrieve out of band information in
order to join a session, or an application allows receivers to send 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 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, the scalability of the application is limited by the ability to send,
receive, and process this additional data. receive, and process this additional data.
LCT requires that the underlying network layer can deliver and LCT requires that the underlying network or transport layer can deliver
demultiplex packets for a given LCT session, and supply packet length and demultiplex LCT packets for a given LCT session, and supply packet
information to the LCT receiver. In IP networks, this is normally length information to the LCT receiver. In IP networks, this is often
achieved by using UDP, or any protocol that can provide an equivalent achieved by using UDP, or any protocol that can provide an equivalent
service, as the underlying transport protocol. service, as the underlying transport protocol.
LCT does not require reverse multicast connectivity, i.e. LCT receivers In this document, we refer to the original multicast service model
do not send multicast traffic. As such, LCT works with both the defined in RFC1112 as Any-Source Multicast, or ASM for short. We refer
original multicast model introduced in [5], which we call Internet to the multicast service model defined in [5] as Source-Specific
Standard Multicast (ISM) in this document, and with the Source Specific Multicast, or SSM for short. LCT does not require reverse multicast
Multicast (SSM) model that is based on [10]. The definition of an LCT connectivity, i.e. LCT receivers do not send multicast traffic. As
group used throughout this document is slightly different with ISM and such, LCT works with both ASM and SSM.
with SSM. When using ISM, packets of an LCT group are sent to a
multicast group address G. When using SSM, packets of an LCT 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 LCT than ISM for a few reasons. First, LCT The definition of an LCT channel used throughout this document is
may use several LCT groups in a session, and the large, local namespace slightly different with ASM and with SSM. When using ASM, a sender S
sends LCT packets to a multicast group G, and the LCT channel address
consists of the pair (S,G), where S is the IP address of the sender and
G is a multicast group address. When using SSM, a sender S sends LCT
packets to an SSM channel (S,G), and the LCT channel address coincides
with the SSM channel address.
^L SSM is more attractive to deployment of LCT than ASM for several
reasons. First, a sender may allocate and use several LCT channels in a
session, sessions may come and go dynamically. A sender can locally
allocate unique SSM channel addresses, and this makes allocation of LCT
channel addresses easy with SSM. To allocate LCT channel addresses
using ASM, the sender must uniquely chose the ASM multicast group
address across the scope of the group, and this makes allocation of LCT
channel addresses more difficult with ASM.
for allocating multicast groups in SSM greatly simplifies the address ^L
allocation problem.
Second, LCT over SSM performs well even in presence of very large and In general SSM performs well even in presence of very large and
dynamically changing receiver sets. Changes in the multicast tree dynamically changing receiver sets. Changes in the multicast tree
topology with SSM are light weight operations (a new branch from the topology with SSM are light weight operations (a new branch from the
receiver towards S grows when a receiver joins, and the branch is receiver towards S grows when a receiver joins, and the branch is
deleted when the receiver leaves), whereas with ISM changes can be deleted when the receiver leaves), whereas with ASM changes can be
heavier weight (involving transitions from a (*,G)-tree rooted at an RP heavier weight (involving transitions from a (*,G)-tree rooted at an RP
to the tree rooted at S). to the tree rooted at S). This efficiency is important when a
congestion control protocol is used with LCT that relies upon joining
Third, LCT over SSM scales well even when receivers span the global and leaving channels to nimbly increase and decrease reception rate.
Internet, as 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 LCT group by joining a channel (S,G) with LCT channels and SSM channels coincide, and thus the receiver will only
SSM, and thus the receiver will only receive packets sent from the receive packets sent to the requested LCT channel. With ASM, the
sender S. With ISM, the receiver joins an LCT group by joining a receiver joins an LCT channel by joining a multicast group G, and all
multicast group G, and all packets sent to G, regardless of their origin packets sent to G, regardless of the sender, may be received by the
sender, will be received by the receiver. Thus, SSM has compelling receiver. In either case, receivers should use mechanisms to filter out
security advantages over ISM for prevention of denial of service packets from unwanted sources. Thus, SSM has compelling security
attacks. advantages over ASM for prevention of denial of service attacks.
LCT also requires receivers to obtain Session Description Information LCT also requires receivers to obtain Session Description Information
before joining a session, as described in Section 4.1. The session before joining a session, as described in Section 4.1. The session
description could be in a form such as SDP [8], or XML metadata, or description could be in a form such as SDP as defined in RFC2327, or XML
HTTP/Mime headers [6], and distributed with SAP, HTTP or in other ways. metadata, or HTTP/Mime headers as defined in RFC2068, and distributed
with SAP [4], using RCCP [8], HTTP, or in other ways.
The particular layered encoder and congestion control protocols used by The particular layered encoder and congestion control protocols used
LCT to provide a complete protocol have an impact on the performance and with LCT have an impact on the performance and applicability of LCT.
applicability of LCT. For example, some layered encoders used for video For example, some layered encoders used for video and audio streams can
and audio streams can produce a very limited number of substreams, thus produce a very limited number of substreams, thus providing a very
providing a very coarse control in the throughput of a session. When coarse control in the reception rate of packets by receivers in a
LCT is used for reliable data transfer, some FEC coders are inherently session. When LCT is used for reliable data transfer, some FEC codecs
limited in the size of the object they can encode, and for objects are inherently limited in the size of the object they can encode, and
larger than this size the reception overhead on the receivers can grow for objects larger than this size the reception overhead on the
substantially. receivers can grow substantially.
As another example, some networks are not amenable to some congestion As another example, some networks are not amenable to some congestion
control protocols that could be used with LCT. In particular, for a control protocols that could be used with LCT. In particular, for a
satellite or wireless network, there may be no mechanism for receivers satellite or wireless network, there may be no mechanism for receivers
to effectively reduce their reception rate since there may be a fixed to effectively reduce their reception rate since there may be a fixed
transmission rate allocated to the session. transmission rate allocated to the session.
^L
2. General Architecture 2. General Architecture
An LCT session comprises all packets sent to one or more LCT groups from An LCT session comprises all LCT packets sent to one or more LCT
a single sender, and pertaining to the transmission of one or more channels from a single sender, and pertaining to the transmission of one
objects that can be of interest for the receivers. or more objects that can be of interest for the receivers.
For example, an LCT session could be used to deliver a TV channel on For example, an LCT session could be used to deliver a TV channel using
three groups. The first group would allow black and white reception,
the first two groups would permit color reception, whereas the set of ^L
three groups delivers HDTV quality images. Objects in this example
would correspond to individual programs (movies, news, commercial) being three channels. Receiving the first channel could allow black and white
transmitted. reception, receiving the first two channels would permit color
reception, whereas receiving the set of three channels delivers HDTV
quality images. Objects in this example could correspond to individual
programs (movies, news, commercial) being transmitted.
As another example, a reliable LCT session could be used to reliably As another example, a reliable LCT session could be used to reliably
deliver hourly-updated weather maps (objects) using ten LCT groups at deliver hourly-updated weather maps (objects) using ten LCT channels at
different rates, using FEC coding. A receiver may join and concurrently different rates, using FEC coding. A receiver MAY join and concurrently
receive packets from subsets of these groups, until it has enough receive LCT packets from subsets of these channels, until it has enough
packets in total to recover the object, then leave the session (or packets in total to recover the object, then leave the session (or
remain there listening to control information only) until it is time to remain there listening to control information only) until it is time to
receive the next object. In this case, the quality metric is the time receive the next object. In this case, the quality metric is the time
required to receive each object. required to receive each object.
Before joining a session, the receivers MUST obtain a session Before joining a session, the receivers MUST obtain a session
description, which MUST include the relevant session parameters needed description, which MUST include the relevant session parameters needed
by a receiver to participate in the session. The session description is by a receiver to participate in the session. The session description is
determined and agreed upon by the senders, and typically communicated to determined and agreed upon by the senders, and typically communicated to
the receivers out of band. In some cases, part of the session the receivers out of band. In some cases, part of the session
description MAY be included in the header of each packet. description MAY be included in the LCT packet.
A layered encoder is used to generate the data that is placed in the An encoder MAY be used to generate the data that is placed in the LCT
payload of LCT packets. A suitable decoder is used to extract the packet payload in order to provide reliability. A suitable decoder is
original information from the payload. used to reproduce the original information from the payload. There MAY
be a reliability packet header that follows the LCT packet header if
such an encoder and decoder is used. The reliability packet header
helps to describe the encoding data carried in the payload of the
packet. The format of the reliability packet header depends on the
coding used, and this is negotiated out-of-band. As an example, one of
the FEC packet headers described in [7] could be used.
LCT congestion control is achieved by sending packets associated with a For LCT, when layered congestion control is used, congestion control is
given session to several LCT groups. Individual receivers dynamically achieved by sending LCT packets associated with a given session to
join to one or more of these groups, according to the network congestion several LCT channels. Individual receivers dynamically join one or more
as seen by the receiver. LCT packet headers include an opaque field of these channels, according to the network congestion as seen by the
which MUST be used to convey congestion control information to the receiver. LCT packet headers include an opaque field which MUST be used
receivers. The actual congestion control scheme to use with LCT is to convey congestion control information to the receivers. The actual
negotiated out-of-band. One of the algorithms that can be used to congestion control scheme to use with LCT is negotiated out-of-band.
achieve congestion control in LCT is described in [1]. LCT can be used Some examples of congestion control protocols that MAY be suitable for
with other congestion control algorithms such as the one described in content delivery are described in [9]. Other congestion controls MAY be
[17], or router-assisted scheme where the selection of which packets to suitable when LCT is used for a streaming application.
forward is performed by routers. This latter approach potentially allows
for finer grain congestion control and a faster reaction to network
congestion, but requires changes to the router infrastructure. See [4]
for a preliminary design description. We do not discuss this approach
^L LCT can be used with other congestion control protocols such as the one
described in [14], or router-assisted schemes where the selection of
which packets to forward is performed by routers. This latter approach
potentially allows for finer grain congestion control and a faster
reaction to network congestion, but requires changes to the router
further in this document. ^L
Depending on the service model in use, receiver can generate LCT request infrastructure. See [2] for a preliminary design description. We do
packets, which have no payload, and are used to request an extension of not discuss this approach further in this document.
the duration of the session.
2.1. Delivery service models 2.1. Delivery service models
LCT can support several different delivery service models. Two examples LCT can support several different delivery service models. Two examples
are briefly described here. are briefly described here.
Streaming service model. Push service model.
This is the basic service model for the delivery of unreliable streams, One way a push service model can be used for reliable content delivery
such as the TV example of Section 1. In this case the receivers join the is to deliver a series of objects. For example, a receiver could join
session, and dynamically adapt the number of LCT groups they subscribe the session and dynamically adapt the number of LCT channels the
to (and the reception quality) according to the available bandwidth. receiver is joined to until enough packets have been received to
Receivers then drop from the session when they are not interested in the reconstruct an object. After reconstructing the object the receiver may
stream anymore. stay in the session and wait for the transmission of the next object.
This service model can also be used for reliable data transfer, in case The push model is particularly attractive in satellite networks and
of objects that need periodic updates such as the weather maps example wireless networks. In these cases, a session may consist of one fixed
mentioned in Section 1. In this case, receivers join the session and rate LCT channel.
dynamically adapt the number of LCT groups they subscribe to until they
have accumulated a sufficient number of packets to reconstruct the
object. Afterwards, they drop from the session (or listen to the lowest
LCT group only) and wait for the transmission of the next object to
resubscribe or restart bandwidth adaptation according to the congestion
control scheme.
As an example, assume that each object to be transmitted has a size of On-demand content delivery model.
5000 1KB packets, and objects are updated every hour. The sender could
set the data rate on the lowest LCT group to 5 1KB packets/s, so that
receivers using just this LCT group could complete reception in 1000
seconds in absence of loss, and would be able to complete reception even
in presence of some substantial amount of losses or because they join
the session after the start of a transmission. Furthermore, the sender
could use a number of LCT groups such that the aggregate data rate when
using all LCT groups is 100 1KB packets/s, so that a receiver could be
able to complete reception of a single object in as little 50 seconds
(assuming no loss and that the congestion control mechanism immediately
converges to the use of all LCT groups).
^L For an on-demand content delivery service model, senders typically
transmit for some given time period selected to be long enough to allow
all the intended receivers to join the session and recover the object.
For example a popular software update might be transmitted using LCT for
several days, even though a receiver may be able to complete the
download in one hour total of connection time, perhaps spread over
several intervals of time.
On demand delivery model. In this case the receivers join the session, and dynamically adapt the
number of LCT channels they subscribe to (and the reception quality)
according to the available bandwidth. Receivers then drop from the
session when they have received enough packets to recover the object.
This service model is mostly relevant for reliable LCT session, where As an example, assume that an object is 50 MB. The sender could set the
the same object is made available by the sender for a sufficiently long data rate on the lowest LCT channel to 50 1KB packets per second, so
amount of time (typically much larger than the download time for the that receivers using just this LCT channel could complete reception of
object) to make it convenient for receivers to enact the download at the object in 1,000 seconds in absence of loss, and would be able to
their discretion. complete reception even in presence of some substantial amount of losses
with the use of coding for reliability. Furthermore, the sender could
use a number of LCT channels such that the aggregate data rate when
using all LCT channels is 1,000 1KB packets per second, so that a
receiver could be able to complete reception of the object in as little
Receivers may join the ongoing object transmission session at their ^L
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 50 seconds (assuming no loss and that the congestion control mechanism
given time period selected to be long enough to allow all the intended immediately converges to the use of all LCT channels).
receivers to join the session and recover the object. For example a
popular software update might be transmitted using LCT for several days,
even though a receiver may be able to complete the download in one hour
total of connection time, perhaps spread over several intervals of time.
Other service models. Other service models.
There are many other delivery service models that LCT can be used for There are many other delivery service models that LCT can be used for
that are not covered above. The description of the many potential that are not covered above. As examples, a live streaming or an on-
applications, the appropriate delivery service model, and the additional demand archival content streaming service model. The description of the
mechanisms to support such functionalities is beyond the scope of this many potential applications, the appropriate delivery service model, and
document. This document only attempts to describe the minimal common the additional mechanisms to support such functionalities when combined
scalable elements to these diverse applications using LCT as the with LCT is beyond the scope of this document. This document only
delivery mechanism. attempts to describe the minimal common scalable elements to these
diverse applications using LCT as the delivery transport.
2.2. Congestion Control 2.2. Congestion Control
The specific congestion control algorithm to be used for LCT sessions The specific congestion control protocol to be used for LCT sessions
depends on the type of data delivered. While the general behaviour of depends on the type of content to be delivered. While the general
the congestion control algorithm is to reduce the throughput in presence behavior of the congestion control protocol is to reduce the throughput
of congestion and gradually increase it in the absence of congestion, in presence of congestion and gradually increase it in the absence of
the actual dynamic behaviour (e.g. response to single losses) can vary. congestion, the actual dynamic behavior (e.g. response to single losses)
can vary.
A possible congestion control algorithm for reliable LCT sessions is Some possible congestion control protocols for reliable content delivery
specified in [1]. Different session types might require a different using LCT are described in [9]. Different delivery service models might
congestion control algorithm. require a different congestion control protocols.
^L 3. LCT packets
3. Packet Formats The type of packet used by LCT sessions is "LCT Packet". LCT packets
are sent by senders to LCT channels.
The primary type of packets used by LCT sessions is "Data Packet". Data Some instances of LCT sessions MAY require the generation of feedback
packets are sent by the data sender(s) to an LCT group. from the receivers to the sender. However, the mechanism for doing this
is outside the scope of LCT.
Some instances of LCT sessions may require the generation of feedback The LCT packet format described in this document is intended to be used
from the receivers to the sender. Such information is carried in in conjunction with the UDP transport protocol as defined in RFC768 or
Request packets, which are OPTIONAL and have the sole purpose of other transport protocols that satisfy the requirements stated in
implementing the "transmission extension" mechanism described in Section Section 1.2, specifically about demultiplexing and delivery of packet
3.4. The LCT packet format described in this document is intended to be size information.
used in conjunction to the UDP transport protocol [14], or other
transport protocols that satisfy the requirements stated in Section 1.2,
specifically about demultiplexing and delivery of packet size
information.
LCT Data packets consist of an LCT header and an optional payload, as LCT packets consist of an LCT packet header and an OPTIONAL LCT packet
shown in Figure 1. When present, the LCT payload immediately follows payload, as shown in Figure 1. When present, the LCT packet payload
the LCT header.
LCT Request Packets only consist of an LCT header, as shown in Figure 2. ^L
LCT Packet Headers have variable size, which is specified by a length immediately follows the LCT packet header. The LCT packet payload MAY
field in the 3dr byte of the header. In the LCT Packet Header, all contain headers for other protocols, such as reliability protocols.
LCT packet headers have variable size, which is specified by a length
field in the third byte of the header. In the LCT packet header, all
integer fields are carried in "big-endian" or "network order" format, integer fields are carried in "big-endian" or "network order" format,
that is, most significant byte (octet) first. Bits designated as that is, most significant byte (octet) first. Bits designated as
"padding" or "reserved" (r) MUST by set to 0 by senders and ignored by "padding" or "reserved" (r) MUST by set to 0 by senders and ignored by
receivers. Unless otherwise noted, numeric constants in this receivers. Unless otherwise noted, numeric constants in this
specification are in decimal (base 10). specification are in decimal (base 10).
3.1. Data-Packet format 3.1. LCT packet format
The format of LCT Data Packets is depicted in Figure 1. The format of LCT packets is depicted in Figure 1.
^L
0 1 2 3 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 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 |D|r|T|X|Trans.Obj.Id.(TOI) | HDR_LEN | Codepoint (CP)| | V | r | I |S|E|X|A|B| HDR_LEN | Codepoint (CP)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Control Information (CCI) | | Congestion Control Information (CCI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Demux Label (DL, if D = 1) | | Transport Object Identifier (TOI, if I >= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Current Time (SCT, if T = 1) | | TOI continued (if I >= 2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expected Residual Time (ERT, if T = 1) | | TOI continued (if I = 3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Extensions (only present if X = 1 ) | | TOI continued (if I = 3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Current Time (SCT, if S = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expected Residual Time (ERT, if E = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Extensions (if X = 1 ) |
| | | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| | | |
| Payload | | Payload |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - LCT Data Packet format Figure 1 - LCT packet format
3.2. Request-Packet format
When using on-demand service, LCT receivers MAY request that the sender
extend the transmission of the packets pertaining to a given object.
Requests should only be sent in response to data packets which are
carrying the TEI field (have the T bit set). Request packets MUST be
unicast to the node (designated out of band) in charge of receiving
Request packets.
The format of Request Packets is shown in Figure 2.
^L ^L
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 |D|r|1|X| Trans.Obj.Id.(TOI)| HDR_LEN | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Desired End Time (DET) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Demux Label (DL, if D = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Extensions (only present if X = 1 ) |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Figure 2: LCT Request Packet format 3.2. LCT packet header fields
3.3. LCT Packet header fields
The function each field in LCT packet headers is the following. Fields The function each field in LCT packet headers is the following. Fields
marked as "1" mean that the corresponding bits MUST be set to "1" by the marked as "1" mean that the corresponding bits MUST be set to "1" by the
generating agent. Fields marked as "r" or "0" mean that the generating agent. Fields marked as "r" or "0" mean that the
corresponding bits MUST be set to "0" by the generating agent. corresponding bits MUST be set to "0" by the generating agent.
LCT version number (V): 2 bits LCT version number (V): 4 bits
Indicates the LCT protocol version. The LCT version number for Indicates the LCT protocol version. The LCT version number for
this specification is 0. this specification is 0.
Demux Label Present flag (D): 1 bit Reserved (r): 5 bits
D = 1 indicates that the Demux Label (DL) field is present. D = 0 Reserved for future use. A sender MUST set these bits to zero and
indicates "no DL field". The DL field contains a 32-bit a receiver MUST ignore these bits.
identifier which can be used to filter packets belonging to the
session.
Transmission Extension Information Present flag (T): 1 bit Transport Object Identifier flag (I): 2 bits
T = 1 indicates that the Transmission Extension Information (TEI) I=0 indicates no Transport Object Identifier (TOI) field is
field is present. T = 0 indicates "no TEI field". The TEI field present.
is inserted by senders when they are willing to accept I=1 indicates that a 32-bit TOI field is present.
Transmission Extension Request packets from the receivers. I=2 indicates that a 64-bit TOI field is present.
I=3 indicates that a 128-bit TOI field is present.
The TOI field indicates which object within the session this LCT
packet pertains to.
Header Extension Present flag (X): 1 bit Sender Current Time present flag (S): 1 bit
X = 1 indicates that Header Extensions are present. X = 0 S = 0 indicates that the Sender Current Time (SCT) field is not
indicates "no Header Extensions". Header Extensions are used in present.
S = 1 indicates that the SCT field is present.
The SCT is inserted by senders to indicate to receivers how long
the session has been in progress.
Expected Residual Time present flag (E): 1 bit
E = 0 indicates that the Expected Residual Time (ERT) field is not
present.
E = 1 indicates that the ERT field is present.
The ERT is inserted by senders to indicate to receivers how much
longer the session will continue.
Senders MUST NOT set E = 1 when the ERT for the session is more
^L ^L
LCT to accommodate optional header fields which are not always than 2^32-1 time units (approximately 49 days), where time is
used or have variable size. measured in units of milliseconds.
Transport Object Identifier (TOI): 10 bits Header extension present flag (X): 1 bit
The Transport Object Identifier (TOI) field indicates which X = 0 indicates no Header Extensions are present.
Transport Object within the session this Data packet or Request X = 1 indicates that Header Extensions are present.
packet pertains to. For example, a source might send a number of Header Extensions are used in LCT to accommodate OPTIONAL header
files in the same session, using TOI=0 for the first file, TOI=1 fields which are not always used or have variable size.
for the second one, etc.
LCT Header Length (HDR_LEN): 8 bits Close TOI flag (A): 1 bit
Length of the variable portion of the LCT header in units of Normally, the Close TOI flag is set to 0. The sender MAY set the
32-bit words (excluding IP or UDP headers). The total LCT header Close TOI flag to 1 when termination of transmission of LCT
length is (HDR_LEN+2) 32-bit words. packets for the object identified by the TOI is imminent. The
Close TOI flag MAY be set to 1 in just the last LCT packet
transmitted for the object, or it MAY be set to 1 in the last
couple of seconds LCT packets transmitted for the object. Once
the sender sets the Close TOI flag to 1 in one packet for a
particular object, the sender SHOULD set the Close TOI flag to 1
in all subsequent packets for the object until termination of
transmission of LCT packets for the object. A received packet
with the Close TOI flag set to 1 indicates to a receiver that the
sender will immediately stop sending LCT packets for the object
identified by the TOI. When a receiver receives a packet with the
Close TOI flag set to 1 then it should assume that no more LCT
packets will be sent to the session for this object.
Close Session flag (B): 1 bit
Normally, the Close Session flag is set to 0. The sender MAY set
the Close Session flag to 1 when termination of transmission of
LCT packets for the session is imminent. The Close Session flag
MAY be set to 1 in just the last LCT packet transmitted for the
session, or it MAY be set to 1 in the last couple of seconds LCT
packets transmitted for the session. Once the sender sets the
Close Session flag to 1 in one packet, the sender SHOULD set the
Close Session flag to 1 in all subsequent packets until
termination of transmission of LCT packets for the session. A
received packet with the Close Session flag set to 1 indicates to
a receiver that the sender will immediately stop sending LCT
packets for the session. When a receiver receives a packet with
the Close Session flag set to 1 then it should assume that no more
LCT packets will be sent to the session.
^L
LCT packet header length (HDR_LEN): 8 bits
Length of the LCT packet header in units of 32-bit words
(excluding IP or UDP headers).
This field can be used for direct access to the beginning of the This field can be used for direct access to the beginning of the
LCT payload. LCT packet payload.
Codepoint (CP): 8 bits Codepoint (CP): 8 bits
An opaque identifier which is passed to the payload decoder to An opaque identifier which is passed to the payload decoder to
convey information on the codec being used for the payload. The convey information on the codec being used for the payload. The
mapping between the codepoint and the actual codec is defined on a mapping between the codepoint and the actual codec is defined on a
per session basis and communicated out-of-band as part of the per session basis and communicated out-of-band as part of the
session description information. session description information. The use of the CP field is
similar to the Payload Type (PT) field in RTP headers as described
The use of the CP field is similar to the Payload Type (PT) field in RFC1889.
in RTP headers [].
Congestion Control Information (CCI): 32 bits Congestion Control Information (CCI): 32 bits
Used to carry Congestion Control Information, e.g. for the scheme Used to carry congestion control information, e.g. for the
described in [1] or other congestion control schemes. This field congestion control specified in [9] or other congestion control
is opaque for the purpose of this specification. schemes. This field is opaque for the purpose of this
specification.
Demux Label (DL): 32 bits (OPTIONAL) Transport Object Identifier (TOI): 32, 64 or 128 bits (OPTIONAL)
Used to carry a 32-bit identifier to be used for filtering This field indicates which object within the session this LCT
purposes. All LCT packets belonging to the same LCT group MUST packet pertains to. For example, a sender might send a number of
have the same DL value that has been communicated out of band to files in the same session, using TOI=0 for the first file, TOI=1
receivers as part of the session description information. for the second one, etc. The mapping of TOI field values to
Receivers MUST discard packets with a non-matching DL. objects MUST be done out of band.
In order to minimize the amount of information to be supplied out This field MUST NOT be present if I=0.
of band, it is suggested that the same DL is used for all LCT This field MUST be 32 bits if I=1.
layers in the same session. This field MUST be 64 bits if I=2.
This field MUST be 128 bits if I=3.
^L
Sender Current Time (SCT): 32 bits (OPTIONAL) Sender Current Time (SCT): 32 bits (OPTIONAL)
This field represents the current clock at the sender at the time This field represents the current clock at the sender at the time
this packet was transmitted, measured in units of 1ms and computed this packet was transmitted, measured in units of 1ms and computed
modulo 2^32 units. modulo 2^32 units from the start of the session.
SCT is used, in conjunction with the ERT and DET fields, to This field MUST NOT be present if S=0 and MUST be present if S=1.
support receiver request generation as described in Section 3.4.
This field is only present in Data Packets when T=1.
Expected Residual Time (ERT): 32 bits (OPTIONAL)
This field represents the expected residual transmission time for
the current object, measured in units of 1ms. Senders MUST NOT
include SCT and ERT if the transmission of the current object is
expected to last for more than 2^32-1 time units (approximately 49
days). See Section 3.4 for a detailed description on the use of
this field. This field is only present in Data Packets when T=1.
Desired End Time (DET): 32 bits
This field represents the desired finish time for the transmission
of the object, measured in units of 1ms and computed modulo 2^32
time units. See Section 3.4 for a detailed description on the use
of this field. This field is only present in Request Packets when
T=1.
3.4. Transmission Extensions
Four fields in the packet headers are used to support the Transmission
Extension mechanism: T, SCT, ERT, DET. These fields have the following
purposes:
o to communicate to receivers the expected finish time for the
transmission of the current object
o to let receivers produce requests to extend transmission which are
idempotent.
When a sender is willing to accept extension requests, it will set T=1
in the data packets, and also include the SCT and ERT fields as follows:
o SCT is set to the current time known at the sender, measured in
units of 1ms, and computed modulo 2^32 units.
^L ^L
o ERT is set to the expected residual transmission time, as known to Expected Residual Time (ERT): 32 bits (OPTIONAL)
the sender, and measured in units of 1ms. The maximum value that
can be accommodated in this field is approximately 49 days. A
sender MUST NOT generate these fields if the residual transmission
time is larger than this maximum value.
The Expected Finish Time (EFT) of the transmission at the sender site
can be computed as
EFT = SCT + ERT.
A receiver can determine the Desired Residual Time (DRT) based on
external information, such as the amount of missing data and the
incoming data rate. DRT is the (estimated) transmission extention
needed, measured from the time of estimation to the time of the desired
end of transmission. The maximum value for DRT is 2^32-1 units of 1ms
each. Higher values must be upper bounded to 2^32-1.
A receiver MUST NOT generate Request packets if the reception is likely
to complete before the expected end of the session, i.e. if DRT << ERT .
If a receiver needs to extend the transmission, they compute the Desired
End Time value to be put into Request packets as
DET = SCT + DRT.
The above procedures make requests idempotent. This field represents the sender expected residual transmission
time for the current session, measured in units of 1ms.
This field MUST NOT be present if E=0 and MUST be present if E=1.
3.5. Header-Extension Fields 3.3. Header-Extension Fields
To allow for additional header fields and to extend the size of some of To allow for additional header fields and to extend the size of some of
the predefined fields, the LCT header contains an additional header the predefined fields, the LCT packet header contains an additional
field flag, "X". If "X" is set to 0 then no additional header fields are header field flag, "X". If "X" is set to 0 then no additional header
included within the LCT header beyond the predefined fields. When fields are included within the LCT packet header beyond the predefined
additional headers beyond the predefined fields are used, the value of fields. When additional headers beyond the predefined fields are used,
"X" within the LCT header MUST be set to 1. the value of "X" within the LCT packet header MUST be set to 1.
Examples of use of header extensions include: Examples of use of Header Extensions include:
o extended-size version of already existing header fields. o Extended-size version of already existing header fields.
o Sender and Receiver authentication information. o Sender and Receiver authentication information.
If present, Header Extensions must be processed before performing any If present, Header Extensions MUST be processed to ensure that they are
congestion control procedure or otherwise accepting the packet. Packets recognized before performing any congestion control procedure or
with unrecognised Header Extensions MUST be discarded by the receiving otherwise accepting an LCT packet. LCT packets with unrecognised Header
Extensions MUST be discarded by the receiving agent, hence the expected
^L use of extensions SHOULD be signaled out-of-band before session startup.
agent, hence the expected use of extentions should be signalled out-of-
band before session startup.
There are two formats for Header Extension fields, as depicted below. There are two formats for Header Extension fields, as depicted below.
The first format is used for variable-length extensions, with HET values The first format is used for variable-length extensions, with Header
between 0 and 63. The second format is used for fixed length (one word) Extension Type (HET) values between 0 and 63. The second format is used
extension, using HET values from 64 to 127. for fixed length (one word) extension, using HET values from 64 to 127.
^L
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| HET (<=63) | HEL | | |L| HET (<=63) | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. . . .
. Header Extension Content (HEC) . . Header Extension Content (HEC) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| HET (>=64) | Header Extension Content (HEC) | |L| HET (>=64) | Header Extension Content (HEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 - format of additional headers Figure 5 - Format of additional headers
The explanation of each sub-field is the following. The explanation of each sub-field is the following.
Last Header Extension (L): 1 bit Last Header Extension (L): 1 bit
MUST be set to 1 in the last Header Extension field present in a MUST be set to 1 in the last Header Extension field present in an
packet header, MUST be set to 0 in all the others. LCT packet header, MUST be set to 0 in all the others.
Header Extension Type (HET): 7 bits Header Extension Type (HET): 7 bits
The type of the header extension. This document defines a number The type of the Header Extension. This document defines a number
of possible types. Additional types may be defined in future of possible types. Additional types may be defined in future
version of this specification. HET values from 0 to 63 are used version of this specification. HET values from 0 to 63 are used
for variable-length Header Extensions. HET values from 64 to 127 for variable-length Header Extensions. HET values from 64 to 127
are used for fixed-length Header Extensions. are used for fixed-length Header Extensions.
Header Extension Length (HEL): 8 bits (OPTIONAL) Header Extension Length (HEL): 8 bits
The length of the whole Header Extension field, expressed in The length of the whole Header Extension field, expressed in
multiples of 32-bit words. This field is only present for multiples of 32-bit words. This field MUST be present for
variable-length extensions (HET between 0 and 63) and MUST NOT be
^L present for fixed-length extensions (HET between 64 and 127).
variable-length extension (HET between 0 and 63).
Header Extension Content (HEC): variable length Header Extension Content (HEC): variable length
^L
The content of the Header Extension. The format of this sub-field The content of the Header Extension. The format of this sub-field
depends on the header extension type. For fixed-length header depends on the Header Extension type. For fixed-length Header
extensions, the HEC is 24 bits. For variable-length header Extensions, the HEC is 24 bits. For variable-length Header
extensions, the HEC field has variable size, as specified by the Extensions, the HEC field has variable size, as specified by the
HEL field. Note that the length of each Header Extension field HEL field. Note that the length of each Header Extension field
MUST be a multiple of 32-bit. Also note that the total size of MUST be a multiple of 32 bits. Also note that the total size of
all header extensions plus optional header fields cannot exceed the LCT packet header, including all Header Extensions and all
255 32-bit words. OPTIONAL header fields, cannot exceed 255 32-bit words.
The originator of a packet with header extensions MUST not leave An LCT packet with Header Extensions MUST NOT have space between the end
additional space between the end of the last Header Extension and the of the last Header Extension and the beginning of the LCT packet
beginning of the LCT payload. payload.
All LCT agents MUST support the EXT_NOP header extension. All senders and receivers of LCT packets MUST support the EXT_NOP Header
Extension.
The following header extension types are defined: The following Header Extension types are defined:
EXT_NOP=0 No-Operation extension. EXT_NOP=0 No-Operation extension.
The information present in this extension field MUST be The information present in this extension field MUST be
ignored by receivers. ignored by receivers.
EXT_CCI=1 Congestion Control Information extension. EXT_CCI_V=1 Congestion Control Information extension, variable length.
This extension field extends the CCI field present in the This extension field extends the CCI field present in the
fixed part of the header. It is used when the congestion fixed part of the header. It is used when the congestion
control information does not fit in the 32 bits CCI field. control information does not fit in the 32-bit CCI field.
When this option is present, receivers MUST ignore the CCI When this option is present, the concatenation of the
field and use the value provided in this option instead. 32-bit CCI field in the fixed part of the header together
The interpretation of the data contained in EXT_CCI MUST with the variable length value provided in this option is
be negotiated out-of-band. used as the congestion control information. The
interpretation of the data contained in EXT_CCI_V MUST be
EXT_TOI=2 Tranport Object Identifier extension. negotiated out-of-band. The use of EXT_CCI_V and
This extension field extends the TOI field of the fixed EXT_CCI_F is mutually exclusive.
header. It is used when the Tranport Object Identifier
does not fit in 10 bits. When this option is present,
receivers MUST ignore the TOI field in the fixed header
and use the value provided in this option instead. The
interpretation of the data contained in EXT_TOI MUST be
negotiated out-of-band.
EXT_AUTH=3 Authentication Extension
Information used to authenticate the source of the packet.
^L EXT_AUTH=2 Authentication extension
If present, the format of this header extension and its Information used to authenticate the sender of the LCT
processing must be communicated out-of-band as part of the packet. If present, the format of this Header Extension
session description. and its processing MUST be communicated out-of-band as
It is recommended that senders and receivers provide some part of the session description.
form of authentication on the packet they transmit. If It is RECOMMENDED that senders provide some form of
authentication on the LCT packets they transmit. If
EXT_AUTH is present, whatever authentication checks that EXT_AUTH is present, whatever authentication checks that
can be performed immediately upon reception of the packet can be performed immediately upon reception of the packet
must be performed before accepting the packet and MUST be performed before accepting the packet and
^L
performing any congestion control-related action on it. performing any congestion control-related action on it.
Some authentication schemes impose a delay of several Some authentication schemes impose a delay of several
seconds between when a packet is received and when the seconds between when a packet is received and when the
packet is fully authenticated. Any congestion control packet is fully authenticated. Any congestion control
related action that is appropriate must not be delayed by related action that is appropriate MUST NOT be delayed by
any such full authentication delay. any such full authentication delay.
EXT_CCI_F=65 Congestion Control Information extension, fixed length.
This extension field extends the CCI field present in the
fixed part of the header. It is used when the congestion
control information does not fit in the 32-bit CCI field.
When this option is present, the concatenation of the
32-bit CCI field in the fixed part of the header together
with the 24-bit fixed length value provided in this option
is used as the congestion control information. The
interpretation of the data contained in EXT_CCI_F MUST be
negotiated out-of-band. The use of EXT_CCI_V and
EXT_CCI_F is mutually exclusive.
4. Procedures 4. Procedures
4.1. Sender Operation 4.1. Sender Operation
Before a session starts, an LCT sender MUST make available all Before a session starts, an LCT sender MUST make available all
applicable information regarding the session, including but not limited applicable information regarding the session. This information could
to: include, but is not limited to:
o number of LCT groups;
o addresses, port numbers and data rates used for each LCT group; o The number of LCT channels;
o the format of the payload (for example, the mapping of codepoints o The addresses, port numbers and data rates used for each LCT
used in the session to FEC codec types and parameters); channel;
o the congestion control scheme being used; o The format of the payload. For example, the payload could contain
other protocol headers such as an FEC header. Then for example the
information could include the mapping of codepoints used in the
session to FEC codec types and parameters;
o the Demux Label (DL) value(s) used for the session; o The congestion control scheme being used;
o the authentication scheme being used, and all relevant information o The possible Header Extensions that could be used in the session;
which is necessary for sender authentication purposes;
o the address of the node in charge of receiving Request packets; o The mapping of TOI value(s) to objects for the session;
The session description could be in a form such as SDP [8], XML o The authentication scheme being used, and all relevant information
metadata, HTTP/Mime headers, etc. It might be carried in a session which is necessary for sender authentication purposes;
announcement protocol such as SAP [9], located on a Web page with
^L ^L
The session description could be in a form such as SDP as defined in
RFC2327, XML metadata, HTTP/Mime headers, etc. It might be carried in a
session announcement protocol such as SAP [4], obtained using RCCP
session control as described in [8], located on a Web page with
scheduling information, or conveyed via E-mail or other out of band scheduling information, or conveyed via E-mail or other out of band
methods. Discussion of session description format, and distribution of methods. Discussion of session description format, and distribution of
session descriptions is beyond the scope of this document. session descriptions is beyond the scope of this document.
Within an LCT session, an LCT sender transmits a sequence of data Within an LCT session, an LCT sender transmits a sequence of LCT packets
packets each containing a payload encoded according to one of the codecs each containing a payload encoded according to one of the codecs defined
defined in the session description. Data packets are sent over one or in the session description. LCT packets are sent over one or more LCT
more LCT groups which together constitute a session. Transmission rates channels which together constitute a session. Transmission rates MAY be
may be different in different groups. This document does not specify the different in different channels. This document does not specify the LCT
policy used to place symbols into packets, nor the order in which packet payload, nor the order in which LCT packets are transmitted, nor
packets are transmitted, nor the scheduling of packets in multiple the organization of a session into multiple channels. Although these
groups. Although these issues affect the efficiency of the protocol, issues affect the efficiency of the protocol, they do not affect the
they do not affect the correctness nor the inter-operability between correctness nor the inter-operability between senders and receivers.
senders and receivers.
Multiple transport objects can be carried within the same LCT session. Multiple objects can be carried within the same LCT session. In this
Each object is identified by a unique Transport Object Identifier (TOI). case, each object is identified by a unique TOI. Objects MAY be
Objects MUST be transmitted sequentially, and the TOIs MUST be used in transmitted sequentially, or they MAY be transmitted concurrently.
strict sequential order. A sender is not allowed to transmit packets for
old objects after starting the transmission of packets for a new one.
Note that despite this restriction, both the network and the underlying
protocol layers can cause some reordering of packets, especially when
sent over different LCT groups, and thus receivers MUST NOT assume that
the reception of a packet for a new object means that there are no more
packets in transit for the previous one, at least for some amount of
time.
Typically, the sender(s) continues to send data packets in a session Typically, the sender(s) continues to send LCT packets in a session
until the transmission is considered complete. The transmission may be until the transmission is considered complete. The transmission MAY be
considered complete when some time has expired, a certain number of considered complete when some time has expired, a certain number of
packets have been sent, or some out of band signal (possibly from a packets have been sent, or some out of band signal (possibly from a
higher level protocol) has indicated completion by a sufficient number higher level protocol) has indicated completion by a sufficient number
of receivers. Feedback through LCT Request packets MAY also be used to of receivers.
determine the end of the session.
The specification of the processing of the payload carried in LCT The specification of the processing of the payload carried in LCT
packets is beyond the scope of this document. LCT will only act as a packets is beyond the scope of this document. LCT will act as a
transport layer and will merely implement congestion control and convey transport layer and convey payload and associated information (Codepoint
payload and associated information (Codepoint and TOI) to the receivers. and TOI) to the receivers and any complete protocol using LCT will
implement congestion control .
For the reasons mentioned above, this document does not pose any For the reasons mentioned above, this document does not pose any
restriction on packet sizes. However, network efficiency considerations restriction on LCT packet sizes. However, network efficiency
recommend that the sender uses as large as possible payload size, but in considerations recommend that the sender uses as large as possible
such a way that packets do not exceed the network's maximum transmission payload size, but in such a way that LCT packets do not exceed the
unit size (MTU), or fragmentation coupled with packet loss might network's maximum transmission unit size (MTU), or fragmentation coupled
introduce severe inefficiency in the transmission. with packet loss might introduce severe inefficiency in the
transmission.
It is also recommended that all packets have the same or very similar It is also RECOMMENDED that all LCT packets have the same or very
similar sizes, as this can have a severe impact on the effectiveness of
congestion control schemes such as the ones described in [9]. A sender
of LCT packets MUST implement the sender-side part of one of the
congestion control schemes that is in accordance with RFC2357, and the
^L ^L
sizes, as this can have a severe impact on the effectiveness of
congestion control schemes such as the one described in [1]. An LCT
sender MUST implement the sender-side part of one of the congestion
control schemes that is in accordance with RFC 2357, and the
corresponding receiver congestion control scheme MUST be communicated corresponding receiver congestion control scheme MUST be communicated
out of band and implemented by any receivers participating in the out of band and implemented by any receivers participating in the
session. session.
If a Sender implements the Transmission Extensions, then it MUST operate
as described in Section 3.4.
4.2. Receiver Operation 4.2. Receiver Operation
Receivers can operate differently depending on the delivery service Receivers can operate differently depending on the delivery service
model. For example, for an on demand service model receivers may join a model. For example, for an on demand service model receivers MAY join a
session, obtain the necessary encoding symbols to reproduce the object, session, obtain the necessary encoding symbols to reproduce the object,
and then leave the session. As another example, for a streaming service and then leave the session. As another example, for a streaming service
model a receiver may be continuously joined to a set of multicast groups model a receiver MAY be continuously joined to a set of LCT channels to
to download all objects in a session. download all objects in a session.
To be able to participate in a session, a receiver MUST first obtain the To be able to participate in a session, a receiver MUST first obtain the
relevant session description information as listed in Section 4.1. relevant session description information as listed in Section 4.1.
To be able to participate in a session, a receiver MUST implement the To be able to participate in a session, a receiver MUST implement the
congestion control algorithm specified in the session description. If a congestion control protocol specified in the session description. If a
receiver is not able to implement the congestion control algorithm used receiver is not able to implement the congestion control protocol used
in the session, it MUST NOT join the session. in the session, it MUST NOT join the session.
If source authentication information is present in data packets, it must If sender authentication information is present in an LCT packet header,
be used as specified in Section 3.5. If a receiver is unable to it MUST be used as specified in Section 3.3. If a receiver is unable to
implement the authentication mechanism used by the session, it MUST NOT implement the authentication mechanism used by the session, it MUST NOT
join the session. join the session.
To be able to participate in a session, receivers MUST be able to To be able to be a receiver in a session, the receiver MUST be able to
process the payload of the packets. At a minimum this involves the process the LCT packet header. The receiver MUST be able to discard,
ability to forward or store the payload, and possibly (in case of forward, store or process the LCT packet payload. If a receiver is not
reliable LCT session) determine when an object can be successfully able to process a LCT packet header, it MUST either drop from the
recovered. If a receiver is not able to process the payload of packets, session, or reduce the receive bandwidth to the minimum value allowed by
it MUST either drop from the session, or reduce the receive bandwidth to the congestion control protocol being used.
the minimum value allowed by the congestion control algorithm being
used.
When the session is transmitted on multiple LCT groups, receivers MUST
do it according to the specified startup behaviour of the congestion
control algorithm itself. For a layered transmission on multiple groups,
this typically means that a receiver will only join a minimal set of LCT
groups, possibly a single one. This rule has the purpose of preventing
^L
receivers from starting at high data rates.
If the Transmission Extension Information field is present in data
packets, receivers MAY originate Request packets to extend the
transmission of an object as specified in Section 3.4. Receivers MUST
NOT originate transmission extension request if the T flag in incoming
data packets is set to 0.
Receivers which generate Request packets MUST implement feedback-
implosion avoidance procedures as follows:
o Receivers must use the Expected Finishing 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.
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 T
flag set to 0.
o A receiver MUST cancel pending extension-requests when the
transmission time of an object is over.
The rules stated above are not sufficient to obtain a good implosion When the session is transmitted on multiple LCT channels, receivers MUST
prevention in all the cases. For improved performance the following do it according to the specified startup behavior of the congestion
guidelines SHOULD be followed: control protocol itself. For a layered transmission on multiple
channels, this typically means that a receiver will initially join only
a minimal set of LCT channels, possibly a single one. This rule has the
purpose of preventing receivers from starting at high data rates.
o Extension requests should be *scheduled* only when the reception of Multiple objects can be carried within the same LCT session. In this
the object is in an advanced status of completion (e.g. more than case, each object is identified by a unique TOI. Note that even if a
50%). This improves the accuracy of the receivers' prediction server stops sending LCT packets for an old object before starting to
transmit LCT packets for a new object, both the network and the
underlying protocol layers can cause some reordering of packets,
especially when sent over different LCT channels, and thus receivers
^L ^L
reducing the chance that an extension is requested uselessly.
o The time needed for a Request to suppress pending Request from other MUST NOT assume that the reception of an LCT packet for a new object
receivers is approximatively a packet round trip time (unicast means that there are no more LCT packets in transit for the previous
request to the sender and multicast data packets to the receivers). one, at least for some amount of time.
Using random-time scheduling for requests is an effective
suppression mechanism only if the length of the interval from which A receiver MAY be concurrently joined to multiple LCT sessions. The
the transmission time is selected is much larger than a round trip receiver MUST perform congestion control on each such LCT session. If
time. For this reason extension requests should be *scheduled* at the congestion control protocol allows the receiver some flexibility in
least a few seconds before the end of transmission. terms of its actions within a session then the receiver MAY make choices
to optimize the packet flow performance across the multiple LCT
sessions, as long as the receiver still adheres to the congestion
control rules for each LCT session individually.
5. Security Considerations 5. Security Considerations
LCT can be subject to denial-of-service attacks by attackers which try LCT can be subject to denial-of-service attacks by attackers which try
to confuse the congestion control mechanism, or send forged packets to to confuse the congestion control mechanism, or send forged packets to
the session which would prevent successful reconstruction of large the session which would prevent successful reconstruction of large
portions of the data stream. portions of the data stream.
The same exact problems are present in TCP, where an attacker can forge The same exact problems are present in TCP, where an attacker can forge
packets and either slow down or increase the throughput of the session, packets and either slow down or increase the throughput of the session,
or replace parts of the data stream with forged data. If the stream is or replace parts of the data stream with forged data. If the stream is
carrying compressed or otherwise coded data, even a single forged packet carrying compressed or otherwise coded data, even a single forged packet
could also cause incorrect reconstruction of the rest of the data could also cause incorrect reconstruction of the rest of the data
stream. stream.
It is therefore recommended that LCT agents implement some form of It is therefore RECOMMENDED that LCT agents implement some form of
authentication to protect themselves against such attacks. authentication to protect themselves against such attacks.
6. IANA Considerations 6. IANA Considerations
No information in this specification is subject to IANA registration. No information in this specification is subject to IANA registration.
Building blocks components used by LCT may introduce additional IANA Building blocks components used by LCT may introduce additional IANA
considerations. considerations.
7. Intellectual Property Issues 7. Intellectual Property Issues
No specific codec or congestion control scheme are specified or No specific reliability protocol or congestion control protocol is
referenced as mandatory in this document. specified or referenced as mandatory in this document.
LCT may be used with congestion control protocols and codecs which are LCT MAY be used with congestion control protocols and other protocols
proprietary, or have pending or granted patents. which are proprietary, or have pending or granted patents.
^L ^L
8. Acknowledgments 8. Acknowledgments
Thanks to Bruce Lueckenhoff, Hayder Radha and Vincent Roca for detailed Thanks to Vincent Roca, Bruce Lueckenhoff and Hayder Radha for detailed
comments on this document. comments on this document.
[1] Luby, M., Vicisano, L., Haken, A., "Layered congestion control [1] Byers, J.W., Luby, M., Mitzenmacher, M., and Rege, A., "A Digital
building block", draft-ietf-rmt-bb-lcc-00.txt, November 2000.
[2] Bradner, S., Key words for use in RFCs to Indicate Requirement
Levels (IETF RFC 2119) http://www.rfc-editor.org/rfc/rfc2119.txt
[3] Byers, J.W., Luby, M., Mitzenmacher, M., and Rege, A., "A Digital
Fountain Approach to Reliable Distribution of Bulk Data", Proceedings Fountain Approach to Reliable Distribution of Bulk Data", Proceedings
ACM SIGCOMM '98, Vancouver, Canada, Sept 1998. ACM SIGCOMM '98, Vancouver, Canada, Sept 1998.
[4] Cain, B., Speakman, T., and Towsley, D., "Generic Router Assist [2] Cain, B., Speakman, T., and Towsley, D., "Generic Router Assist
(GRA) Building Block, Motivation and Architecture", Internet Draft (GRA) Building Block, Motivation and Architecture", Internet Draft
draft-ietf-rmt-gra-arch-00.txt, a work in progress. draft-ietf-rmt-gra-arch-00.txt, a work in progress.
[5] Deering, S., "Host Extensions for IP Multicasting", RFC 1058, [3] Gemmell, J., Schooler, E., and Gray, J., "FCast Scalable Multicast
Stanford University, Stanford, CA, 1988.
[6] 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
[7] Gemmell, J., Schooler, E., and Gray, J., "FCast Scalable Multicast
File Distribution: Caching and Parameters Optimizations", Technical File Distribution: Caching and Parameters Optimizations", Technical
Report MSR-TR-99-14, Microsoft Research, Redmond, WA, April, 1999. Report MSR-TR-99-14, Microsoft Research, Redmond, WA, April, 1999.
[8] Handley, M., and Jacobson, V., "SDP: Session Description Protocol", [4] Handley, M., "SAP: Session Announcement Protocol", Internet Draft,
RFC 2327, April 1998. IETF MMUSIC Working Group, Nov 1996, a work in progress.
[9] Handley, M., "SAP: Session Announcement Protocol", Internet Draft,
IETF MMUSIC Working Group, Nov 1996.
[10] Holbrook, H., Cheriton, D., "IP Multicast Channels: Experss Support [5] Holbrook, H., Cain, B., "Source-Specific Multicast for IP", Internet
for Large-scale Single-source Applications", ACM SIGCOMM'99 Draft, SSM Working Group, March 2001, draft-holbrook-ssm-arch-02.txt, a
work in progress.
[11] Luby, M., Gemmell, Vicisano, L., J., Rizzo, L., Handley, M., [6] Luby, M., Gemmell, Vicisano, L., J., Rizzo, L., Handley, M.,
Crowcroft, J., "The use of Forward Error Correction in Reliable Crowcroft, J., "The use of Forward Error Correction in Reliable
Multicast", Internet Draft draft-ietf-rmt-info-fec-00.txt, November Multicast", Internet Draft draft-ietf-rmt-info-fec-00.txt, November
2000. 2000, a work in progress.
[12] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M., [7] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M.,
Crowcroft, J., "RMT BB Forward Error Correction Codes", Internet Draft
draft-ietf-rmt-bb-fec-03.txt, July 2001.
^L [8] Luby, M., Hernek, D., Kushi, D., Rasmussen, L., Simu, S., Vainish,
R., "Rich Content Control Protocol: A session control protocol
instantiation", Digital Fountain document, a work in progress.
Crowcroft, J., "RMT BB: Forward Error Correction Codes", Internet Draft [9] Luby, M., Vicisano, L., Haken, A., "RMT BB Layered congestion
draft-ietf-rmt-bb-fec-01.txt, November 2000. control", draft-ietf-rmt-bb-lcc-00.txt, November 2000, a work in
progress.
[13] Mankin, A., Romanow, A., Brander, S., Paxson, V., "IETF Criteria [10] Rizzo, L., "Effective Erasure Codes for Reliable Computer
for Evaluating Reliable Multicast Transport and Application Protocols," Communication Protocols", ACM SIGCOMM Computer Communication Review,
RFC2357, June 1998. Vol.27, No.2, pp.24-36, Apr 1997.
[14] J. Postel, "User Datagram Protocol", RFC768, August 1980. ^L
[15] Rizzo, L, and Vicisano, L., "Reliable Multicast Data Distribution [11] Perrig, A., Canetti, R., Briscoe, B., Tygar, D., Song, D., "TESLA:
Multicast Source Authentication Transform", draft-irtf-smug-
tesla-00.txt, November, 2000, a work in progress.
[12] Rizzo, L, and Vicisano, L., "Reliable Multicast Data Distribution
protocol based on software FEC techniques", Proceedings of the Fourth protocol based on software FEC techniques", Proceedings of the Fourth
IEEES Workshop on the Architecture and Implementation of High IEEES Workshop on the Architecture and Implementation of High
Performance Communication Systems, HPCS'97, Chalkidiki, Greece, June Performance Communication Systems, HPCS'97, Chalkidiki, Greece, June
1997. 1997.
[16] Rizzo, L., "Effective Erasure Codes for Reliable Computer [13] Speakman, T., Farinacci, D., Crowcroft, J., Gemmell, J., Lin, S.,
Communication Protocols", ACM SIGCOMM Computer Communication Review, Tweedly, A., Leshchiner, D., Luby, M., Bhaskar, N., Edmonstone, R.,
Vol.27, No.2, pp.24-36, Apr 1997. Johnson, K., Montgomery, T., Rizzo, L., Sumanasekera, R., Vicisano, L.,
"PGM Reliable Transport Protocol", draft-speakman-pgm-spec-06.txt, a
work in progress.
[17] Vicisano, L., Rizzo, L., Crowcroft, J., "TCP-like Congestion [14] Vicisano, L., Rizzo, L., Crowcroft, J., "TCP-like Congestion
Control for Layered Multicast Data Transfer", IEEE Infocom '98, San Control for Layered Multicast Data Transfer", IEEE Infocom '98, San
Francisco, CA, Mar.28-Apr.1 1998. Francisco, CA, Mar.28-Apr.1 1998.
[18] Vicisano, L., "Notes On a Cumulative Layered Organization of Data [15] Vicisano, L., "Notes On a Cumulative Layered Organization of Data
Packets Across Multiple groups with Different Rates", University College Packets Across Multiple groups with Different Rates", University College
London Computer Science Research Note RN/98/25, Work in Progress (May London Computer Science Research Note RN/98/25, Work in Progress (May
1998). 1998).
9. Authors' Addresses 9. Authors' Addresses
Michael Luby Michael Luby
luby@digitalfountain.com luby@digitalfountain.com
Digital Fountain Digital Fountain
600 Alabama Street 39141 Civic Center Drive
San Francisco, CA, USA, 94110 Suite 300
Fremont, CA, USA, 94538
Jim Gemmell Jim Gemmell
jgemmell@microsoft.com jgemmell@microsoft.com
Microsoft Research Microsoft Research
301 Howard St., #830 301 Howard St., #830
San Francisco, CA, USA, 94105 San Francisco, CA, USA, 94105
Lorenzo Vicisano Lorenzo Vicisano
lorenzo@cisco.com lorenzo@cisco.com
cisco Systems, Inc. cisco Systems, Inc.
170 West Tasman Dr., 170 West Tasman Dr.,
^L
San Jose, CA, USA, 95134 San Jose, CA, USA, 95134
^L
Luigi Rizzo Luigi Rizzo
luigi@iet.unipi.it luigi@iet.unipi.it
ACIRI/ICSI, ACIRI/ICSI,
1947 Center St, Berkeley, CA, USA, 94704 1947 Center St, Berkeley, CA, USA, 94704
and and
Dip. Ing. dell'Informazione, Dip. Ing. dell'Informazione,
Univ. di Pisa Univ. di Pisa
via Diotisalvi 2, 56126 Pisa, Italy via Diotisalvi 2, 56126 Pisa, Italy
Mark Handley Mark Handley
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/