[Rpm] Alternate definitions of "working condition" - unnecessary?

[Sebastian Moeller]

Hi Christoph,

> On Oct 7, 2021, at 02:11, Christoph Paasch via Rpm <rpm at lists.bufferbloat.net> wrote:
> 
> On 10/07/21 - 02:18, Jonathan Morton via Rpm wrote:
>>> On 7 Oct, 2021, at 12:22 am, Dave Taht via Rpm <rpm at lists.bufferbloat.net> wrote:
>>> There are additional cases where, perhaps, the fq component works, and the aqm doesn't.
>> 
>> Such as Apple's version of FQ-Codel?  The source code is public, so we might as well talk about it.
> 
> Let's not just talk about it, but actually read it ;-)
> 
>> There are two deviations I know about in the AQM portion of that.  First is that they do the marking and/or dropping at the tail of the queue, not the head.  Second is that the marking/dropping frequency is fixed, instead of increasing during a continuous period of congestion as real Codel does.
> 
> We don't drop/mark locally generated traffic (which is the use-case we care abhout).

	In this discussion probably true, but I recall that one reason why sch_fq_codel is a more versatile qdisc compared to sch_fq under Linux is that fq excels for locally generated traffic, while fq_codel is also working well for forwarded traffic. And I use "forwarding" here to encompass things like VMs running on a host, where direct "back-pressure" will not work... 


> We signal flow-control straight back to the TCP-stack at which point the queue
> is entirely drained before TCP starts transmitting again.
> 
> So, drop-frequency really doesn't matter because there is no drop.

	But is it still codel/fq_codel if it does not implement head drop (as described in https://datatracker.ietf.org/doc/html/rfc8290#section-4.2) and if the control loop (https://datatracker.ietf.org/doc/html/rfc8289#section-3.3) is changed? (I am also wondering how reducing the default number of sub-queues from 1024 to 128 behaves on the background of the birthday paradox).

Best Regards
	Sebastian

P.S.: My definition of working conditions entails bidirectionally saturating traffic with responsive and (transiently) under-responsive flows. Something like a few long running TCP transfers to generate "base-load" and a higher number of TCP flows in IW or slow start to add some spice to the whole. In the future, once QUIC actually takes off*, adding more well defined/behaved UDP flows to the mix seems reasonable. My off the cuff test for the effect of IW used to be to start a browser and open a collection of (30-50) tabs getting a nice "thundering herd" of TCP flows starting around the same time. But it seems browser makers got too smart for me and will not do what I want any more but temporally space the different sites in the tabs so that my nice thundering herd is less obnoxious (which IMHO is actually the right thing to do for actual usage, but for testing it sucks).

*) Occasionally browsing the NANOG archives makes me wonder how the move from HTTP/TCP to  QUIC/UDP is going to play with operators propensity to rate-limit UDP, but that is a different kettle of fish...


> 
> 
> Christoph
> 
>> 
>> I predict the consequences of these mistakes will differ according to the type of traffic applied:
>> 
>> With TCP traffic over an Internet-scale path, the consequences are not serious.  The tail-drop means that the response at the end of slow-start will be slower, with a higher peak of intra-flow induced delay, and there is also a small but measurable risk of tail-loss causing a more serious application-level delay.  These alone *should* be enough to prompt a fix, if Apple are actually serious about improving application responsiveness.  The fixed marking frequency, however, is probably invisible for this traffic.
>> 
>> With TCP traffic over a short-RTT path, the effects are more pronounced.  The delay excursion at the end of slow-start will be larger in comparison to the baseline RTT, and when the latter is short enough, the fixed congestion signalling frequency means there will be some standing queue that real Codel would get rid of.  This standing queue will influence the TCP stack's RTT estimator and thus RTO value, increasing the delay consequent to tail loss.
>> 
>> Similar effects to the above can be expected with other reliable stream transports (SCTP, QUIC), though the details may differ.
>> 
>> The consequences with non-congestion-controlled traffic could be much more serious.  Real Codel will increase its drop frequency continuously when faced with overload, eventually gaining control of the queue depth as long as the load remains finite and reasonably constant.  Because Apple's AQM doesn't increase its drop frequency, the queue depth for such a flow will increase continuously until either a delay-sensitive rate selection mechanism is triggered at the sender, or the queue overflows and triggers burst losses.
>> 
>> So in the context of this discussion, is it worth generating a type of load that specifically exercises this failure mode?  If so, what does it look like?
>> 
>> - Jonathan Morton
>> _______________________________________________
>> Rpm mailing list
>> Rpm at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/rpm
> _______________________________________________
> Rpm mailing list
> Rpm at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm