From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rn-mailsvcp-ppex-lapp45.apple.com (rn-mailsvcp-ppex-lapp45.rno.apple.com [17.179.253.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 601703CB37 for ; Fri, 8 Oct 2021 19:32:21 -0400 (EDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp45.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp45.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 198NW0OP009177; Fri, 8 Oct 2021 16:32:17 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=20180706; bh=37I3Q1JJdiiFT5NerIUDf2ciWA0I+Yk14EkSopMvkPc=; b=q3jUs9H7B45oxnP8AKipc2HoFJzTQxfLZxbia+jD+SXquXnEdUyhlHfVNQRg6JOYngNn wuIgrDZYt8HsX9O5uX8FB6qToV8XV8eDMdAOiAMdKdopQKDAvF2Y5tujkddLycMyLD2X t1DIeGfmEbB6Ofy10DveM6HwadLN8X5O9a7whZM+lp+qMsR4GyhWL0C2es9M19q9oGYA KP+9JOSFNSZxByC+eIxUoKmwIdz4J7Nd/POsrkSP6S0+O8we8Fr5+j7vQnPI896ed6g/ xOFmeffNtMuFzbhYXWw0WxfHanyJ+uey9CkniVyFu24N3sqy7z8vS2pDFnUqflAzKtnP VA== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by rn-mailsvcp-ppex-lapp45.rno.apple.com with ESMTP id 3bjgurvsat-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 08 Oct 2021 16:32:16 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R0O00CWEMPOXXE0@rn-mailsvcp-mta-lapp01.rno.apple.com>; Fri, 08 Oct 2021 16:32:12 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R0O00J00MPHVS00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Fri, 08 Oct 2021 16:32:12 -0700 (PDT) X-Va-A: X-Va-T-CD: 0af778c0afa90afa8c4c05937d25c782 X-Va-E-CD: 938e555460f7490709cbb3f2f19f0a00 X-Va-R-CD: 759152a7f0ea58b844add9314c7862f7 X-Va-CD: 0 X-Va-ID: 74cf3395-692a-4657-9ba3-70740c09bfd2 X-V-A: X-V-T-CD: 0af778c0afa90afa8c4c05937d25c782 X-V-E-CD: 938e555460f7490709cbb3f2f19f0a00 X-V-R-CD: 759152a7f0ea58b844add9314c7862f7 X-V-CD: 0 X-V-ID: e5f80a23-c566-41c4-b8df-5256963584a0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-10-08_07:2021-10-07, 2021-10-08 signatures=0 Received: from localhost ([17.234.9.166]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R0O00VKMMPNC900@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Fri, 08 Oct 2021 16:32:12 -0700 (PDT) Date: Fri, 08 Oct 2021 16:32:11 -0700 From: Christoph Paasch To: Sebastian Moeller Cc: Jonathan Morton , Rpm Message-id: References: <45E18E9B-DD71-4F8A-92C2-AB5AA4439DC0@gmx.de> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: <45E18E9B-DD71-4F8A-92C2-AB5AA4439DC0@gmx.de> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-10-08_08:2021-10-07, 2021-10-08 signatures=0 Subject: Re: [Rpm] Alternate definitions of "working condition" - unnecessary? X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 23:32:21 -0000 On 10/07/21 - 12:30, Sebastian Moeller wrote: > Hi Christoph, > > > On Oct 7, 2021, at 02:11, Christoph Paasch via Rpm > > wrote: > > > > On 10/07/21 - 02:18, Jonathan Morton via Rpm wrote: > >>> On 7 Oct, 2021, at 12:22 am, Dave Taht via Rpm > >>> 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 >