network's maximum transmission unit size (MTU), or when fragmentation
coupled with packet loss might introduce severe inefficiency in the
transmission.
It is recommended that all 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 [22], [3],
and [25]. A sender of packets using LCT MUST implement the sender-
side part of one of the congestion control schemes that is in
accordance with RFC2357 [13] using the Congestion Control
Information field provided in the LCT header, and the corresponding
receiver congestion control scheme is to be communicated out-of-band
and MUST be implemented by any receivers participating in the
session.
6.2 Receiver Operation
Receivers can operate differently depending on the delivery service
model. For example, for an on demand service model, receivers may
join a session, obtain the necessary packets to reproduce the object,
and then leave the session. As another example, for a streaming
service model, a receiver may be continuously joined to a set of LCT
channels to download all objects in a session.
To be able to participate in a session, a receiver MUST obtain the
relevant session description information as listed in Section 6.1.
If packet authentication information is present in an LCT header, it
SHOULD be used as specified in Section 5.2. To be able to be a
receiver in a session, the receiver MUST be able to process the LCT
header. The receiver MUST be able to discard, forward, store or
process the other headers and the packet payload. If a receiver is
not able to process a LCT header, it MUST drop from the session.
To be able to participate in a session, a receiver MUST implement the
congestion control protocol specified in the session description
using the Congestion Control Information field provided in the LCT
header. If a receiver is not able to implement the congestion control
protocol used in the session, it MUST NOT join the session. When the
session is transmitted on multiple LCT channels, receivers MUST
initially join channels according to the specified startup behavior
of the congestion control protocol. For a multiple rate congestion
control protocol that uses multiple channels, this typically means
that a receiver will initially join only a minimal set of LCT
channels, possibly a single one, that in aggregate are carrying
packets at a low rate. This rule has the purpose of preventing
receivers from starting at high data rates.
Several objects can be carried either sequentially or concurrently
within the same LCT session. In this case, each object is identified
by a unique TOI. Note that even if a server stops sending packets
for an old object before starting to transmit 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 SHOULD 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.
A receiver MAY be concurrently joined to multiple LCT sessions from
one or more senders. The receiver MUST perform congestion control on
each such LCT session. If the congestion control protocol allows the
receiver some flexibility in terms of its actions within a session
then the receiver MAY make choices to optimize the packet flow
performance across the multiple LCT sessions, as long as the receiver
still adheres to the congestion control rules for each LCT session
individually.
7. Requirements from Other Building Blocks
As described in RFC3048 [23], LCT is a building block that is
intended to be used, in conjunction with other building blocks, to
help specify a protocol instantiation. A congestion control building
block that uses the Congestion Control information field within the
LCT header MUST be used by any protocol instantiation that uses LCT,
and other building blocks MAY also be used, such as a reliability
building block.
The congestion control MUST be applied to the LCT session as an
entity, i.e., over the aggregate of the traffic carried by all of the
LCT channels associated with the LCT session. Some possible schemes
are specified in [22], [3], and [25]. The Congestion Control
Information field in the LCT header is an opaque field that is
reserved to carry information related to congestion control. There
MAY also be congestion control Header Extension fields that carry
additional information related to congestion control.
The particular layered encoder and congestion control protocols used
with LCT have an impact on the performance and applicability of LCT.
For example, some layered encoders used for video and audio streams
can produce a very limited number of layers, thus providing a very
coarse control in the reception rate of packets by receivers in a
session. When LCT is used for reliable data transfer, some FEC
codecs are inherently limited in the size of the object they can
encode, and for objects larger than this size the reception overhead
on the receivers can grow substantially.
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 MAY be used in conjunction with LCT for reliable content
delivery are specified in [12]. The Codepoint field in the LCT
header is an opaque field that can be used to carry information
related to the encoding of the packet payload.
LCT also requires receivers to obtain a session description, as
described in Section 6.1. The session description could be in a form
such as SDP as defined in RFC2327 [8], or XML metadata as defined in
RFC3023 [14], or HTTP/Mime headers as defined in RFC2068 [6], and
distributed with SAP as defined in RFC2974 [9], using HTTP, or in
other ways. It is RECOMMENDED that an authentication protocol such
as IPSEC [11] be used to deliver the session description to receivers
to ensure the correct session description arrives.
It is recommended that LCT implementors use some packet
authentication scheme to protect the protocol from attacks. An
example of a possibly suitable scheme is described in [15].
Some protocol instantiations that use LCT MAY use building blocks
that require the generation of feedback from the receivers to the
sender. However, the mechanism for doing this is outside the scope
of LCT.
8. Security Considerations
LCT can be subject to denial-of-service attacks by attackers which
try to confuse the congestion control mechanism, or send forged
packets to the session which would prevent successful reconstruction
or cause inaccurate reconstruction of large portions of an object by
receivers. LCT is particularly affected by such an attack since many
receivers may receive the same forged packet. It is therefore
RECOMMENDED that an integrity check be made on received objects
before delivery to an application, e.g., by appending an MD5 hash
[17] to an object before it is sent and then computing the MD5 hash
once the object is reconstructed to ensure it is the same as the sent
object. Moreover, in order to obtain strong cryptographic integrity
protection a digital signature verifiable by the receiver SHOULD be
computed on top of such a hash value. It is also RECOMMENDED that
protocol instantiations that use LCT implement some form of packet
authentication such as TESLA [15] to protect against such attacks.
Finally, it is RECOMMENDED that Reverse Path Forwarding checks be
enabled in all network routers and switches along the path from the
sender to receivers to limit the possibility of a bad agent injecting
forged packets into the multicast tree data path.
Another vulnerability of LCT is the potential of receivers obtaining
an incorrect session description for the session. The consequences
of this could be that legitimate receivers with the wrong session
description are unable to correctly receive the session content, or
that receivers inadvertently try to receive at a much higher rate
than they are capable of, thereby disrupting traffic in portions of
the network. To avoid these problems, it is RECOMMENDED that
measures be taken to prevent receivers from accepting incorrect
Session Descriptions, e.g., by using source authentication to ensure
that receivers only accept legitimate Session Descriptions from
authorized senders.
A receiver with an incorrect or corrupted implementation of the
multiple rate congestion control building block may affect health of
the network in the path between the sender and the receiver, and may
also affect the reception rates of other receivers joined to the
session. It is therefore RECOMMENDED that receivers be required to
identify themselves as legitimate before they receive the Session
Description needed to join the session. How receivers identify
themselves as legitimate is outside the scope of this document.
9. IANA Considerations
No information in this specification is subject to IANA registration.
Building blocks used in conjunction with LCT MAY introduce additional
IANA considerations.
10. Acknowledgments
Thanks to Vincent Roca and Roger Kermode for detailed comments and
contributions to this document. Thanks also to Bruce Lueckenhoff,
Hayder Radha and Justin Chapweske for detailed comments on this
document.
11. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[3] Byers, J.W., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M.,
Roetter, A. and W. Shaver, "FLID-DL: Congestion Control for
Layered Multicast", Proceedings of Second International Workshop
on Networked Group Communications (NGC 2000), Palo Alto, CA,
November 2000.
[4] Byers, J.W., Luby, M., Mitzenmacher, M. and A. Rege, "A Digital
Fountain Approach to Reliable Distribution of Bulk Data",
Proceedings ACM SIGCOMM'98, Vancouver, Canada, September 1998.
[5] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, August 1989.
[6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2616, January 1997.
[7] Gemmell, J., Schooler, E. and J. Gray, "Fcast Multicast File
Distribution", IEEE Network, Vol. 14, No. 1, pp. 58-68, January
2000.
[8] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC2327, April 1998.
[9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
Protocol", RFC2974, October 2000.
[10] Holbrook, H. W., "A Channel Model for Multicast", Ph.D.
Dissertation, Stanford University, Department of Computer
Science, Stanford, California, August 2001.
[11] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and
J. Crowcroft, "The Use of Forward Error Correction (FEC) in
Reliable Multicast", RFC3453, December 2002.
[12] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and
J. Crowcroft, "Forward Error Correction (FEC) Building Block",
RFC3452, December 2002.
[13] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC2357, June 1998.
[14] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[15] Perrig, A., Canetti, R., Song, D. and J.D. Tygar, "Efficient and
Secure Source Authentication for Multicast", Network and
Distributed System Security Symposium, NDSS 2001, pp. 35-46,
February 2001.
[16] Postel, J., "User Datagram Protocol", STD 6, RFC768, August
1980.
[17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC1321, April
1992.
[18] Rizzo, L., "Effective Erasure Codes for Reliable Computer
Communication Protocols", ACM SIGCOMM Computer Communication
Review, Vol.27, No.2, pp.24-36, Apr 1997.
[19] Rizzo, L, "PGMCC: A TCP-friendly single-rate multicast
congestion control scheme", Proceedings of SIGCOMM 2000,
Stockholm Sweden, August 2000.
[20] Rizzo, L and L. Vicisano, "Reliable Multicast Data Distribution
protocol based on software FEC techniques", Proceedings of the
Fourth IEEES Workshop on the Architecture and Implementation of
High Performance Communication Systems, HPCS'97, Chalkidiki
Greece, June 1997.
[21] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[22] Vicisano, L., Rizzo, L. and J. Crowcroft, "TCP-like Congestion
Control for Layered Multicast Data Transfer", IEEE Infocom'98,
San Francisco, CA, Mar.28-Apr.1 1998.
[23] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S.
and M. Luby, "Reliable Multicast Transport Building Blocks for
One-to-Many Bulk-Data Transfer", RFC3048, January 2001.
[24] Kermode, R., Vicisano, L., "Author Guidelines for Reliable
Multicast Transport (RMT) Building Blocks and Protocol
Instantiation documents", RFC3269, April 2002.
[25] Luby, M., Goyal V. K, Skaria S., Horn, G., "Wave and Equation
Based Rate Control using Multicast Round-trip Time", Proceedings
of ACM SIGCOMM 2002, Pittsburgh PA, August, 2002.
Authors' Addresses
Michael Luby
Digital Fountain
39141 Civic Center Dr.
Suite 300
Fremont, CA, USA, 94538
EMail: luby@digitalfountain.com
Jim Gemmell
Microsoft Research
455 Market St. #1690
San Francisco, CA, 94105
EMail: jgemmell@microsoft.com
Lorenzo Vicisano
cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA, USA, 95134
EMail: lorenzo@cisco.com
Luigi Rizzo
Dip. Ing. dell'Informazione,
Univ. di Pisa
via Diotisalvi 2, 56126 Pisa, Italy
EMail: luigi@iet.unipi.it
Mark Handley
ICIR
1947 Center St.
Berkeley, CA, USA, 94704
EMail: mjh@icir.org
Jon Crowcroft
Marconi Professor of Communications Systems
University of Cambridge
Computer Laboratory
William Gates Building
J J Thomson Avenue
Cambridge CB3 0FD, UK
EMail: Jon.Crowcroft@cl.cam.ac.uk
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.