The congestion-notification conflict

Posted Mar 22, 2019 19:00 UTC (Fri) by mm7323 (subscriber, #87386)
Parent article: The congestion-notification conflict

What's to stop me setting the 'fast queue' bit in all my headers and enjoying the speedup - at least until everyone else does the same?

Unless ISPs are going to filter at ingress points (and so break the end-to-end congestion management anyway), surely everyone has to agree and implement the same rules or it won't work - regardless of patents or politics.

to post comments

The congestion-notification conflict

Posted Mar 22, 2019 21:30 UTC (Fri) by roc (subscriber, #30627) [Link] (3 responses)

> What's to stop me setting the 'fast queue' bit in all my headers and enjoying the speedup - at least until everyone else does the same?

The same thing that stops you from disabling TCP congestion control or using a congestion-oblivious UDP transport. I.e. nothing, until you become a big enough problem that ISPs start blocking your traffic.

The congestion-notification conflict

Posted Mar 23, 2019 9:52 UTC (Sat) by farnz (subscriber, #17727) [Link] (1 responses)

Which is a strike against L4S, in my book; if I can cheat by just setting a bit in my headers, what is to stop me from doing so while my usage is small? And following on from that, when I'm a big enough problem, if I'm also a legitimate service (say Netflix or YouTube), I'm also effectively immune to blocking - block me, and I'll be able to allege that it's because I'm a big competitor to your services, not because I'm cheating.

Similar issues apply to global deployment of DiffServ - you can't stop users setting their traffic to an EF codepoint or even an AF codepoint, and absent a global agreement on shaping that should apply to such codepoints, you end up having to either block EF/AF traffic, or treat it as no better than DF traffic.

This is where SCE has an advantage - the endpoint setting the markers can request worse treatment, but not better.

Cheating

Posted Mar 23, 2019 12:35 UTC (Sat) by corbet (editor, #1) [Link]

My guess is that cheating would work less well than one might like. One of the big objectives behind L4S is low latency; that means tiny queues in the fast lane and tight congestion-control loops. If you don't implement the congestion-control side, you're probably going to overflow the queues and end up retransmitting a lot of dropped packets.

The congestion-notification conflict

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

> The same thing that stops you from disabling TCP congestion control or using a congestion-oblivious UDP transport. I.e. nothing, until you become a big enough problem that ISPs start blocking your traffic.

There is actually something stopping yourself from entirely disabling any form of congestion control: you'll be hurting not just the others but your own connections/sockets too.

As often one key thing missing in this discussion is the definition and boundary between "my" (headers/connections/sockets/...) versus others'; wherever is that boundary I doubt "my" describes just one socket.