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

["Xiaoqing Zhu (xiaoqzhu)" <[e-mail]>]

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
>