From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 B48573B2A4 for ; Tue, 9 Mar 2021 08:53:15 -0500 (EST) Received: by mail-lj1-x229.google.com with SMTP id q14so20730626ljp.4 for ; Tue, 09 Mar 2021 05:53:15 -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=7uxyPpxGjxFEPoNj5K5uPS3xqn7FZf465feDq+N8S/o=; b=MruwQKWHT7KDORQWyhqXPktN2Qcwup0a+6uUk7Ordhp3cvVZShB7IIl9SyLGF4eyQ8 nVtb+QZADnr4OKhd09loo/9R8s7imfYEyqXmrWl4VLwOLsdXdP8qNtLUXBJAdaJnUacp YSRwBLt6vytQQ2ddtxyZ83uIt87RMYWVSzPLDoxf1JRChPwMbWx2qOFq2PFff+t2wodU Fqhvy8pkPVQLe/peY7T4EiGfRObRAUQCKlABvyF5sTf6qVNqYJZmow06n9NC04+B6uo8 SqmGh0YMc91ZzKE0Zjzzmyepyc9U/2HxPdN/2TrmqJwMlMRw350MyPnRA2MyRn6UgZ+m xt1g== 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=7uxyPpxGjxFEPoNj5K5uPS3xqn7FZf465feDq+N8S/o=; b=YBTINX6SdsVxY5k0nmes/masGCWGVerYQnE85XRoRrQBtpKOcJLaq3H8ocJljI6gk4 yT3QpdlcfAPgu1kUwwGVVEjAUb4ZcW+hseXok/EqehkOEXRnBvMIB34WQr4aGFHf4gOG tD89Qk/ERmtmeLmW2cr2iMzUiLLvCxrCEkga3Z7/Xz1wEBbb4GjW7kOCP+IGrJhLhI2V diMdq14FHZouIe8SMiCvjJgTUOZ6/ZdM3RF6g2siEYBuwU/2lR7pvvXAMAYoA/euf/d8 qffz3vKGPFcOqaQhHsYJIlj4VyNolqvK77NZ14rIWmXpRvUmwndILfmwz7F6z4ReHYbn l7Mw== X-Gm-Message-State: AOAM530UvCdVZihwPj7A9eXQYTgk8yrh9c2TCgKiJI1v77La3dMLVsd/ T85jLUkeSwjJry4zbx2wXAM= X-Google-Smtp-Source: ABdhPJxaVvUWmUHFs55GR7awak69a5vBDzfEVH4niUm1SacVKkpQ8od5nPOY3pWoel6lx2NwuQpxwA== X-Received: by 2002:a05:651c:30c:: with SMTP id a12mr15665058ljp.194.1615297994597; Tue, 09 Mar 2021 05:53:14 -0800 (PST) Received: from jonathartonsmbp.lan (176-93-29-60.bb.dnainternet.fi. [176.93.29.60]) by smtp.gmail.com with ESMTPSA id x19sm1795692lfr.198.2021.03.09.05.53.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Mar 2021 05:53:14 -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: <1cb500b5cff9a570f71a9b92096f5f279f4a27e7.camel@heistp.net> Date: Tue, 9 Mar 2021 15:53:13 +0200 Cc: Steven Blake , ECN-Sane Content-Transfer-Encoding: quoted-printable Message-Id: <0B2ABDF5-A4B0-418B-A6C3-90FE8E4F20BC@gmail.com> References: <7ff9063df5c5e05420ef47245becb77a2de80f2f.camel@petri-meat.com> <1cb500b5cff9a570f71a9b92096f5f279f4a27e7.camel@heistp.net> To: Pete Heist X-Mailer: Apple Mail (2.3445.9.7) Subject: Re: [Ecn-sane] IETF 110 quick summary 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 13:53:16 -0000 > On 9 Mar, 2021, at 11:57 am, Pete Heist wrote: >=20 > FQ protects competing flows, unless L4S and non-L4S traffic ends up in > the same queue. This can happen with a hash collision, or maybe more > commonly, with tunneled traffic in tunnels that support copying the = ECN > bits from the inner to the outer. If anyone thinks of any other = reasons > we haven't considered why competing flows would share the same 5-tuple > and thus the same queue, do mention it. Bob Briscoe's favourite defence to this, at the moment, seems to be that = multiple flows sharing one tunnel are *also* disadvantaged when they = share an FQ AQM bottleneck with multiple other flows that are not = tunnelled, and which the FQ mechanism *can* distinguish. Obviously this = is specious, but it's worth pinning down exactly *why* so we can explain = it back to him (and more importantly, anyone else paying attention). Bob's scenario involves entirely conventional traffic, and a saturated = bottleneck managed by an FQ-AQM (fq_codel), which is itself shared with = at least one other flow. We assume that all AQMs in existing networks = are ECN enabled (as distinct from the also-common policers which only = drop). The FQ mechanism treats the tunnel as a single flow, and shares = out bandwidth equally on that basis. So the throughput available to the = tunnel as a whole is one share of the total, no matter how many flows = occupy the tunnel. Additionally, the same AQM mark/drop rate is applied = to everything in the tunnel, causing the flows using it to adopt an = RTT-fair relationship to each other. The disadvantage experienced by the tunnel (relative to a plain AQM) is = proportional to the number of flows using the tunnel, and only = indirectly related to the number of other flows using the bottleneck. = This I would classify as Minor severity, since it is a moderate, = sustained effect. It increases in effect only linearly with the load on = the tunnel, which is the same as at any ordinary bottleneck - and this = is routinely tolerated. Note that if the tunnel is the only traffic using the bottleneck, the = situation is equivalent to a plain, single-queue AQM. This is an = important degenerate case, which we can come back to later. Also, in = principle the effect can be avoided by either not using the tunnel, or = by dividing the flows between multiple tunnels that the FQ mechanism = *can* distinguish. This puts the risk into either an "involved = participant" or "interested observer" category, unless the tunnel has = been imposed on the user without knowledge or consent. What this means = is that the tunnel user might reasonably consider the security or = privacy benefit of the tunnel to outweigh the performance defect it = incurs, and thereby choose to continue using it. Now, let us add one L4S flow to the tunnel, replacing one of the = conventional flows in it, but keeping everything else the same. The = conventional flows *outside* the tunnel are unaffected, because they are = protected by the FQ-AQM. But the conventional flows *inside* the = tunnel, which the FQ-AQM cannot protect because it cannot distinguish = them, are immediately squashed to minimum cwnd or thereabouts, which may = be considerably less than the fair-share BDP within that allocated by = the tunnel. The L4S flow thereby grows to dominate the tunnel traffic = as described elsewhere. This is clearly a Major severity effect, as the = conventional traffic in the tunnel is seriously impaired. Note that if the tunnel shared a plain AQM bottleneck, without FQ, with = other conventional flows outside the tunnel, these other flows would = *also* be squashed by the L4S flow in the tunnel. This is because the = AQM must increase its signalling rate considerably to control the L4S = flow, and it applies the same signalling rate to all traffic. The = FQ-AQM only increases signalling to the flow requiring it. Returning to the degenerate case where the tunnel is the only traffic = using the bottleneck, the situation remains the same within the tunnel, = and the behaviour is again equivalent to a plain AQM, with the L4S flow = dominating and the conventional traffic severely impaired. The tunnel = as a whole now occupies the full bottleneck rather than merely a = fraction of it, but almost all of this extra capacity is used by the L4S = flow, and can't be effectively used by the conventional flows within the = tunnel. It is therefore clear that the effect is caused by the L4S flow meeting = a conventional AQM, and not by the FQ mechanism. Furthermore, the = effect of an L4S flow within a tunnel is *over and above* any effects = imposed on the tunnel as a whole by an FQ-AQM. The main proposed solution to this is to upgrade the AQM at the = bottleneck, so that it understands the ECT(1) signal distinguishing the = L4S traffic from conventional traffic. But this imposes the burden of = mitigating the problem on the existing network, an "innocent bystander". = This is therefore clearly not an appropriate strategy; L4S should = instead ensure that it reacts appropriately to congestion signals = produced by existing networks, which by RFC-3168 compliance treat ECT(1) = as equivalent to ECT(0). If L4S cannot do this reliably - and we doubt that it can - then it must = either be redesigned to use an unambiguous signal, or explicitly = confined to networks which have been prepared for it by = removing/upgrading all conventional AQMs. We have proposed two possible = methods of redesigning L4S, both of which have been rejected by the L4S = team. - Jonathan Morton=