From: David Lang <david@lang.hm>
To: "Steinar H. Gunderson" <sgunderson@bigfoot.com>
Cc: Jonathan Morton <chromatix99@gmail.com>,
"cerowrt-devel@lists.bufferbloat.net"
<cerowrt-devel@lists.bufferbloat.net>,
Michael Welzl <michawe@ifi.uio.no>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation?
Date: Fri, 20 Mar 2015 17:25:08 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.02.1503201716420.22474@nftneq.ynat.uz> (raw)
In-Reply-To: <20150321001306.GA23642@sesse.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2252 bytes --]
On Sat, 21 Mar 2015, Steinar H. Gunderson wrote:
> On Fri, Mar 20, 2015 at 05:03:16PM -0700, David Lang wrote:
>> 1. If you mark packets as congested if they have ECN and drop them
>> if they don't, programmers will mark everything ECN (and not slow
>> transmission) because doing so gives them an advantage over
>> applications that don't mark their packets with ECN
>
> I'm not sure if this is actually true. Somehow TCP stacks appear to be tricky
> enough to mess with that the people who are capable of gaming congestion
> control algorithms are also wise enough not to do so. Granted, we are seeing
> some mild IW escalation, but you could very well make a TCP that's
> dramatically unfair to everything else and deploy that on your CDN, and
> somehow we're not seeing that.
It doesn't take deep mucking with the TCP stack. A simple iptables rule to OR a
bit on as it's leaving the box would make the router think that the system has
ECN enabled (or do it on your local gateway if you think it gives you higher
priority over the wider network)
If you start talking about ECN and UDP things are even simpler, there's no need
to go through the OS stack at all, craft your own packets and send the raw
packets
> (OK, concession #2, “download accelerators” are doing really bad things with
> multiple connections to gain TCP unfairness, but that's on the client side
> only, not the server side.)
>
> Based on this, I'm not convinced that people would bulk-mark their packets as
> ECN-capable just to get ahead in the queues.
Given the money they will spend and the cargo-cult steps that gamers will do in
the hope of gaining even a slight advantage, I can easily see this happening
> It _is_ hard to know when to
> drop and when to ECN-mark, though; maybe you could imagine the benefits of
> ECN (for the flow itself) to be big enough that you don't actually need to
> lower the drop probability (just make the ECN probability a bit higher),
> but this is pure unfounded speculation on my behalf.
As I said, there are two possibilities
1. if you mark packets sooner than you would drop them, advantage non-ECN
2. if you mark packets and don't drop them until higher levels, advantage ECN,
and big advantage to fake ECN
David Lang
next prev parent reply other threads:[~2015-03-21 0:25 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-16 20:35 [Cerowrt-devel] " Matt Taggart
2015-03-17 23:32 ` Valdis.Kletnieks
2015-03-18 4:34 ` David P. Reed
2015-03-18 6:26 ` Jonathan Morton
2015-03-18 19:38 ` JF Tremblay
2015-03-18 19:50 ` Jonathan Morton
2015-03-19 13:53 ` dpreed
2015-03-19 14:11 ` JF Tremblay
2015-03-19 15:38 ` dpreed
2015-03-19 15:40 ` Jim Gettys
2015-03-19 17:04 ` Michael Richardson
2015-03-19 17:14 ` Jonathan Morton
2015-03-19 17:11 ` Dave Taht
2015-03-19 19:58 ` [Cerowrt-devel] [Bloat] " Livingood, Jason
2015-03-19 20:29 ` dpreed
2015-03-19 23:18 ` Greg White
2015-03-20 8:18 ` MUSCARIELLO Luca IMT/OLN
2015-03-20 13:31 ` David P. Reed
2015-03-20 13:46 ` Sebastian Moeller
2015-03-20 14:05 ` MUSCARIELLO Luca IMT/OLN
2015-03-20 10:07 ` Sebastian Moeller
2015-03-20 13:50 ` [Cerowrt-devel] Latency Measurements in Speed Test suites (was: DOCSIS 3+ recommendation?) Rich Brown
2015-03-29 17:36 ` [Cerowrt-devel] [Bloat] " Pedro Tumusok
2015-03-30 7:06 ` Jonathan Morton
2015-03-20 13:57 ` [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation? Livingood, Jason
2015-03-20 14:08 ` David P. Reed
2015-03-20 14:14 ` MUSCARIELLO Luca IMT/OLN
2015-03-20 14:48 ` Matt Mathis
2015-03-20 18:04 ` Valdis.Kletnieks
2015-03-20 13:48 ` Jim Gettys
2015-03-20 14:11 ` Livingood, Jason
2015-03-20 14:54 ` Michael Welzl
2015-03-20 15:31 ` Jim Gettys
2015-03-20 15:39 ` Michael Welzl
2015-03-20 16:31 ` Jonathan Morton
2015-03-20 20:59 ` Michael Welzl
2015-03-20 23:47 ` David P. Reed
2015-03-21 0:08 ` Michael Welzl
2015-03-21 0:03 ` David Lang
2015-03-21 0:13 ` Steinar H. Gunderson
2015-03-21 0:25 ` David Lang [this message]
2015-03-21 0:34 ` Jonathan Morton
2015-03-21 0:38 ` David Lang
2015-03-21 0:43 ` Jonathan Morton
2015-03-22 4:15 ` Michael Welzl
2015-03-21 0:15 ` Michael Welzl
2015-03-21 0:29 ` David Lang
2015-03-22 4:10 ` Michael Welzl
2015-03-20 18:14 ` Jonathan Morton
2015-03-18 8:06 ` [Cerowrt-devel] " Sebastian Moeller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.02.1503201716420.22474@nftneq.ynat.uz \
--to=david@lang.hm \
--cc=bloat@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=michawe@ifi.uio.no \
--cc=sgunderson@bigfoot.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox