From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (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 3B99A21F417; Fri, 20 Mar 2015 17:29:08 -0700 (PDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t2L0T0FB019079; Fri, 20 Mar 2015 16:29:00 -0800 Date: Fri, 20 Mar 2015 17:29:00 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Michael Welzl In-Reply-To: <46B196A4-7755-4275-99E8-3D259EB46C33@ifi.uio.no> 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> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="680960-2088230678-1426897740=:22474" Cc: Jonathan Morton , "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Bloat] [Cerowrt-devel] DOCSIS 3+ recommendation? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 00:29:37 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --680960-2088230678-1426897740=:22474 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Sat, 21 Mar 2015, Michael Welzl wrote: >> On 21. mar. 2015, at 01.03, David Lang wrote: >> >> On Fri, 20 Mar 2015, Michael Welzl wrote: >> >>>> 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’s always a win to drop packets (in the service of signalling congestion) if the induced delay exceeds the inherent RTT. >>> >>> 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 : >> >> You are viewing this as a question to drop a packet or not drop a packet. >> >> The problem is that isn't the actual question. >> >> 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. >> >> 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. 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/10385c493layfousub74lnvqaaaaaahg7lbwdgdvonyyaaaaa/C?V=emlwX2NvZGUBAUNVU1RfTEFTVF9OTQFMQU5HAVJFV0FSRFNfQkF MQU5DRQExNi43MwFnX2luZGV4AQFDVVNUX0ZJUlNUX05NAURBVklEAUxBU1RfNAE1NDE3AWxfaW5kZXgBAXByb2ZpbGVfaWQBNDg0Mzk5MjEyAW1haWxpbmdfaWQBMTE 0OTI5NTU5AV9XQVZFX0lEXwE4NTY2MDAxNzQBX1BMSVNUX0lEXwExNjgwMTYwMQFVTlFfRU5STF9DRAEyMTEyMzkzOTE1AWVtYWlsX2FkX2lkAQFMU1RfU1RNVF9EQVR FATAyLzAxLzE1AWVtYWlsX2FkZHIBZGF2aWRAbGFuZy5obQFfU0NIRF9UTV8BMjAxNTAzMjAyMTAwMDABcHJvZmlsZV9rZXkBQTE0NjQ3MjgxMTQ%3D&KwXv5L3yGN8q uPM67mqc0Q > >> marking packets with ECN gives an advantage to them in mixed environments >> >> 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? 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!!!" David Lang --680960-2088230678-1426897740=:22474--