RFC 4410

Selectively Reliable Multicast Protocol (SRMP)

📅 published February 2006, from ietf

RFC 4410: Selectively Reliable Multicast Protocol (SRMP) 🦋

okay bestie, let's start with the header stuff so you know exactly what we're dealing with ✨

Network Working Group 💜

  • Request for Comments: 4410
  • Category: Experimental 🧪
  • Date: February 2006 📅
  • Authors: M. Pullen, F. Zhao (George Mason Univ), and D. Cohen (Sun Microsystems) 👑

the header doesn't list any Obsoletes or Updates lines, so this doc isn't replacing or updating anything else 🫶

Status of This Memo 🌸

this one is an Experimental Protocol for the Internet community, so it's not an Internet standard of any kind 🧪. they're literally asking for discussion and suggestions to make it better, and distribution of the memo is unlimited 💖

Copyright (C) The Internet Society (2006).

Abstract 🦋

okay so SRMP is a transport protocol built for delivering a mix of reliable and best-effort messages in an any-to-any multicast environment 🌈. the best-effort traffic shows up in way bigger volume than the reliable traffic, and that's the whole trick: the best-effort stream can carry the sequence numbers of the reliable messages, which lets you detect loss 🧚. it's aimed at distributed simulation apps, where only the latest value of reliable transmission for any particular data identifier actually needs to get delivered ✨.

under the hood, SRMP has two sublayers 👑. first there's the bundling sublayer, which handles message aggregation and congestion control, and then there's the Selectively Reliable Transport (SRT) sublayer 💜. and the choice between reliable and best-effort messages? that's made by the application, not the protocol itself 💅.

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 ..........................................26
   9. Contributions ..................................................27
   10. References ....................................................27

1. Introduction ✨

okay so there's no good generic way to do reliable transport over multicast networks yet 😭. the approaches that actually work rely on the transport protocol taking advantage of special properties of the traffic, which is an idea Cohen [10] originally proposed. SRMP is built for real-time traffic that's a mix of two kinds of messages: a small fraction that needs reliable delivery, mixed in with a main flow of best-effort messages 🌸.

this kind of traffic shows up in distributed virtual simulation (RFC 2502 [4]) and also in some forms of distributed multimedia conferencing 🎀. these apps usually have some data that barely changes, or never changes at all, so you get the best efficiency by sending that data reliably. the external look of a simulated vehicle is a perfect example 🚗. they also need real-time delivery of a best-effort stream, like the position and orientation of that vehicle 🧭. reliable transmission for this stream is pointless, because new updates usually show up faster than loss could be identified and retransmitted 💀. by piggy-backing the sequence number (SN) of the latest reliable transmission onto each bundle of traffic, the reliable and best-effort traffic can co-exist synergistically 🫶. that's the approach SRMP takes ✨.

the IETF ran a successful working group on Reliable Multicast Transport (RMT), which produced RFCs 2357 [6], 2887 [11], and 3450 through 3453 [12 - 15] 💜. those define building block protocols for reliable multicast 🧱. selectively reliable multicast is similar in spirit to them, and it actually uses one of them: TCP-Friendly Multicast Congestion Control (TFMCC) 🔥. this document lays the groundwork for specifying SRMP with TFMCC, for use on an experimental basis 🧪. the key RMT requirements that carry forward here are in RFC 2357 [6]. they mostly come down to scalability and congestion control, and those are covered in section 6 of this document 👑.

1.1. Terminology 💅

in this doc, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in RFC 2119 [1], and they indicate requirement levels for compliant implementations 🌈.

that's part 1 of 6 bestie 💖 more is coming, so stay tuned for part 2 🦋

2. Protocol Description ✨

okay so SRMP has two big pieces 💖: Selectively Reliable Transport (SRT) and a "bundling sublayer" that runs TCP-Friendly Multicast Congestion Control (TFMCC), which Widmer and Handley came up with [2]. The bundling sublayer exists so SRMP can meet the congestion avoidance requirements in RFC 2357 [6] 🫶

