Toerless, Abstracting from the kernel/userland discussion, defaults matter. There's a strong presumption that unless there is a congestion control specifically designed for your application or environment, you should use Reno/Cubic. To me, that makes it a general purpose algorithm.
Regardless, as the charter has both general purpose and case-specific algorithms in scope, I'm not sure this debate has an actionable outcome. On Wed, Jul 6, 2022 at 10:20 AM Toerless Eckert <[email protected]> wrote: > Thanks, Martin, inline > > On Wed, Jul 06, 2022 at 09:58:56AM -0700, Martin Duke wrote: > > 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) > > I think these two bullet points are orthogonal. Aka: whether or not > some transport feature get implemented in kernel/system space or in > application/user space is independent of what type of application > it aims to be beneficial for. We even had for decades people running > around in the IETF claiming that it was a bad idea to put RTP on top > of UDP instead of natively on top of IP (as TCP), and that its > inventors (such as Steve Casner, who sadly just passed away), did > just implement RTP on top of UDP (sockets) because they either did not > want to bother working in the kernel, or (IMHO) didn't want to expect > their customers to have something that is not yet standardized in the > kernel. That latter argument was equally driving Google AFAIK when they > later did their TCP improvement works on top of UDP, ending up with > QUIC being on top of UDP. > > Aka: There is IMHO a very fundamental need to rethink our layering > wrt. to "system/kernel" vs. "user/application" space, and effectively > we should move towards designs where as much as possible (especially > in transport, but also network layers) can be done in "user/application" > space, and just think about the "system/kernel" space assomething that > does provider "user/application" space mux/demux and the ability to > schedule packets from/to "user/application" space as efficient as > today it can only be done today in kernel space. I think we could > ve very close with getting to this point, but i am not sure IETF > has the architectural interest to solve this issue, so i am not > sure i should detail here, how i could think this can be done. > > But in any case: I would challenge you to think that ANY future > transport improvements SHOULD be thought of as happening on top of > UDP in "user/application" space, including TCP (my mean of improved > sockets that allow userland to do TCP), and then my question remains: > > what is and what is not general-purpose ? > > My challenge list would be: > - short-lived connections for web-browsing (what QUIC was designed for) > - long-lived best-effort transfers (FTP, Web-download) > - web-transactions (e.g.: M2M/REST over HTTP, or COAP use cases) > - todays OTT streamin (mayority of Internet, DASH and the like, highly > bursty) > - real-time traffic (RTP and similar) > > Cheers > Toerless > > > 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] > > > > > -- > --- > [email protected] >
