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]
