[R-C] BoF approved

[Michael Welzl]

Hi,

This is just to say that I absolutely agree with everything you say  
below, as well as everything Randell has said in his answer to my  
post, in the same thread.

Indeed, at least having some guidelines would be good.

Cheers,
Michael



On Jul 25, 2012, at 11:34 AM, Zaheduzzaman Sarker wrote:

> 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
> ============================================
>
>