> On 21. mar. 2015, at 01.03, David Lang <da...@lang.hm> wrote: > > On Fri, 20 Mar 2015, Michael Welzl wrote: > >>> On 20. mar. 2015, at 17.31, Jonathan Morton <chromati...@gmail.com> wrote: >>>> On 20 Mar, 2015, at 16:54, Michael Welzl <mich...@ifi.uio.no> 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. > 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? Cheers, Michael _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
