From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 66A723B2A4 for ; Tue, 9 Mar 2021 13:48:25 -0500 (EST) Received: by mail-il1-x130.google.com with SMTP id k2so13134091ili.4 for ; Tue, 09 Mar 2021 10:48:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NePQkkrCnTRpl4Ev8sUroN3Wdf6wxFMbd+HK8jSY7+E=; b=VxeZNte5ARXjUH0Z5F1nqr+hbiEbbgQ9/YTv9mySjCp2gkOJ0BJ4BA/GPC3gXV1V29 XVQ3mdT69+ha8FOhTlKJUla9EGiCRjvNXA0DdQhY+KZoQqoXowWiVc/bLdrTkwTExXj2 mhUQWCrQyeNWIakehS/qMEkfrirZkiXxDImywNe/DpAhZdNTIM0Lx63+qkl6XhMEKQ5d aCPemvBdSFAesFN5gK0lXM72z2ecuiwpjxkB93Hvp4mK7g0N35q0I5loZgf1N2MUyMmu n4Jp0CzdoHVEXajj2p+t2mEGSY3PkRqn69eRC4nakOWLaB/oC9tMnhvUECphLWby8bKQ ib8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NePQkkrCnTRpl4Ev8sUroN3Wdf6wxFMbd+HK8jSY7+E=; b=XGC2zaq2qtyWmyZquHez3/RbVNcbV5M80P9v7mtiZWUaiVfTqsKUpuV4FoQEqrOI+R ESywvaZfiGa0q/4lli/KSjKzq7EV5bA5Gu61QgLsxl/QdmfxNrwqoHm98XQ6FaSry3ci 9Y29QjSAG18Z++YmY2PXRaXF3ESjsE6wKGIBxkyxm/jAvsHg4/xeW/Gwb3SXVdT6UTiO WKZIchSizOTK0LQr2g+ila2OkkCUy3Zfaw/OBS5nzxuoBTaLS0J9p7dg8O7sOkxdhvy9 SQ3RU7XoxjZAaA5KqdqeBkjM/nyqlcDHGU0TCVna1sk/AikYJflHUxbaPZTxnBd+6IGQ 1f3A== X-Gm-Message-State: AOAM5320rN/lhJmE6sPAoYHQYnjbro+GuhBVQCDlxPTuh4Shyb3hRli3 82zadNnyx4jKBIwsMYcyAgvQ/wmM0HWmwFp/FNQ= X-Google-Smtp-Source: ABdhPJxM3A1O/sI1CI3fNLD7K4dKt99PJsQjRQ4pqWOkzdDBTm/vj0hz4JPAbO23GaeXxP/uuRRFfzHE0tSGMEbTvfg= X-Received: by 2002:a05:6e02:f06:: with SMTP id x6mr23483080ilj.287.1615315704765; Tue, 09 Mar 2021 10:48:24 -0800 (PST) MIME-Version: 1.0 References: <202103091519.129FJBQg077653@gndrsh.dnsmgr.net> <96258C16-D03C-44F0-AFC8-3403F6866FF7@gmail.com> In-Reply-To: <96258C16-D03C-44F0-AFC8-3403F6866FF7@gmail.com> From: Dave Taht Date: Tue, 9 Mar 2021 10:48:13 -0800 Message-ID: To: Jonathan Morton Cc: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, ECN-Sane Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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:48:25 -0000 I do not think anything other than a brick wall can be implemented in high speed hardware. I really wish you'd try a brick wall, and fiddle on bbr. It is also heavily influenced by kathies work on codel. On Tue, Mar 9, 2021 at 10:43 AM Jonathan Morton wro= te: > > > On 9 Mar, 2021, at 8:09 pm, Dave Taht wrote: > > > > while I appreciated the experiments with making the assertion of SCE_th= reshold spread out, and not a brick wall, to me it seems best to coalesce o= n a brick wall for it at a fixed period of time the operator considers "que= uing". > > > > Does the SCE team agree with this approach? > > In a word, no. While it might be an acceptable compromise versus impleme= ntation 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* de= lay in that queue. It only takes a small number of packets in each RTT goi= ng 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 qu= eue 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 de= lay with variance. This strategy has worked well and applies nicely to pat= hs including a wifi link, so long as the target sojourn time is greater tha= n 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 ma= rkedly better than with a fixed ramp based at the same level, which would t= end 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 C= odel and PIE and putting them together. Like Codel, it measures queue sojo= urn time and manages a marking frequency (not probability), making it a ful= ly 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 o= f 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 functi= on, which permits a constant cwnd when an appropriate marking frequency is = received. This in turn is completely unlike traditional AIMD congestion co= ntrol, which exhibits a large sawtooth. > > Implementation of the first qdisc incorporating DelTiC is not yet complet= e, and then we have to see how well it works in practice. I'll talk about = it more when it's ready. > > - Jonathan Morton --=20 "For a successful technology, reality must take precedence over public relations, for Mother Nature cannot be fooled" - Richard Feynman dave@taht.net CTO, TekLibre, LLC Tel: 1-831-435-0729