Re: [Cake] [Bloat] Two questions re high speed congestionmanagement anddatagram protocols

Re: [Cake] [Bloat] Two questions re high speed congestionmanagement anddatagram protocols

[David P. Reed]

How to find a kernel maintainer to care about DCCP, seems to be the question for Linux.
I am tempted... Not to get involved with IETF "barriers" (what a mess, given the folks in IETF who resisted in AQM, I wouldn't last a minute), but to keep DCCP support alive.
The barrier here is getting accepted as a Linux maintainer, which is a different issue entirely, looking at my last two experiences with submitting simple bug fixes to the kernel, which were nightmares. I don't have the commitment to become accepted as a maintainer.
But it seems good to maintain DCCP, despite its lack of popularity as an IETF standard. It does deal with CC in a way that simplifies use of UDP for serious work.

(One such nightmare can be seen in LKML... Search for dpreed@deepplum.com patch emails. I tried hard, was worn down, then gave up, since I found a way to avoid the bug, in virtualization code on x86, and gave up on getting it fixed after a year. Life is too short. The prior one was almost 20 years ago when Alan Cox showed his asshole side, insulting me and HP. Alan is, thank goodness, gone now from Linus's inside circle)


-----Original Message-----
From: "Dave Taht via Cake" <cake@lists.bufferbloat.net>
Sent: Tue, Jun 27, 2023 at 10:03 pm
To: "Stephen Hemminger" <stephen@networkplumber.org>
Cc: "Stephen Hemminger" <stephen@networkplumber.org>, cake@lists.bufferbloat.net, bloat@lists.bufferbloat.net
Subject: Re: [Cake] [Bloat] Two questions re high speed congestionmanagement anddatagram protocols

https://datatracker.ietf.org/doc/charter-ietf-ccwg/

is a new wg intended to poke into these issues

On Tue, Jun 27, 2023 at 4:49 PM Stephen Hemminger via Cake
 wrote:
>
> On Tue, 27 Jun 2023 12:47:01 -0700 (PDT)
> David Lang  wrote:
>
> > On Mon, 26 Jun 2023, David P. Reed via Bloat wrote:
> >
> > > Sorry for top posting, but ... Bigger question:
> > > Why would DCCP be deprecated by Linux kernel?
> > > Who makes that decision? Who argues against it?
> >
> > Linus or the networking maintaners make the decision.
> >
> > Usually things get pulled from the kernel because there are updates that need to
> > be made to the code (to match changes elsewhere in the kernel or because of
> > security issues) and there isn't a maintainer who works on the code in a
> > resonable time. This means that the maintainers for the general code area (in
> > this case networking maintainers) will need to do extra work in an area they
> > aren't that interested in (and, especially in the case of hardware, may not have
> > the ability to test). They do some of it, especially if it's commonly used, but
> > eventually either another maintainer steps up, or it goes away
> >
> > David Lang
>
> See https://patchwork.kernel.org/project/netdevbpf/patch/20230614194705.90673-3-kuniyu@amazon.com/
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



-- 
Podcast: https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/
Dave Täht CSO, LibreQos
_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [Bloat] Two questions re high speed congestionmanagement anddatagram protocols

[Toke Høiland-Jørgensen]

"David P. Reed via Bloat" <bloat@lists.bufferbloat.net> writes:

> (One such nightmare can be seen in LKML... Search for
> dpreed@deepplum.com patch emails. I tried hard, was worn down, then
> gave up, since I found a way to avoid the bug, in virtualization code
> on x86, and gave up on getting it fixed after a year. Life is too
> short.

Went looking, since I think it's important to learn from such process
failures (and you're certainly not the first to opine that getting
patches into the kernel is challenging).

I'm assuming you're referring to this series, right?

https://lore.kernel.org/all/20200704203809.76391-4-dpreed@deepplum.com/

Which, to me, looks like it was pretty close to being accepted; another
revision would probably have made the cut...

...In fact it seems those patches were later resurrected by Sean as part
of this series, six months later:

https://lore.kernel.org/all/20201231002702.2223707-1-seanjc@google.com/

One of the patches retained your authorship and made it into the kernel
in this commit:

https://git.kernel.org/torvalds/c/53666664a305


So wouldn't necessarily call that a complete failure :) Seems the main
process issue you hit here was a subsystem that was too resource
constrained on the review side, which does sadly happen. The kernel
process tends to heavily favour convenience of reviewers for the same
reason (which is one of the reasons it can be off-putting to outsiders,
so it's a bit of a chicken and egg situation...)

-Toke

Re: [Cake] [Bloat] Two questions re high speed congestionmanagement anddatagram protocols

[Stephen Hemminger]

On Wed, 28 Jun 2023 10:32:32 -0400 (EDT)
"David P. Reed" <dpreed@deepplum.com> wrote:

> How to find a kernel maintainer to care about DCCP, seems to be the question for Linux.
> I am tempted... Not to get involved with IETF "barriers" (what a mess, given the folks in IETF who resisted in AQM, I wouldn't last a minute), but to keep DCCP support alive.
> The barrier here is getting accepted as a Linux maintainer, which is a different issue entirely, looking at my last two experiences with submitting simple bug fixes to the kernel, which were nightmares. I don't have the commitment to become accepted as a maintainer.
> But it seems good to maintain DCCP, despite its lack of popularity as an IETF standard. It does deal with CC in a way that simplifies use of UDP for serious work.

Interesting that there is an out of tree DCCP, complete with likely GPL license violation.
https://github.com/telekom/mp-dccp

Re: [Cake] [Bloat] Two questions re high speed congestionmanagement anddatagram protocols

[Sebastian Moeller]

[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]

For what it is worth, the tsv working group is considering whether to process mp-dccp on the standards track, but then the IETF seems not to care too deeply about open-source licence compliance. Or recent kernel implementations or implementations that have a realistic path towards mainline inclusion... but I digress.

Regards
        Sebastian





On 10 July 2023 22:35:40 CEST, Stephen Hemminger via Bloat <bloat@lists.bufferbloat.net> wrote:
>On Wed, 28 Jun 2023 10:32:32 -0400 (EDT)
>"David P. Reed" <dpreed@deepplum.com> wrote:
>
>> How to find a kernel maintainer to care about DCCP, seems to be the question for Linux.
>> I am tempted... Not to get involved with IETF "barriers" (what a mess, given the folks in IETF who resisted in AQM, I wouldn't last a minute), but to keep DCCP support alive.
>> The barrier here is getting accepted as a Linux maintainer, which is a different issue entirely, looking at my last two experiences with submitting simple bug fixes to the kernel, which were nightmares. I don't have the commitment to become accepted as a maintainer.
>> But it seems good to maintain DCCP, despite its lack of popularity as an IETF standard. It does deal with CC in a way that simplifies use of UDP for serious work.
>
>Interesting that there is an out of tree DCCP, complete with likely GPL license violation.
>https://github.com/telekom/mp-dccp
>_______________________________________________
>Bloat mailing list
>Bloat@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/bloat

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 2252 bytes --]

Re: [Cake] [Bloat] Two questions re high speed congestionmanagement anddatagram protocols

[Stephen Hemminger]

On Mon, 10 Jul 2023 23:27:46 +0200
Sebastian Moeller <moeller0@gmx.de> wrote:

> For what it is worth, the tsv working group is considering whether to process mp-dccp on the standards track, but then the IETF seems not to care too deeply about open-source licence compliance. Or recent kernel implementations or implementations that have a realistic path towards mainline inclusion... but I digress.

The issue is the MP-DCCP implementation is derived from the existing kernel DCCP which is GPL-v2.
You can't go randomly mixing proprietary code and GPL code in the kernel.