From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cassarossa.samfundet.no (cassarossa.samfundet.no [IPv6:2001:67c:29f4::29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id A279821F3C5; Fri, 20 Mar 2015 17:13:17 -0700 (PDT) Received: from pannekake.samfundet.no ([2001:67c:29f4::50] ident=unknown) by cassarossa.samfundet.no with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YZ72J-0008I3-7o; Sat, 21 Mar 2015 01:13:09 +0100 Received: from sesse by pannekake.samfundet.no with local (Exim 4.80) (envelope-from ) id 1YZ72J-0007mp-0z; Sat, 21 Mar 2015 01:13:07 +0100 Date: Sat, 21 Mar 2015 01:13:07 +0100 From: "Steinar H. Gunderson" To: David Lang Message-ID: <20150321001306.GA23642@sesse.net> References: <1426773234.362612992@apps.rackspace.com> <2E2D6622-1791-4CBB-856E-CE7BA39D99E0@gmail.com> <4C566C48-769A-4AC9-910F-B852EBF4B7A8@ifi.uio.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: Linux 3.18.4 on a x86_64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Jonathan Morton , "cerowrt-devel@lists.bufferbloat.net" , Michael Welzl , bloat 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: Sat, 21 Mar 2015 00:13:46 -0000 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. (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. 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. /* Steinar */ -- Homepage: http://www.sesse.net/