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://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]
> >
--
---
[email protected]
