[Bloat] [Cerowrt-devel] DOCSIS 3+ recommendation?

[Michael Welzl]

> On 21. mar. 2015, at 01.03, David Lang <david at lang.hm> wrote:
> 
> On Fri, 20 Mar 2015, Michael Welzl wrote:
> 
>>> On 20. mar. 2015, at 17.31, Jonathan Morton <chromatix99 at gmail.com> wrote:
>>>> On 20 Mar, 2015, at 16:54, Michael Welzl <michawe at 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