SRMP can do reliable message delivery over multicast networks 🦋 It's built for the case where the reliable messages are just a slice of a bigger best-effort flow, and only the latest reliable message actually has to arrive. The core trick is to spend as little network capacity as possible on reliability. Each sender buffers its most recently sent reliable message and piggybacks that message's sequence number onto its best-effort messages. There are three sending modes 🌸

  • Mode 0 messages. These are best-effort, so if one gets lost, nobody retransmits it 💀
  • Mode 1 messages. When a receiver notices a Mode 1 message went missing, it sends a NACK back to the sender, and SRMP retransmits the latest reliable message from that sender. Senders define data identifiers (dataIDs) so several reliable message streams can coexist 🧚 Mode 1 messages can be up to 131,071 bytes long. SRMP does segmentation and reassembly, but only for the latest Mode 1 message for any given <sourceAddress, multicastAddress, dataID>.
  • Mode 2 messages. These give you a lightweight, reliable, connectionless peer-to-peer unicast transaction between any two members of the multicast group 👑 It's a unicast message that requires a positive acknowledgement (ACK).

Here's how the layers stack up 🍓

  | Application   |
  -----------------       ----------
  |      SRT      |
  -----------------   ->     SRMP
  |Bundling(TFMCC)|
  -----------------       ----------
  |      UDP      |

The bundling sublayer is invisible to SRT, which is the vibe 🌈 It handles congestion control in two ways: it drops Mode 0 messages at the source when it has to, and it bundles together the short messages apps hand over within a short time window. It also does NACK suppression ✨

A bundling sublayer data unit is called a bundle 🎀 A bundle is a bundle header plus one or more Mode 0 and Mode 1 SRMP messages. If a Mode 1 message gets retransmitted, the bundle it was originally in doesn't get retransmitted with it. The retransmitted message just shows up in a brand-new bundle 💜

Now the TFMCC part, which is honestly so cool 😭 It follows the mechanism Widmer and Handley described. It's an equation-based multicast congestion control mechanism. In a multicast group, every receiver works out its loss rate relative to the sender, then calculates a desired sending rate using an equation that models the steady-state sending rate of TCP. A distributed feedback suppression mechanism limits feedback to the receivers most likely to report the lowest desired rates. Congestion control happens 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 stuff like geographic location, so the app keeps working (just at lower fidelity) when they get dropped 🦋

As Widmer and Handley explain it, TFMCC's congestion control goes like this 💅

  • Each receiver measures the loss event rate and its Round-Trip Time (RTT) to the sender.
  • Each receiver then combines that info with an equation for TCP throughput to derive a TCP-friendly sending rate.
  • Through a distributed feedback suppression mechanism, only a subset of receivers is allowed to give feedback, which stops a feedback implosion at the sender. The mechanism makes sure receivers reporting a low desired transmission rate have a high probability of sending feedback 🔥
  • Receivers whose feedback wasn't suppressed send the calculated transmission rate back to the sender in so-called receiver reports. Those reports do two jobs: they tell the sender the right transmit rate, and they let receivers measure their RTT 🌸
  • The sender picks the receiver reporting the lowest rate as the current limiting receiver (CLR). Whenever feedback with an even lower rate reaches the sender, that receiver becomes the new CLR and the sending rate drops to match its calculated rate. The sending rate goes back up when the CLR reports a calculated rate higher than the current sending rate ⭐

TFMCC was originally meant for fixed-size packets with variable rate. SRMP uses it on variable-size SRMP messages that are mostly the same size 🧁 That's because the best-effort updates usually represent the same kind of simulation info, and during heavy network activity they get grouped into bundles just under one MTU. Future TFMCC work on variable-size messages would be super valuable for SRMP, assuming it turns out to suit the traffic SRMP is meant to carry 🌟

SRMP is meant for general use by any application that needs it, and it can run in parallel instances on the same host 🫧 So the UDP port gets picked ad hoc from the application ports available. That means a well-known port for SRMP would not be appropriate 🙈

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 going to the same multicast address 💖 A bundle can only hold Mode 0 and Mode 1 messages. Mode 2 messages go over unicast addresses instead 🦋

SRMP identifies the sender and receiver with their 32-bit Sender_ID, which can be an IPv4 address 💜 For IPv6, a user group will need to set up a unique identifier per host. This identifier doesn't have to be unique across the whole Internet. It only has to be unique within 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     |
  +-----------------------------------------------------------+

