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

[Christoph Paasch <cpaasch@apple.com>]

On 10/07/21 - 12:30, Sebastian Moeller wrote:
> Hi Christoph,
> 
> > On Oct 7, 2021, at 02:11, Christoph Paasch via Rpm
> > <rpm@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@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... 

Our main use-case is iOS. This is by far the most common case and thus there
are no VMs or alike. All traffic is generated locally by our TCP
implementation.

>> > 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).

Not sure where the 128 comes from ?
And birthday paradox does not apply. The magic happens in inp_calc_flowhash() ;-)


Cheers,
Christoph


> 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@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/rpm
> > _______________________________________________ Rpm mailing list
> > Rpm@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/rpm
>