From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id AB9DF21F38A; Sat, 21 Mar 2015 21:15:58 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YZXIo-0004JH-Bb; Sun, 22 Mar 2015 05:15:54 +0100 Received: from [38.96.210.190] (helo=[10.1.212.173]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1YZXIn-0004kg-K2; Sun, 22 Mar 2015 05:15:54 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: Date: Sat, 21 Mar 2015 23:15:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <58B50E56-24ED-43BF-AD88-E7E8321618C0@ifi.uio.no> References: <1426773234.362612992@apps.rackspace.com> <2E2D6622-1791-4CBB-856E-CE7BA39D99E0@gmail.com> <4C566C48-769A-4AC9-910F-B852EBF4B7A8@ifi.uio.no> <20150321001306.GA23642@sesse.net> To: David Lang X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 13 msgs/h 3 sum rcpts/h 17 sum msgs/h 4 total rcpts 26702 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 763E3F5A87B987D5E58B5D52A76447A099073136 X-UiO-SPAM-Test: remote_host: 38.96.210.190 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 4 max/h 3 blacklist 0 greylist 0 ratelimit 0 Cc: "Steinar H. Gunderson" , bloat , "cerowrt-devel@lists.bufferbloat.net" , Jonathan Morton Subject: Re: [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation? X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 04:16:27 -0000 > On 20. mar. 2015, at 19.25, David Lang wrote: >=20 > On Sat, 21 Mar 2015, Steinar H. Gunderson wrote: >=20 >> 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 >>=20 >> 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. >=20 > 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) >=20 > 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 >=20 >> (OK, concession #2, =E2=80=9Cdownload accelerators=E2=80=9D are doing = really bad things with >> multiple connections to gain TCP unfairness, but that's on the client = side >> only, not the server side.) >>=20 >> Based on this, I'm not convinced that people would bulk-mark their = packets as >> ECN-capable just to get ahead in the queues. >=20 > 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 >=20 >> 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. >=20 > As I said, there are two possibilities >=20 > 1. if you mark packets sooner than you would drop them, advantage = non-ECN Agreed, with a risk of starvation of ECN flows as we've seen - this is = not easy to get right and shouldn't be "just done somehow". > 2. if you mark packets and don't drop them until higher levels, = advantage ECN, and big advantage to fake ECN Same level as you would normally drop is what the RFC recommends. = Result: advantage ECN mostly because of the end-to-end effects I was = explaining earlier, not because of the immediate queuing behavior (as = figure 14 in https://www.duo.uio.no/handle/10852/37381 shows). "Big = advantage to fake ECN" is the part I don't buy; I explained in more = detail in the AQM list. Cheers, Michael