Subject: [rmcat] SCReAM feedback requirements

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 21 Jan 2016 08:23:42 +0000

Hi
It was expressed at the last meeting that the feedback requirements should be outlined for the RMCAT candidate algorithms.

This is an outline of the requirements on the congestion control feedback in SCReAM, the text is taken from section 5 in the older version of the SCReAM draft (https://tools.ietf.org/html/draft-ietf-rmcat-scream-cc-00#page-20 )

   The feedback is over RTCP [RFC3550] and is based on [RFC4585].  It is
   implemented as a transport layer feedback message (RTPFB), see
   proposed example in Figure 2.  The feedback control information part
   (FCI) consists of the following elements.

   o  Highest received RTP sequence number (16bits): The highest received RTP
      sequence number for the given SSRC

   o  n_lost (8bits): Accumulated number of lost RTP packets for the given SSRC

   o  Timestamp (32bits) : A timestamp value indicating when the last packet was
      received which makes it possible to compute the one way (extra)
      delay (OWD). The timestamp resolution is recommended to be 0.001s

   o  n_ECN (8bit): Accumulated number of ECN-CE marked RTP packets for the
      given SSRC

   o  Source quench bit (Q), (1bit): Makes it possible to request the sender to
      reduce its congestion window.  This is useful if WebRTC media is
      received from many hosts and it becomes necessary to balance the
      bitrates between the streams.

        0                   1                   2                   3
        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |V=2|P|   FMT   |       PT      |          length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  SSRC of packet sender                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  SSRC of media source                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Highest recv. seq. nr. (16b)  |    n_lost     |   n_ECN       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Timestamp (32bits)                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Q|               Reserved for future use                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 2: Transport layer feedback message

Based on experiments the feedback rate per SSRC is somewhat dependent on the bitrate.
At low bitrates  it is sufficient with a feedback interval of 100ms, while at high bitrates a feedback interval of ~20ms is to prefer.
This leads to a feedback rate according to the following equation
rate_fb = min(50,max(10,rate_rtp/20000))
rate_rtp is the RTP media bitrate expressed in [bits/s]
rate_fb is the feedback rate expressed in [packets/s]

converted to feedback interval it becomes
interval = 1/min(50,max(10,rate_rtp/20000))

The transmission interval is not critical, this means that in the case of multi-stream handling between two hosts, the feedback for two or more SSRCs can be bundled to save UDP/IP overhead.

/Ingemar
=================================
Ingemar Johansson  M.Sc.
Senior Researcher

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com

"We can be heroes,
  just for one day"
    David Bowie
=================================

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 25 Jan 2016 10:21:42 +0000

Hi again

A followup on the n_lost feedback element. The computation of n_lost has some margin for packet reordering, the implementation use a 5 packet reordering margin and that may work to a great extent.
However, given that packet reordering can be quite large it can be a good idea to make the reordering margin adaptive or introduce a time based reordering window similar to TCP RACK. For this reason I am thinking that it could be good to reintroduce the old ACK vector again. This then makes it possible to move the loss detection intelligence to the sender completely, it also makes it quite straightforward to implement adaptive reordering window and RACK functionality.

The feedback format would then change to the below, the functionality will still be the same
             o  Highest received RTP sequence number (16bits): The highest received RTP
                sequence number for the given SSRC

             o  ACK vector (Size ?): A vector that indicates successful reception of packets with sequence number lower than the highest received RTP sequence number. Size is T.B.D, may be a 32 or 64 bit vector or an RLE coded vector, or a vector similar to Googles proposed generic format.

/Ingemar
          _____________________________________________
          From: Ingemar Johansson S
          Sent: den 21 januari 2016 09:24
          To: rmcat WG ([email-masked])
          Cc: Ingemar Johansson S; [email-masked]
          Subject: SCReAM feedback requirements

          Hi

                  0                   1                   2                   3

          /Ingemar

          Ericsson AB
          Wireless Access Networks
          Labratoriegränd 11
          971 28, Luleå, Sweden
          Phone +46-1071 43042
          SMS/MMS +46-73 078 3289
          [email-masked]<mailto:[email-masked]>
          www.ericsson.com<http://www.ericsson.com>

          "We can be heroes,
            just for one day"
              David Bowie