[R-C] Charter

[Randell Jesup]

On 8/6/2012 10:48 PM, John Leslie wrote:
>     I wish to strongly agree with Matt's point about diagnosis:
>
> Matt Mathis <mattmathis at google.com> wrote:
>>
>> - Techniques to detect, instrument or diagnose failing to meet RT
>>    schedules due to failures of components out side of the charter scope,
>>    possibly in collaboration with IPPM.
>
> (though I think it needs wordsmithing, which I'll tackle in another post.)
>
>     But first I must tackle some overall points.
>
>     I've gone over the proposed charter _very_ carefully since Thursday.
> Overall, I find it is a lot better than I initially thought.

That's very good to hear.

>
>     However, I will suggest changes which I think make misunderstandings
> like mine less likely.
>
>     First, I support Mirja and Michael that it's generally better to say
> "congestion avoidance" than "congestion control". Specifically

Sure, this is reasonable.


>     I think we agreed that under "topics out of scope":
> - s/Active queue management/Requiring Active Queue Management/
> (the point being we can't avoid discussing AQM, but we need to live
> with whatever AQM there is or isn't).

Agreed totally (I made a similar comment at the mic).

> Matt again:
>
>> It was pointed out that "fair share when competing with itself" may be
>> a difficult goal, and that "fair share when competing with other
>> protocols" is not likely to be possible.  (It certainly is not
>> possible if "other protocol" is unconstrained).  I suggest splitting
>> this item into multiples.
>> - fair share when competing with itself
>> - reasonable share when competing with other RT protocols
>> - Idealy (but may not be feasible) a reasonable share when competing
>> with TCP and other protocols.
>
> (Presumably Matt meant the second bullet under "set of requirements"
> gets split into three bullets, making five bullets altogether.)
>
>     I strongly recommend avoiding the word "fair"; thus I suggest the
> five bullets read:
> - Low delay for cases where there is no competing traffic
> - Reasonable share when competing with RMCAT traffic
> - Reasonable share when competing with other RT protocols
> - Reasonable share when competing with TCP-like protocols
> - Effective use of signals such as ECN and packet loss
> (I think we must _define_ a "reasonable share" when competing with TCP:
> but it won't look much like our traditional TCP-friendly definitions.)

Sounds good to me.  "Fair" is a horribly defined (and loaded) term.

>     In case the above isn't sufficient to start some flame-wars, I also
> strongly suggest adding language better defining the problem, to cover:
> - RMCAT strongly wants low delay and low jitter
> - RMCAT can tolerate loss better than high delay
> - RMCAT prefers consistent bandwidth to inconsistent high bandwidth
> - we posit that RMCAT can reasonably adjust slower than TCP

I'm ok with that.  All quite reasonable and may reduce confusion in 
cases, though it's edging towards solution space.

>     I'm not at all particular about where that goes, though I feel
> earlier is better...
>
>     If we settle on language quickly, I see no reason this couldn't
> come before the IESG Thursday, August 16, and be approved for External
> Review.

Great!

-- 
Randell Jesup
randell-ietf at jesup.org