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.
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.
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.
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).
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.
HTH
Bob
On 04/07/2022 08:37, Zaheduzzaman Sarker wrote:
On 1 Jul 2022, at 17:30, Dave Taht <[email protected]> wrote:
I wish rmcat was not considered out of scope in this charter. The
internet is a communications network, not just a file transfer
network.
The RMCAT WG still exits and can take work on standardising congestion control
algorithms for interactive real-time communications, if needed. However, the
working group activities have declined over the last couple of years and I am
not sure how much interest/energy is there for new work (in genera)l for the
real-time interactive traffic. The working group has published materials that
can useful if discussions pops up in relevant forums/working groups.
I wish the congestion control algorithms RMCAT produced were used widely in
WebRTC and other RTP based real-time communication systems. That is not the
case yet. This also shows the fact that there should be honest interest not
only in developing good congestion control algorithms but also deploying it.
Also I find measurement tools that depend on obsolete 00's thinking -
like owamp - and rtp - very out of date when we should be thinking
about latency
and jitter in the sub 8ms range - if we're really serious about
building a metaverse. These days I am working with very fine grained
(3ms - preferably 1ms but no cloudy machine I have access to can
actually reliably generate packets from userspace on a 1ms interval)
active measurement data.
As an example of what we learn from inspecting a network at 3ms
detail, see: https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/108848/3142
for some current plots and a plotting script - of starlink's behaviors
using the irtt tool.
I was thinking about doing a talk (in iccrg? here?) on how we think
about network traffic at too large a granularity (mbits/sec) in favor
of "steady kbit/ms" or "steady packets over ms" (SPOM).
I would be interest in this kind of talks. If you have proposals we can pick
venues.
//Zahed
On Fri, Jul 1, 2022 at 5:28 AM Martin Duke <[email protected]> wrote:
Hello Transport Enthusiasts,
(bcc: TCPM, QUIC, and ICCRG)
Zahed and I would like to invite you to the TSVAREA meeting at IETF 114 (Monday
13:30 local time), where we will be having a more action-oriented discussion
than usual.
TL;DR the way we do congestion control standards is written down in RFC 5033,
and is no longer aligned with how congestion control innovation happens or the
family of transport protocols that use standard congestion control. The IETF is
largely irrelevant to new congestion control deployments. So we'll discuss a
proposal to fix it. This meeting will have some BoF-like elements but it is not
formally a BoF.
In consultation with several stakeholders, we've devised a strategy to address
this:
* Colin Perkins, IRTF chair, has agreed to add at least one chair to ICCRG (I'm
sure Colin would welcome volunteer candidates!). While retaining its hosting
presentations role, there will be renewed emphasis on serving as a forum to
produce experimental RFCs, with a charter update if necessary.
* The Transport ADs are going to consider chartering a new IETF working group
to update the administrative framework for congestion control standardization,
and potentially adopt any proposals that are sufficiently mature for the
standards track. We've formulated a proposed charter. Please consider it a
starting point for discussion.
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-89f2a2da742ddce8&q=1&e=e6a9d612-3bda-4815-aac4-b5fd39764cb5&u=https%3A%2F%2Fgithub.com%2Fmartinduke%2Fcongestion-control-charter%2F
I ask you to review this document before attending. It answers many of the
questions you may already have.
In Philadelphia, we hope to answer as many of the following questions as
possible, in order:
* Is there rough consensus on the problem to solve?
* Are the deliverables right?
* Are there people willing to take responsibility for those deliverables? (The meeting is
over if the answer is "no")
* Does the proposed charter need changes?
* Is anyone especially excited to chair this WG?
Please come to Philadelphia having thought about these questions and prepared
to answer them. You are also welcome to share thoughts on the tsv-area list;
all other recipients have been Bcced: so that the rest of the thread will go to
only that list. Subscribe if you want to track the discussion.
Although charter wordsmithing is somewhat premature, you are also welcome to
file issues and PRs on the github linked above.
See you there,
Martin and Zahed
Your friendly Transport ADs
--
FQ World Domination pending:
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-52d7a4659d6bb6c6&q=1&e=e6a9d612-3bda-4815-aac4-b5fd39764cb5&u=https%3A%2F%2Fblog.cerowrt.org%2Fpost%2Fstate_of_fq_codel%2F
Dave Täht CEO, TekLibre, LLC
--
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/
