[Bloat] [Bug 1436945] Re: devel: consider fq_codel as the default qdisc for networking

[Mario Hock]

Am 06.06.2018 um 10:15 schrieb Sebastian Moeller:
> 	Well, sending a packet incurs serialization delay for all queued up packets, so not sending a packet reduces the delay for all packets that are sent by exactly the serialization delay. If egress bandwidth is precious (so when it is congested and low in comparison with the amount of data that should be send) resorting to congestion signaling by dropping seems okay to me, as that immeiately frees up a "TX-slot" for another flow.

If the packet is dropped and the "TX-slot" is freed up, two things can 
happen:

1. The next packet belongs to the same flow. In this case, a TCP flow 
has no benefit because head-of-line-block occurs until the packet is 
retransmitted. (This might be different for loss-tolerant 
latency-sensitive UDP traffic, though.)

2. The next packet belongs to another flow. Obviously, this flow would 
benefit. However, the question which flow should be served next should 
be made by the scheduler, not by the dropper. (In the case of 
scheduler/dropper combinations, such as fq_codel.)

Best, Mario Hock