[R-C] Charter

[John Leslie]

   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.

   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 at jlc.net>