From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 659E421F3C6; Fri, 20 Mar 2015 17:15:42 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YZ74l-000849-Bq; Sat, 21 Mar 2015 01:15:39 +0100 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.114]) by mail-mx6.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80.1) (envelope-from ) id 1YZ74k-0006WT-F6; Sat, 21 Mar 2015 01:15:39 +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 01:15:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <46B196A4-7755-4275-99E8-3D259EB46C33@ifi.uio.no> References: <20150316203532.05BD21E2@taggart.lackof.org> <123130.1426635142@turing-police.cc.vt.edu> <15A0911A-E3B7-440A-A26B-C5E1489EA98B@viagenie.ca> <1426773234.362612992@apps.rackspace.com> <2E2D6622-1791-4CBB-856E-CE7BA39D99E0@gmail.com> <4C566C48-769A-4AC9-910F-B852EBF4B7A8@ifi.uio.no> To: David Lang X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 10 msgs/h 2 sum rcpts/h 12 sum msgs/h 2 total rcpts 26677 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B1E6AC5A1A50182AB9450A5A997F5A52FD86CF72 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 463 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: Jonathan Morton , "Livingood, Jason" , "cerowrt-devel@lists.bufferbloat.net" , 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:16:12 -0000 > On 21. mar. 2015, at 01.03, David Lang wrote: >=20 > On Fri, 20 Mar 2015, Michael Welzl wrote: >=20 >>> On 20. mar. 2015, at 17.31, Jonathan Morton = wrote: >>>> On 20 Mar, 2015, at 16:54, Michael Welzl = wrote: >>>> I'd like people to understand that packet loss often also comes = with delay - for having to retransmit. >>> Or, turning it upside down, it=E2=80=99s always a win to drop = packets (in the service of signalling congestion) if the induced delay = exceeds the inherent RTT. >>=20 >> Actually, no: as I said, the delay caused by a dropped packet can be = more than 1 RTT - even much more under some circumstances. Consider this = quote from the intro of = https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 : >=20 > You are viewing this as a question to drop a packet or not drop a = packet. >=20 > The problem is that isn't the actual question. >=20 > The question is to drop a packet early and have the sender slow down, = or wait until the sender has filled the buffer to the point that all = traffic (including acks) is experiencing multi-second latency and then = drop a bunch of packets. >=20 > In theory ECN would allow for feedback to the sender to have it slow = down without any packet being dropped, but in the real world it doesn't = work that well. I think it's about time we finally turn it on in the real world. > 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 heard this before but don't buy this as being a significant problem = (and haven't seen evidence thereof either). Getting more queue space and = occasionally getting a packet through that others don't isn't that much = of an advantage - it comes at the cost of latency for your own = application too unless you react to congestion. > marking packets with ECN gives an advantage to them in mixed = environments >=20 > 2. If you mark packets as congested at a lower level than where you = drop them, no programmer is going to enable ECN because flows with ECN = will be prioritized below flows without ECN Well.... longer story. Let me just say that marking where you would = otherwise drop would be fine as a starting point. You don't HAVE to mark = lower than you'd drop. > If everyone use ECN you don't have a problem, but if only some = users/applications do, there's no way to make it equal, so one or the = other is going to have an advantage, programmers will game the system to = do whatever gives them the advantage I don't buy this at all. Game to gain what advantage? Anyway I can be = more aggressive than everyone else if I want to, by backing off less, or = not backing off at all, with or without ECN. Setting ECN-capable lets me = do this with also getting a few more packets through without dropping - = but packets get dropped at the hard queue limit anyway. So what's the = big deal? What is the major gain that can be gained over others? Cheers, Michael