Re: [tsvwg] New Version Notification for draft-heist-tsvwg-ecn-deployment-observations-02.txt

Jonathan Morton <chromatix99@gmail.com> Tue, 09 March 2021 13:53 UTC

Return-Path: <chromatix99@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4DA3A0CB4 for <tsvwg@ietfa.amsl.com>; Tue, 9 Mar 2021 05:53:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.848
X-Spam-Level:
X-Spam-Status: No, score=-6.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGZn9-_1xT_d for <tsvwg@ietfa.amsl.com>; Tue, 9 Mar 2021 05:52:57 -0800 (PST)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB7683A0CB3 for <tsvwg@ietf.org>; Tue, 9 Mar 2021 05:52:54 -0800 (PST)
Received: by mail-lj1-x22f.google.com with SMTP id i26so9089890ljn.1; Tue, 09 Mar 2021 05:52:54 -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=cH+EJ6B89e8bQU57wFFGVLHU9h3mZBLW4Ex3/sNUHMc=; b=iAjQv5NULKVLBJFVP0p4tvysasWxLQ77kjbepXCYO47XI57JfjUI4Z/mLTtX9vBMLE Zx4cY6f+z14bJTyGZo6KCETOTT5uu0NTCjLc+pVDNUXJyCsnRd2avaPcE37KR1YIYRZo rj270zeDCTFtS6xTTZjxDfebhxFFY90WMCMHHjDi1M99adRqi4jB+eqpu2MJkyVANLqI tr1dJrZzgcP2YtzVF+gP2NHD+GlDYz7PyYxJyu8g4++U3OrUvBPreokMSa7iGi/ZZirX d8cEgGCBi9/tILnFbQJh+lXS9qlRWoFnsfnEIwtX7Fm7z0KxZHL+1tKEfpvCKYNBd6/y FB4w==
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=cH+EJ6B89e8bQU57wFFGVLHU9h3mZBLW4Ex3/sNUHMc=; b=IzXXU0tuNly4IygcJJhMiu2+GsWulRJBuB9zXjrlUTI/mRPOG7j77mjcFCVjA53I84 N5Pu/irHuNDM48Dxx84U+yvI7kLsEDaKqv/+y6HZp9JmnyPY0n+kDS658RN59aPp9Ckn 1FXgO2mH/uyGMjJkoPagmywhlmtmxkBTIjba/uDpjsAlUiQytfT9mF6NuRz6+90dDx52 7o5sQhuhVPPffw/xLe55k86tkxvHUzeGwsqZYLlh3fILtuZk2lQctoX2L8tr6YiIRvVJ 6DSK2vs8vvdKLkSwHKLg1F1vYPxssVOaSRsjk61tk/d9JiFyJncnV3v87e+iRYuUJ+yz 4qHw==
X-Gm-Message-State: AOAM533CRp5xqNIM0t73V0K5k+BCvmmx/syy1GvNw9y2I7i/E6qzmBvI 1LXWKZ1ZVmT/+mIk6oVQ7wo=
X-Google-Smtp-Source: ABdhPJzcvA6SIAfdup8gopk2Uu7QRC4wxFtqZi6uVcx6h/8UAdX/gVPeCGZfa4zg34V0Wdaym6+p6A==
X-Received: by 2002:a2e:9ad0:: with SMTP id p16mr13830932ljj.414.1615297973094; Tue, 09 Mar 2021 05:52:53 -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.52.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Mar 2021 05:52:52 -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 <chromatix99@gmail.com>
In-Reply-To: <0F3DBF89-9DA3-401C-9793-5F0F2C72ED5E@gmx.de>
Date: Tue, 9 Mar 2021 15:52:51 +0200
Cc: Bob Briscoe <ietf@bobbriscoe.net>, tsvwg IETF list <tsvwg@ietf.org>, maprg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <22CD0890-346C-4A43-AE20-DCED78E99FEA@gmail.com>
References: <161519742798.12373.8424747645620734074@ietfa.amsl.com> <4cc306ea278dab68741b0c27713bfb7c84522e11.camel@heistp.net> <72467bfe9a38edee74c4ab8e12ec350e23315ec9.camel@heistp.net> <ce2c8397-1bb9-8634-7822-88b9ba6d3b22@bobbriscoe.net> <0F3DBF89-9DA3-401C-9793-5F0F2C72ED5E@gmx.de>
To: Sebastian Moeller <moeller0@gmx.de>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/u5dJusmfDnMyKq6KUAI54VfexYI>
Subject: Re: [tsvwg] New Version Notification for draft-heist-tsvwg-ecn-deployment-observations-02.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Mar 2021 13:53:01 -0000

> On 9 Mar, 2021, at 2:37 pm, Sebastian Moeller <moeller0@gmx.de> wrote:
> 
> a) even without a flow queueing AQM on the bottleneck, sharding works to get a higher part of the capacity since TCP tends to be more or less fair to itself
> 
> b) most ISP put a lid on games like that by simply also enforcing (policing or shaping) each users aggregate capacity to numbers mentioned in the contract...
> 
> So fq_codel, while by no means ideal here, does not really make thinks worst that the status quo, it is just that sharding can make pure flow fairness regress to less equitable sharing between classes other than flows.

This is true IMHO.  FQ still has a significant advantage here, in that latency effects are still isolated between flows; sparse flows, which are typically more latency-sensitive, are not affected by the various saturating flows rushing past them on all sides.  That would not necessarily be true with a single queue.

> For a cooperative use case, something like a per-member QFQ instance that equitably shares capacity between members with an fq_codel inside each of the QFQ classes seems like a better fit, no?

This is similar in effect to what Cake can be configured to do.  Cake does it by weighting the delivery rate of individual flows to produce a constant total weight per host.

Since this seems to be a fairly common use case for ISPs, I'm considering writing a qdisc specialised to do it efficiently.  This could be a drop-in replacement for an fq_codel or HTB+fq_codel deployment, assuming the device needing it is running a new enough kernel.

 - Jonathan Morton