Thanks, David, sounds good. The more generalized question i was raising and that L24 tries to provide an answer to is whether/how we can mix traffic with different congestion behavior better than through manually configured DiffServ parameters such as WRR parameters or tail-drop parameters (such as in AF4x).
The golden goose seems to be that if there are k different classes k=1...K (K=2 in L4S afaik) of congestion aware traffic whose flows would not play fair with each other if sitting in one "normal" queue, and each class has i(k) active flows, then we would like to give each class (i(k) / sum(i(k)|k=1...K)) parts of the overall bandwidth - without having to be i(k) aware. Or at least however close to that goal as we can get. If we do not solve this across all those different classes of Internet traffic we have with different congestion goals, it seems we're not trying to solve the hardest problem. L4S seems like a great stepping stone. (Not saying which WG this should be in, that is just bureaucracy ;-) Cheers Toerless On Wed, Jul 06, 2022 at 10:04:46PM +0000, Black, David wrote: > Hi Toerless, > > > This makes me think, that "scalable congestion control" is one of the core > > requirements. Don't remember right now if this is covered in the charter. > > Hmm - I suspect the answer to whether it's covered is "not exactly" ... but > there's a really good suggestion lurking in your comment. > > L4S had to define the concept of a "scalable congestion control" and specify > its requirements in considerable detail in order to distinguish L4S traffic > from non-L4S traffic. The bulk of that material is in Section 4 and Appendix > A of draft-ietf-tsvwg-ecn-l4s-id (Explicit Congestion Notification (ECN) > Protocol for Very Low Queuing Delay (L4S) ), based on the justification that > the requirements have to be met in order to use the ECT(1) codepoint for the > ECN field in IP headers. > > The concept of "scalable congestion control" is applicable well beyond the > specifics of L4S, and the initial specification for L4S, while representing a > lot of very good and hard work, is almost certainly neither 100% correct nor > 100% complete for all time. ... so it seems useful to extract that concept > and its requirements into a separate document on "scalable congestion > control" that could be carried forward independent of the L4S documents. > This activity appears to be related to this area of work in the charter: > > * Devise a framework for specifying congestion controls agnostic to > protocol. It > might establish norms for when protocol-specific considerations are minor > enough > to include in the base document, or protocol-specific documents are needed. > > > In addition, the charter does not answer my other point, e.g. how much > > can we expect isolation/separation. > > I'm not Martin ... but ... I don't think there's a single answer to that > question. > > Deployability of any new congestion control is clearly important, and > approaches to this vary widely. At one end of the spectrum is L4S, where > coexistence with (capital-I) Internet traffic has been an important > consideration - > > > So, for example: Is what L4S is doing, e.g.: reducing latency for this > > use-case at the expense of being to classify non-conformant traffic > > an in-scope solution space ? If it is we end up with a better future > > "general-purpose", > > if it is not, we end up with an easier to deploy, but worse > > "general-purpose". > > At the other end of the spectrum are new data center congestion control > protocols that aren't intended for use outside data centers and aren't > expected to play nice with existing transports, starting with TCP, and they > are also in the currently-proposed scope: > > * New algorithms mature enough for standardization. CCLR may consider not > only > the open internet, but also algorithms focused on Data Centers, "Controlled > environments", Multipath, and Internet of Things use cases. Any adopted > document must be clear about the domains to which its operation is > restricted. > > Thanks, --David > > -----Original Message----- > From: tsv-area <[email protected]> On Behalf Of Toerless Eckert > Sent: Wednesday, July 6, 2022 2:39 PM > To: Martin Duke > Cc: Dave Taht; [email protected] > Subject: Re: At TSVAREA in Philadelphia: The Future of Congestion Control at > IETF > > > [EXTERNAL EMAIL] > > Martin, > > Its missing any explanation/definition of what future "general purpose" > is supposed to be, in the opinion of those who agree on the charter. > > The way i see it, general-purpose should not do any optimization for > the specific throughput/latency/burstyness-charactreistic profile of > different applications, but really consider "traditional download", > but with lowest possible latency" as its reference application. > > This makes me think, that "scalable congestion control" is one of the core > requirements. Don't remember right now if this is covered in the charter. > > In addition, the charter does not answer my other point, e.g. how much > can we expect isolation/separation. > > So, for example: Is what L4S is doing, e.g.: reducing latency for this > use-case at the expense of being to classify non-conformant traffic > an in-scope solution space ? If it is we end up with a better future > "general-purpose", > if it is not, we end up with an easier to deploy, but worse "general-purpose". > > Cheers > Toerless > > On Wed, Jul 06, 2022 at 10:24:43AM -0700, Martin Duke wrote: > > 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://urldefense.com/v3/__https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/108848/3142__;!!LpKI!jVUdXMDuq1T6vlU447-PL4_pXGC1Jchd3OjBvaC8a4s_eD8F_7hti-tZPfpt9H2_VAx60H5AlBKPYQ$ > > > > > [forum[.]openwrt[.]org] > > > > > > 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://urldefense.com/v3/__https://github.com/martinduke/congestion-control-charter/__;!!LpKI!jVUdXMDuq1T6vlU447-PL4_pXGC1Jchd3OjBvaC8a4s_eD8F_7hti-tZPfpt9H2_VAx60H6n93PIFQ$ > > > > > > > [github[.]com] > > > > > > > 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://urldefense.com/v3/__https://blog.cerowrt.org/post/state_of_fq_codel/__;!!LpKI!jVUdXMDuq1T6vlU447-PL4_pXGC1Jchd3OjBvaC8a4s_eD8F_7hti-tZPfpt9H2_VAx60H7pjjybSw$ > > > > > [blog[.]cerowrt[.]org] > > > > > > Dave Täht CEO, TekLibre, LLC > > > > > > > > > > -- > > > > > --- > > > > > [email protected] > > > > > > > > > > > -- > > > --- > > > [email protected] > > > > > -- > --- > [email protected] -- --- [email protected]
