a suppression mechanism similar to that described for NACK
suppression my be used. The "age" of receivers’ RTT measurement
should be kept by receivers and used as a metric in competing for
feedback opportunities in the suppression scheme. For example,
receiver who have not made any RTT measurement or whose RTT
measurement has aged most should have precedence over other
receivers. In turn the sender may have limited capacity to provide
an "echo" of the receiver timestamps back to the group, and it could
use this RTT "age" metric to determine which receivers get
precedence. The sender can determine the GRTT as described in 3.7.1
if it provides sender timestamps to the group. Alternatively,
receivers who note their RTT is greater than the sender GRTT can
compete in the feedback opportunity/suppression scheme to provide the
sender and group with this information.
3.7.3. Many-to-Many RTT Measurement
For reliable multicast sessions that involve multiple senders, it may
be useful to have RTT measurements occur on a true "many-to-many"
basis rather than have each sender independently tracking RTT. Some
protocol efficiency can be gained when receivers can infer an
approximation of their RTT with respect to a sender based on RTT
information they have on another sender and that other sender’s RTT
with respect to the new sender of interest. For example, for
receiver "a" and sender’s "b" and "c", it is likely that:
RTT(a<->b) <= RTT(a<->c)) + RTT(b<->c)
Further refinement of this estimate can be conducted if RTT
information is available to a node concerning its own RTT to a small
subset of other group members and RTT information among those other
group members it learns during protocol operation.
3.7.4. Sender GRTT Advertisement
To facilitate deterministic NORM protocol operation, the sender
should robustly advertise its current estimation of GRTT to the
receiver set. Common, robust knowledge of the sender’s current
operating GRTT estimate among the group will allow the protocol to
progress in its most efficient manner. The sender’s GRTT estimate
can be robustly advertised to the group by simply embedding the
estimate into all pertinent messages transmitted by the sender. The
overhead of this can be made quite small by quantizing (compressing)
the GRTT estimate to a single byte of information. The following C-
language functions allows this to be done over a wide range (RTT_MIN
through RTT_MAX) of GRTT values while maintaining a greater range of
precision for small GRTT values and less precision for large values.
Values of 1.0e-06 seconds and 1000 seconds are RECOMMENDED for
RTT_MIN and RTT_MAX respectively. NORM applications may wish to
place an additional, smaller upper limit on the GRTT advertised by
senders to meet application data delivery latency constraints at the
expense of greater feedback volume in some network environments.
unsigned char QuantizeGrtt(double grtt)
{
if (grtt > RTT_MAX)
grtt = RTT_MAX;
else if (grtt < RTT_MIN)
grtt = RTT_MIN;
if (grtt < (33*RTT_MIN))
return ((unsigned char)(grtt / RTT_MIN) - 1);
else
return ((unsigned char)(ceil(255.0-
(13.0 * log(RTT_MAX/grtt)))));
}
double UnquantizeRtt(unsigned char qrtt)
{
return ((qrtt <= 31) ?
(((double)(qrtt+1))*(double)RTT_MIN) :
(RTT_MAX/exp(((double)(255-qrtt))/(double)13.0)));
}
Note that this function is useful for quantizing GRTT times in the
range of 1 microsecond to 1000 seconds. Of course, NORM protocol
implementations may wish to further constrain advertised GRTT
estimates (e.g., limit the maximum value) for practical reasons.
3.8. Group Size Determination/Estimation
When NORM protocol operation includes mechanisms that excite feedback
from the group at large (e.g., congestion control), it may be
possible to roughly estimate the group size based on the number of
feedback messages received with respect to the distribution of the
probabilistic suppression mechanism used. Note the timer-based
suppression mechanism described in this document does not require a
very accurate estimate of group size to perform adequately. Thus, a
rough estimate, particularly if conservatively managed, may suffice.
Group size may also be determined administratively. In absence of a
group size determination mechanism a default group size value of
10,000 is RECOMMENDED for reasonable management of feedback given the
scalability of expected NORM usage.
3.9. Congestion Control Operation
Congestion control that fairly shares available network capacity
with other reliable multicast and TCP instantiations is REQUIRED for
general Internet operation. The TCP-Friendly Multicast Congestion
Control (TFMCC) [16] or Pragmatic General Multicast Congestion
Control (PGMCC) techniques [17] may be applied to NORM operation to
meet this requirement.
3.10. Router/Intermediate System Assistance
NACK-oriented protocols may benefit from general purpose router
assistance. In particular, additional NACK suppression where routers
or intermediate systems can aggregate NACK content (or filter
duplicate NACK content) from receivers as it is relayed toward the
sender could enhance NORM group size scalability. For NORM protocols
using FEC, it is possible that intermediate systems may be able to
filter FEC repair messages to provide an intelligent "subcast" of
repair content to different legs of the multicast topology depending
on the repair needs learned from previous receiver NACKs. Both of
these types of assist functions would require router interpretation
of transport data unit content identifiers and flags.
3.11. NORM Applicability
The NORM building block applies to protocols wishing to employ
negative acknowledgement to achieve reliable data transfer. Properly
designed negative-acknowledgement (NACK)-oriented reliable multicast
(NORM) protocols offer scalability advantages for applications and/or
network topologies where, for various reasons, it is prohibitive to
construct a higher order delivery infrastructure above the basic
Layer 3 IP multicast service (e.g., unicast or hybrid
unicast/multicast data distribution trees). Additionally, the
scalability property of NACK-oriented protocols [18], [19] is
applicable where broad "fan-out" is expected for a single network hop
(e.g., cable-TV data delivery, satellite, or other broadcast
communication services). Furthermore, the simplicity of a protocol
based on "flat" group-wide multicast distribution may offer
advantages for a broad range of distributed services or dynamic
networks and applications. NORM protocols can make use of reciprocal
(among senders and receivers) multicast communication under the Any-
Source Multicast (ASM) model defined in RFC 1112 [2], and are capable
of scalable operation in asymmetric topologies such as Single-Source
Multicast (SSM) [8] where there may only be unicast routing service
from the receivers to the sender(s).
NORM operation is compatible with transport layer forward error
correction coding techniques as described in [13] and congestion
control mechanisms such as those described in [16] and [17]. A
principal limitation of NORM operation involves group size
scalability when network capacity for receiver feedback is very
limited. NORM operation is also governed by implementation buffering
constraints. Buffering greater than that required for typical
point-to-point reliable transport (e.g., TCP) is recommended to allow
for disparity in the receiver group connectivity and to allow for the
feedback delays required to attain group size scalability.
4. Security Considerations
NORM protocols are expected to be subject to the same sort of
security vulnerabilities as other IP and IP multicast protocols.
NORM is compatible with IP security (IPsec) authentication mechanisms
[20] that are RECOMMENDED for protection against session intrusion
and denial of service attacks. A particular threat for NACK based
protocols is that of NACK replay attacks that would prevent a NORM
sender from making forward progress in transmission. Any standard
IPsec mechanisms that can provide protection against such replay
attacks are RECOMMENDED for use. Additionally, NORM protocol
instantiations SHOULD consider providing support for their own NACK
replay attack protection when network layer mechanisms are not
available. The IETF Multicast Security (msec) Working Group is also
developing solutions which may be applicable to NORM in the future.
5. Acknowledgements (and these are not Negative)
The authors would like to thank Rick Jones, and Joerg Widmer for
their valuable comments on this document. The authors would also
like to thank the RMT working group chairs, Roger Kermode and Lorenzo
Vicisano, for their support in development of this specification, and
Sally Floyd for her early inputs into this document.
6. References
6.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, August 1989.
6.2. Informative References
[3] Mankin, A., Romanow, A., Bradner, S., and V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC 2357, June 1998.
[4] Clark, D. and D. Tennenhouse, "Architectural Considerations for
a New Generation of Protocols". In Proc. ACM SIGCOMM, pages
201--208, September 1990.
[5] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable
Multicast Transport (RMT) Building Blocks and Protocol
Instantiation documents", RFC 3269, April 2002.
[6] Nonnenmacher, J. and E. Biersack, "Optimal Multicast Feedback,"
in IEEE Infocom, San Francisco, California, p. 964, March/April
1998.
[7] Macker, J. and R. Adamson, "Quantitative Prediction of Nack
Oriented Reliable Multicast (NORM) Feedback", Proc. IEEE MILCOM
2002, October 2002.
[8] Holbrook, H., "A Channel Model for Multicast", Ph.D.
Dissertation, Stanford University, Department of Computer
Science, Stanford, California, August 2001.
[9] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and
J. Crowcroft, "Forward Error Correction (FEC) Building Block",
RFC 3452, December 2002.
[10] Floyd, S., Jacobson, V., McCanne, S., Liu, C., and L. Zhang. "A
Reliable Multicast Framework for Light-weight Sessions and
Application Level Framing", Proc. ACM SIGCOMM, August 1995.
[11] Metzner, J., "An Improved Broadcast Retransmission Protocol",
IEEE Transactions on Communications, Vol. Com-32, No.6, June
1984.
[12] Macker, J., "Reliable Multicast Transport and Integrated
Erasure-based Forward Error Correction", Proc. IEEE MILCOM 97,
October 1997.
[13] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and
J. Crowcroft, "The Use of Forward Error Correction (FEC) in
Reliable Multicast", RFC 3453, December 2002.
[14] Gossink, D. and J. Macker, "Reliable Multicast and Integrated
Parity Retransmission with Channel Estimation", IEEE GLOBECOM
98’.
[15] Ozdemir, V., Muthukrishnan, S., and I. Rhee, "Scalable, Low-
Overhead Network Delay Estimation", NCSU/AT&T White Paper,
February 1999.
[16] Widmer, J. and M. Handley, "Extending Equation-Based Congestion
Control to Multicast Applications", Proc ACM SIGCOMM 2001, San
Diego, August 2001.
[17] Rizzo, L., "pgmcc: A TCP-Friendly Single-Rate Multicast
Congestion Control Scheme", Proc ACM SIGCOMM 2000, Stockholm,
August 2000.
[18] Pingali, S., Towsley, D., and J. Kurose, "A Comparison of
Sender-Initiated and Receiver-Initiated Reliable Multicast
Protocols". In Proc. INFOCOM, San Francisco, CA, October 1993.
[19] B.N. Levine, J.J. Garcia-Luna-Aceves, "A Comparison of Known
Classes of Reliable Multicast Protocols", Proc. International
Conference on Network Protocols (ICNP-96), Columbus, Ohio, Oct
29--Nov 1, 1996.
[20] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
7. Authors’ Addresses
Brian Adamson
Naval Research Laboratory
Washington, DC 20375
EMail: adamson@itd.nrl.navy.mil
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
D-28334 Bremen, Germany
EMail: cabo@tzi.org
Mark Handley
Department of Computer Science
University College London
Gower Street
London
WC1E 6BT
UK
EMail: M.Handley@cs.ucl.ac.uk
Joe Macker
Naval Research Laboratory
Washington, DC 20375
EMail: macker@itd.nrl.navy.mil
Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF’s procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.