Here's the rundown on each field, bestie 🧚

  • Version: 4 bits, currently 0010 🌸
  • Type: 4 bits, 0000 means bundle 🍓
  • fb_nr: 4 bits, feedback round, range 0-15 🌈
  • flag: 4 bits, 0001 is Is_CLR, and the other bits are reserved ⭐
  • bundle_SN: 16 bits, range 0-65535 💅
  • Sender_Timestamp: 16 bits, the time the bundle was sent out (in milliseconds) based on the sender's local clock 🕰️
  • Receiver_Timestamp: 16 bits, an echo of the Receiver_Time_Stamp field (in milliseconds) from the receiver feedback message. If the sender has a time delay between receiving the feedback and echoing the timestamp, it MUST adjust the Receiver_Timestamp value to compensate 🫶
  • Receiver_ID: 32 bits, a unique identifier for the receiver within the multicast group. IPv4 addresses may be used 🎀
  • Sender_ID: 32 bits, a unique identifier for the sender within the multicast group. IPv4 addresses may be used 💖
  • X_supp: 16 bits, the suppression rate for the sender, in bits/s. Only 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 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 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 is made of three fields 👑
    • dataID: 16 bits, a unique number tied to a particular data element on the sending host, used to identify a Mode 1 message.
    • SN: 9 bits, the sequence number tied to a particular Mode 1 transmission of a particular dataID.
    • NoSegs: 7 bits, the number of segments, if the dataID was long enough to need segmentation. Otherwise it's 0x0.

Quick note: the number of DSNs tracks how many different Mode 1 DataIDs this SRMP instance is supporting right now. It is NOT a count of the SRMP messages bundled in the transmission 🙈

Also, 16-bit timestamps wrap around every 65536 milliseconds. That shouldn't 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 💌

Okay so this is the feedback message, the little note the receiver sends back to the sender 🦋 Here's the layout:

  0              8              16             24             32
  +--------------+--------------+--------------+--------------+
  |Version| Type | fb_nr| flag  |             X_r             |
  +--------------+--------------+--------------+--------------+
  |       Sender_Timestamp      |    Receiver_Timestamp       |
  +--------------+--------------+--------------+--------------+
  |                       Sender_ID                           |
  +--------------+--------------+--------------+--------------+
  |                      Receiver_ID                          |
  +--------------+--------------+--------------+--------------+
  • Version is 4 bits and currently 0010 💖
  • Type is 4 bits with the value 0001 ✨
  • fb_nr is 4 bits and holds the current feedback round of the sender 🔥
  • flag is 4 bits, and these values mean:
    • 0001 is have_RTT
    • 0010 is have_loss
    • 0100 is receiver_leave
    • other values are reserved 🙈
  • X_r is 16 bits and holds the desired sending rate X_r in bits/s. The receiver calculates it to be TCP-friendly. It's a 16 bit floating point value with 8 bits for the unsigned exponent and 8 bits for the unsigned mantissa 🌸
  • Sender_Timestamp is 16 bits and is an echo of the Sender_Timestamp from the bundle header. If the receiver has a time delay between receiving the bundle and echoing the timestamp, it MUST adjust the Sender_Timestamp value correspondingly. Main character energy, but make it accurate 🎀
  • Receiver_Timestamp is 16 bits and is the time when the feedback message was sent out from the receiver ⭐
  • Receiver_ID is 32 bits and is a unique identifier for the receiver within the multicast group. IPv4 addresses may be used. This field identifies the receiver that sends the feedback message 🧚
  • Sender_ID is 32 bits and is a unique identifier for the sender within the multicast group. IPv4 addresses may be used. This field identifies the sender that is the destination of the current feedback message 💜

3.4. SRT Mode 0 Header Format 🍓

Mode 0 gets its own little header, so here it is:

  0              8              16             24             32
  +--------------+--------------+--------------+--------------+
  |Version| Type | 000 |  00000000  |        Length           |
  +--------------+--------------+--------------+--------------+
  • Version is 4 bits and currently 0010 💅
  • Type is 4 bits and is 0000 🌈
  • Mode is 3 bits and is 000 🫶
  • Padding is 8 bits and is 00000000 🦋
  • Length is 11 bits and is the length of the payload data in octets. It does not include the header ✨

3.5. SRT Mode 1 Header Format 🌸

