From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 39B583B2A4 for ; Tue, 9 Mar 2021 13:43:03 -0500 (EST) Received: by mail-lj1-x22b.google.com with SMTP id e20so2970980ljn.6 for ; Tue, 09 Mar 2021 10:43:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VUkB5NGagRh80hWhQa9/lPs5NX0K+fgIFYIx08HCo6s=; b=LKmwiL54erQd+mG7/p1qnymdFOhG7EcPRJTwig3HtSpVxSCWhk+v44T/WwARUrQ406 um/KtwWSjAqGVuDfVdSEVsH4mgQq4ZnPEQLxR1mASSnMnlpBh57ZCoAcYMd6ZKppIpLI b++oh7fvAvrGIf3uQd5wbpNJhmX4+pBSHbgWPslL7lOgPs43lzLVwr54R5VcZfUXQo1x dishFa/D7dS3IWzbcnOu/efPv/MK15lyIjPUcceu1+je2ZfsSj/2ngTzaoUbVeOxm/e2 wBHH53zKiDbCm9uItjEporp3sVvE8zm8esaZ4DVoYR02SQ5YMB6IIlafSvVFVG//QO7E 2NWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VUkB5NGagRh80hWhQa9/lPs5NX0K+fgIFYIx08HCo6s=; b=LHFFOxGXXSPTss95AUBwaO9gpJnGRXRGhNyOUQKxxnt3gsiiGF5J8mc1hBjgEYi5/5 SYRfvfZ+dvqb87WDctoP3FuUuRg1WFgiL8NOHt4wpwHoE/l3jo8dbYioVysLYPBhpDzC bA52fpHUUhXgqlIL2SoUxdAI6TFnU1uvebbiqhdz1WUjybgSNa3DY4habNkGS3Re7KBa SSCaX3/YGZ8s6ocF+MYdoMfbURH89CzMP0z8yixKyZ49hTcFVLQyD6WndsuGBJEAI2jI trraoGhEbBUkH5R+XIe0R6D7klWwBS/jktY+D/dR8lC6osCXQ52oQHxGlS+ZSCkoDHgb psFw== X-Gm-Message-State: AOAM531BpHjRxRyxtEjaso+eEjth1q8ca2okNX4QD9afQnz0AQz1wucw ei9seLiDpbzIoaaScZcnDO4= X-Google-Smtp-Source: ABdhPJxR0ZTYoU9A3mP4DeGK+mCLcOuy5N7kYoosxxQdmUTu0NmxDpHHh6215tEx+et0rLapP9iGdw== X-Received: by 2002:a2e:8e28:: with SMTP id r8mr18470004ljk.156.1615315382016; Tue, 09 Mar 2021 10:43:02 -0800 (PST) Received: from jonathartonsmbp.lan (176-93-29-60.bb.dnainternet.fi. [176.93.29.60]) by smtp.gmail.com with ESMTPSA id l21sm2023565lfc.91.2021.03.09.10.43.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Mar 2021 10:43:01 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) From: Jonathan Morton In-Reply-To: Date: Tue, 9 Mar 2021 20:42:59 +0200 Cc: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, ECN-Sane Content-Transfer-Encoding: quoted-printable Message-Id: <96258C16-D03C-44F0-AFC8-3403F6866FF7@gmail.com> References: <202103091519.129FJBQg077653@gndrsh.dnsmgr.net> To: Dave Taht X-Mailer: Apple Mail (2.3445.9.7) Subject: Re: [Ecn-sane] A brick wall threshold for SCE_threshold X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 18:43:03 -0000 > On 9 Mar, 2021, at 8:09 pm, Dave Taht wrote: >=20 > while I appreciated the experiments with making the assertion of = SCE_threshold spread out, and not a brick wall, to me it seems best to = coalesce on a brick wall for it at a fixed period of time the operator = considers "queuing". >=20 > Does the SCE team agree with this approach? In a word, no. While it might be an acceptable compromise versus = implementation cost in the datacentre, in the general case you're not = going to get good performance that way. Formally, what a brick-wall control law gives you is control of *peak* = delay in that queue. It only takes a small number of packets in each = RTT going over the threshold to make the flow back off. If there's more = variation of delay than the threshold is set at, then the trough will be = with the queue empty and the link idle - and the link introducing the = variation might be remote from the one serving as the bottleneck and = doing the marking, so you can't merely set the threshold higher at those = particular links. Kathy Nichols designed Codel specifically to control the *trough* of a = delay with variance. This strategy has worked well and applies nicely = to paths including a wifi link, so long as the target sojourn time is = greater than the time between txops. Since the limit on wifi = aggregation is 4ms, the default setting of 5ms dovetails nicely with = that. The SCE marking target is 2.5ms is actually a little low, but = using this with Codel still works markedly better than with a fixed ramp = based at the same level, which would tend to control the peak. Some of my current effort is going into a new AQM algorithm called = DelTiC (Delay Time Control). You can think of it as taking the best = ideas from Codel and PIE and putting them together. Like Codel, it = measures queue sojourn time and manages a marking frequency (not = probability), making it a fully time-domain algorithm. The control law = is PID, not merely PI, so it can detect a rapidly rising queue depth = (due to slow-start exponential growth, say) and act sooner to control it = than Codel does. I think that was one of the big shortcomings of Codel = you were keen to see solved. Unlike Codel, DelTiC has a true steady-state condition where the marking = frequency can remain constant. This goes well with the SCE response = function, which permits a constant cwnd when an appropriate marking = frequency is received. This in turn is completely unlike traditional = AIMD congestion control, which exhibits a large sawtooth. Implementation of the first qdisc incorporating DelTiC is not yet = complete, and then we have to see how well it works in practice. I'll = talk about it more when it's ready. - Jonathan Morton=