Martin,
Thx. No push back from me to anything you've said, except one
clarification inline tagged [BB].
On 06/07/2022 18:19, Martin Duke wrote:
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.
[BB] When I said that people get most interested when an RFC preclude
something they're doing, I wasn't meaning solely "shouldn't use algo XYZ".
I meant more generally that, if a draft takes care to specify how to
/test/ a required behaviour, if some company already has an algo that
would fail that compliance test, they would suddenly become v interested
in participating in the IETF. Whereas before they could just ignore it.
So, encouraging this potential CCLR WG to include testability among its
activities ought to bring in participation from people with skin in the
game.
This sounds obvious, but it's not straightforward. Some algos provide no
public access (closed source and not even available as a binary -
perhaps just used in CDN senders). To test such an algo, you can only
observe its behaviour in response to other traffic in a bottleneck that
you are either controlling or monitoring.
Bob
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.
--
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/
