Re: [rmcat] How we should handle feedback, and where the congestion should run

["Michael Ramalho (mramalho)" <[e-mail]>]

+1 to what Xiaoqing said below.

In my discussion time at the microphone I mentioned that all the information needed in the feedback for a per-packet feedback reporting scheme (defined as information on every packet reception sent in one or more the reverse direction packets but at a rate much less than the send packet rate) is highly compressible.

If I assume for the purpose of this discussion that we won't use a transport-wide sequence number (because you can account for all sequence numbers IF you know all the SSRCs you want in the aggregate), then you need to compress the identifier for the equivalent information of 1: {sequence numbers + SSRC} mapping (to know gaps in the aggregate) and 2: receive timestamps for packets in the immediate past.

If I further assume an RTCP XR like reporting which has an overlap in packet reception data (i.e., some portion of the information in older packets were also included in one or more previous reports), I mentioned that one could do an experiment on how efficiently one could compress the data with a "trivial/simple" compressor. Perhaps a delta on sequence numbers, a delta on timestamps and some form of entropy or run-length encoding?

If we can come to agreement on the rough syntax of such information, I'd like to see a back-of-the-envelope calculation for how many bits (on average) the result of this compression would look like with reasonable assumptions on receive time granularity (~100 microseconds) and a reasonable number of SSRCs (for simulcast situations) in the aggregate.

Then we could re-run the experiment with a "transport wide sequence number" in each sent packet (we know exactly how much bandwidth this takes). Then the report need not have the SSRC mapping part of what I describe above (because we have sequence numbers on the aggregate) and the resulting information may compress better (I really don't have a good feeling for this - perhaps Stefan does).

If the result of this thought experiment is that the number of bits per RTCP XR feedback isn't too great  (i.e., the bandwidth penalty relative to the feedback each proposal has now isn't too great) ... then we can think of developing this per-packet feedback approach some more.

Thoughts? Anyone want to take a stab at: 1) the format, 2) the RTCP XR reporting interval (e.g., every 100ms), 3) the overlap in packet reporting (1/3 new packets, 2/3 old packets similar to the 1-out-of-3 RTCP loss assumption for DTMF?).

Michael Ramalho

-----Original Message-----
From: rmcat [mailto:[e-mail]] On Behalf Of Xiaoqing Zhu (xiaoqzhu)
Sent: Monday, November 09, 2015 6:47 PM
To: Randell Jesup
Cc: [e-mail]
Subject: Re: [rmcat] How we should handle feedback, and where the congestion should run

Thanks, Randell, for your comments regarding the bidirectional test case results and also what performance metrics to show. Agree that it will be good to have a side-by-side comparison between scenarios with congested vs. uncongested feedback path. Will add such graphs in future.

Back to the more general discussions on sender-based vs. receiver-based
CC: the discussions here are helpful so we are aware of the advantages and
limitations of either approach.    To me, one additional advantage of the
sender is that it¹s right at the ³place of action², and may have better knowledge on the limitations and current status of the live encoder (e.g., how fast the encoder is reacting to the ramp-up rate request). So, even if the CC rate is recommended by a receiver, the sender will have the final say on what rate to encode at and send.

That said, it¹s probably still possible to combine the best of both worlds. The original GCC proposal has both a sender-based and a receiver-based component, whereas their current design has moved to sender-based. Maybe some good lessons to be learned there from that ³migration². 


Currently, since all three candidate schemes are sender-based, one obvious first step is for us to figure out how often and how much feedback from the receiver is needed as feedback to support this mode of operation, and whether the amount of required overhead is within reason.

For the scenario with bidirectional calls (A<=>B), there should also be the opportunity to piggy-back feedback for A->B along with payload for
B->A, which typically saves on feedback bandwidth. We may either want to
consider that optional now, or wait till after we have a good understanding on the feedback needed for the basic case with one-directional calls.

- Xiaoqing


On 11/6/15, 11:43 PM, "rmcat on behalf of Randell Jesup"
<[e-mail] on behalf of [e-mail]> wrote:

>On 11/6/2015 11:33 PM, Xiaoqing Zhu (xiaoqzhu) wrote:
>> In the eval-test-case draft, there is currently one test case 
>> dedicated for exploring impact of two-way traffic (Sec. 5.3.  
>> Congested Feedback Link with Bi-directional RMCAT flows). Some 
>> corresponding graphs can be found below (they may not reflect the 
>> most up-to-date algorithm performance).
>>
>> * 
>> NADA:http://www.ietf.org/proceedings/92/slides/slides-92-rmcat-4.pdf
>> (page #9 and #10)
>> * SCReAM:
>> 
>>http://www.ietf.org/proceedings/interim/2014/11/09/rmcat/slides/slides
>>-in
>>te
>> rim-2014-rmcat-1-1.pdf (page #9)
>> (Sorry, I was not able to find one with GCC yet.).
>
>Thanks!  Those don't look too bad, though it can be hard to drill down 
>into the details due to the PDF and thickness of the lines (and 
>dense-ness of the graph); I found the closeups at the end of your pdf 
>especially interesting (though not focused on this case).  One question 
>that will be interesting as we develop a feedback mechanism is going to 
>be the requirements from the algorithms on it, and the bandwidth it uses.
>
>I note NADA seems to be slower to respond to delay, though it also 
>seems to do much better against competing TCP flows (and likely the two 
>items are linked, which will make for some interesting tradeoffs and 
>tuning to do).
>
>> Would like to know whether you think that current design of the test 
>>case  has captured gist of the issue encountered by two-way calls, or 
>>any  suggestions on additional test scenarios in that regard?
>
>I think showing a graph similar to Scream's, with congested and 
>non-congested feedback paths is a useful comparison - much easier to 
>see the impact.  Feedback bandwidth would be useful, though that might 
>be fairly fixed right now (multiple of packet rate), so unless it's 
>surprising it may not need graphing (just noting on the graph).
>
>--
>Randell Jesup -- rjesup a t mozilla d o t com Please please please 
>don't email [e-mail]!  Way too much spam
>