Thanks Bob Replies inline
On Mon, Jul 4, 2022 at 3:23 PM Bob Briscoe <[email protected]> wrote: > Zahed, Martin, > > I agree with DaveT - the reasoning for not including r-t CCs seems weak. > The main reason for bringing everything together is that CC expertise is > thin on the ground. Including r-t would force the CCLR WG to think > carefully about what is possible as 'general-purpose' and what isn't, > and to decide on what the maximum subsets are, and what is necessary for > interop between them. > > It seems like RMCAT is approaching end-of-life, so it would surely be > sensible to pick up any future r-t CC work in this newly proposed group, > rather than ruling it out in the charter. I.e. better to rule it in to > this CCLR charter as an intention, but rule it out as a short-term > exception while RMCAT finishes its current work stand-alone. > [MD] I filed an issue on this. Zahed, Colin, and I will discuss what baseline we should bring to the meeting. > > Here's some additional thoughts on the proposed new WG and charter: > > 1) Name-and-shame compliance testing > In other areas of the IETF, people and companies most want to get > involved when an RFC is about to publish interop requirements that will > preclude what they want to do - unless they intervene and contribute. CC > is generally sender-only, so there is no binary works/fails interop > test. Instead, CC interop is "non-functional", meaning it's about harm > to the performance of others (or of self). I don't mean testing to give > products a compliance certificate. I am thinking more about name and > shame. So if this WG wants to ensure healthy participation, it ought to > at least consider compliance testing work. > [MD] Although this is a bit out of the usual IETF activity, I can imagine the occasional IETF document saying that you shouldn't use algorithm XYZ. I'm not sure this would work out in practice, but if others are interested, we can consider it. Issue filed. 2) Division between research and standardization > The discussion, and the charter, needs to try to define the limits of CC > standardization, where research (ICCRG) should step in. A standards WG > needs to be clear that it will not take on problems for which there are > no known solutions yet. The ICCRG is hardly active at all between > meetings, so one might imagine that creating a second group for the same > community would just result in two communities that come out of > hibernation every 4 months. However, if idea #1 creates some hunger for > interop, the opposite could happen - it might give renewed purpose and > vigour to the CC research community. > [MD] The charter tries to be clear about this; perhaps it failed. The intent is for ICCRG to become much more active. The bar for standardization ought to be high; consensus that the algorithm is mature and safe, and also clear intent from implementation(s) that matter to deploy it. > 3) Think not what the community can do for the IETF, rather what the > IETF... > The charter seems rather too focused on tidying up IETF process (which > is nonetheless a valid goal) and making sure the IETF has a role in a > process that for many years has largely progressed without it. There is > less about providing something useful to the Internet and to the CC > developer community. The main recent development is that QUIC opens up > congestion control to user space, but most QUIC developers don't feel > capable of building a CC algo. The obvious goal here would be a CC algo > for low latency - possibly the first step being a faster startup than > slow start (but that might be considered research - see point #2). > [MD] This charter is gun-shy by design about naming particular congestion control problems to solve, because: - I don't know who is willing to do the document work - I don't know if they are properly experimental via IRTF or standards-track via IETF - The RFC5033bis process is totally undefined That said, if proponents emerge to go standards track with BBR or Prague or DCTCP or something else, and there's a rough consensus that standards track is the right course, I'm happy to add that to the initial charter. A more likely path, IMO, is that these start out as Experimental, and about the time that the process deliverables are complete we may have enough data to standardize and recharter accordingly. In terms of "what the IETF can do for the community"... ICCRG today provides a good venue for expert review. What the working group can add is standards-track documents. People are free to question the value of that, but clearly *some* people are interested in this process -- we would not be standardizing Cubic if that were not the case. > > 4) I like Toeless's point about the lack of AQM in the charter. If > someone were to want to progress one of the existing experimental AQM > RFCs onto the standards track, since the AQM WG closed, tsvwg became the > WG for ad hoc AQM drafts. Given tsvwg is always extremely busy, and CC > expertise and AQM expertise overlap significantly, then new AQM work > could be taken on by CCLR. Tsvwg would of course still be the > WG-of-last-resort for AQM work if CCLR ever closed. > [MD] OK, issue filed.
