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. 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 under "Description of Working Group": - s/congestion control mechanisms/congestion avoidance mechanisms/ under "The working group will": - s/congestion control requirements/congestion avoidance requirements/ - s/congestion control feedback/congestion feedback/ - s/congestion control algorithms/congestion avoidance algorithms/ NB RFC 2914 (congestion control principles): no change under "The following topics are out of scope": No changes under "Deliverables": - s/congestion control algorithms/congestion avoidance algorithms/ - s/congestion control algorithms/congestion avoidance algorithms/ - s/congestion control algorithm/congestion avoidance algorithm/ - s/congestion control algorithms/congestion avoidance algorithms/ - s/congestion control algorithm/congestion avoidance algorithm/ under Milestones: (needs more wordsmithing; I'll leave to another post.) 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). 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.) 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 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. -- John Leslie <john@jlc.net>