I wish rmcat was not considered out of scope in this charter. The internet is a communications network, not just a file transfer network.
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). 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://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 -- FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/ Dave Täht CEO, TekLibre, LLC
