Toerless, By "general purpose" I mean something suitable for a TCP kernel implementation, which obviously has to support a wide variety of use cases.
This is contrast to algorithms designed for a very specific traffic type (eg, RMCAT) or a certain environment (DCTCP) On Fri, Jul 1, 2022 at 10:57 AM Toerless Eckert <[email protected]> wrote: > 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] >
