[R-C] Charter update

[Piers O'Hanlon]

On 15 Aug 2012, at 09:03, Michael Welzl wrote:

> 
> On Aug 15, 2012, at 2:53 AM, Matt Mathis wrote:
> 
>>> /• Reasonable share of bandwidth when competing with RMCAT traffic, other
>>> real-time media protocols, TCP and other congestion control protocols. A
>>> 'reasonable share' means that no flow has a significantly negative impact
>>> [RFC5033] on other flows and at minimum that no flow starves./
>> 
>> This does not work.   The hedging language for TCP in the previous
>> text ("idealy") is required because protecting RMCAT from TCP (and
>> other protocols such as LEDBAT) can't be solved in general within the
>> scope of this WG.    We can try, and there are some partial solutions
>> that will help some of the time, but there are no general solutions
>> that really solve this problem.
>> 
>> Adding the definition of reasonable share is fine.
> 
> So, the final thing could become:
> 
>>> /• Reasonable share of bandwidth when competing with RMCAT traffic, other
>>> real-time media protocols, TCP and other congestion control protocols. A
>>> 'reasonable share' means that, ideally, no flow has a significantly negative impact
>>> [RFC5033] on other flows and at minimum that no flow starves./
> 
> (I just added "ideally" to Bob's text above)
> 
I think Matt meant to keep it ("ideally") in its original place as he was ok with Bob's 'reasonable share' definition.

Though it seems to me that RMCAT traffic will need to be able to compete on some basis with TCP, though the appropriate trade-offs are something that need to be defined by the group - e.g. competing with TCP on a low RTT/Q path may be perfectly feasible whilst maintaining RT media delay bounds and 'reasonable' bandwidth share, however on larger RTT/Q path this trade-off may not work.

So I'd agree with keeping the hedging language. And leaving Bob's original reasonable share definition as there's unlikely to be a situation where squeezing out TCP or other flows entirely is going to be beneficial to RMCAT flows.

Piers.


> ??
> 
> Cheers,
> Michael
> 
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion