[R-C] Charter update

[Michael Welzl]

On Aug 15, 2012, at 10:35 AM, Piers O'Hanlon wrote:

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

Ah yes, thanks - I think you're right and I misunderstood. So the  
final thing is:

>>>> /• Reasonable share of bandwidth when competing with RMCAT  
>>>> traffic, other
>>>> real-time media protocols, and ideally also TCP and other  
>>>> protocols. A
>>>> 'reasonable share' means that no flow has a significantly  
>>>> negative impact
>>>> [RFC5033] on other flows and at minimum that no flow starves./


i.e., the first sentence is back to what it was before, whereas the  
second is Bob's.

(btw, Bob: I think your other two suggestions can be accepted without  
any further debate)


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

Copy that  :-)

Cheers,
Michael