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 5DE4321F38A; Sat, 21 Mar 2015 21:10:36 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YZXDc-00048M-5P; Sun, 22 Mar 2015 05:10:32 +0100 Received: from [38.96.210.190] (helo=[10.1.212.173]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1YZXDa-00014W-SE; Sun, 22 Mar 2015 05:10:32 +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:10:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <46B196A4-7755-4275-99E8-3D259EB46C33@ifi.uio.no> To: David Lang X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 2 sum rcpts/h 12 sum msgs/h 3 total rcpts 26697 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: 862AFAF80A82FAD2A182287C1C662368BF7ECF02 X-UiO-SPAM-Test: remote_host: 38.96.210.190 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 3 max/h 2 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: Sun, 22 Mar 2015 04:11:05 -0000 > On 20. mar. 2015, at 19.29, David Lang wrote: >=20 > On Sat, 21 Mar 2015, Michael Welzl wrote: >=20 >>> 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. >>=20 >> I think it's about time we finally turn it on in the real world. >>=20 >>=20 >>> 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 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. >=20 > but the router will still be working to reduce traffic, so more = non-ECN flows will get packets dropped to reduce the = loadhttp://email.chase.com/10385c493layfousub74lnvqaaaaaahg7lbwdgdvonyyaaa= aa/C?V=3DemlwX2NvZGUBAUNVU1RfTEFTVF9OTQFMQU5HAVJFV0FSRFNfQkF > = MQU5DRQExNi43MwFnX2luZGV4AQFDVVNUX0ZJUlNUX05NAURBVklEAUxBU1RfNAE1NDE3AWxfa= W5kZXgBAXByb2ZpbGVfaWQBNDg0Mzk5MjEyAW1haWxpbmdfaWQBMTE > = 0OTI5NTU5AV9XQVZFX0lEXwE4NTY2MDAxNzQBX1BMSVNUX0lEXwExNjgwMTYwMQFVTlFfRU5ST= F9DRAEyMTEyMzkzOTE1AWVtYWlsX2FkX2lkAQFMU1RfU1RNVF9EQVR > = FATAyLzAxLzE1AWVtYWlsX2FkZHIBZGF2aWRAbGFuZy5obQFfU0NIRF9UTV8BMjAxNTAzMjAyM= TAwMDABcHJvZmlsZV9rZXkBQTE0NjQ3MjgxMTQ%3D&KwXv5L3yGN8q > uPM67mqc0Q >=20 >>=20 >>> 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 >>=20 >> 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. >>=20 >>=20 >>> 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 >>=20 >> 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? >=20 > for gamers, even a small gain can be major. Don't forget that there's = also the perceived advantage "If I do this, everyone else's packets will = be dropped and mine will get through, WIN!!!" I just addressed this with a message to the AQM list (should soon be in = the archives: = http://www.ietf.org/mail-archive/web/aqm/current/maillist.html ). In = short, I don't see any clear indications for this "benefit". And clearly = game developers also want low delay - blowing up the queue creates more = delay... and without clear knowledge about how many flows are actively = filling up the queue in parallel, there is a risk of creating extra = delay with this for no actual benefit whatsoever. Cheers, Michael