On Fri, Jul 01, 2022 at 08:30:09AM -0700, Dave Taht 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.
Indeed. I question the sanity of a term "general-purpose" as used in the charter, when one considers that the Internet is mixing several types of traffic into best-effort/Internet that we previously called classes. Only that we cannot isolate them from each other in the Internet because DiffServ cannot be operationalized for the Internet (fine for controlled networks) and i question whether L4S can have any more succes as long as the only form of classiciation it has is to squeeze an ECN bit. And i question how far outside of subscriber routers flow-aware AQM can be operationalized too. I can think of at least web-browsing, streaming, web-services, rt-media as traffic classes within the Internet, likely there are more, all with different CC requirements. Web-browsing is maybe QUIC, aka: min-roundtrip, rather short-lived, streaming is the congestion-self-unfriendlyness of DASH bursts, web-services is transactions, that maybe (as phil mentioned) better not use HTTP but something optimized like CoAPs, which is then strangled by whatever DTLS calls congestion control, and finally rt-media with RTP or other UDP based mechanisms. If the charter was actually inclusive of everything, we already have the only CC solution: RFC8084 (sorry for being facetious). If general-purpose is a subset, then please be more specific which subset, and don't call it general-purpose. From what i read, i can only guess that "general-purpose" is meant to be streaming, because everything else is already out-of-scope, but streamining has the very application specific CC problems of stuff like DASH segment conditioning and the like, so i don't think that could be called general-purpose. > 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. Is the metaverse "general-purpose" ? ;-)) i should stop now, i think i made my point. The other point implied above: I cannot read the wods AQM in the charter, but it of course is a key player for CC. If "general-purpose" also means "whatever AQM on-path", especially "whatever bad AQM", then we will very likely reach other conclusions that may be applicable to more parts of the Internet we unfortunately have, then if we assumed some minimum good performing AQM, which would then likely give us better CC solutions for the Internet we wished we had (and maybe are gong to get by promoting AQM in the process). > 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. [ OT: How about DPDK, supported by at least some cloud provider on quick look. I'd hope you could then play with userland PMD at the expense of burning CPU ? ] > 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). Sounds interesting. WOuld like to listen Cheers Toerless > 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 -- --- [email protected]