Mode 1 adds a segment number and a DSN, so the header looks like this:

  0              8              16             24             32
  +--------------+--------------+--------------+--------------+
  |Version| Type | 001 |  SegNo    |            Length        |
  +--------------+--------------+--------------+--------------+
  |                            DSN                            |
  +--------------+--------------+--------------+--------------+
  • Version is 4 bits and currently 0010 💖
  • Type is 4 bits and is 0000 🔥
  • Mode is 3 bits and is 001 👑
  • SegNo is 7 bits and is the index number of this segment 🧚
  • Length is 14 bits and is the length of the payload data in octets. It does not include the header 💜
  • DSN is 32 bits and is the same as in the bundle header. Note that this contains NoSegs, whereas SegNo is a separate element 🙈

3.6. SRT Mode 2 Header Format ⭐

Mode 2 is a little leaner, and this is what it looks like:

  0              8              16             24             32
  +--------------+--------------+--------------+--------------+
  |Version| Type |010 |  00000  |            Length           |
  +--------------+--------------+--------------+--------------+
  |                            SN                             |
  +--------------+--------------+--------------+--------------+
  • Version is 4 bits and currently 0010 🎀
  • Type is 4 bits and is 0010 🌈
  • Mode is 3 bits and is 010 💅
  • Padding is 5 bits and is 00000 ✨
  • Length is 16 bits and is the length of the payload data in octets. It does not include the header 🍓
  • SN is 32 bits and is the same as in the bundle header 🦋

3.7. SRT NACK Format 🙈

The NACK format is the one that says "hey, that message didn't arrive" 💀 Here's the layout:

  0              8              16             24             32
  +--------------+--------------+--------------+--------------+
  |Version| Type |111 |  00000  |          reserved           |
  +--------------+--------------+--------------+--------------+
  |                            DSN                            |
  +--------------+--------------+--------------+--------------+
  |                      Sender Address                       |
  +--------------+--------------+--------------+--------------+
  • Version is 4 bits and currently 0010 💜
  • Type is 4 bits and is 0010 ✨
  • Mode is 3 bits and is 111 🔥
  • Padding is 5 bits and is 00000 🫶
  • Reserved is 16 bits 🌸
  • DSN is 32 bits and is a sequence number 👑
  • Sender Address is the IP address of the sender of the message being NACKed 🧚

3.8. User-Configurable Parameters 🎀

These are the knobs you can turn, and here are the minimums and recommended values, all in one table:

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 🧮

Okay this one is the math moment 🤓 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. Here's what the letters mean:

  • 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. It's the number of loss events as a fraction of the number of messages transmitted.

Different TCP formulas may be swapped in for this equation later on 💅 The only real 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 get wrapped up into a bundle 🎁 When a new SRMP message (Mode 0 or Mode 1) arrives, the SRMP daemon tries to add it into the current bundle.

The SRMP daemon MUST keep a timer, and that timer gets reset when the first SRMP message is added into the bundle. After Bundle_Timeout, the timer times out, and the current bundle should be transmitted immediately. A new bundle is then started to hold new SRMP messages. Bundle_Timeout SHALL NOT be less than 1 ms. The recommended value is 10 ms ⏰

The bundle length MUST NOT exceed LENGTH_MAX. If adding a new SRMP message would make it longer than that, 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) 🫶

A bundle can have multiple SRMP messages with the same dataID. In that 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 determines its maximum RTT, suppression data rate, and sending rate with respect to each sender. Each receiver measures its RTT and desired rate to each sender in the group, and sends 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 take part in TFMCC information exchange with all senders. So when a receiver sends a feedback message, it must identify which source the message should go to, 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 gets used in a TCP throughput equation to get a desired source rate. But 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.

So in SRMP, the mean value of the 10 most recent bundles' sizes is used as the bundle size in the TCP throughput equation. This mean value is independent from the network condition and reflects the current activity of the source 📊

4.7. Data Rate Control 🎛️

Each host has a single instance of SRMP supporting all of its applications. So 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's 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 🕵️‍♀️

Okay so bundle header processing is where the receiver checks every DSN in the bundle header 👀. For each DSN carrying a dataID that some application has shown interest in, it schedules a NACK, but only if the SN/SegNo in that DSN says a NACK is needed. NACKs get sent in bundles and can ride along with data messages 🚀. A NACK is required if:

  • the SN is one or more greater (mod 512) than the latest received Mode 1 message for that dataID, or
  • 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 passes the DSN list from any received bundle header over to the SRT sublayer. It also suppresses NACKs in outgoing bundles, which we'll get into in the next section 💜

4.8.1. Sending a Negative Acknowledgement 🙈

