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

Sebastian Moeller <moeller0@gmx.de> Tue, 09 March 2021 14:31 UTC

Return-Path: <moeller0@gmx.de>
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 4C5A93A0DD7 for <tsvwg@ietfa.amsl.com>; Tue, 9 Mar 2021 06:31:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 I_5tKUAdC1gI for <tsvwg@ietfa.amsl.com>; Tue, 9 Mar 2021 06:31:10 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 582693A0DCD for <tsvwg@ietf.org>; Tue, 9 Mar 2021 06:31:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1615300221; bh=oU+maTu1h2K+ucmJEcqVNtTIWaaIrkozCaeirWubZQw=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=hDzLZzcW/sY2p//zu3EQb9Ro7kj1RT2ElfycOMiq7YmEmPKmMOtSx72nhq8KmwFAd DhkTrx7HClw/iNvaYpYmcBe9b8zjha4sE84maP9qwX+OCxgr4ECcWEl9uTMaVqMypz 6CI/heqA5LJaoajsZI+xzcnGdRlJosxUrxK/94mI=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [172.16.10.207] ([134.76.241.253]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N5mGB-1lpnV80QAd-017Hfz; Tue, 09 Mar 2021 15:30:21 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <22CD0890-346C-4A43-AE20-DCED78E99FEA@gmail.com>
Date: Tue, 9 Mar 2021 15:30:19 +0100
Cc: Bob Briscoe <ietf@bobbriscoe.net>, tsvwg IETF list <tsvwg@ietf.org>, maprg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <508A2F0A-7CA3-4558-A845-B1D5B204D587@gmx.de>
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> <22CD0890-346C-4A43-AE20-DCED78E99FEA@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:AE/Lra6ViYgoP01O+XV/dlT2sn0EWi0hkehQ+MNcBPgcggd1omD hoYVqC0/kfNPyzOv4hJcnb8C+XOjmOU3nviQ3sFMgWpVe3b95U3HdTYm3c53+A2mjkWrOXB S/d3Wl3tc4EH9g1asTT+vos1T/+8UiDIpYFVfwEq34mB2y8OsS96AUYpMoBtbW05VaS/HMi OKofqI9noTttbt/pS0N2w==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Tud+n7cWDaY=:dlGIMc4L8OVot6OVJrlV27 rpBU00cCcoOjkfPdxI+AE/wsZJF4vVWRlUSh1VEucNeLttlAcrTl00goHdzTkuFg33E4jpCqz AXPw3ge/KVLdQVfQ17h30jnNVH96sFPhCvdQHtqoSQUnk/7PEvgOzCIqsyGvIva0HwoNZOQh7 lvMB5PDyGDnVdVTJ9Wolf3bHWVTOcD7ZxuxUFH2jXHZCJQfsKINJPj64cQ0tTVbOvQBuJxge/ VcYvLkkCxYJoRfeTjgb2ebehUWN23NwfOoUvo0JJ6wHumfUHt77fSfgcGBZruPTp7ercOUtGB yaWGmbnXLKtWYCRMwOXY14esmTvqY8lLFhoUj7orYBkZbBe6JaxBRBlY71TCLmQezWK4ITyQ9 ZALyxqqfqhLeBK21FYkEQp3mcbWkwTiQL5X04GXmi+zgmKgGJFGtAQl7ZVvb732rrJ3FZsvpQ Mrq4R/ZI4sK7rhncRJZkirWzNPVKvZBhoWOCaBvtaAKo0ZFp3oX9NOQ9p0NFQKhNwqyevQ1sZ lCkGjfmiaWhmI9C97QFT0/NAPZ9T1DDWSUvywecYEAzqkwT/uRYwAnfdNis1Ya8wfF2cpCxQu sqInbHFAycgp+vWiPzGM5t2Zs5JBs/YFefcYtx5OV3eEICV6DKZVEjpw3P/h2XHX0hG7bEquy qz8k+5sKCXIw7nXx7M/Anih62Mnwh2Z1Y//8xSj7KgJaoDYc8wk+cTDwTZzXEsz6KlXoZxTID 5xxVidOPQsu5k6CCRe8P15PV7KORsxGKLPqi1+zrIhJ3bm2vo569b80cFn1S4f/nY5O2iTgBa Rr14yaqBub7F8o3ooqjIXFK09dEuxbTbnCZZmtBfYmN5rvahMo3kBthCZMm/2F9dK9nsAvBOV vf5zZ9x/E+7w5UUgRHGw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/AcpREJXj6uuGXKKqtkN-lAftCPA>
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 14:31:13 -0000

HI Jonathan,


> On Mar 9, 2021, at 14:52, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
>> 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.

	[SM] Guess where I got my inspiration from ;)?


> 
> 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.

	[SM] Most commercial ISPs tend to sell fixed PIR type of contracts, so would require a per "user" control for the shaper speed, no?

Best Regards
	Sebastian

> 
> - Jonathan Morton