interface on the sending system reports an error to SRT when the
attempt to send the SRT message is made, an implementation may
attempt to resend the message any finite number of times.
However, every implementation MUST provide a mode in which no
retries are attempted. Implementations should default to this
latter mode of operation. The implementation MUST report to the
application whether the message was ultimately accepted by UDP.
4. If some user-configurable "ACK_Threshold" (which should be greater
than the worst-case round-trip time for the multicast group)
elapses without receipt of an ACK for the Mode 2 message, it is
retransmitted. An implementation may define a maximum number of
retransmissions to be attempted before the Mode 2 message is
removed from the buffer.
5.3.2. Receiving Mode 2 Data Messages
When a Mode 2 data message is received by SRT, it should be processed
as follows after verifying version, dataID, sender address, and SN:
1. For Mode 2 messages, the sequence number field is used to
associate the required positive acknowledgement with a specific
Mode 2 message. If the message passes verification, the
encapsulated user data is delivered to all applications that have
indicated interest in the dataID and multicast address of the
received message, regardless of the value of the SN field.
2. Additionally, an ACK MUST be sent to the host from which the Mode
2 data message originated. See section 5.3.3. below for details.
5.3.3. Sending a Positive Acknowledgement
A positive acknowledgement (ACK) is triggered by the receipt of a
Mode 2 data message. To send an ACK, a new SRT message is generated
with version set to 0x02, message type set to 0x2, and transmission
mode set to 0x2. The dataID and SN are those of the Mode 2 data
message being acknowledged. The destination address field is set to
the source IP address from which the data message was received.
Since Mode 2 data messages are unicast, there is little concern about
an ACK implosion causing excessive congestion at the original sender,
so no suppression mechanism is necessary.
5.3.4. Receiving a Positive Acknowledgement
When an ACK is received by SRT, after verifying the transmission
mode, dataID, and source IP address against outstanding Mode 2
transmission, SRT MUST remove the pending transmission from its
buffer.
6. RFC 2357 Analysis
This section provides answers to the questions posed by RFC 2357 for
reliable multicast protocols, which are quoted.
6.1. Scalability
"How scalable is the protocol to the number of senders or receivers
in a group, the number of groups, and wide dispersion of group
members?"
SRMP is intended to scale at least to hundreds of group members. It
has been designed not to impose limitations on the scalability of the
underlying multicast network. No problems have been identified in
its mechanisms that would preclude this on uncongested networks.
"Identify the mechanisms which limit scalability and estimate those
limits."
There is a practical concern with use of TFMCC, in that the receiver
with the most congested path constrains delivery to the entire group.
Distributed virtual simulation requires data delivery at rates
perceived as continuous by humans. Therefore, it may prove necessary
to assign such receivers to different, lower-fidelity groups as a
practical means of sustaining performance to the majority of
participating hosts. SRMP does not have a mechanism to support such
pruning at this time.
6.2. Congestion
"How does the protocol protect the Internet from congestion? How
well does it perform? When does it fail? Under what circumstances
will the protocol fail to perform the functions needed by the
applications it serves? Is there a congestion control mechanism?
How well does it perform? When does it fail?"
Both simulations and tests indicate that SRMP with TFMCC displays
backoff comparable to that of TCP under conditions of significant
packet loss. The mechanism fails in a network-friendly way, in that
under severe congestion, it reduces sending of the best-effort
traffic to a very small rate that typically is unsatisfactory to
support a virtual simulation. This is possible because the reliable
traffic typically is a small percentage of the overall traffic and
SRMP is NACK oriented, with NACK suppression, so that reliable
traffic loss adds little traffic to the total. If the traffic mix
assumption is not met, the reliable traffic (which does not back off
under increased RTT) could produce a higher level of traffic than a
comparable TCP connection. However, levels of reliable traffic this
large are not in the intended application domain of SRMP.
"Include a description of trials and/or simulations which support the
development of the protocol and the answers to the above questions."
SRMP has been simulated using a discrete event simulator developed
for academic use [8]. The design assumptions were validated by the
results. It also has been emulated in a LAN-based cluster and
application-tested in a wide-area testbed under its intended traffic
mix (distributed virtual simulation) and using a traffic generator
with losses emulated by random dropping of packets [9].
"Include an analysis of whether the protocol has congestion avoidance
mechanisms strong enough to cope with deployment in the Global
Internet, and if not, clearly document the circumstances in which
congestion harm can occur. How are these circumstances to be
prevented?"
Because it provides sending backoff comparable to TCP, SRMP is able
to function as well as TCP for congestion avoidance, even in the
Global Internet. The only way an SRMP sender can generate congestion
is to use the protocol for unintended purposes, for example, reliable
transmission of a large fraction of the traffic. Doing this would
produce unsatisfactory results for the application, as SRMP’s
mechanism for providing reliability will not function well if the
best-effort traffic does not constitute the majority of the total
traffic.
"Include a description of any mechanisms which contain the traffic
within limited network environments."
SRMP has no such mechanisms, as it is intended for use over the open
Internet.
"Reliable multicast protocols must include an analysis of how they
address a number of security and privacy concerns."
See section 7 below.
7. Security Considerations
As a transport protocol, SRMP is subject to denial of service by
hostile third parties sending conflicting values of its parameters on
the multicast address. SRMP could attempt to protect itself from
this sort of behavior. However, it can be shielded from such attacks
by traffic authentication at the network layer, as described below.
A comparable level of authentication also could be obtained by a
message using MD5, or a similar message hash in each bundle, and
using the SRMP bundle header to detect duplicate transmissions from a
given host. However, this would duplicate the function of existing
network layer authentication protocols.
Specific threats that can be eliminated by packet-level
authentication are as follows:
a. Amplification attack: SRMP receivers could be manipulated into
sending large amounts of NACK traffic, which could cause network
congestion or overwhelm the processing capabilities of a sender.
This could be done by sending them faked traffic indicating that a
reliable transmission has been lost. SRMP’s NACK suppression
limits the effect of such manipulation. However, true protection
requires authentication of each bundle.
b. Denial-of-service attack: If an SRMP sender accepts a large number
of forged NACKs, it will flood the multicast group with repair
messages. This attack also is stopped by per-bundle
authentication.
c. Replay attack: The attacker could copy a valid, authenticated
bundle containing a NACK and send it repeatedly to the original
sender of the NACKed data. Protection against this attack
requires a sequence number per transmission per source host. The
SRMP bundle header sequence number would satisfy this need.
However, the SN also can be applied at a lower layer.
d. Reverse path forwarding attack (spoofing): If checks are not
enabled in all network routers and switches along the path from
each sender to all receivers, forged packets can be injected into
the multicast tree data path to manipulate the protocol into
sending a large volume of repairs. Packet-level authentication
can eliminate this possibility.
e. Inadvertent errors: A receiver with an incorrect or corrupted
implementation of TFMCC could respond with values of RTT that
might stimulate a TFMCC sender to create or increase congestion in
the path to that sender. 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.
The required authentication could become part of SRMP or could be
accomplished by a lower layer protocol. In any case, it needs to be
(1) scalable and (2) not very computationally demanding so it can be
performed with minimal delay on a real-time virtual simulation
stream. Public-key encryption meets the first requirement but not
the second. Using the IPsec Authentication Header (AH) (RFC 4302
[3]) meets the second requirement using symmetric-key cryptography.
However, RFC 4302 guidance is that a separate Security Association
(SA) should be established for each sender-receiver pair so that no
host in the group can spoof traffic from another source. This
approach is not scalable over a large number of multicast group
members. Moving the authentication function to SRMP would introduce
the same problem. If the policy is to trust all hosts that are
legitimate senders, IPsec AH with one SA per multicast group meets
both requirements. If the guidance in RFC 4302 is treated as policy,
no scalable solution is known to exist. In practice, users of
distributed simulation are likely to work over a (possibly virtual)
private network and thus will not need special authentication for
SRMP. For those who do not, it is RECOMMENDED that users of SRMP
over the open Internet should use the IPsec AH but, in so doing, must
accept the risk of the unlikely case where a member of the trusted
group of hosts undertakes an attack on the group by masquerading as
another group member.
8. List of Acronyms Used
ACK - positive acknowledgement
AH - Authentication Header
CLR - current limiting receiver
IPSEC - Internet Protocol Security
MTU - maximum transmission unit
NACK - negative acknowledgement
RTT - round-trip time
SA - security association
SRMP - Selectively Reliable Multicast Protocol
SRT - Selectively Reliable Transport
TFMCC - TCP-Friendly Multicast Congestion Control
9. Contributions
We gratefully acknowledge the significant contributions of two
people without whom this RFC would not have been developed.
Vincent Laviano created the first specification and implementation
of SRMP (at that time called SRTP). Babu Shanmugam employed SRMP
in a sizable distributed virtual simulation environment, where he
revised the implementation and helped revise the design to support
distributed virtual simulation workload effectively.
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] J. Widmer, M. Handley, Extending Equation-Based Congestion
Control to Multicast Applications, ACM SIGCOMM Conference, San
Diego, August 2001. <http://www.sigcomm.org/sigcomm2001/p22-
widmer.pdf>
[3] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
10.2. Informative References
[4] Pullen, M., Myjak, M., and C. Bouwens, "Limitations of Internet
Protocol Suite for Distributed Simulation the Large Multicast
Environment", RFC 2502, February 1999.
[5] J. Padhye, V. Firoiu, D. Towsley and J. Kurose, "Modeling TCP
Throughput: A Simple Model and its Empirical Validation",
Proceedings of ACM SIGCOMM 1998.
[6] Mankin, A., Romanow, A., Bradner, S., and V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC 2357, June 1998.
[7] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914,
September 2000.
[8] J. M. Pullen, "The Network Workbench: Network Simulation
Software for Academic Investigation of Internet Concepts,"
Computer Networks Vol 32 No 3 pp 365-378, March 2000.
[9] J. M. Pullen, R. Simon, F. Zhao and W. Chang, "NGI-FOM over
RTI-NG and SRMP: Lessons Learned," Proceedings of the IEEE Fall
Simulation Interoperability Workshop, paper 03F-SIW-111,
Orlando, FL, September 2003.
[10] D. Cohen, "NG-DIS-PDU: The Next Generation of DIS-PDU (IEEE-
P1278)", 10th Workshop on Standards for Interoperability of
Distributed Simulations, March 1994.
[11] Handley, M., Floyd, S., Whetten, B., Kermode, R., Vicisano, L.,
and M. Luby, "The Reliable Multicast Design Space for Bulk Data
Transfer", RFC 2887, August 2000.
[12] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J.
Crowcroft, "Asynchronous Layered Coding (ALC) Protocol
Instantiation", RFC 3450, December 2002.
[13] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M., and
J. Crowcroft, "Layered Coding Transport (LCT) Building Block",
RFC 3451, December 2002.
[14] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and
J. Crowcroft, "Forward Error Correction (FEC) Building Block",
RFC 3452, December 2002.
[15] 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.
Authors’ Addresses
J. Mark Pullen
C4I Center
George Mason University
Fairfax, VA 22030
USA
EMail: mpullen@gmu.edu
Fei Zhao
C4I Center
George Mason University
Fairfax, VA 22030
USA
EMail: fzhao@netlab.gmu.edu
Danny Cohen
Sun Microsystems
M/S UMPK16-160
16 Network Circle
Menlo Park, CA 94025
USA
EMail: danny.cohen@sun.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 procedures with respect to rights in RFC 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 provided by the IETF
Administrative Support Activity (IASA).