Okay this part is so clever. NACKs are used by SRMP for multicast messages so you don't get an "ACK implosion" slamming the original sender, which would likely happen if everyone sent positive acknowledgements instead 😭. But here's the catch: with a big multicast group spread out over a congested wide-area network, enough members can miss a message and all send NACKs, and that still causes serious congestion at the original sender 💀. So SRMP uses a NACK suppression mechanism to cut down on the NACKs generated for any single lost message 🌈.

The NACK suppression mechanism uses the Bundle_Timeout to spread NACKs out over an appropriate time window. This assumes the user has picked a bundle timeout that fits the application's real-time responsiveness needs ⏱️.

When the bundling sublayer is ready to send a bundle, it strips out any NACKs for which another member of the multicast group has already sent a response within the NACK_Repeat_Timeout window 🧹. If the original Bundle_Timeout hasn't expired yet, the bundle may be held until that timeout expires or the bundle is full, whichever comes first 🎀.

4.9. Unbundling 🎁

After a receiver finishes congestion control processing on a bundle, it parses the bundle into SRT messages and sends them up 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 hasn't sent any bundle, an empty bundle gets sent to trigger Mode 1 loss detection. So the heartbeat keeps the loss detection alive even when things are quiet 🫧.

5. SRT Operation 👑

SRMP runs in three distinct transmission modes so it can deliver different levels of reliability 💖. Mode 0 is for multicast data that doesn't need reliable transmission. Mode 1 is for data that every member of a multicast group must receive reliably. Mode 2 is for data that has to be received reliably by a single dynamically chosen member of a multicast group 🦋.

Mode 0 is a pure best-effort service 🌸. Mode 1 uses negative acknowledgements only, triggered by bundle arrivals that reveal a Mode 1 message was lost 🔍. Mode 2 uses a positive acknowledgement for each message to get reliability and low latency 🏃‍♀️. Mode 2 is used when a transaction between two members of a multicast group is needed. Since a group can have lots of members, a transaction protocol with reliability handled by SRMP retransmission avoids the huge pile of connection setup and state that would pile up if every pair of hosts in the group opened a separate TCP connection 🧚.

SRMP assumes only a small fraction of messages will need reliable multicast, and a similarly small fraction will need reliable unicast. That's because of a property of distributed virtual simulation: most messages are state update streams for object attributes like position and orientation 🌍. SRMP probably won't do a good job with reliable multicast if the traffic doesn't have that property 🙅‍♀️.

In SRMP, "dataID" is what links related messages together 🔗. Usually, all messages with the same dataID belong to the same application entity. All messages with the same dataID MUST be transmitted in the same mode 🔒. Among all messages with the same dataID, the latest version obsoletes all the older ones 💅.

5.1. Mode 0 Operation 🌊

Mode 0 is for multicast messages that don't need reliable transmission, because they're part of a real-time stream of data that gets updated often and at high frequency ⚡. Any such message is very likely to be superseded by a newer update before a retransmission could finish 😭.

5.1.1. Sending Mode 0 Messages 📤

When an application asks to transmit Mode 0 data, a destination multicast group has to be given to SRMP along with the data 📬. After checking the data length and multicast group, the SRT sublayer MUST perform the following steps:

  1. An SRT message MUST be generated with these characteristics: the version is set to the current version, the message type is set to 0x0, and the mode is set to 0x0. User data goes in right after the message header. If the message can't be generated like that, the user data is discarded and the error MUST be reported to the application 🙃.
  2. If step 1 finished 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 SRMP receives a Mode 0 message, it MUST process it like this: after verifying the version, message type, and destination multicast address fields, the user data MUST be delivered to all applications associated with the multicast group in the message 💌. If the SRMP receiver has never received any Mode 1 messages before this Mode 0 message arrives, the Mode 0 message should be silently discarded 🫥.

It is RECOMMENDED that the following information be given to the receiving applications: message body and 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. That stream will likely include Mode 0 messages too (see section 5.1.1), though a data stream can also be made up entirely 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 won't fit in an empty bundle with DSN_Max DSN in the header, the message MUST be segmented. The remaining steps apply to each segment of the message. Each segment gets a unique SegNo, starting at 0 and ending at (NoSegs-1) 🧩.
  2. An SRT message is generated with these characteristics: the version is set to 0x02, the message type is set to 0x0, the transmission mode is set to 0x01, and 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 previously buffered Mode 1 message with the same dataID and destination multicast address. If the message can't be buffered, the user data is discarded and the error is reported to the application 🗂️.
  4. If step 2 finished without error, the newly generated message is sent to the TFMCC sublayer 🛫.

