> On 20. mar. 2015, at 19.29, David Lang <[email protected]> wrote: > > On Sat, 21 Mar 2015, Michael Welzl wrote: > >>> On 21. mar. 2015, at 01.03, David Lang <[email protected]> wrote: >>> >>> On Fri, 20 Mar 2015, Michael Welzl wrote: >>> >>>>> On 20. mar. 2015, at 17.31, Jonathan Morton <[email protected]> wrote: >>>>>> On 20 Mar, 2015, at 16:54, Michael Welzl <[email protected]> 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!!!"
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 _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
