Subject: [rmcat] SCReAM feedback rate (was RE: Feedback format for SCReAM)

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 24 Feb 2015 07:42:17 +0000

Hi Mirja

Added the RMCAT list to this thread.

The relatively high feedback rate in SCReAM is not really of importance for the congestion window growth, for that to work it is likely sufficient with one feedback per RTT as you say. 

The issue is with the ACK clocking in SCReAM, a low feedback rate will acknowledge many packets but as the transmission scheduling cannot transmit more than the available send window. I low feedback will thus make packets pile up in the RTP queue until the feedback is received and as the video rate control monitors the size of the RTP queue the effect is that the video bitrate is reduced. This has made SCReAM vulnerable to reverse path congestion before, the algorithm is not that vulnerable today as the video target bitrate is calculated differently (see section 4.1.3 " maximum value of rate_transmit and rate_acked ").
If low feedback rate is necessary, one idea would be to predict how many bytes that will be ACKed but that would risk make reaction to congestion worse. 

With that said. A high feedback rate is  most important at high bitrates. Some experimentation shows that at 10Mbps it is necessary with a feedback interval of 20-30m in order to sustain the high thorughput. While at 100kbps (think audio) a feedback interval of 200ms will work.
This would give an RTCP overhead of ~0.5% at 10Mbps and ~2-3% at 100kbps, assuming 50byte RTCP (Reduced Size)

/Ingemar

-----Original Message-----
From: Mirja Kühlewind [mailto:[email-masked]] 
Sent: den 23 februari 2015 17:12
To: Ingemar Johansson S
Cc: Magnus Westerlund; Karen E. E. Nielsen; Eggert, Lars ([email-masked]); [email-masked]
Subject: Re: Feedback format for SCReAM

Hi Ingemar,

okay, get the argument about the overhead. Still the question if it's really worth it to have an other report format here. However, that's on the RTP/WebRTC guys to decide.

The other question is, how often is the feedback really needed. That question really depends on your algorithm design. If you have a packet based sending window and increase by at max one packet per RTT, in fact you only need on feedback report per RTT (expect of redundancy in case of loss; but in this case it might potentially even make sense to request a higher rate somehow dynamically.).

So what would be the minimum feedback frequency you'd need?

Mirja

> Am 23.02.2015 um 15:57 schrieb Ingemar Johansson S <[email-masked]>:
> 
> Hi
> 
> The receive timestamp is for the highest received sequence number. On the sender side this is compared against the wallclock timestamp when said RTP packet was transmitted, this makes it possible to compute the one way delay. It is not necessary to ACK every RTP packet for a good estimate of the OWD, a too sparse feedback can however reduce the max throughput for higher bitrate video as the ACK-clocking becomes less efficient (at 10Mbps it is necessary with a feedback roughly every 20-30ms).
> 
> PT in feedback : My though was that it is necessary to discriminate the feedback based on the {SSRC,PT} tuple, this because two PTs may have different sequence number space, but if that is not the case then I am happy to remove the PT from the feedback.
> 
> Regarding a reusing or extending RTCP XR, my only concern is that the 
> feedback is sufficiently slim to support the relatively high feedback 
> rate at high video bitrates without necessitating a very high RTCP BW, 
> of course reduced size RTCP helps a bit here
> 
> /Ingemar
> 
> 
> 
> -----Original Message-----
> From: Magnus Westerlund
> Sent: den 23 februari 2015 15:41
> To: Mirja Kühlewind; Ingemar Johansson S
> Cc: Karen E. E. Nielsen; Eggert, Lars ([email-masked]); 
> [email-masked]
> Subject: Re: Feedback format for SCReAM
> 
> On 2015-02-23 15:11, Mirja Kühlewind wrote:
>> Hi,
>> 
>> see below.
>> 
>> 
>>> Am 23.02.2015 um 12:45 schrieb Ingemar Johansson S <[email-masked]>:
>>> 
>>> Hi
>>> 
>>> OK, good that you agree on the ACK vector Yes, one could use RFC6679 
>>> ECN feedback report format as it contains a lost packets counter.
>>> The missing elements are
>>> + RTP PT (8bit)
>>> + Receive timestamp (32bit)
>> 
>> Okay, one potentially stupid question because I'm not an RTCP
>> expert:
> Wouldn't it be sufficient to simply define another extended report with these information?
> 
> Yes, that is reasonably straight forward. The PT we may not need. The question is which Receive timestamp do you need? Just for the latest received packet?
> 
> One possibility is to use the RTCP XR formats Packet Receipt Times Report Block, which is defined in Section 4.3 of RFC 3611. I think one could potentially use this with just a single sequence number.
> 
> But, if more efficient packing is needed for Scream, defining a new format is relatively easy.
> 
>> 
>>> The RTP PT is needed for the cases where a session runs the same 
>>> SSRC but multiplex media over two different PT.
>> 
>> Is this really the way this is used? And do you need to split this up 
>> to perform congestion control separately for the two PTs.? Is this 
>> the right way to do this?
> 
> No, it is not. I haven't discussed this with Ingemar. But one SSRC is one media source, or at least packet source (in case of Retransmission or layered codecs). The PT really only indicates how the packet was encoded, it shall not be necessary to use to do flow separation.
> 
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: [email-masked]
> ----------------------------------------------------------------------