5.2.2. Receiving Mode 1 Data Messages 📨

When SRT receives a Mode 1 data message, it's processed as follows (assuming the version field has already been verified to be 0x02) 🕵️:

  1. The destination address MUST be verified as a valid IP multicast address that this instance of SRMP is a member of. If that's not the case, the message should be silently discarded 🚫.
  2. The destination address MUST be verified as one that some application has shown interest in. Otherwise, the message should be silently discarded 🙅‍♀️.
  3. The SN, SegNo, source_ip_address, and body of the received message MUST be buffered, and then the user data MUST be delivered to all applications that have shown interest in the multicast group of the received message 💖.
  4. When a new DSN value arrives with NoSegs greater than zero, a timer should be set for Segment_Timeout. When it expires, a NACK should be sent to the bundling sublayer and the timer 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 receiving 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 have arrived, the segments that did arrive should be dropped silently 🍂.
  7. It is RECOMMENDED that the following information be given to the receiving applications: message body, dataID, source_ip_address, and multicast_group address 💅.
  8. When a client signs on to a new multicast group, all locally buffered Mode 1 messages related to that group should be delivered to the client right away 🎉.

5.2.3. Sending a Negative Acknowledgement 🆘

Whenever a bundle is received, the bundling sublayer forwards the DSN list from the bundle header to the SRT sublayer 📦. The SRT sublayer checks the buffered values of <SenderID,dataID,SN,SegNo> to figure out whether a NACK is required. If it is, the SRT sublayer generates a NACK message and sends it to the bundling sublayer 💌. The NACK message has version set to 0x2, message type set to 0x2, and transmission mode set to 0x7. The dataID, SN, and destination address are set to those of the Mode 1 message the NACK is for. If a NACK has been received from any member of the destination multicast group for that Mode 1 message within the NACK threshold, no NACK gets generated 🙌.

For segmented messages, there are two possible kinds of NACK 🧩:

  • Based on the DSN list in the bundle header, the SRT implementation may determine that an entire segmented Mode 1 message was lost. In that case, the NACK MUST carry SegNo=0x7F (all in one field) 💀.
  • Based on the Segment Timeout, the SRT implementation may determine that one or more segments of a message haven't been delivered. In that case, a NACK will be sent for each missing segment 🧚‍♀️.

5.2.4. Receiving a Negative Acknowledgement 🙈

okay so when a NACK lands at SRT, it MUST be processed like this, but only after SRT checks 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 the move for rare, reliable, transaction-style chats between two members of a multicast group who get picked on the fly. TCP could technically do it, but spinning up a whole stream connection just for one exchange is extra overhead and extra delay, and these hosts are already trading best-effort data anyway. The example they give is a Distributed Interactive Simulation (DIS) collision PDU 💥.

5.3.1. Sending Mode 2 Data Messages 💌

When an application asks to send Mode 2 data, a dataID and a destination unicast IP address MUST be handed to SRT along with the data. After SRT checks the data length, dataID, and destination address, SRT MUST do the following:

  1. An SRT message gets generated with these details: 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 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 one, a new SRT message is generated with the version set to 0x02, the message type set to 0x2, and the 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 the outstanding Mode 2 transmission, SRT MUST remove the pending transmission from its buffer. 🧹

6. RFC 2357 Analysis 🔍

okay bestie, this section is where the doc answers the questions RFC 2357 asked about reliable multicast protocols. The questions are quoted, so you can see exactly what they were asking ✨

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 meant to scale at least to hundreds of group members. It was designed so it doesn't put limits on the scalability of the underlying multicast network. No problems have been found in its mechanisms that would stop this on uncongested networks, so it's looking good 💅

"Identify the mechanisms which limit scalability and estimate those limits."

