[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 4410

Internet-Draft                                                 M. Pullen
draft-pullen-srmp-00.txt                                    B. Shanmugam
Expires: March 2003                                              F. Zhao
                                                       George Mason Univ
                                                              V. Laviano
                                                           Stanford Univ
                                                                D. Cohen
                                                        Sun Microsystems
                                                            October 2002

            Selectively Reliable Multicast Protocol (SRMP)


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

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
   best-effort traffic and therefore can be used to 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.

Pullen                       Expires: March 2003              [Page 1]

Internet Draft            draft-pullen-srmp-00.txt          October 2002

   SRMP has two sublayers: a bundling sublayer that combines short
   messages, peforms NAK suppression, and incorporates the TCP-Friendly
   Multicast Congestion Control of Widmer and Handley, dropping best-
   effort traffic in order to achieve congestion control; and a
   selectively reliable transport (SRT) sublayer that formats best-
   effort and reliable transmissions and also creates negative
   acknowledgements when loss of reliable messages is detected.


Table of Contents

   1. Introduction
   1.1 Terminology
   2. Protocol description
   3. Message formats
   3.1 Bundle packet format
   3.2 bundle header format
   3.3 feedback message format
   3.4 SRT Mode 0 header format
   3.5 SRT Mode 1 header format
   3.6 SRT Mode 2 header format
   3.7 User-configurable parameters
   4. TFMCC Operation
   4.1 TCP rate prediction equation
   4.2 Bundling
   4.3 Congestion Control
   4.3.1 The sender's functions
   4.3.1.1 Sender initialization
   4.3.1.2 Measuring the Maximum_RTT
   4.3.1.3 Selecting CLR
   4.3.1.4 Adjusting the Sending Rate
   4.3.1.5 Controlling Receiver Feedback
   4.3.1.6 Select a receiver
   4.3.2 The receiver's functions are
   4.3.2.1 updating the loss event rate
   4.3.2.2 RTT measurement
   4.3.2.3 Setting the desired rate
   4.3.2.4 Feedback and Feedback Suppression
   4.4 Any-Source Multicast
   4.5  Multiple Sources Issue
   4.6 Bundle Size
   4.7 Data rate control
   4.8 Mode 1 loss detection
   4.8.1 Sending a Negative Acknowledgement
   4.9 Unbundling
   4.10 Heartbeat bundle
   5. SRT Operation
   5.1 Mode 0 operation
   5.1.1 Sending Mode 0 messages
   5.1.2 Receiving Mode 0 Messages



Pullen                       Expires: March 2003              [Page 2]

Internet Draft            draft-pullen-srmp-00.txt          October 2002

   5.2 Mode 1 operation
   5.2.1 Sending Mode 1 Data messages
   5.2.2 Receiving Mode 1 Data messages
   5.2.3 Scheduling a Negative Acknowledgement
   5.2.4 Receiving a Negative Acknowledgement
   5.3 Mode 2 Operation
   5.3.1  Sending Mode 2 Data messages
   5.3.2 Receiving Mode 2 Data messages
   5.3.3 Sending a Positive Acknowledgement
   5.3.4 Receiving a Positive Acknowledgement
   6. IANA considerations
   7. Security considerations
   8. Authors' addresses
   9. References
   10. Full copyright statement


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. 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 (RFC2402 [1]) and also with some
   forms of distributed multimedia conferencing.

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 and
   indicate requirement levels for compliant TFMCC 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 Congestion Control (TFMCC)
   as proposed by Widmer and Handley [3] in order to meet the
   requirements of RFC3269 [2] for congestion avoidance.

   SRMP is capable of reliable message delivery over multicast
   networks, when the messages to be delivered reliably represent a
   small fraction (typically, less than 2%) of a larger, associated
   best-effort flow and only the latest reliable message must be
   delivered. The basic strategy of SRMP is to buffer the latest
   sent reliable message at each sender and piggyback its sequence
   number on associated best-effort messages. For this purpose, three
   modes of sending are defined:

Pullen                       Expires: March 2003              [Page 3]

Internet Draft            draft-pullen-srmp-00.txt          October 2002


   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 NAK 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, 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.

       | 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 also by
   bundling multiple short messages that are presented by applications
   within a short time window. It also performs NAK suppression.

   A bundling sublayer data unit is called a bundle. A bundle is made
   up of a bundle header and any of Mode 0 and 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 provides TCP-friendly
   backoff. 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. In distributed simulation, Mode 0
   messages are part of a stream of state update for dynamic data such
   as geographic location; therefore the application can continue to
   function (with lower fidelity) when they are dropped.



Pullen                       Expires: March 2003              [Page 4]

Internet Draft            draft-pullen-srmp-00.txt          October 2002


3. Message formats

3.1 Bundle message format:

   ----------------------------------------------------------
   | bundle header |  SRT Message 1  | SRT message 2 | ...
   ----------------------------------------------------------

   A bundle is an aggregation of multiple SRMP messages of 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 sender and receiver using their 32-bit Sender_ID,
   which may be an IPv4 address.

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 0x2

   type:
      4 bits   0x0 - bundle
               0x1 - feed back
               0x2 - mode 2 message
               other values reserved

   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

Pullen                       Expires: March 2003              [Page 5]

Internet Draft            draft-pullen-srmp-00.txt          October 2002


   Sender_Timestamp:
      16 bits   Representing the time that the bundle was sent out.

   Receiver_Timestamp:
      16 bits   Echo of the Receiver_Time_Stamp field of receiver
                feedback message. If the sender has time delay between
                receiving the feedback and echoing the timestamp, it
                must adjust the Receiver_Timestamp value
                correspondently.

   Receiver_ID
      32 bits   Unique identifier for the receiver within the multicast
                group. IPv4 address may be used.

   Sender_ID:
      32 bits   Unique identifier for the sender within the multicast
                group. IPv4 address may be used.
   X_supp:
      16 bits   The suppression rate corresponding with the sender. Only
                those receivers whose desired rate is less than the
                suppression rate, or RTT larger than R_max, can 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 at end of the header.

   Length:
      16 bits   Range from 0~65535. The total length of the bundle
                (including 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.


Pullen                       Expires: March 2003              [Page 6]

Internet Draft            draft-pullen-srmp-00.txt          October 2002

      NoSegs:
         7 bits   Number of segments, if the DataID was long enough
                  to require segmentation; otherwise 0x0.

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 0x2

   type:
      4 bits   value 0x01

   fb_nr:
      4 bits   current feedback round of the sender.

   flag:
      4 bits
         0001 - have_RTT
         0010 - have_loss
         0100 - receiver_leave
         other bits reserved

   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
                Receiver_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 address may be used. (identifies the receiver
                that sending out feedback message)

   Sender ID:
      32 bits   Unique identifier for the sender within the multicast
                group. IPv4 address may be used. (identifes the sender
                that is the destination of current feedback message)

Pullen                       Expires: March 2003              [Page 7]

Internet Draft            draft-pullen-srmp-00.txt          October 2002


   X_r:
      12 bits   the receiver's desired rate. The desired rate should be
                represented as a 12 bits floating point value with 5
                bits for the unsigned exponent and 7 bits for the
                unsigned mantissa.


3.4 SRT Mode 0 header format

    0              8              16             24             32
    +--------------+--------------+--------------+--------------+
    |version| Type | Mode |padding|            Length           |
    +--------------+--------------+--------------+--------------+

   Version:
      4 bits   (currently 0x2)

   Type:
      4 bits   0x0 - data
               0x1 - NAK
               0x2 - ACK
               other values reserved

   Mode:
      3 bits   0x0 - mode 0
               0x1 - mode 1
               0x2 - mode 2
               other values reserved

   Length:
      11 bits  Length of the payload data (does not include header)


3.5 SRT Mode 1 header format

    0              8              16             24             32
    +--------------+--------------+--------------+--------------+
    |version| Type |Mode|   SegNo   |          Length           |
    +--------------+--------------+--------------+--------------+
    |                            DSN                            |
    +--------------+--------------+--------------+--------------+

   Version:
      4 bits   (currently 0x2)

   Type:
      4 bits   0x0 - data
               0x1 - NAK
               0x0 - ACK
               other values reserved


Pullen                       Expires: March 2003              [Page 8]

Internet Draft            draft-pullen-srmp-00.txt          October 2002


   Mode:
      3 bits   equals 0x1

   SegNo:
      7 bits   The index number of this segment

   Length:
      11 bits   Length of the payload data (does not include header)

   DSN:
      32 bits   Same as in bundle header. Note that this contains
                NoSegs, whereas SegNo is a separate element.

3.6 SRT Mode 2 header format

    0              8              16             24             32
    +--------------+--------------+--------------+--------------+
    |version| Type |Mode| padding |            Length           |
    +--------------+--------------+--------------+--------------+
    |                            SN                             |
    +--------------+--------------+--------------+--------------+

   Version:
      4 bits   (currently 0x2)

   Type:
      4 bits   equals to 0x2

   Mode:
      3 bits   equals to 0x2

   padding:
      5 bits

   Length:
      16 bits   The length of the payload data (does not include header)

   SN:
      32 bits   sequence number

3.7 User-configurable parameters

   Name                 Minimum Value     Recommended Value

   DSN_Max              1                 32
   DataID_Timeout       none              none
   Segment_Timeout      50 ms             250 ms
   Bundle_Timeout       1 ms              10 ms
   Heartbeat_Interval   1 s               none
   Mode2_Max            1                 none
   ACK_Threshold        none              worst RTT for multicast group

Pullen                       Expires: March 2003              [Page 9]

Internet Draft            draft-pullen-srmp-00.txt          October 2002


4 TFMCC Operation

4.1 TCP rate prediction equation

   The recommended throughput equation we currently for SRMP is a
   Slightly simplified version of the throughput equation for Reno TCP
   from [3]:
                                  8 s
     X = ------------------------------------------------------   (1)
         R * (sqrt(2*p/3) + (12*sqrt(3*p/8) * p * (1+32*p^2)))

   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 future, different TCP equations 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 current bundle.

   The SRMP daemon should 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.
   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. 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 is useful.
   SRMP may check for duplicate DataIDs in the same bundle and delete
   all but the latest one.

Pullen                       Expires: March 2003             [Page 10]

Internet Draft            draft-pullen-srmp-00.txt          October 2002

   The bundle header contains the DSN <DataID,SN,NoSegs> for Mode 1
   messages from this sender. The absolute maximum number of DSN is
   256, 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.

4.3 Congestion Control

   The congestion control mechanism operates as described in [3].

4.3.1 Sender functions

4.3.1.1 Sender initialization

   When initialized, the sender should set Maximum_RTT to 500ms or
   greater, set fb_nr and SN to 0x0, set CLR to NULL. The sender should
   set its transmission rate to 1 message/Second. The sender should
   keep a local variable CLR_Leave, and initialize it to 0x0.

4.3.1.2 Measuring the Maximum_RTT

   Upon receiving a feedback message from receiver, the sender must
   calculate the round trip time by

      RTT = t_now - Sender_Timestamp

   If the RTT value is larger than current Maximum_RTT, then
   Maximum_RTT must be updated to RTT. If a sender didn't receive any
   receiver's feedback during a feedback_round, the Maximum_RTT will be
   reduced exponentially by

      Maximum_RTT = Maximum_RTT * 0.95

4.3.1.3 Selecting CLR

   Upon receiving a feedback message from receiver r, the sender must
   check X_r field in the feedback header. If X_r is less than current
   sending rate X_send, then receiver r becomes CLR.

4.3.1.4 Adjusting the Sending Rate

   After initialization, the sender get into slow start. During this
   stage, for each feedback message received, the sender simply
   increase its sending rate to receiver's desired rate. If during one
   Maximum_RTT, the sending rate increment is less than 8s/Maximum_RTT,
   the sender may increase the rate by up to 8s/Maximum_RTT. Whenever
   one receiver report its desired rate less than the sending rate,

Pullen                       Expires: March 2003             [Page 11]

Internet Draft            draft-pullen-srmp-00.txt          October 2002


   slow start will terminate. After slow start, the sender should set
   its sending rate according to the following algorithm:

   for each feedback message
       IF (have_RTT = = 0)
           X_r = X_r * R_max / RTT ;
       END IF
       IF ( CLR = = NULL)
       {   CLR = r ;
           IF ( X_r < X_send + 8s/R_max)
              X_send = X_r ;
           ElSE
               X_send increase to X_r at an increase rate of no more
               than 8s/R_max every R_max ;
       }
       ELSE IF( CLR != r)
       {   IF ( X_r < X_send && receiver_leave == 0)
           {   CLR = r ;
              X_send = X_r ;
           }
           ELSE IF ( CLR_leave = = 1)
           {   CLR = r ;
              IF ( no other feedback received during feedback round)
                 X_send = X_r ;
           }
       }
       ELSE
       {   X_send=min(X_r, X_send+8s/R_Max) ;
           IF ( receiver_leave = = 1)
               CLR_leave =1 ;
       }
       END IF

   If the sender does nott receive any feedback for 10 consecutive RTTs,
   the sending rate must be halved. The sending rate can at most be
   reduced to 1 bundle each 64 seconds. After that, if the sender begins
   to receive new feedback, it should increase the transmission rate at
   1 bundle/RTT^2.

4.3.1.5 Controlling Receiver Feedback

   The sender must keep a timer for feedback round. A feedback round
   equals to four times of current MaxRTT. At the begining of each
   feedback round, the timer must be reset, and fb_nr is incremented by
   1 module 16. X_supp must be set to the highest value that can be
   represented.

   Upon receiving a feedback message, if X_supp > X_r,

      X_supp = 0.9 * X_r


Pullen                       Expires: March 2003             [Page 12]

Internet Draft            draft-pullen-srmp-00.txt          October 2002


   After the timer expires, a new feedback round will begin.

4.3.1.6 Select a receiver

   For each outgoing Bundle, the sender must select a receiver, and
   echo Receiver_Timestamp of that receiver. The sender should select a
   receiver following the sequence:

   1.   a new CLR (after a change of CLR's) or a CLR withoud any
        previous RTT measurements.
   2.   receivers without any previous RTT measurements in the order of
        the feedback round echo of the corresponding receiver report
        (i.e., older feedback first)
   3.   non-CLR receivers with previous RTT measurements, again in
        ascending order of the feedback round echo of the report
   4.   the CLR

   If receiver is selected, the sender must set the correspond
   Receiver_ID field in the bundle header. And if receiver r is CLR,
   the sender must also set IS_CLR flag.

4.3.2 Receiver functions

4.3.2.1 updating the loss event rate

   For each bundle received, the receiver must updates its bundle
   history. It then recalculates the new value of loss event rate P.

4.3.2.1.1 translation from Loss History to Loss Events

   The loss of a bundle is detected by the arrival of at least 3
   bundles with a higher sequence number than the lost bundle. When a
   loss is detected, the sender must calculate the bundle loss time as:

      T_loss = T_before + ( T_after - T_before)
                *(S_loss -S_before)/ (S_after - S_before);

      S_loss - the sequence number of a lost bundle
      S_before - the sequence number of the last bundle to arrive with
         sequence number before S_loss
      S_after - the sequence number of the first bundle to arrive with
         sequence number after S_loss
      T_before - the reception time of S_before
      T_after - the reception time S_after

   If S_after < S_before, then adjust both S_after and S_before with:

      S= (S+65536/2)mod(65536)

   If the lost message S_old was determined to have started the previous
   loss event, and we have just determined that S_new has been lost,

Pullen                       Expires: March 2003             [Page 13]

Internet Draft            draft-pullen-srmp-00.txt          October 2002


   then we interpolate the nominal arrival times of S_old and S_new,
   called T_old and T_new respectively.

   If T_old + RTT >= T_new, then S_new is part of the existing loss
   event. Otherwise S_new is the first message of a new loss event.

4.3.2.1.2 Inter_Loss Event Interval

   If a loss interval, A, is determined to have started with message
   sequence number S_B, then the number of messages in loss interval A
   is given by (S_B - S_A).

4.3.2.1.3 Average Loss Interval

   Average Loss Interval is the mean value of the n most recent
   Inter_loss Event Interval with weights. Recommended value forn is 8.

   Weights w_0 to w_(n-1) are calculated as:

      If (i< n/2)
         w_i =1;

      Else
         w_i = 1-(i-(n/2-1))/(n/2+1);

   w_0 is the weight for most recent Loss Interval.

   Let I_i be the Loss Interval ( I_0 is the most recent one). The
   Average Loss Interval I_mean is calculated as:

      I_tot0 = 0;
      I_tot1 = 0;
      W_tot = 0;
      for( i=0 to n-1) {
         I_tot0=I_tot0 + ( I_i * W_i);
         W_tot = W_tot + W_i;
      }
      for ( i=1 to n ) {
         I_tot1 = I_tot1 + ( I_i * w_(i-1));
      }
      I_tot = max( I_tot0, I_tot1);
      I_mean = I_tot/W_tot;

4.3.2.1.4 Loss Event Rate
   The Loss Event Rate P is calculated as:

   P = 1/ I_mean;

4.3.2.1.5 Initial Loss Event Rate

   Before the first message loss detected, the receiver must measure the

Pullen                       Expires: March 2003             [Page 14]

Internet Draft            draft-pullen-srmp-00.txt          October 2002


   mean receive rate over last 3 RTTs. If RTT is not measured yet, use
   R_Max instead.

   If the receiver first calculated l_0 wiht R_max, then got its RTT
   measured, it must adjust l_0 as:

      l_0 = l_0 * (RTT/ R_max) ^2

4.3.2.2 RTT measurement

   RTT measurement is triggered by calculating the desired rate (see
   4.3.2.3).

   There are 3 cases:

   1.   No RTT measurement has been accomplished yet.

        RTT = Maximum_RTT

   2.   At least one RTT measurement has been fufilled. And the current
        feedback has not been responded by the sender.

        D_r = Receiver_Timestamp ( last echoed by sender) -
              Receiver_Timestamp ( last feedback)
        RTT= t_now - Receiver_Timestamp ( current feedback) + D_r

   3.   Current feedback was already responsed by the sender

        R_sample=t_now - Receiver_Timestamp (echoed by sender)
        RTT = q * RTT + (1-q) * R_sample
             ( If receiver is CLR, q=0.9. Else q=0.5)

4.3.2.3 Setting the desired rate

   For each outgoing feedback message, the receiver must calculate the
   desired rate, and set its value to X_r field in feedback header.

   If a receiver has not experienced any loss events, the receiver must
   keep on measuring the mean receive rate over the last 3 RTTs. It
   should set the desired rate as 2 times of the mean receive rate.

   Otherwise, the receiver should use equation (1) to calculate desired
   rate.

4.3.2.4 Feedback and Feedback Suppression

   Upon receiving a bundle, the receiver must check the fb_nr field in
   the bundle header. When a new feedback round begins, previous
   unfinished measurements must be cancelled. The sender must schedule
   a new feedback.


Pullen                       Expires: March 2003             [Page 15]

Internet Draft            draft-pullen-srmp-00.txt          October 2002


   If the Receiver_ID field in the bundle is current receiver, and
   IS_CLR flag was set, the receiver must immediately send a feedback.

   Otherwise, if the receiver's calculated rate is less than the
   suppression rate or the receiver's RTT is higher than the R_max, the
   receiver must set a feedback timer. Using an exponentially weighted
   random timer mechanism, the feedback timer is set to expire after

      t = max( T * (1+log(x)/log(N), 0)

   where
      x is a random variable uniformly distributed in (0,1]
      T is the duration of a feedback round
      N is an estimated upper bound on the number of receivers.

   A feedback message must be sent to the group by multicast after the
   feedback timer expires. The timer must be cancelled if a bundle
   with a lower suppression rate than the receivers calculated rate
   and a higher or equal R_max than the receivers RTT is received.

   When the R_max changes significantly during one feedback round, it
   is necessary to reschedule the feedback timer in proportion.

      T = t * R_max / R_max'

   where
      R_max is the new R_max value in bundle header.
      R_max' is the previous value.

   If the last bundle was received more than a time interval of R_max
   ago, the receiver must add the difference of the inter-message gap
   and the R_max to the feedback time to prevent a feedback implosion.

      T = t + max(t_now - tr_i - R_max, 0)

   Where tr_i is the time when the last bundle arrived at the receiver.

4.4 Any-Source Multicast

   SRMP uses 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 receiver. 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.

Pullen                       Expires: March 2003             [Page 16]

Internet Draft            draft-pullen-srmp-00.txt          October 2002


   The feedback is multicast to the group. Feedback messages for other
   senders should be silently discarded.

4.6. Bundle Size

   TFMCC is designed for traffic with fixed message size. The maximum
   bundle size (including header) for SRMP is 1454 bytes (Ethernet MTU
   less IP and UDP header length). 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. This will happen in two cases:

   1.   After bundle time out, the current bundle will not wait for new
        SRMP messages. This will happen with sources sending at a slow
        rate.
   2.   Over length; there is no further space in the current bundle
        for new SRMP messages. This will happen with sources sending at
        a high rate.

   The case 1 bundle size is likely to be much smaller than that of
   case 2.

   Therefore in SRMP the TCP the mean value of the 10 most recent
   bundle's size, as the bundle size used in TCP throughput equation.
   This mean value is independent from 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. This the sender's source rate is the sum of the rates
   all clients of the same multicast group.

   If the source rate is larger than the senders 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 NAK for each DSN bearing a DataID for which
   some application has indicated interest, if the SN/SegNo in that DSN
   indicates a NAK is needed. NAKs are sent in bundles, and may be
   bundled with data messages. A NAK is required if:


   o   the SN is one or more greater (mod 512) than the latest received
       Mode 1 message for that DataID, or



Pullen                       Expires: March 2003             [Page 17]

Internet Draft            draft-pullen-srmp-00.txt          October 2002


   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 NAKs 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 NAKs to cause considerable congestion at the original
   sender despite the use of negative acknowledgements instead of
   positive acknowledgements. For this reason, SRMP uses a NAK
   suppression mechanism to reduce the number of NAKs generated in
   response to any single lost message.

   The NAK suppression mechanism uses the Bundle_Timeout to distribute
   NAKs over an appropriate time window. This assumes that the user has
   Selected a bundle timeout appropriate to 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 NAKs for which a response has been sent by
   another member of the multicast group within the NAK_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
   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.





Pullen                       Expires: March 2003             [Page 18]

Internet Draft            draft-pullen-srmp-00.txt          October 2002


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, bundled with
   associated mode 1 transmissions for loss detection. 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 DataID
   and a destination multicast group must be provided to SRMP along
   with the data to be sent. After verifying the data length, DataID
   and multicast group, the following steps must be performed by the
   SRT sublayer:

Pullen                       Expires: March 2003             [Page 19]

Internet Draft            draft-pullen-srmp-00.txt          October 2002


   1.   An SRMP 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 or not
        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 both the multicast group and
   DataID of the message.

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 NAK. 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 3.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 detination 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 0x1, 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

Pullen                       Expires: March 2003             [Page 20]

Internet Draft            draft-pullen-srmp-00.txt          October 2002


        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 DataID must be verified to be one for which some
        application has indicated interest. If no application wants the
        DataID, the message should be silently discarded.

   3.   The <SN,SegNo> of the received message must be buffered, and
        the user data must then be delivered to all applications that
        have indicated interest in the DataID and 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 NAK
        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.

5.2.3 Scheduling 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 NAK is required. If so, it will generate a
   NAK message and send it to the bundling sublayer. The NAK message
   will have version set to 0x2, message type set to 0x1, transmission
   mode set to 0x1. DataID, SN, and destination address are set to that

Pullen                       Expires: March 2003             [Page 21]

Internet Draft            draft-pullen-srmp-00.txt          October 2002


   of the Mode 1 message for which the NAK is being sent. A NAK
   consists solely of a header with empty user data field. If a NAK has
   been received from any member of the destination multicast group for
   the Mode 1 message in question within the NAK threshold, no NAK is
   generated.

   For segmented messages, there are two possible types of NAKs:

   o   Based on the DSN list in the bundle header, SRT may determine
       that an entire segmented Mode 1 message was lost. In this case
       the NACK must carry Segno=0x127 (all one in field).

   o   Based on Segment Timeout, SRT may determine that one or more
       Segments of a message have not been delivered. In this case, a
       NAK will be sent for each missing segment.

5.2.4 Receiving a Negative Acknowledgement

   When a NAK is received by SRT, it must be processed as follows, after
   verifying the multicast address, DataID, and transmission mode:

   1.   If this instance of SRT's most recent Mode 1 message of the
        DataID indicated in the NAK has a SN newer than SN in the NAK,
        that message (which is buffered) should be immediately
        retransmitted to the multicast address indicated in the
        received NAK. If the most recent Mode 1 message has a SN
        equal to the SN indicated in the NAK, and if the SegNo field
        in the NAK contains 0x127, 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 NAK and the (local machine)
        time at which the NAK was received should be buffered. Each
        instance of SRT must know how many NAKs 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 NAKs 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. A Distributed Interactive Simulation (DIS) collision
   PDU is an example of data that would benefit from using transmission
   Mode 2.


Pullen                       Expires: March 2003             [Page 22]

Internet Draft            draft-pullen-srmp-00.txt          October 2002


5.3.1 Sending Mode 2 Data messages

   When an application requests the 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 0x0, 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.

   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 or not 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:

Pullen                       Expires: March 2003             [Page 23]

Internet Draft            draft-pullen-srmp-00.txt          October 2002


   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 3.3.3. below for
        details.

5.3.3 Sending a Positive Acknowledgement

   A positive acknowledgement (ACK) is triggered by the receipt of a
   Mode 2 data message. To send an ACK, a new SRT message is generated
   with version set to 0x02, message type set to 0x2, and transmission
   mode set to 0x2. DataID and SN are those of the Mode 2 data message
   being acknowledged. The destination address field is set to the
   source IP address from which the data message was received. Since
   Mode 2 data messages are unicast there is little concern about an
   ACK implosion causing excessive congestion at the original sender,
   so no suppression mechanism is necessary.

5.3.4 Receiving a Positive Acknowledgement

   When an ACK is received by SRT, after verifying the transmission
   mode, DataID, and source IP address against outstanding Mode 2
   transmission SRT must remove the pending transmission from its
   buffer.


6. IANA Considerations

There are no IANA actions required for this document.


7. Security Considerations

   As a transport protocol, SRMP is subject to denial of service by
   hostile third parties sending conflicting values of its parameters
   on the multicast address. SRMP does not attempt to protect itself
   from this sort of behavior, however it can be shielded from such
   attacks by IPSEC traffic authentication as specified in RFC 2402.









Pullen                       Expires: March 2003             [Page 24]

Internet Draft            draft-pullen-srmp-00.txt          October 2002


8. Authors' Addresses

   J. Mark Pullen
   C3I Center
   George Mason University
   Fairfax, VA 22030
   USA
   mpullen@gmu.edu

   Babu Shanmugam
   C3I Center
   George Mason University
   Fairfax, VA 22030
   USA
   bshanmug@netlab.gmu.edu

   Fei Zhao
   C3I Center
   George Mason University
   Fairfax, VA 22030
   USA
   fzhao@netlab.gmu.edu

   Vincent Laviano
   Distributed Systems Group
   Stanford University
   Stanford, CA 94305
   USA
   vlaviano@stanford.edu

   Danny Cohen
   Sun Microsystems
   6601 Center Drive West
   Los Angeles, CA 90045
   USA
   danny.cohen@sun.com


9. References

[1] J. M. Pullen, J.M., M. Myjak, and C. Bouwens, "Limitations of
    Internet Protocol Suite for Distributed Simulation in the Large
    Multicast Environment,"  Internet Engineering Task Force
    Informational RFC 2502, Internet Society, 1999

[2] S. Floyd, "Congestion Control Principles", Internet Engineering
    Task Force Best Current Practice RFC 2914, Internet Society, 1999

[3] J. Widmer and M. Handley, "TCP-Friendly Multicast Congestion
    Control (TFMCC): Protocol Specification", work in progress, IETF
    Reliable Multicast Transport Working Group, November 2001

Pullen                       Expires: March 2003             [Page 25]

Internet Draft            draft-pullen-srmp-00.txt          October 2002


[4] J. Padhye, V. Firoiu, D. Towsley and J. Kurose, "Modeling TCP
    Throughput: A Simple Model and its Empirical Validation",
    Proceedings of ACM SIGCOMM 1998


10. Full Copyright Statement

Copyright (C) The Internet Society (2002).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS 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."






















Pullen                       Expires: March 2003             [Page 26]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/