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]
