From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 6EB093B29D for ; Wed, 6 Oct 2021 19:18:50 -0400 (EDT) Received: by mail-lf1-x131.google.com with SMTP id j5so16886179lfg.8 for ; Wed, 06 Oct 2021 16:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fV+OLLdKS2QU69uWhQFgXtftMV+AnWdU6OBLqk3XzBY=; b=d40Dtvlj4eHWiQBnt40P9k/4aUbALsyBzbe/h8zCfNBOV43dQt5mBOeFhadl26nWhN NkIB2SBB4/GkTg21uMINEHB1o8a6UvEPlU2GnxMutkOGBz91Y9XwmKxnx9diuX2pkJQb U9P8d+5kpgWmwLHLy7CE8ucPZYBtQbJJuP6OBhEnhgNgli3a0nc25xlbnYJ8dINGQd6W +aDlw08yFYe+pZD2A5mqV21uzqsPKmuaANnMZIsFar2FLyFNbQTHs41TRjd6z/ksvNgy l1/qZpX9ORyJTDt44X2SPWSz8uGNSkjuHG+qX7Dc74nEQrh8sPKTJj6MxlEECBKYwUAH Mxpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fV+OLLdKS2QU69uWhQFgXtftMV+AnWdU6OBLqk3XzBY=; b=Xaxk8RLjDUHn+Vakr4VetPuq2c574mowhi2lPLeysJAf0AnF+DIyVvixJeuhZM0pGg jlBtvSONp7Juiui+hUwe8ZqnLzELE3Aj4ZJjL/x9WbuqoSAgbLRIrudT5Oz3d5zo5tck 6IIOhAykRpX4IoonwYtSXeq+dGngxfh0dtjzNbmfHymmJbDrmcEypxb08kcZ/SWM4goE 9ufuYTqzNFPmx2CGHC1ZF7PBC7se5hi2q4BDJjwErxb/HTqYiY+B30hgv4ja1Gw8n1tq qdtKRC1zI/ateWzJsJEDQmQhOv2pHlh6iQ+IrDECXW86U5qC/CHzYWT+tQTXKYymaZYz gM/g== X-Gm-Message-State: AOAM533a7y4KnRjERDmX2KHyV88vWKWS3NLj73cPp5zKawV60TH0Vr9w Kp2PKGwjCIbX8I1ilN4ljkM= X-Google-Smtp-Source: ABdhPJy3Zo6sR1XYQe5bLLgrbzKOHjVsK99iTh4YyioFKY7GnByIY3DcP4wG94n4IPiwVwMlXWn2Cg== X-Received: by 2002:a05:6512:b13:: with SMTP id w19mr814780lfu.666.1633562329080; Wed, 06 Oct 2021 16:18:49 -0700 (PDT) Received: from smtpclient.apple (176-93-88-52.bb.dnainternet.fi. [176.93.88.52]) by smtp.gmail.com with ESMTPSA id t17sm2363944lft.296.2021.10.06.16.18.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Oct 2021 16:18:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Jonathan Morton In-Reply-To: Date: Thu, 7 Oct 2021 02:18:47 +0300 Cc: Rich Brown , Rpm Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dave Taht X-Mailer: Apple Mail (2.3654.100.0.2.22) 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: Wed, 06 Oct 2021 23:18:50 -0000 > On 7 Oct, 2021, at 12:22 am, Dave Taht via Rpm = wrote: >=20 > 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. 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. 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=