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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> 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 _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
