Request for Comments: 4410 F. Zhao
Category: Experimental George Mason Univ
D. Cohen
Sun Microsystems
February 2006
Selectively Reliable Multicast Protocol (SRMP)
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Selectively Reliable Multicast Protocol (SRMP) is a transport
protocol, intended to deliver a mix of reliable and best-effort
messages in an any-to-any multicast environment, where the best-
effort traffic occurs in significantly greater volume than the
reliable traffic and therefore can carry sequence numbers of reliable
messages for loss detection. SRMP is intended for use in a
distributed simulation application environment, where only the latest
value of reliable transmission for any particular data identifier
requires delivery. SRMP has two sublayers: a bundling sublayer
handling message aggregation and congestion control, and a
Selectively Reliable Transport (SRT) sublayer. Selection between
reliable and best-effort messages is performed by the application.
Table of Contents
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Protocol Description ............................................4
3. Message Formats .................................................6
3.1. Bundle Message Format: .....................................6
3.2. Bundle Header Format .......................................7
3.3. Feedback Message Format ....................................9
3.4. SRT Mode 0 Header Format ..................................10
3.5. SRT Mode 1 Header Format ..................................11
3.6. SRT Mode 2 Header Format ..................................11
3.7. SRT NACK Format ...........................................12
3.8. User-Configurable Parameters ..............................13
4. TFMCC Operation ................................................13
4.1. TCP Rate Prediction Equation for TFMCC ....................13
4.2. Bundling ..................................................13
4.3. Congestion Control ........................................14
4.4. Any-Source Multicast ......................................14
4.5. Multiple Sources ..........................................14
4.6. Bundle Size ...............................................15
4.7. Data Rate Control .........................................15
4.8. Mode 1 Loss Detection .....................................16
4.8.1. Sending a Negative Acknowledgement .................16
4.9. Unbundling ................................................17
4.10. Heartbeat Bundle .........................................17
5. SRT Operation ..................................................17
5.1. Mode 0 Operation ..........................................18
5.1.1. Sending Mode 0 Messages ............................18
5.1.2. Receiving Mode 0 Messages ..........................18
5.2. Mode 1 Operation ..........................................18
5.2.1. Sending Mode 1 Data Messages .......................19
5.2.2. Receiving Mode 1 Data Messages .....................19
5.2.3. Sending a Negative Acknowledgement .................20
5.2.4. Receiving a Negative Acknowledgement ...............21
5.3. Mode 2 Operation ..........................................21
5.3.1. Sending Mode 2 Data Messages .......................21
5.3.2. Receiving Mode 2 Data Messages .....................22
5.3.3. Sending a Positive Acknowledgement .................23
5.3.4. Receiving a Positive Acknowledgement ...............23
6. RFC 2357 Analysis ..............................................23
6.1. Scalability ...............................................23
6.2. Congestion ................................................24
7. Security Considerations ........................................25
8. List of Acronyms Used ..........................................27
9. Contributions ..................................................27
10. References ....................................................27
1. Introduction
There is no viable generic approach to achieving reliable transport
over multicast networks. Existing successful approaches require that
the transport protocol take advantage of special properties of the
traffic in a way originally proposed by Cohen [10]. The protocol
described here is applicable to real-time traffic containing a mix of
two categories of messages: a small fraction requiring reliable
delivery, mixed with a predominating flow of best-effort messages.
This sort of traffic is associated with distributed virtual
simulation (RFC 2502 [4]) and also with some forms of distributed
multimedia conferencing. These applications typically have some data
that changes rarely, or not at all, so the best efficiency will be
achieved by transmitting that data reliably (the external appearance
of a simulated vehicle is an excellent example). They also require
real-time transmission of a best-effort stream (for example, the
position and orientation of the vehicle). There is no value to
reliable transmission of this stream because typically new updates
arrive faster than loss identification and retransmission could take
place. By piggy-backing the sequence number (SN) of the latest
reliable transmission on each bundle of traffic, the reliable and
best-effort traffic can co-exist synergistically. This approach is
implemented in the Selectively Reliable Multicast Protocol (SRMP).
The IETF has conducted a successful working group on Reliable
Multicast Transport (RMT) that has produced RFCs 2357 [6], 2887 [11],
and 3450 through 3453 [12 - 15], which define building block
protocols for reliable multicast. Selectively reliable multicast is
similar in spirit to these protocols and in fact uses one of them,
TCP-Friendly Multicast Congestion Control (TFMCC). This document
provides the basis for specifying SRMP with TFMCC for use on an
experimental basis. Key requirements of the RMT process that is
carried forward here are specified in RFC 2357 [6]. These generally
relate to scalability and congestion control, and are addressed in
section 6 of this document.
1.1. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
indicate requirement levels for compliant implementations.
2. Protocol Description
The Selectively Reliable Multicast Protocol (SRMP) has two major
components: Selectively Reliable Transport (SRT) and a "bundling
sublayer" that implements TCP-Friendly Multicast Congestion Control
(TFMCC), as proposed by Widmer and Handley [2], in order to meet the
requirements of RFC 2357 [6] for congestion avoidance.
SRMP is capable of reliable message delivery over multicast networks,
when the messages to be delivered reliably represent a fraction of a
larger, associated best-effort flow and only the latest reliable
message must be delivered. The basic strategy for SRMP is to trade
as little network capacity as possible for reliability by buffering
the most recently sent reliable message at each sender and piggy-
backing its sequence number on associated best-effort messages. For
this purpose, three modes of sending are defined:
o Mode 0 messages. These will be delivered best-effort; if lost, no
retransmission will be done.
o Mode 1 messages. When a Mode 1 message loss is detected, the
receiver will send back a NACK to the sender, where SRMP will
retransmit the latest reliable message from that sender. Senders
define data identifiers (dataIDs), allowing multiple reliable
message streams to be supported. Mode 1 messages may be up to
131,071 bytes long; SRMP provides for segmentation and reassembly,
but only for the latest Mode 1 message for any given
<sourceAddress, multicastAddress, dataID>.
o Mode 2 messages. Through Mode 2 messages, SRMP provides for a
lightweight, reliable, connectionless peer-to-peer unicast
transaction exchange between any two members of the multicast
group. This is a unicast message requiring positive
acknowledgement (ACK).
| Application |
----------------- ----------
| SRT |
----------------- -> SRMP
|Bundling(TFMCC)|
----------------- ----------
| UDP |
The bundling sublayer is transparent to the Selectively Reliable
Transport (SRT) sublayer. It implements congestion control both by
dropping Mode 0 messages at the source when needed and by bundling
multiple short messages that are presented by applications within a
short time window. It also performs NACK suppression.
A bundling sublayer data unit is called a bundle. A bundle is made
up of a bundle header and one or more Mode 0 and Mode 1 SRMP
messages. Retransmission of Mode 1 messages does not imply
retransmission of the original bundle; the retransmitted message
becomes part of a new bundle.
The TFMCC layer’s behavior follows the mechanism described by Widmer
and Handley. This is an equation-based multicast congestion control
mechanism: in a multicast group, each receiver determines its loss
rate with regard to the sender, and calculates a desired source
sending rate based on an equation that models the steady-state
sending rate of TCP. A distributed feedback suppression mechanism
restricts feedback to those receivers likely to report the lowest
desired rates. Congestion control is achieved by dropping best-
effort (Mode 0) messages at random. For example, in distributed
simulation, Mode 0 messages are part of a stream of state updates for
dynamic data such as geographic location; therefore, the application
can continue to function (with lower fidelity) when they are dropped.
As described by its authors, TFMCC’s congestion control mechanism
works as follows:
o Each receiver measures the loss event rate and its Round-Trip Time
(RTT) to the sender.
o Each receiver then uses this information, together with an
equation for TCP throughput, to derive a TCP-friendly sending
rate.
o Through a distributed feedback suppression mechanism, only a
subset of the receivers is allowed to give feedback to prevent a
feedback implosion at the sender. The feedback mechanism ensures
that receivers reporting a low desired transmission rate have a
high probability of sending feedback.
o Receivers whose feedback is not suppressed report the calculated
transmission rate back to the sender in so-called receiver
reports. The receiver reports serve two purposes: they inform the
sender about the appropriate transmit rate, and they allow the
receivers to measure their RTT.
o The sender selects the receiver that reports the lowest rate as
the current limiting receiver (CLR). Whenever feedback with an
even lower rate reaches the sender, the corresponding receiver
becomes the CLR and the sending rate is reduced to match that
receiver’s calculated rate. The sending rate increases when the
CLR reports a calculated rate higher than the current sending
rate.
TFMCC was intended for fixed-size packets with variable rate. SRMP
applies it to variable-size SRMP messages that are mostly the same
size because the best-effort updates typically all represent the same
sort of simulation information and are grouped into bundles of size
just under one MTU during periods of heavy network activity. Future
developments in TFMCC for variable-size messages will be of high
value for inclusion in SRMP if, as expected, they prove to be
appropriate for the types of traffic SRMP is intended to support.
SRMP is intended for general use under applications that need its
services and may exist in parallel instances on the same host. The
UDP port is therefore established ad hoc from available application
ports; accordingly, it would not be appropriate to have a well-known
port for SRMP.
3. Message Formats
3.1. Bundle Message Format:
--------------------------------------------------------------------
| bundle header | SRT Message 0 | SRT message 1 | SRT message 2 |...
--------------------------------------------------------------------
A bundle is an aggregation of multiple SRMP messages destined for the
same multicast address. A bundle can contain only Mode 0 and Mode 1
messages; Mode 2 messages are exchanged using unicast addresses.
SRMP identifies the sender and receiver using their 32-bit Sender_ID,
which may be an IPv4 address. For use with IPv6, a user group will
need to establish a unique identifier per host. There is no
requirement for this identifier to be unique in the Internet; it only
needs to be unique in the communicating group.
3.2. Bundle Header Format
0 8 16 24 32
+--------------+--------------+--------------+--------------+
|Version| Type |fb_nr | flag | bundle_SN |
+--------------+--------------+--------------+--------------+
| Sender_ID |
+--------------+--------------+--------------+--------------+
| Receiver_ID |
+--------------+--------------+--------------+--------------+
| Sender_Timestamp | Receiver_Timestamp |
+--------------+--------------+--------------+--------------+
| x_supp | R_max |
+--------------+--------------+--------------+--------------+
| DSN_count | padding | Length |
+--------------+--------------+--------------+--------------+
| 0 to 255 DSN: <dataID, SN, NoSegs> of this sender |
+-----------------------------------------------------------+
Version:
4 bits currently 0010
Type:
4 bits 0000 - indicates bundle
fb_nr:
4 bits feedback round, range 0-15
flag:
4 bits 0001 Is_CLR
other bits reserved
bundle_SN:
16 bits range 0-65535
Sender_Timestamp:
16 bits Representing the time that the bundle was sent out (in
milliseconds) based on the sender’s local clock.
Receiver_Timestamp:
16 bits Echo of the Receiver_Time_Stamp field (in milliseconds)
of the receiver feedback message. If the sender has
time delay between receiving the feedback and echoing
the timestamp, it MUST adjust the Receiver_Timestamp
value to compensate.
Receiver_ID
32 bits Unique identifier for the receiver within the multicast
group. IPv4 addresses may be used.
Sender_ID:
32 bits Unique identifier for the sender within the multicast
group. IPv4 addresses may be used.
X_supp:
16 bits The suppression rate corresponding to the sender, in
bits/s. Only those receivers whose desired rate is less
than the suppression rate, or whose RTT is larger than
R_max, may send feedback information to the sender. The
suppression rate is represented as a 16-bit floating
point value with 8 bits for the unsigned exponent and 8
bits for the unsigned mantissa.
R_max:
16 bits The maximum of the RTTs of all receivers, in
milliseconds. The Maximum RTT should be represented as
a 16-bit floating point value with 8 bits for the
unsigned exponent and 8 bits for the unsigned mantissa.
DSN_count:
8 bits The count of DSN blocks following the header.
Length:
16 bits Range from 0~65535. The total length of the bundle
in octets (including the header).
DSN:
32 bits There can be up to 256 of these in a header. An SRMP
implementation MUST support a minimum of 1. Each DSN
consists of three fields:
dataID:
16 bits A unique number associated with a particular data
element on the sending host, used to identify a
Mode 1 message.
SN:
9 bits Sequence number associated with a particular Mode 1
transmission of a particular dataID.
NoSegs:
7 bits Number of segments, if the dataID was long enough
to require segmentation; otherwise 0x0.
Note that the number of DSNs reflects the number of different Mode 1
DataIDs being supported at this time by this instance of SRMP, and is
not the count of SRMP messages bundled in this transmission.
Note also that 16-bit timestamps will wrap around in 65536
milliseconds. This should not be a problem unless an RTT is greater
than 65 seconds. If a timestamp is less than its predecessor
(treating the 16 bits as an unsigned integer), its value must be
increased by 65536 for comparisons against the predecessor.
3.3. Feedback Message Format
0 8 16 24 32
+--------------+--------------+--------------+--------------+
|Version| Type | fb_nr| flag | X_r |
+--------------+--------------+--------------+--------------+
| Sender_Timestamp | Receiver_Timestamp |
+--------------+--------------+--------------+--------------+
| Sender_ID |
+--------------+--------------+--------------+--------------+
| Receiver_ID |
+--------------+--------------+--------------+--------------+
Version:
4 bits currently 0010
Type:
4 bits value 0001
fb_nr:
4 bits current feedback round of the sender
flag:
4 bits
0001 - have_RTT
0010 - have_loss
0100 - receiver_leave
other values reserved
X_r:
16 bits desired sending rate X_r in bits/s, calculated by the
receiver to be TCP-friendly, 16 bit floating point
value with 8 bits for the unsigned exponent and 8 bits
for the unsigned mantissa.
Sender_Timestamp:
16 bits Echo of the Sender_Timestamp in bundle header. If the
receiver has time delay between receiving the bundle and
echoing the timestamp, it MUST adjust the
Sender_Timestamp value correspondently.
Receiver_Timestamp:
16 bits The time when the feedback message was sent out from the
receiver.
Receiver_ID:
32 bits Unique identifier for the receiver within the multicast
group. IPv4 addresses may be used. (Identifies the
receiver that sends the feedback message).
Sender_ID:
32 bits Unique identifier for the sender within the multicast
group. IPv4 addresses may be used. (Identifies the
sender that is the destination of the current feedback
message.)
3.4. SRT Mode 0 Header Format
0 8 16 24 32
+--------------+--------------+--------------+--------------+
|Version| Type | 000 | 00000000 | Length |
+--------------+--------------+--------------+--------------+
Version:
4 bits currently 0010
Type:
4 bits 0000
Mode:
3 bits 000
Padding:
8 bits 00000000
Length:
11 bits Length of the payload data in octets (does not include
the header).
3.5. SRT Mode 1 Header Format
0 8 16 24 32
+--------------+--------------+--------------+--------------+
|Version| Type | 001 | SegNo | Length |
+--------------+--------------+--------------+--------------+
| DSN |
+--------------+--------------+--------------+--------------+
Version:
4 bits currently 0010
Type:
4 bits 0000
Mode:
3 bits 001
SegNo:
7 bits The index number of this segment.
Length:
14 bits Length of the payload data in octets (does not include
the header).
DSN:
32 bits Same as in the bundle header. Note that this contains
NoSegs, whereas SegNo is a separate element.
3.6. SRT Mode 2 Header Format