0 8 16 24 32
+--------------+--------------+--------------+--------------+
|Version| Type |010 | 00000 | Length |
+--------------+--------------+--------------+--------------+
| SN |
+--------------+--------------+--------------+--------------+
Version:
4 bits currently 0010
Type:
4 bits 0010
Mode:
3 bits 010
Padding:
5 bits 00000
Length:
16 bits Length of the payload data in octets (does not the
include header).
SN:
32 bits Same as in bundle header.
3.7. SRT NACK Format
0 8 16 24 32
+--------------+--------------+--------------+--------------+
|Version| Type |111 | 00000 | reserved |
+--------------+--------------+--------------+--------------+
| DSN |
+--------------+--------------+--------------+--------------+
| Sender Address |
+--------------+--------------+--------------+--------------+
Version:
4 bits currently 0010
Type:
4 bits 0010
Mode:
3 bits 111
Padding:
5 bits 00000
Reserved:
16 bits
DSN:
32 bits sequence number
Sender Address:
The IP address of the sender of the message being NACKed.
3.8. User-Configurable Parameters
Name Minimum Value Recommended Value Units
DSN_Max 1 32 messages
dataID_Timeout none none ms
Segment_Timeout 50 250 ms
Bundle_Timeout 1 10 ms
Heartbeat_Interval 1 none s
Mode2_Max 1 none messages
ACK_Threshold none worst RTT in group ms
4. TFMCC Operation
4.1. TCP Rate Prediction Equation for TFMCC
The RECOMMENDED throughput equation for SRMP is a slightly simplified
version of the throughput equation for Reno TCP from [5]:
8*s
X = ------------------------------------------------------ (1)
R * (sqrt(2*p/3) + (3*sqrt(6*p) * p * (1+32*p^2)))
(the formula may be simplified for implementation), where
X is the transmit rate in bits/second.
s is the message size in bytes.
R is the round-trip time in seconds.
p is the loss event rate, between 0.0 and 1.0, of the number of
loss events as a fraction of the number of messages transmitted.
In the future, different TCP formulas may be substituted for this
equation. The requirement is that the throughput equation be a
reasonable approximation of the sending rate of TCP for conformant
TCP congestion control.
4.2. Bundling
Multiple SRMP messages will be encapsulated into a bundle. When a
new SRMP message (Mode 0 or Mode 1) arrives, the SRMP daemon will try
to add the new message into the current bundle.
The SRMP daemon MUST keep a timer, which will be reset when the first
SRMP message is added into the bundle. After Bundle_Timeout, the
timer will time out, and the current bundle should be transmitted
immediately. A new bundle will then be initialized to hold new SRMP
messages. Bundle_Timeout SHALL NOT be less than 1 ms. The
recommended value is 10 ms.
Also, the bundle length MUST NOT exceed LENGTH_MAX. If adding a new
SRMP message will produce a greater length, the SRMP daemon MUST
initialize a new bundle for the new SRMP messages, and the current
bundle should be transmitted immediately. The recommended value for
LENGTH_MAX is 1454 bytes (Ethernet MTU minus IP and UDP header
lengths).
In a bundle, there may exist multiple SRMP messages with the same
dataID. In this case, only the latest version of that dataID is
useful. SRMP may check for duplicate dataIDs in the same bundle and
delete all but the latest one. If a Mode 1 message appears in the
outgoing bundle, then the corresponding DSN should not appear in the
bundle header.
The bundle header contains the DSN <dataID,SN,NoSegs> for Mode 1
messages from this sender. The absolute maximum number of DSN is
255; however, an implementation may apply a user-specified DSN_Max,
no smaller than 1. An implementation may support a user-defined
dataID_Timeout, after which a given dataID will not be announced in
the bundle header unless a new Mode 1 message has been sent. If the
sender has more dataIDs sent (and not timed out) than will fit in the
bundle header, the DSNs MUST be announced on a round-robin basis,
with the exception that no bundle header will announce a DSN for a
Mode 1 message contained within that bundle. If a duplicate DSN is
received, it may be silently discarded.
4.3. Congestion Control
The congestion control mechanism operates as described in [7].
4.4. Any-Source Multicast
SRMP uses the Any-Source Multicast Mode. Each sender will determine
its maximum RTT, suppression data rate, and sending rate with respect
to each sender. Each receiver will measure its RTT and desired rate
to each sender in the group, and send feedback to every sender by
sending to the multicast group.
4.5. Multiple Sources
Under SRMP, each group member in a multicast group is a sender as
well as a receiver. Each receiver may need to participate in TFMCC
information exchange with all senders. Thus, when a receiver sends a
feedback message, it must identify to which source the message should
be sent using the "Sender ID" field in the header.
The feedback is multicast to the group. Depending on the network
situation, senders may select different receivers to provide
feedback. Feedback messages from receivers that are not among those
selected by the local TFMCC to provide feedback should be silently
discarded.
4.6. Bundle Size
TFMCC is designed for traffic with a fixed message size. The maximum
bundle size (including header) for SRMP is set to a configurable
maximum, typically 1454 bytes (Ethernet MTU minus IP and UDP header
lengths). The bundle size will be used in a TCP throughput equation,
to get a desired source rate. However, in SRMP, the message size is
variable because:
1. After bundle time out, the current bundle will not wait for new
SRMP messages. This happens with sources sending at a slow rate.
2. In long messages, there is no further space in the current bundle
for new SRMP messages. This will happen with sources sending at a
high rate or sending messages with a length over half of the
bundle payload size.
The case 1 bundle size is likely to be much smaller than that of case
2.
Therefore, in SRMP, the mean value of the 10 most recent bundles’
sizes will be used as the bundle size in the TCP throughput equation.
This mean value is independent from the network condition and
reflects current activity of the source.
4.7. Data Rate Control
Each host will have a single instance of SRMP supporting all of its
applications. Thus, the sender’s source rate is the sum of the rates
of all the clients of the same multicast group.
If the source rate is larger than the sender’s desired transmission
rate, it is the sender’s responsibility to do traffic shaping. Any
method that conforms to the target sending rate may be used. The
RECOMMENDED method is to randomly discard enough Mode 0 messages to
meet the target rate.
4.8. Mode 1 Loss Detection
Bundle header processing includes checking each DSN in the bundle
header and scheduling a NACK for each DSN bearing a dataID for which
some application has indicated interest, if the SN/SegNo in that DSN
indicates that a NACK is needed. NACKs are sent in bundles and may
be bundled with data messages. A NACK is required if:
o the SN is one or more greater (mod 512) than the latest received
Mode 1 message for that dataID, or
o the SegNo has not been received, some segment of the <dataID,SN>
has been received, and a user-defined Segment_Timeout, which SHALL
NOT be less than 50 ms, has expired since receipt of the first
SegNo for the <dataID,SN>.
The bundling sublayer will pass the DSN list in any received bundle
header to the SRT sublayer. It also will suppress NACKs in outgoing
bundles, as described in the next section.
4.8.1. Sending a Negative Acknowledgement
Negative acknowledgements are used by SRMP for multicast messages in
order to avoid the congestion of an "ACK implosion" at the original
sender that would likely occur if positive acknowledgements were used
instead. However, with a large multicast group spread out over a
congested wide-area network, there is the potential for enough
members of the multicast group to fail to receive the message and
generate NACKs to cause considerable congestion at the original
sender despite the use of negative acknowledgements instead of
positive acknowledgements. For this reason, SRMP uses a NACK
suppression mechanism to reduce the number of NACKs generated in
response to any single lost message.
The NACK suppression mechanism uses the Bundle_Timeout to distribute
NACKs over an appropriate time window. This assumes that the user
has selected a bundle timeout appropriate for the needs of the
application for real-time responsiveness.
When the bundling sublayer is ready to send a bundle, it removes from
the bundle any NACKs for which a response has been sent by another
member of the multicast group within the NACK_Repeat_Timeout window.
If the original Bundle_Timeout has not expired, transmission of the
bundle may then be delayed until the original Bundle_Timeout expires
or the bundle is full, whichever happens first.
4.9. Unbundling
After a receiver completes congestion control processing on a bundle,
it parses the bundle into SRT messages and sends these to the SRT
sublayer.
4.10. Heartbeat Bundle
SRMP implementations may support a user-defined Heartbeat_Interval,
which SHALL NOT be less than one second. At the end of each
heartbeat interval, if the sender has not sent any bundle, an empty
bundle will be sent in order to trigger Mode 1 loss detection.
5. SRT Operation
SRMP operates in three distinct transmission modes in order to
deliver varying levels of reliability: Mode 0 for multicast data that
does not require reliable transmission, Mode 1 for data that must be
received reliably by all members of a multicast group, and Mode 2 for
data that must be received reliably by a single dynamically
determined member of a multicast group.
Mode 0 operates as a pure best-effort service. Mode 1 operates with
negative acknowledgements only, triggered by bundle arrivals that
indicate loss of a Mode 1 message. Mode 2 uses a positive
acknowledgement for each message to provide reliability and low
latency. Mode 2 is used where a transaction between two members of a
multicast group is needed. Because there can be many members in such
a group, use of a transaction protocol, with reliability achieved by
SRMP retransmission, avoids the potentially large amount of
connection setup and associated state that would be required if each
pair of hosts in the group established a separate TCP connection.
Use of SRMP anticipates that only a small fraction of messages will
require reliable multicast, and a comparably small fraction will
require reliable unicast. This is due to a property of distributed
virtual simulation: the preponderance of messages consist of state
update streams for object attributes such as position and
orientation. SRMP is unlikely to provide effective reliable
multicast if the traffic does not have this property.
In SRMP, "dataID" is used to associate related messages with each
other. Typically, all messages with the same dataID are associated
with the same application entity. All the messages with the same
dataID must be transmitted in the same mode. Among all the messages
with the same dataID, the latest version will obsolete all older
messages.
5.1. Mode 0 Operation
Mode 0 is for multicast messages that do not require reliable
transmission because they are part of a real-time stream of data that
is periodically updated with high frequency. Any such message is
very likely to have been superceded by a more recent update before
retransmission could be completed.
5.1.1. Sending Mode 0 Messages
When an application requests transmission of Mode 0 data, a
destination multicast group must be provided to SRMP along with the
data to be sent. After verifying the data length and multicast
group, the following steps MUST be performed by the SRT sublayer:
1. An SRT message MUST be generated with the following
characteristics:
the version is set to the current version, the message type is set
to 0x0, the mode is set to 0x0. User data is included after the
message header. If the message cannot be generated as described
above, the user data is discarded and the error MUST be reported
to the application.
2. If step 1 was completed without error, the newly generated message
MUST be sent to the bundling sublayer. The implementation MUST
report to the application whether the message was ultimately
accepted by UDP.
5.1.2. Receiving Mode 0 Messages
When a Mode 0 message is received by SRMP, it MUST be processed as
follows: after verifying the version, message type, and destination
multicast address fields, the user data MUST be delivered to all
applications that are associated with the multicast group in the
message. If the SRMP receiver has never received any Mode 1 messages
before the Mode 0 message is received, the Mode 0 message should be
silently discarded.
It is RECOMMENDED that the following information be provided to the
receiving applications: message body, multicast address.
5.2. Mode 1 Operation
Mode 1 is for multicast data that requires reliable transmission. A
Mode 1 message can be either a data message or a NACK. Mode 1 data
messages are expected to be part of a data stream. This data stream
is likely to contain Mode 0 messages as well (see section 5.1.1), but
it is possible for a data stream to be comprised solely of Mode 1
messages.
5.2.1. Sending Mode 1 Data Messages
After the data length, dataID, and destination multicast group are
verified, SRT MUST take the following steps:
1. If the message will not fit in an empty bundle with DSN_Max DSN in
the header, the message MUST be segmented. The remaining steps
pertain to each segment of the message. Each segment receives a
unique SegNo, starting with 0 and ending with (NoSegs-1).
2. An SRT message is generated with the following characteristics:
the version is set to 0x02, the message type is set to 0x0, the
transmission mode is set to 0x01, the SN is set equal to the SN of
the most recently sent Mode 1 complete message of the same dataID,
incremented by 1 modulo 512. If no such Mode 1 message exists,
the SN is set to 0x0.
3. The newly generated message (all segments) must then be buffered,
replacing any formerly buffered Mode 1 message of the same dataID,
destination multicast address. If the message cannot be buffered,
the user data is discarded and the error is reported to the
application.
4. If step 2 was completed without error, the newly generated message
is sent to the TFMCC sublayer.
5.2.2. Receiving Mode 1 Data Messages
When a Mode 1 data message is received by SRT, it will be processed
as follows (assuming that the version field has already been verified
to be 0x02):
1. The destination address MUST be verified to be a valid IP
multicast address on which this instance of SRMP is a member. If
this is not the case, the message should be silently discarded.
2. The destination address MUST be verified to be one for which some
application has indicated interest. Otherwise, the message should
be silently discarded.
3. The SN, SegNo, source_ip_address, and the body of the received
message MUST be buffered, and the user data MUST then be delivered
to all applications that have indicated interest in the multicast
group of the received message.
4. When a new DSN value is received with NoSegs greater than zero, a
timer should be set for Segment_Timeout, after which a NACK should
be sent to the bundling sublayer and the timer should be restarted
for Segment_Timeout.
5. If NoSegs in the received message is not 0, a reassembly process
MUST be started. Each segment MUST be buffered. If receipt of
the current message completes the segment, the reassembled message
MUST be released to the application and the Segment_Timeout timer
cancelled.
6. If a new DSN is received before all segments of the previous DSN
are received, the segments that have been received should be
dropped silently.
7. It is RECOMMENDED that the following information be provided to
the receiving applications: message body, dataID,
source_ip_address, multicast_group address.
8. When a client signs on to a new multicast group, all locally
buffered Mode 1 messages related to that multicast group should be
delivered to the client immediately.
5.2.3. Sending a Negative Acknowledgement
Whenever a bundle is received, the bundling sublayer will forward the
DSN list from the bundle header to the SRT sublayer. The SRT
sublayer will examine buffered values of <SenderID,dataID,SN,SegNo>
to determine whether a NACK is required. If so, it will generate a
NACK message and send it to the bundling sublayer. The NACK message
will have version set to 0x2, message type set to 0x2, and
transmission mode set to 0x7. dataID, SN, and destination address
are set to that of the Mode 1 message for which the NACK is being
sent. If a NACK has been received from any member of the destination
multicast group for the Mode 1 message in question within the NACK
threshold, no NACK is generated.
For segmented messages, there are two possible types of NACKs:
o Based on the DSN list in the bundle header, the SRT implementation
may determine that an entire segmented Mode 1 message was lost.
In this case, the NACK MUST carry SegNo=0x7F (all in one field).
o Based on the Segment Timeout, the SRT implementation may determine
that one or more segments of a message have not been delivered.
In this case, a NACK will be sent for each missing segment.
5.2.4. Receiving a Negative Acknowledgement
When a NACK is received by SRT, it MUST be processed as follows,
after verifying the multicast address, dataID, source IP address, and
transmission mode:
1. If this instance of SRT’s most recent Mode 1 message of the dataID
indicated in the NACK has an SN newer than the SN in the NACK,
that message (which is buffered) should be immediately
retransmitted to the multicast address indicated in the received
NACK. If the most recent Mode 1 message has an SN equal to the SN
indicated in the NACK, and if the SegNo field in the NACK contains
0x7F, all segments of the buffered Mode 1 message MUST be
retransmitted; if the SegNo has some other value, only the
indicated segment should be retransmitted.
2. Whether or not step 1 results in the retransmission of a message,
the event of receiving the NACK and the (local machine) time at
which the NACK was received should be buffered. Each instance of
SRT MUST buffer the number of NACKs that have been received for
each dataID-multicast address pair, since the most recent Mode 1
message of the same pair was received and the time at which the
most recent of these NACKs was received.
5.3. Mode 2 Operation
Mode 2 is for infrequent reliable transaction-oriented communication
between two dynamically determined members of a multicast group. TCP
could be used for such communication, but there would be unnecessary
overhead and delay in establishing a stream-oriented connection for a
single exchange of data, whereas there is already an ongoing stream
of best-effort data between the hosts that require Mode 2
transmission. An example is a Distributed Interactive Simulation
(DIS) collision PDU.
5.3.1. Sending Mode 2 Data Messages
When an application requests transmission of Mode 2 data, a dataID
and a destination unicast IP address MUST be provided to SRT along
with the data to be sent. After verifying the data length, dataID,
and destination address, SRT MUST perform the following steps:
1. An SRT message is generated with the following characteristics:
the version is set to 0x02, the message type is set to 0x02, the
transmission mode is set to 0x2, the dataID is set to the
application-provided value, and the destination address is set to
the application-provided IP address. The SN is set equal to the
SN of the most recently sent Mode 2 message of the same dataID
incremented by 1 modulo 65536. If no such Mode 1 message exists,
it is set to 0x0.
2. The newly generated message is buffered. This new message does
not replace any formerly buffered Mode 2 messages. An
implementation MUST provide a Mode 2 message buffer that can hold
one or more Mode 2 messages. Mode 2 messages are expected to be
infrequent (less than 1 percent of total traffic), but it is still
strongly RECOMMENDED that an implementation provide a buffer of
user-configurable size Mode2_Max that can hold more than a single
Mode 2 message. If the message cannot be buffered, the user data
is discarded and the error MUST be reported to the application.
If the message can be buffered, it should be sent to UDP
immediately after being buffered.
3. If step 2 was completed without error, the newly generated message
MUST be sent to the IP address contained in its destination
address field, encapsulated within a UDP datagram. If the UDP