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

[Dave Taht]

as for the tail loss/rto problem, doesn't happen unless we are already
in a drop state for a queue, and it doesn't happen very often, and
when it does, it seems like a good idea to me to so thoroughly back
off in the face of so much congestion.

fq_codel originally never dropped the last packet in the queue, which
led to a worst case latency of 1024 * mtu at the bandwidth. That got
fixed and I'm happy with the result. I honestly don't know what cake
does anymore except that jonathan rarely tests at real rtts where the
amount of data in the pipe is a lot more than what's sane to have
queued, where I almost always have realistic path delays.

It would be good to resolve this debate in some direction one day,
perhaps by measuring utilization > 0 on a wide range of tests.

On Mon, Jun 11, 2018 at 11:39 PM, Dave Taht <dave.taht at gmail.com> wrote:
> "So there is no effect on other flows' latency, only subsequent
> packets in the same flow - and the flow is always hurt by dropping
> packets, rather than marking them."
>
> Disagree. The flow being dropped from will reduce its rate in an rtt,
> reducing the latency impact on other flows.
>
> I regard an ideal queue length as 1 packet or aggregate, as "showing"
> all flows the closest thing to the real path rtt. You want to store
> packets in the path, not buffers.
>
> ecn has mass. It is trivial to demonstrate an ecn marked flow starving
> out a non-ecn flow, at low rates.
>
> On Wed, Jun 6, 2018 at 6:04 AM, Jonathan Morton <chromatix99 at gmail.com> 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.
>>
>> That's only true in case Cake is not at the bottleneck, in which case it will only have a transient queue and AQM will disengage anyway.  (This assumes you're using an ack-clocked protocol, which TCP is.)
>>
>>>>> …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…
>>
>> Evidently.  You've been following Cake development for how long, now?  This is basic stuff.
>>
>>> …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?.
>>
>> At the point where the AQM drop decision is made, Cake (and fq_codel) has already decided which flow to service. On a bulk flow, most packets are the same size (a full MTU), and even if the packet delivered is the last one presently in the queue, probably another one will arrive by the time it is next serviced - so the effect of the *flow's* presence remains even into the foreseeable future.
>>
>> So there is no effect on other flows' latency, only subsequent packets in the same flow - and the flow is always hurt by dropping packets, rather than marking them.
>>
>>  - Jonathan Morton
>>
>> _______________________________________________
>> Bloat mailing list
>> Bloat at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>
>
>
> --
>
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619