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
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]> 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>, 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/
> 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]
> https://www.ietf.org/mailman/listinfo/tcpm
--
---
[email protected]
--
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/