ngl there is one practical worry with TFMCC: the receiver with the most congested path ends up holding back delivery for the whole group 😭 Distributed virtual simulation needs data to arrive at rates that feel continuous to humans, so it might end up being necessary to put those receivers into different, lower-fidelity groups. That's how you keep things smooth for most of the participating hosts. SRMP doesn't have a mechanism to support that kind of 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 show that SRMP with TFMCC backs off in a way that's comparable to TCP when there's a lot of packet loss. The mechanism fails in a network-friendly way: under severe congestion, it drops the best-effort traffic to a super tiny rate, which is usually too low to support a virtual simulation. That works out because the reliable traffic is typically only a small slice of the overall traffic, and SRMP is NACK oriented, with NACK suppression, so reliable traffic loss adds very little to the total. If that traffic mix assumption isn't met, the reliable traffic (which doesn't back off under increased RTT) could push out a higher level of traffic than a comparable TCP connection. But levels of reliable traffic that big aren't in SRMP's intended application domain, so it's not the vibe 🙅‍♀️

"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 built for academic use [8], and the results validated the design assumptions 🧪 It has also been emulated in a LAN-based cluster, and application-tested in a wide-area testbed under its intended traffic mix (distributed virtual simulation). It was also tested with a traffic generator that emulated losses by randomly dropping packets [9]. Iconic testing era 🎀

"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 gives sending backoff comparable to TCP, SRMP can work just as well as TCP for congestion avoidance, even in the Global Internet 🌍 The only way an SRMP sender can cause congestion is by using the protocol for purposes it wasn't made for, like sending reliable transmission for a large fraction of the traffic. Doing that would give the application unsatisfactory results, because SRMP's reliability mechanism won't work well if the best-effort traffic isn't the majority of the total traffic. Don't be that sender 🙈

"Include a description of any mechanisms which contain the traffic within limited network environments."

SRMP has no such mechanisms, because it's 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 🔐

okay bestie, this is the part where we talk about who's trying to ruin our vibes 😤. SRMP is a transport protocol, so it can be hit with denial of service by hostile third parties who send conflicting values for its parameters to the multicast address. SRMP could try to protect itself from that kind of behavior 🛡️. But it can be shielded from these attacks with traffic authentication at the network layer, as described below. A similar level of authentication could also come from a message using MD5, or some other message hash in each bundle, with the SRMP bundle header used to detect duplicate transmissions from a given host. The catch is that this would duplicate what existing network layer authentication protocols already do, so it's kinda redundant 🙄.

Here are the specific threats that packet-level authentication can get rid of:

  • a. Amplification attack: SRMP receivers could be manipulated into sending huge amounts of NACK traffic 📢. That could cause network congestion or overwhelm the processing power of a sender. An attacker could do this by sending them faked traffic that says a reliable transmission was lost. SRMP's NACK suppression limits the damage from this kind of manipulation, but real 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 is also stopped by per-bundle authentication.
  • c. Replay attack: An attacker could copy a valid, authenticated bundle containing a NACK and keep sending it to the original sender of the NACKed data 🔁. Protecting against this requires a sequence number per transmission per source host. The SRMP bundle header sequence number would cover that need. However, the SN can also be applied at a lower layer.
  • d. Reverse path forwarding attack (spoofing): If checks aren't 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 🌳. That could trick 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 RTT values that might push a TFMCC sender to create or increase congestion on the path to that sender 🤦‍♀️. So it is 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 a lower layer protocol could handle it. Either way, it needs to be (1) scalable and (2) not very computationally demanding, so it can run with minimal delay on a real-time virtual simulation stream ⏱️. Public-key encryption meets the first requirement but not the second. The IPsec Authentication Header (AH) (RFC 4302 [3]) meets the second requirement by using symmetric-key cryptography 🔑. For guidance on multicast per-packet authentication, see RFC 4302 [3]. In practice, distributed simulation users are likely to work over a (possibly virtual) private network, so they won't need special authentication for SRMP 🏡.

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 really want to give a huge shoutout to two people without whom this RFC wouldn't exist 💖. Vincent Laviano created the first specification and implementation of SRMP, which was called SRTP at the time 👑. Babu Shanmugam used SRMP in a sizable distributed virtual simulation environment, revised the implementation, and helped revise the design so it could handle distributed virtual simulation workloads 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

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 keep all their rights 📜.

This document and the information in it 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 on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the implementation or use of the technology in this document, or on whether any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify such rights. Info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 📖.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, and the results of any attempt to get a general license or permission for implementers or users of this specification to use the proprietary rights can be found in the IETF online IPR repository at http://www.ietf.org/ipr 🔗.

The IETF invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology needed to implement this standard. Please send that 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) ✨.

📦 where this page comes from