>
https://github.com/martinduke/congestion-control-charter/blob/main/congestion-control-charter.txt
Following up on this thread and today's nice discussion in the tsv-area
meeting, regarding this passage:
The following are specifically in scope:
* New algorithms mature enough for standardization.
I'd suggest expanding this to something like:
The following are specifically in scope:
* New or existing congestion control, AQM, or loss recovery algorithms
that are
considered mature enough for standardization.
Rationale:
+ I'd suggest "New or existing" rather than "New" since it's not clear what
qualifies as "new", and there are several existing algorithms, like CUBIC
and DCTCP, that folks have noted are probably ready for promotion from
informational to something more standards-ish.
+ As was noted by Toerless, Bob, and others, AQM is inherently overlapping
with congestion control, and we'd ideally like the same set of people
reviewing/vetting/etc both.
+ I would suggest including loss recovery as well, for several reasons. At
a high level, loss recovery has important interactions with congestion
control and AQM.
For example:
(1) There are some backstops against congestion problems that involve
interactions between congestion control and loss recovery. For example,
exponential backoff in retransmission timers is an important mechanism that
straddles congestion control and loss recovery.
(2) There are loss recovery mechanisms that have implications for what
congestion control strategies make sense. For example, in TCP, if using
RACK-TLP then it's best to use PRR to avoid excessive bursts when using
sparse ACK feedback or recovering from lost retransmissions.
(3) Ideally we do not want folks deploying AQMs that create loss patterns
that are hard for commonly deployed loss recovery (and/or congestion
control) algorithms to handle.
Yes, I agree the details of loss recovery are often specific to a transport
protocol, as mentioned in the meeting. And that's OK. There will be cases
where some in the room/community don't know the details about a particular
transport. But that's OK; that happens in TSVWG sessions already. IMHO it
is worth the cost of occasionally drilling down into transport details
unfamiliar to a portion of the audience in order to reap the huge rewards
from promoting/inspiring/enabling the sharing of best practices across
transport protocols.
In short, AFAICT it's highly desirable to have the same shared community of
people working on CC, AQMs, and loss recovery, sharing best practices
across all major transport protocols. Collecting this work together in a
single WG seems like a nice way to foster this.
cheers,
neal
On Mon, Jul 25, 2022 at 10:02 AM Toerless Eckert <[email protected]> wrote:
>
>
> On Mon, Jul 25, 2022 at 01:56:25PM +0200, Michael Welzl wrote:
> > Maybe this can also lead to a broader recognition that CC is indeed a
> network layer function… AQM is a reminder of this truth.
>
> Ah, no, sorry, we can't do that, even if it was correct.
> We do not have a Network Layer Area in the IETF.
> You have to pick routing or transport, and surely it can not be routing.
>
> (tongue in cheek).
>
> Then again, RTG also has TEAS, RAW, replication (multicast) is arguably
> also
> not routing. But probably this would create too much of a rift.
>
> On the othrer hand, I would certainly like to see CC and AQM to not be done
> in different working groups, because if planned together, they will work
> better.
> And i would love to not see them tied into the "fad of the decade"
> transport protocol that
> primarily attempts to solve completelty different issues (such as
> minimizing
> the number of round trips in messages to establish a crypto association).
> (Not that there is anything bad with a fad of the decade, but upgrading the
> Internet infrastructure for better CC takes longer, and so it would be
> prudent
> to also design the host-side CC aspects from that perspective and
> nonwithstanding
> which transport protocol they're integrated into).
>
> Cheers
> Toerless
>
> > Cheers,
> > Michael
> >
> >
> >
> > > On 25 Jul 2022, at 13:49, Bob Briscoe <[email protected]> wrote:
> > >
> > > Martin,
> > >
> > > On 24/07/2022 17:38, Martin Duke wrote:
> > >> In practice, TCPM does most standards-track work in this area. RMCAT
> has a specific problem, and TSVWG by definition is a grab bag for anything
> else that doesn't fit.
> > >>
> > >> Modulo the debate about this replacing RMCAT, TCPM and TSVWG would no
> longer be the venue for this work.
> > >
> > > [BB] Returning to the issue of whether AQM should be added:
> https://github.com/martinduke/congestion-control-charter/issues <
> https://github.com/martinduke/congestion-control-charter/issues>
> > > I would like to see this question discussed in the session later
> today.
> > >
> > > If that happened, aqm would be added to your above list of things
> removed from the tsvwg charter.
> > >
> > > Indeed I would tend not to support the idea of a separate CC WG unless
> AQM was also included.
> > > Reason: I would be concerned that the amount of CC standardization
> work will be too low to sustain active attention and attendance.
> > >
> > >
> > > Bob
> > >
> > >
> > >>
> > >> On Sat, Jul 23, 2022 at 8:47 PM Toerless Eckert <[email protected]
> <mailto:[email protected]>> wrote:
> > >> Martin: General question. Just curious.
> > >>
> > >> Is the proposed charter meaning to take away items from existing WGs
> > >> chartre, for example in the hope to give those existing groups
> > >> breathing room for other work (TSVWG always needs that for example
> ;-).
> > >> Or do you think this is all new and nothing of this was part of other
> > >> WG charter...
> > >>
> > >> Cheers
> > >> Toerless
> > >>
> > >> On Thu, Jun 30, 2022 at 03:49:11PM -0700, Martin Duke 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 <https://www.rfc-editor.org/rfc/rfc5033.html <
> https://www.rfc-editor.org/rfc/rfc5033.html>>, 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://github.com/martinduke/congestion-control-charter/ <
> https://github.com/martinduke/congestion-control-charter/>
> > >> > 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
> > >>
> > >> > _______________________________________________
> > >> > tcpm mailing list
> > >> > [email protected] <mailto:[email protected]>
> > >> > https://www.ietf.org/mailman/listinfo/tcpm <
> https://www.ietf.org/mailman/listinfo/tcpm>
> > >>
> > >>
> > >> --
> > >> ---
> > >> [email protected] <mailto:[email protected]>
> > >
> > > --
> > > ________________________________________________________________
> > > Bob Briscoe http://bobbriscoe.net/ <
> http://bobbriscoe.net/>
>
> --
> ---
> [email protected]
>
>
