From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 4F7993B29D for ; Wed, 6 Oct 2021 20:11:39 -0400 (EDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 19709CFG062734; Wed, 6 Oct 2021 17:11:38 -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=IJ4O1JxS6hzi4M0BRO5GRrqvipaagJb62rszxpjJb2w=; b=hl4xNrSHBLYhwwQakIYEyhCm86OLzkqzOvNIMspNXYQxpDW56DBSJk0OOwcsMB964Ilx g2bko5Yb2FPXi+ZOf6PP4QhIV8qkQ7w91sZrpl6fhce879F4/e93JYXu/wcWCzQFadPQ 1qb9MyYJLNdGJWhXFkXJ6LWguJ2JmNvUaPlP3z+1fKm/78ho9yWBo783sw6QqaLYP0mj Uh/7/hCGNLW0vVS2mtgjSLoddS2QVh1U/UbF9XNOaLEOfj6BwoQpzumNvrlABgQqRWRz m3uqMC7n4LSirp5le/ak/448NxguAqcW/30fPuE8HAKtA6rQPr9YT2QNknwzzx4pYTm/ /A== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 3bem3uauke-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 06 Oct 2021 17:11:38 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R0K00VSJZ7BT3B0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Wed, 06 Oct 2021 17:11:35 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0R0K00O00YLZZR00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Wed, 06 Oct 2021 17:11:35 -0700 (PDT) X-Va-A: X-Va-T-CD: 91d727c8e9d4f1c9cb58324f55a5e336 X-Va-E-CD: 938e555460f7490709cbb3f2f19f0a00 X-Va-R-CD: 759152a7f0ea58b844add9314c7862f7 X-Va-CD: 0 X-Va-ID: 64d83f6e-791f-4a3e-834a-b4f22cf1bf0d X-V-A: X-V-T-CD: 91d727c8e9d4f1c9cb58324f55a5e336 X-V-E-CD: 938e555460f7490709cbb3f2f19f0a00 X-V-R-CD: 759152a7f0ea58b844add9314c7862f7 X-V-CD: 0 X-V-ID: d4e931af-b68c-4c68-810c-ec7b192dd491 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-10-06_04:2021-10-06, 2021-10-06 signatures=0 Received: from localhost ([17.11.80.94]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0R0K00NC6Z7BLY30@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Wed, 06 Oct 2021 17:11:35 -0700 (PDT) Date: Wed, 06 Oct 2021 17:11:35 -0700 From: Christoph Paasch To: Jonathan Morton Cc: Dave Taht , Rpm Message-id: References: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-10-06_04:2021-10-06, 2021-10-06 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: Thu, 07 Oct 2021 00:11:39 -0000 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). 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. 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