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

David Lang david at lang.hm
Fri Mar 20 20:29:00 EDT 2015

On Sat, 21 Mar 2015, Michael Welzl wrote:

>> 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.

but the router will still be working to reduce traffic, so more non-ECN flows 
will get packets dropped to reduce the 

>>  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

More information about the Bloat mailing list