home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-parnes-rtp-ext-srm-01.txt < prev    next >
Text File  |  1996-11-21  |  32KB  |  882 lines
  1.  
  2.  
  3. Internet Engineering Task Force                            Peter Parnes
  4. INTERNET-DRAFT                                                 LuTH/CDT
  5. draft-parnes-rtp-ext-srm-01.txt                       November 20, 1996
  6.                                                      Expires: May, 1997
  7.  
  8.  
  9.              RTP extension for Scalable Reliable Multicast
  10.  
  11.  
  12.  
  13.                           Status of this Memo
  14.  
  15.        This document is an Internet-Draft. Internet-Drafts are working
  16.      documents of the Internet Engineering Task Force (IETF), its areas,
  17.      and its working groups. Note that other groups may also distribute
  18.      working documents as Internet-Drafts.
  19.  
  20.      Internet-Drafts are draft documents valid for a maximum of six
  21.      months and may be updated, replaced, or obsoleted by other
  22.      documents at any time. It is inappropriate to use Internet-Drafts
  23.      as reference material or to cite them other than as "work in
  24.      progress."
  25.  
  26.      To learn the current status of any Internet-Draft, please check the
  27.      "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  28.      Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  29.      munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  30.      ftp.isi.edu (US West Coast).
  31.  
  32.      Distribution of this document is unlimited.
  33.  
  34. Abstract
  35.  
  36.      This document describes how the Real-time Transport Protocol, RTP
  37.      (RFC1889), could be extended to include support for parts of the
  38.      framework called Scalable Reliable Multicast. The scheme proposed
  39.      could be used for transporting a data flow reliably over the
  40.      transport protocols supported by RTP in a light-weight way. This
  41.      could be used for numerous applications, for instance white-boards,
  42.      semi-reliable audio/video and messaging/data-transfers within
  43.      group-ware applications.
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54. Peter Parnes                                                    [Page 1]
  55.  
  56.  
  57.  
  58.  
  59. INTERNET-DRAFT                RTP-EXT-SRM                  November 1996
  60.  
  61.  
  62. 1. Introduction
  63.  
  64.    The Real-time Transport Protocol, (RTP) [1] is based on UDP which is
  65.    a best-effort transport protocol meaning that packets can be lost.
  66.    For some applications this is acceptable but for other, for instance
  67.    white-board-applications, it is necessary to do retransmission so an
  68.    end-user can rely on that he has received everything that everybody
  69.    else has sent.
  70.  
  71.    This document describe how RTP could be extended to include support
  72.    for the framework of the so called Scalable Reliable Multicast [2].
  73.    The scheme proposed could be used for transporting a data flow
  74.    reliably over the transport protocols supported by RTP.
  75.  
  76.    This new RTP/SRM-platform could be used for numerous applications,
  77.    including for instance semi-reliable audio/video and distributed
  78.    group-ware applications.
  79.  
  80.  
  81. 2. The Scalable Reliable Multicast Framework
  82.  
  83.    Scalable Reliable Multicast,(SRM) [2] is a reliable multicast
  84.    framework for application level framing and light-weight sessions.
  85.    The algorithms of this framework are efficient, robust and scale well
  86.    to both very large networks and very large sessions. The framework
  87.    has been prototyped in wb, a distributed white-board application, and
  88.    has been extensively tested on a global scale with sessions ranging
  89.    from a few to more than 1000 participants.
  90.  
  91. 2.1 The SRM ideas
  92.  
  93.    The ideas of SRM can briefly be described as follows:
  94.  
  95.      1) Every packet transmitted is uniquely identified by a sender-
  96.         identification and a sequence-number that is incremented by one
  97.         for each transmitted packet.
  98.  
  99.      2) Every member of the session buffers a certain amount of packets,
  100.         even if she is only a receiver and not a sender, so if necessary
  101.         she can participate in 'repairs' of lost packets.
  102.  
  103.      3) When a receiver notices that she has lost packets (by checking
  104.         if the difference of the sequence-numbers of the incoming packet
  105.         and the last heard packet before that is greater than 1) she
  106.         sends a negative acknowledgment, NACK, using multicasting so all
  107.         members of the session sees the NACK. But before sending the
  108.         NACK she waits for a random time determined by the distance of
  109.         the original source and if she hears a NACK for the same packet
  110.  
  111.  
  112.  
  113. Peter Parnes                                                    [Page 2]
  114.  
  115.  
  116.  
  117.  
  118. INTERNET-DRAFT                RTP-EXT-SRM                  November 1996
  119.  
  120.  
  121.         from another member she suppress her own NACK-transmission. See
  122.         section 2.2 for a discussion of how the timers and the distance
  123.         is calculated.
  124.  
  125.      4) Any member that gets a NACK and has the packet requested can
  126.         send a repair but just as in the NACK-case she waits a random
  127.         time before sending the repair. Again see section 2.2 for the
  128.         calculation of the repair-timers.
  129.  
  130.      5) Loss is detected by finding a gap in the sequence space but
  131.         since it is possible the last data-packet is dropped, each
  132.         sender sends a low-rate periodic message, a heartbeat,
  133.         announcing the highest sequence number used.
  134.  
  135.    Please note that this only gives the basic ideas of the algorithms
  136.    used and implementers should read the SRM-paper first.
  137.  
  138.  
  139. 2.2  Calculating timers in SRM
  140.  
  141.    Every timer is based on the distance, D, between the sender and the
  142.    receiver. A member that only is active in repairs is also called a
  143.    sender.
  144.  
  145. 2.2.1 NACK timers (point 6)
  146.  
  147.    When loss is detected a NACK-timer is started. The expire-time is
  148.    chosen from the uniform distribution of
  149.  
  150.                          2^i*[C1*Dsa, (C1+C2)*Dsa]
  151.  
  152.    seconds, where Dsa is host A's estimate of the one-way delay to the
  153.    original source S of the missing data, C1 and C2 are parameters of
  154.    the request algorithm and i is the count of how many times back-off
  155.    has been issued. See section 2.2.3 for initial values of C1 and C2.
  156.    The initial value of i is 0. When the request timer expires, host A
  157.    multicasts the NACK for the missing data, and doubles the request-
  158.    timer by increasing i by one to wait for the repair.
  159.  
  160.    If host A receives a NACK for the missing data before its own
  161.    request-timer for that missing data expires, host A does a
  162.    exponential back-off, and resets its request timer. This means that
  163.    the new timers expire-time is randomly chosen from the uniform
  164.    distribution of
  165.  
  166.                       2^(i+1)*[C1*Dsa, (C1+C2)*Dsa].
  167.  
  168.    To improve the repair time we don't back-off the request timer for
  169.  
  170.  
  171.  
  172. Peter Parnes                                                    [Page 3]
  173.  
  174.  
  175.  
  176.  
  177. INTERNET-DRAFT                RTP-EXT-SRM                  November 1996
  178.  
  179.  
  180.    every duplicate request that is received. For example, if a member
  181.    receives several duplicate requests immediately after receiving the
  182.    initial request, that member only backs off its request timer once.
  183.    After the initial timer back-off, we only back-off the timer again if
  184.    a request is received close to the time when the timer is set to
  185.    expire. More precisely, when we back-off the request timer, we set an
  186.    ignore-back-off variable to a time halfway between the current time
  187.    and the expiration time, and we ignore additional duplicate requests
  188.    until the ignore-back-off time.
  189.  
  190. 2.2.2 Repair-timers (point 7)
  191.  
  192.    When host B receives a request from A that host B is capable of
  193.    answering, host B sets a repair timer to a random value from the
  194.    uniform distribution of
  195.  
  196.                            [D1*Dab, (D1+D2)*Dab]
  197.  
  198.    seconds where Dab is host B's estimate of the one-way delay to host
  199.    A, and D1 and D2 are parameters of the repair algorithm. See section
  200.    2.2.3 for initial values of D1 and D2. If host B receives a repair
  201.    for the missing data before its repair timer expires, host B cancels
  202.    the timer. Otherwise, when host B's repair timer for that data
  203.    expires host B multicasts the repair.
  204.  
  205.    A host could receive duplicate NACKs immediately after sending a
  206.    repair. In order to prevent these duplicate NACKs from triggering a
  207.    responding set of duplicate repairs, host B ignores NACKs for data d
  208.    for 3*Dsb seconds after sending or receiving a repair for that data.
  209.    Host s is either the original source of data d or the source of the
  210.    first NACK.
  211.  
  212. 2.2.3 Initial values of the timer parameters
  213.  
  214.    The initial values of the timer parameters should be set to C1=C2=2,
  215.    D1=D2=log10(G), where G is is the current number of members in the
  216.    session.
  217.  
  218.    An adaptive algorithm for changing these parameters is presented in
  219.    [2].
  220.  
  221.  
  222. 2.3 Calculating the host-to-host distances
  223.  
  224.    In order to be able to calculate the NACK and repair timers we need
  225.    to have some knowledge of the host-to-host distance. This distance is
  226.    calculated in seconds based on how long it takes for a packet to
  227.    travel from host A to host B.
  228.  
  229.  
  230.  
  231. Peter Parnes                                                    [Page 4]
  232.  
  233.  
  234.  
  235.  
  236. INTERNET-DRAFT                RTP-EXT-SRM                  November 1996
  237.  
  238.  
  239.    To be able to do this each member of the session sends a time-stamp
  240.    which is used in the following way to calculate the host-to-host
  241.    distance:
  242.  
  243.      Assume that host A sends a session packet P1 at time t1 and host B
  244.      receives P1 at time t2. At some later time, t3, host B generates a
  245.      session packet P2, containing (t1, d), where d = t3 - t2 (time t1
  246.      is included in P2 to make the algorithm robust to lost session
  247.      packets). Upon receiving P2 at time t4, host A can estimate the
  248.      latency from host B to host A as (t4 - t1 - d)/2. Note that while
  249.      this estimate does assume that the paths are symmetric, it does not
  250.      assume synchronized clocks.
  251.  
  252.  
  253. 3. How does SRM fit into RTP?
  254.  
  255.    Here follows a description of how the SRM ideas fit into RTP
  256.    according to the points in the earlier sections. Points marked with a
  257.    needed changes.
  258.  
  259.      1)  RTP has a unique sender-ID, the Synchronization Source (SSRC)
  260.          and each data-packet has a sequence-number.
  261.  
  262.      2)  The buffering can be accomplished without interfering with the
  263.          protocol itself.
  264.  
  265.      3*) The transmission of NACKs has to be incorporated into RTP using
  266.          for instance the Real-time Transport Control Protocol, RTCP.
  267.  
  268.      4*) The transmission of repairs have to be incorporated into RTP.
  269.  
  270.      5*) The heartbeats have to be incorporated into RTP/RTCP.
  271.  
  272.      6)  The timer calculations don't imply any changes to RTP/RTCP.
  273.  
  274.      7*) The time-stamps should be incorporated into RTCP. The NTP-
  275.          time-stamp in the RTCP/SR packet is to be used but this implies
  276.          that all clients has to implement the usage of this field (the
  277.          RTP specification has left it optional for clients to use this
  278.          field). In order to calculate the host-to-host delay all
  279.          clients need to have some notion of wall-clock time or elapsed
  280.          time.
  281.  
  282.    Out-of-order packets could initially be seen as lost packets and lead
  283.    to a started NACK-timer but when the "lost" packet(s) arrives the
  284.    NACK-timer should be cancelled and an ignore flag should be raised
  285.    for a time of 3*Dsa, where Dsa is the receivers notion of the
  286.    distance to the sender. All NACKs received within this time should be
  287.  
  288.  
  289.  
  290. Peter Parnes                                                    [Page 5]
  291.  
  292.  
  293.  
  294.  
  295. INTERNET-DRAFT                RTP-EXT-SRM                  November 1996
  296.  
  297.  
  298.    ignored.
  299.  
  300.  
  301. 4. What extensions are needed to RTP/RTCP
  302.  
  303.    This section explains the needed additions to RTP/RTCP. The new
  304.    needed packet-formats are discussed section 5.
  305.  
  306.    The additional SRM-generated-traffic can be incorporated into RTP
  307.    basically in two ways; either incorporate all additional packets and
  308.    data into the same channel as the original RTP or send all traffic on
  309.    a separate multicast-group as a new channel.
  310.  
  311.      The first method would allow for clients that don't understand the
  312.      SRM additions to benefit from the retransmitted repairs but would
  313.      destroy their jitter-calculations and traffic-monitoring
  314.      applications.
  315.  
  316.      The second method means that all additional SRM-generated-packets
  317.      are sent on a separate RTP-data/RTCP channel. Only "standard" RTP-
  318.      data/RTCP packets are sent on the base-channel. This would allow
  319.      clients that doesn't understand the SRM extension to join and
  320.      listen to the session. This is for instance preferable when doing
  321.      semi-reliable audio/video transfers where clients understanding the
  322.      extension could get extra value.
  323.  
  324.    The second method is the one chosen and discussed in the rest of this
  325.    draft. The added channel is called the "SRM-channel".
  326.  
  327. 4.1 NACKs (point 3)
  328.  
  329.    The NACK-transmissions should be implemented using RTCP by adding a
  330.    new RTCP packet-type, 205 is proposed for now.
  331.  
  332. 4.2 Retransmission of data-packets (point 4)
  333.  
  334.    The retransmissions can be handled in three ways:
  335.  
  336.      * Either we just let applications that don't understand the SRM-
  337.        extension to see the retransmitted packets as original data and
  338.        interpret them as duplicates or late packets. This would be nice
  339.        because applications that don't understand SRM would benefit, but
  340.        it would unfortunately 'break' traffic estimation and analysis
  341.        programs. It would also break applications, like for instance the
  342.        MBone-tool VAT, because they adjust the play-out delay according
  343.        to the jitter of the incoming packets.
  344.  
  345.      * Or all the retransmitted packets could be encapsulated using a
  346.  
  347.  
  348.  
  349. Peter Parnes                                                    [Page 6]
  350.  
  351.  
  352.  
  353.  
  354. INTERNET-DRAFT                RTP-EXT-SRM                  November 1996
  355.  
  356.  
  357.        new payload-type for redundant data. This would not break
  358.        existing applications as RTP states that unknown payload-types
  359.        should be ignored.
  360.  
  361.      * Or the extra data-packets could be sent on a separate RTP-channel
  362.        using layered encoding. This means that the extension-
  363.        understanding client would listen to at least two channels, the
  364.        base-channel (an ordinary RTP-channel) and a secondary channel,
  365.        the SRM-channel, where all SRM-originated traffic is sent. The
  366.        SRM-channel should be run on a separate multicast group to
  367.        benefit from group pruning.
  368.  
  369.        The third method is to be used.
  370.  
  371. 4.3 Heartbeats (point 5)
  372.  
  373.    The heartbeats could be incorporated into the SR-packets using the
  374.    "profile-specific-extensions" but two things argue against this:
  375.  
  376.      * This isn't inter-operable with other payload-specific-extensions
  377.        as there can only be one header-extension.
  378.  
  379.      * The SR-packets are only sent during and once right after a sender
  380.        transmits data but the heartbeats should be sent all the time, so
  381.        a receiver that have lost several packets directly after the end
  382.        of a data-flow would notice that she has lost packets.
  383.  
  384.    Instead the heartbeats should be sent using the new RTCP-SRM packet-
  385.    type on the SRM-channel.
  386.  
  387.    These heartbeats should be sent more often right after a sender has
  388.    stopped sending so receivers can notice that they have lost packets
  389.    more quickly. This isn't a problem for small groups as the dynamic
  390.    delay between RTCP-packets is small but in larger groups the delay
  391.    could become a problem.
  392.  
  393. 4.4 Time-stamps (point 7)
  394.  
  395.    Time-stamps for active senders on the RTP-channel are calculated
  396.    using the Sender- and Receiver reports (SR and RR) in RTP as
  397.    described in section 6.3.1 of [RFC1889]. No extra information is
  398.    needed for this.
  399.  
  400.    This section describe how time-stamps for passive members should be
  401.    calculated.
  402.  
  403.    The time-stamps are added into the new RTCP-packet-type and divided
  404.    into two types.
  405.  
  406.  
  407.  
  408. Peter Parnes                                                    [Page 7]
  409.  
  410.  
  411.  
  412.  
  413. INTERNET-DRAFT                RTP-EXT-SRM                  November 1996
  414.  
  415.  
  416.    The first type is "time-stamp queries" where a member sends out his
  417.    wall-clock time-stamp and every other member of the session is
  418.    expected to answer this query using the second type "time-stamp
  419.    replies".
  420.  
  421.    A time-stamp query should be included in the first RTCP-packet that a
  422.    new member sends out after joining the session.
  423.  
  424.    Replies to pending queries (if any) should be sent each time we send
  425.    a RTCP-packet. Several replies can be contained in the same RTCP-
  426.    packet as it would lower the overhead. The time-stamp replies for a
  427.    new member should have higher priority than replies to an old member.
  428.  
  429.    When old receivers see a new member they should set a query-timer
  430.    chosen randomly from the interval [0.5 , 5]*current_RTCP_interval
  431.    with a minimum of 5 seconds and a maximum of 2 minutes. If they
  432.    before the expire don't see another query they send out a query of
  433.    their own. If they on the other hand do see a query they reset their
  434.    query-timer and choose a new random expire-time.
  435.  
  436.    Each 5*current_RTCP_interval since last query, (minimum 2 minutes,
  437.    maximum 5 minutes) the member sends out a new query.
  438.  
  439.  
  440. 5. Packet format
  441.  
  442.    This section explains the format of the new RTCP-SRM packets.
  443.  
  444.    A new RTCP packet type is defined, PT = 205.
  445.  
  446. 5.1 Header format
  447.  
  448.    The header is the same for all RTCP-SRM packets:
  449.  
  450.     0                   1                   2                   3
  451.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  452.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  453.    |V=2|CM | Count |       PT      |             length            | header
  454.    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  455.  
  456.      Version (V): 2 bits
  457.           Identifies the version of RTP, two (2).
  458.  
  459.      Command (CM): 2 bits
  460.           The SRM-command as defined below.
  461.  
  462.      Count: 4 bits
  463.           The number of command-data-fields minus one included in this
  464.  
  465.  
  466.  
  467. Peter Parnes                                                    [Page 8]
  468.  
  469.  
  470.  
  471.  
  472. INTERNET-DRAFT                RTP-EXT-SRM                  November 1996
  473.  
  474.  
  475.           packet. How this field is used depends on the command, see
  476.           below.
  477.  
  478.      Packet type (PT): 8 bits
  479.           Contains the constant 205 to identify this RTCP packet as a
  480.           SRM packet.
  481.  
  482.      Packet length (length): 16 bits
  483.           The length of this RTCP packet in 32-bit words minus one,
  484.           including the header. (The offset of one makes zero a valid
  485.           length and avoids a possible infinite loop in scanning a
  486.           compound RTCP packet, while counting 32-bit words avoids a
  487.           validity check for a multiple of 4.)
  488.  
  489.    Depending on the Command (CM) field the header is followed by any of
  490.    the following:
  491.  
  492. 5.2 Heartbeat (CM=0)
  493.  
  494.    For heartbeats CM contains the constant 0 and the header is followed
  495.    by 16-bits containing the latest sequence number used by the sender
  496.    when this report was issued. The next 16 bits contain the cycle
  497.    number which indicate how many times the sender has wrapped his
  498.    sequence number. This allows for clients detect that they have lost
  499.    more that 2^16 packets (when the sequence number counter wraps
  500.    around) which can happen during net-failure and/or high
  501.    transmission-speeds.
  502.  
  503.    The sender is identified by the SSRC field in the SR or RR-report
  504.    that must come before this SRM-packet.
  505.  
  506.     0                   1                   2                   3
  507.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  508.    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  509.    |        Sequence number        |         Cycle number          |
  510.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  511.  
  512.      Sequence number: 16 bits
  513.           The highest sequence number used by the sender when sending
  514.           this report.
  515.  
  516.      Cycle number: 16 bits
  517.           How many times the sender has wrapped his sequence number.
  518.  
  519. 5.3 Time-stamp queries (CM=1)
  520.  
  521.    To be able to calculate the host-to-host delay a member has to send
  522.    out a time-stamp. The time-stamp is composed of the 32 middle bits of
  523.  
  524.  
  525.  
  526. Peter Parnes                                                    [Page 9]
  527.  
  528.  
  529.  
  530.  
  531. INTERNET-DRAFT                RTP-EXT-SRM                  November 1996
  532.  
  533.  
  534.    a 64 bits NTP time-stamp, meaning the 16 first bits signify the
  535.    seconds and the later 16 bits signify the fraction.
  536.  
  537.    The CM-field in the header contains the constant 1 and the count
  538.    field is not used.
  539.  
  540.    The header is followed by the following:
  541.  
  542.     0                   1                   2                   3
  543.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  544.    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  545.    |                           time-stamp                          |
  546.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  547.  
  548.      time-stamp: 32 bits
  549.           The senders current wall-clock time as defined above.
  550.  
  551. 5.4 Time-stamp replies (CM=2)
  552.  
  553.    Several time-stamp replies can be contained in the same SRM-packet
  554.    and the number of replies are count+1.
  555.  
  556.    A reply-packet for a certain receiver should only be issued if we
  557.    earlier have received a time-stamp query.
  558.  
  559.    The header is followed by the following:
  560.  
  561.     0                   1                   2                   3
  562.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  563.    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  564.    |                             SSRC_1                            |block1
  565.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  566.    |                         Last time-stamp(LTQ)                  |
  567.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  568.    |                              DLTQ                             |
  569.    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  570.    |                             SSRC_2                            |block2
  571.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  572.    |                              ....                             |
  573.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  574.  
  575.      SSRC_n: 32 bits
  576.           The SSRC of the sender to whom we are answering.
  577.  
  578.      Last time-stamp query (LTQ): 32 bits
  579.           The time-stamp that SSRC_n sent out earlier
  580.  
  581.      Delay since last time-stamp query (DLTQ): 32 bits
  582.  
  583.  
  584.  
  585. Peter Parnes                                                   [Page 10]
  586.  
  587.  
  588.  
  589.  
  590. INTERNET-DRAFT                RTP-EXT-SRM                  November 1996
  591.  
  592.  
  593.           The delay, expressed in units of 1/65536 seconds, between
  594.           receiving the last time-stamp query packet from source SSRC_n
  595.           and sending this reply.
  596.  
  597.    If SSRC_n receives this reply at time A the host-to-host delay, D,
  598.    can be calculated as
  599.  
  600.                          D = (A - LTQ - DLTQ) / 2
  601.  
  602. 5.5 NACKs (CM=3)
  603.  
  604.    Three different types of NACK-packets are currently defined:
  605.  
  606.      Single NACKs for specific packets from one sender.
  607.  
  608.      Sequential NACKs requesting a series of lost packets.
  609.  
  610.      Application specific NACKs.
  611.  
  612.    Each RTCP-NACK can include NACKs for one sender, but several NACKs
  613.    for different senders may be included into a compound RTCP-packet.
  614.  
  615.    Different NACK-types are distinguished by the NACK-Type-field, NT.
  616.  
  617.    Each NACK-request also include an urgent-flag (U) indicating (if
  618.    raised) that this request should be prioritized over requests that
  619.    don't have the flag set. How this flag is used is application
  620.    specific (see section 6).
  621.  
  622. 5.5.1 Single NACKs, (NT=0)
  623.  
  624.    This type of NACK is used for requesting lost packets by specifying
  625.    each lost packet.
  626.  
  627.    The CM-field contains the constant 0 and the count field contains the
  628.    number of NACKs minus one included in this SRM-packet. This makes
  629.    zero a useful number as it doesn't make much sense to send an empty
  630.    NACK packet just containing the SSRC.
  631.  
  632.    The header is followed by the following:
  633.  
  634.     0                   1                   2                   3
  635.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  636.    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  637.    |NT |U|        not used         |          Cycle count          |
  638.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  639.    |                              SSRC                             |
  640.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  641.  
  642.  
  643.  
  644. Peter Parnes                                                   [Page 11]
  645.  
  646.  
  647.  
  648.  
  649. INTERNET-DRAFT                RTP-EXT-SRM                  November 1996
  650.  
  651.  
  652.    |                     First Sequence number                     |
  653.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  654.    :                              ....                             :
  655.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  656.    |                      Last Sequence number                     |
  657.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  658.  
  659.      NACK-Type (NT): 2 bits
  660.           Indicates the type of the NACK as a single NACK, 0.
  661.  
  662.      Urgent (U): 1 bit
  663.           Indicating that this is an urgent request.
  664.  
  665.      Cycle count: 16 bits
  666.           The cycle count for the first sequence number as reported in
  667.           an earlier heartbeat.
  668.  
  669.      SSRC: 32 bits
  670.           The SSRC of the sender from whom we have lost the packets.
  671.  
  672.      First/Last Sequence number: 32 bits
  673.           The sequence numbers of the packets lost from this SSRC. The
  674.           number of sequence numbers is determined by the count-field in
  675.           the header.
  676.  
  677. 5.5.2 Sequential NACKs, (NT=1)
  678.  
  679.    This type of NACK is used for requesting lost packets by specifying a
  680.    sequence number and the number of following lost packets.
  681.  
  682.    The CM-field contains the constant 1 and the count field contains the
  683.    number of NACKs minus one included in this SRM-packet. This makes
  684.    zero a useful number as it doesn't make much sense to send an empty
  685.    NACK packet just containing the SSRC.
  686.  
  687.    The header is followed by the following:
  688.  
  689.     0                   1                   2                   3
  690.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  691.    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  692.    |NT |U| Number of lost packets  |          Cycle count          |
  693.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  694.    |                              SSRC                             |
  695.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  696.    |                     First Sequence number                     |
  697.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  698.  
  699.      NACK-Type (NT): 2 bits
  700.  
  701.  
  702.  
  703. Peter Parnes                                                   [Page 12]
  704.  
  705.  
  706.  
  707.  
  708. INTERNET-DRAFT                RTP-EXT-SRM                  November 1996
  709.  
  710.  
  711.           Indicates the type of the NACK as a sequential NACK, 1.
  712.  
  713.      Urgent (U): 1 bit
  714.           Indicating that this is an urgent request.
  715.  
  716.      Number of lost packets: 13 bits
  717.           The number of lost packets following the specified sequence
  718.           number.
  719.  
  720.      Cycle count: 16 bits
  721.           The cycle count for the first sequence number as reported in
  722.           an earlier heartbeat.
  723.  
  724.      SSRC: 32 bits
  725.           The SSRC of the sender from whom we have lost the packets.
  726.  
  727.      First Sequence number: 32 bits
  728.           The sequence number of the first packets lost from this SSRC
  729.           in this sequence of lost packets.
  730.  
  731. 5.5.2 Application specific NACKs, (NT=2)
  732.  
  733.    This type of NACK is used for requesting lost packets in a way that
  734.    is specific for the application using this RTP/SRM scheme. It can be
  735.    used by applications to optimize the buffering by allowing repairers
  736.    to reconstruct repair-packets from some other representation of the
  737.    data. This could be used for file-transmissions where the incoming
  738.    data is transformed into a file.
  739.  
  740.    The CM-field contains the constant 2 and the length of this packet is
  741.    determined by the length field in the header.
  742.  
  743.    The header is at-least followed by 4 bytes where the first byte is
  744.    defined as follows:
  745.  
  746.     0                   1                   2                   3
  747.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  748.    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  749.    |NT |                      Un-specified                         |
  750.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  751.    :                              ...                              :
  752.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  753.    :                              ...                              :
  754.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  755.  
  756.      NACK-Type (NT): 2 bits
  757.           Indicates the type of the NACK as a application specific NACK,
  758.           2.
  759.  
  760.  
  761.  
  762. Peter Parnes                                                   [Page 13]
  763.  
  764.  
  765.  
  766.  
  767. INTERNET-DRAFT                RTP-EXT-SRM                  November 1996
  768.  
  769.  
  770.           6. Semi-reliable sessions
  771.  
  772.           Not all applications can wait a long time-period before
  773.           receiving a repair for a lost packet. For instance, real-time
  774.           data as audio and video that is played out almost immediately
  775.           as received would have to get their repairs almost
  776.           immediately. This leads to that the NACKs for such streams has
  777.           to be prioritized over other NACKs if contained within the
  778.           same RTP-session. The U-flag in the NACK-RTCP-packet can be
  779.           used for this.
  780.  
  781.           For some applications it might not make any sense in receiving
  782.           the repair after a certain time-period (as the real-time data
  783.           might already have been played out). These applications might
  784.           decide not to retransmit a certain repair if the time since
  785.           they received the NACK plus the network distance is larger
  786.           that some number. This number is application specific.
  787.  
  788.           This type of sessions are called semi-reliable sessions.
  789.  
  790.  
  791. 7. Further issues
  792.  
  793.    [2] presents algorithms for dynamically adjusting the timer
  794.    parameters C1,C2,D1 and D2. These algorithms should be included but
  795.    do not imply any changes to the actual packet-format.
  796.  
  797.    [2] also presents methods for "local recovery" meaning that we don't
  798.    multicast NACKs to the whole session but instead minimize the scope
  799.    of the NACKs by adjusting the TTL. This TTL is adaptively changing as
  800.    clients get to know their "loss neighbourhood".
  801.  
  802.  
  803. 8. Acknowledgments
  804.  
  805.    I'd like to thank Jon Crowcroft, Anders Klemets and Todd Montgomery
  806.    for creative comments and encouragements.
  807.  
  808.    This work is done within the Multimedia Assisted distributed Tele-
  809.    Engineering Services, MATES, project (ESPRIT 20598). I want to thank
  810.    the Department of Computer Science and the Centre for Distance-
  811.    spanning Technology at the Lulea Technical University for giving me
  812.    the opportunity to do this work.
  813.  
  814.  
  815. 9. Author's Address
  816.  
  817.         Peter Parnes
  818.  
  819.  
  820.  
  821. Peter Parnes                                                   [Page 14]
  822.  
  823.  
  824.  
  825.  
  826. INTERNET-DRAFT                RTP-EXT-SRM                  November 1996
  827.  
  828.  
  829.         Dept. of Computer Science/Centre for Distance-spanning Technology
  830.         Lulea Technical University
  831.         S-971 87 Lulea, Sweden
  832.         Tel: +46 920 72421
  833.         Fax: +46 920 72191
  834.         E-Mail: peppar@cdt.luth.se
  835.         WWW: <URL:http://www.cdt.luth.se/~peppar/>
  836.  
  837.  
  838. 10. References
  839.  
  840.       [1] Schulzrine/Casner/Frederic/Jacobson, "RTP: A Transport
  841.           Protocol for Real-Time Applications", RFC 1889, January 1996
  842.  
  843.       [2] Floyd/Jacobson/McCanne/Liu/Zhang, "A Reliable Multicast
  844.           Framework for Light-weight Sessions and Application Level
  845.           Framing", Proceedings of ACM SIGCOMM 95,
  846.           <URL:ftp://ftp.ee.lbl.gov/papers/srm_sigcomm.ps.Z>. An
  847.           extended and corrected version is submitted to IEEE/ACM
  848.           Transactions on Networking,
  849.           <URL:ftp://ftp.ee.lbl.gov/papers/srm1.tech.ps.Z>
  850.  
  851.  
  852.  
  853.  
  854.  
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861.  
  862.  
  863.  
  864.  
  865.  
  866.  
  867.  
  868.  
  869.  
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880. Peter Parnes                                                   [Page 15]
  881.  
  882.