On 8/6/2012 10:48 PM, John Leslie wrote:
I wish to strongly agree with Matt's point about diagnosis:
Matt Mathis <mattmathis@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@jesup.org