[go: up one dir, main page]

|
|
Log in / Subscribe / Register

The congestion-notification conflict

The congestion-notification conflict

Posted Mar 24, 2019 17:28 UTC (Sun) by ajb (subscriber, #9694)
Parent article: The congestion-notification conflict

The patent is a huge issue, and I think the community should be wary of it until either ALu gives better licence conditions, or it becomes clear that it is invalid. Hopefully this article will advance one outcome or the other.

I think it's premature to decide that SCE "better matches the values" of the Linux networking stack, however. As I understand it, in L4S, the dual-q mechanism is a transition mechanism, and the end state is that everyone - except for old stacks - end up in the second, low-latency, bucket. Whereupon the behaviour of the system is controlled by the end-hosts - very much how the Linux networking community would have it. Linux - if, and it's a big if, the patent issue is solved - would move to the second bucket very fast, give how quickly Linux development goes.

SCE, however, appears to rely on per-flow queueing (FQ) being implemented at any hop that could end up being the bottleneck. FQ is fine if its on your home router and thus under your control. But if it's implemented everywhere, then the network, not the end clients, are controlling the behaviour of the system.

The bufferbloat guys are pushing for FQ to be implemented everywhere. So far, it's not happened because the fast path of ISP-class switches are mostly implemented in ASICs, where queues are a limited resource. If it were to happen, you can be sure that the facility to weight those queues according the the commercial policy of the ISPs would also be implemented also. Despite FQ coming from the grass-roots, the difficulty implementing it at the ISP level may well be, paradoxically, something the open community should be grateful for.


to post comments

The congestion-notification conflict

Posted Mar 24, 2019 18:05 UTC (Sun) by mtaht (guest, #11087) [Link] (2 responses)

After so many heated discussions last week, what I would like most is for more people to have read the l4s, tcp prague, and dualpi drafts. It saves time to skip to the appendixes, and then a more coherent dialog can emerge.

The congestion-notification conflict

Posted Mar 28, 2019 6:51 UTC (Thu) by marcH (subscriber, #57642) [Link] (1 responses)

> After so many heated discussions last week, what I would like most is for more people to have read the [...] drafts

Wow, speaking of grey hair *you* must have a lot of it; you're clearly from some pre- social media era :-)

The congestion-notification conflict

Posted Mar 29, 2019 12:31 UTC (Fri) by mtaht (guest, #11087) [Link]

I'm pretty bald, actually. My beard has turned almost completely grey.

The congestion-notification conflict

Posted Mar 25, 2019 8:16 UTC (Mon) by mtaht (guest, #11087) [Link] (2 responses)

There have been a few things going by here that I would like to address but I don't really have time today. Most of the SCE activity is taking place on the ecn-sane mailing list. We (currently) think implementing SCE *does not require* FQ and aim to prove that in the coming weeks:

https://lists.bufferbloat.net/pipermail/ecn-sane/2019-Mar...

(and see the explosion of traffic on that list for far, far more debate and detail)

It helps to have read the ecn-sane charter:

https://www.bufferbloat.net/projects/ecn-sane/wiki/

and rules of operation: https://www.bufferbloat.net/projects/ecn-sane/wiki/rules/

before actually joining the list.

before joining the list. Anyone that has issues with ecn-sane's rules or charter is welcome to submit a pull request against the https://github.com/tohojo/bufferbloat-net repo.

People are also welcome to attempt to join the DOCSIS consortium, under their rules. Or the ietf, under their rules.

The congestion-notification conflict

Posted Mar 27, 2019 17:49 UTC (Wed) by ajb (subscriber, #9694) [Link] (1 responses)

Thanks. I don't quite see how SCE can be useful without FQ, since if they are in the same queues client stacks are constrained in how differently they can respond to these signals without dominating or being dominated by unmodified client stacks. Hopefully this will be made clear.

The congestion-notification conflict

Posted Mar 30, 2019 15:41 UTC (Sat) by mtaht (guest, #11087) [Link]

For those that don't like reading drafts...

Jonathan's talk on SCE at tsvwg is now up at: https://www.youtube.com/watch?v=JQmWyr0JDJM&t=1h3m50s

And the cable industry's talk is prior to that.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds