[R-C] BoF approved

[Zaheduzzaman Sarker]

On 2012-07-21 12:16, Michael Welzl wrote:
> Hi,
>
> I'm getting a bit lost here, see below:
>
>
> On Jul 18, 2012, at 3:06 PM, Mo Zanaty (mzanaty) wrote:
>
>> Zaheduzzaman Sarker <zaheduzzaman.sarker at ericsson.com> wrote:
>>> The only thing that can be expected is that the upcoming WG
>>> solution have
>>> fallback mechanism to work with existing RTP application using
>>> standard
>>> mechanism such as RTCP SR/RR. The upcoming WG solution should also
>>> consider that fact that there could be application out in the
>>> Internet
>>> which falls in to real-time interactive category but does not adapt
>>> at all.
>
> About the latter sentence, in which way do you suggest that the WG
> should consider that fact?

My thinking below-

1. The WG's should provide behavior guidelines for the standard 
compliant side when communicating with non-compliant side. It's task 
should not stop by only specifying new signals and behaviors where both 
side follows them. I understand that there could be lots of ways one 
endpoint becomes non-compliant and it will be tricky to cover all. Thus 
the WG should define how one endpoint becomes non-compliant and then 
simple guideline for the compliant endpoint about what to do with it.
This is necessary otherwise people will try to solve it in their own 
ways and will result in lots of different solution to same problem.

2. When evaluating new solutions, WG should include the case where other 
flows sharing the same bottleneck node do not adapt at all but falls 
into same real time traffic category. How much the non adaptive flows 
will contribute to the congestion is an open question though. I believe 
at some point this to be formed WG will have to converge to some 
measurable figures to evaluate the proposed CC mechanism.

>
>
>> Agreed. The fallback mechanism should be something better than the
>> RTP circuit breakers draft. Some basic level of congestion control
>> should be possible, and specified, when interoperating with existing
>> RTP applications. That is, specify behavior in the absence of some
>> (or perhaps all) feedback. There will be a long transition period as
>> current adaptive and non-adaptive RTP applications migrate to the
>> new congestion control standard (if/when that happens), so it is
>> important to understand and specify interoperation for these cases.
>
> Just to be clear, what is the scenario you're envisioning? An
> application where one side does new-rmcat-congestion-control and the
> other side doesn't, and the new side has to make the most out of the
> feedback that it gets from the other?

yes, but it will be hard if the other endpoint does not use standard 
form of feedback for example standard RTCP SR/RR. As I believe if you 
don't understand the feedback you are receiving from other endpoint you 
can make nothing out of it. But the new-rmcat-congestion-control could 
very well include new as well as old standard congestion control feedback.

>
> Cheers,
> Michael
>


-- 
Zahed

============================================
ANM ZAHEDUZZAMAN SARKER


Ericsson AB
Multimedia Technologies (MMT)
Ericsson Research
P.O. Box 920, SE-971 28, Luleå, Sweden
Phone +46 10 717 37 43
Fax +46 920 996 21
SMS/MMS +46 76 115 37 43
zaheduzzaman.sarker at ericsson.com
www.ericsson.com
============================================