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

[Sebastian Moeller]

Hi Jonathan,



> On Jun 5, 2018, at 21:31, Jonathan Morton <chromatix99 at gmail.com> wrote:
> 
>> On 5 Jun, 2018, at 9:34 pm, Sebastian Moeller <moeller0 at gmx.de> wrote:
>> 
>> The rationale for that decision still is valid, at low bandwidth every opportunity to send a packet matters…
> 
> Yes, which is why the DRR++ algorithm is used to carefully choose which flow to send a packet from.

Well, but look at it that way, the longer the traversal path after the cake instance the higher the probability that the packet gets dropped by a later hop. So on ingress we in all likelihood already passed the main bottleneck (but beware of the local WLAN quality) on egress most of the path is still ahead of us. 

> 
>> …and every packet being transferred will increase the queued packets delay by its serialization delay.
> 
> This is trivially true, but has no effect whatsoever on inter-flow induced latency, only intra-flow delay, which is already managed adequately well by an ECN-aware sender.

	I am not sure that I am getting your point, at 0.5Mbps every full-MTU packet will hog the line foe 20+ milliseconds, so all other flows will incur at least that 20+ ms additional latency, this is independent of inter- or intra-flow perspective, no?.

> 
> May I remind you that Cake never drops the last packet in a flow subqueue due to AQM action, but may still apply an ECN mark to it.  

	I believe this not dropping is close to codel's behavior? 

> That's because dropping a tail packet carries a risk of incurring an RTO before retransmission occurs, rather than "only" an RTT delay.  Both RTO and RTT are always greater than the serialisation delay of a single packet.

	Thanks for the elaboration; clever! But dropping a packet will instantaneous free bandwidth for other flows independent of whether the sender has already realized that fact; sure the flow with the dropped packet will not as smoothly revover from the loss as it would deal with ECN signaling, but tat is not the vintage point from which I am looking at the issue here..

> 
> Which is why ECN remains valuable even on very low-bandwidth links.

	Well, I guess I should revisit that and try to get some data at low bandwidths, but my hunch still is that 
> 
> - Jonathan Morton
>