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

Sebastian Moeller <moeller0@gmx.de> Tue, 09 March 2021 12:38 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 52AD43A08BE for <tsvwg@ietfa.amsl.com>; Tue, 9 Mar 2021 04:38:31 -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 4yv5c05oT2bN for <tsvwg@ietfa.amsl.com>; Tue, 9 Mar 2021 04:38:30 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 98BCF3A08BB for <tsvwg@ietf.org>; Tue, 9 Mar 2021 04:38:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1615293464; bh=MdGwoOrtserBNO6skihY42Vch1H0uBTsx6e0dbRPyC0=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=Aj08jCZHzWO0Wd51E0zJ4EJA9hkjPxc0EHqSp4/EVsMgTC17zh6TCFzb5VLuXLlHZ udXUzitTNgLU+JyVOJeq1akSr9wVag0hBS26+e13ln0lmLdUYvyXvu902+ukrzBReZ h5A8/w/YeRdmcyhyZuVfI6oZaNrrBo+aPX791bag=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [172.16.10.207] ([134.76.241.253]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MPog5-1l5X8l3Asl-00Mwlk; Tue, 09 Mar 2021 13:37:44 +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: <ce2c8397-1bb9-8634-7822-88b9ba6d3b22@bobbriscoe.net>
Date: Tue, 9 Mar 2021 13:37:43 +0100
Cc: Pete Heist <pete@heistp.net>, tsvwg IETF list <tsvwg@ietf.org>, maprg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0F3DBF89-9DA3-401C-9793-5F0F2C72ED5E@gmx.de>
References: <161519742798.12373.8424747645620734074@ietfa.amsl.com> <4cc306ea278dab68741b0c27713bfb7c84522e11.camel@heistp.net> <72467bfe9a38edee74c4ab8e12ec350e23315ec9.camel@heistp.net> <ce2c8397-1bb9-8634-7822-88b9ba6d3b22@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:CO+T8uInbdiKByOooGlBuotKHwnXPKK0tLZU/YS0XKca1RFAs2Z ABbebFQRXp25Pw7u94vRlyabFo+YMUlMMvEyfKofCWaBbQEFGbu5I/fRNS4BHLXwk1vg5wM 2zHQEZcDExr9HfFxeizYrytBJ6gSwMQeFt3TSJL5pPKTzkJTge/3eqBfUcm7PSOpFjeYOnZ v3PvjWrhI6KeZZPcTKaRw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:7lYrOKb7lCI=:E6Se5p+K5vIeY0BEf5iyx8 5PaQ8QwqMqRulET0X/yykHJf4pguP3+u5goHW3dnJ4LOimNshjYMotq/pPQ8+t7Vk3I8HdxPS 9NACI4gHeuWvOj1bG2fxhvZhqepZG1fpuu5Zz03MBSj1K8pYzNiJBUE3/D8zOHGoPfAWxz2kF eNrHltNR12eTmID92QYLAcXLNw/IxzHaH56YZ6caKRKFrh56LIAoyzfMmYEbWErIQItcL3eTQ tZ5yeHPh+vVj3PrW0nPTGF+c1cX/GY70tU62+dLL96y151FZxw4pVWocSAEW8sjB8CCxlqcyL haJZnrPLyPJvmA7spmZSjTPNZFW4RTqCtxlbV7Z0WzU26RkQdw5xQ+gBthtyXfNpKbipbIRDl 3QzFzim/fOiM7a3NCs8PnTaxTnTBImgAHLaYKE8W7QIfjzDXWFPz8LjbxjORfwjGn3cBKKM2r TzOn6bBmhI79wf2vckaH3e6kpixCttomL50RUItRr3rA7wzXYjFBxfMJmLQbLNhkbfQ2VVY5Q OKDZlNLAFgiCfX7kdTCRAQKTKeCM+q1lEwyuk1n1peSPj+WU0TaQMg1DLQGJbIn+LEqw2r1xM c77Zlr5J/DuKFhMFvAZo6sdncIqZ/+ZlAJ03JMue6w+CYiaY+lxX2ipWGBl9b+KIBfoXs0rH7 eXR9xUeY8X4q4nnem4yKqdwheZLNe/HHbj9uraAGtQzm0/c4EQ+u4A/RSfKnFeGMqgFHrI7Os /f/5i+ODTPiBM6hAExVC4Nzn1RXGGRty1AgZ91r0ltwpl48l2S8lMgMzthVwtkh0YZvyHEUBY u25XHkUFYy6EHcCoclZNn4X9ofTCMyHTdHdlVpm7oG8avsMbdxWA7QlZU1/UUWC6C/l4b2z3a h/Nk00t/qCaBkXoauIxw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/xMYvop5m-35MgSiGWjwcpldjPJc>
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 12:38:31 -0000

> On 08/03/2021 22:19, Pete Heist wrote:
[...]
>> IMO, fq_codel isn't ideal in this situation. When there actually is
>> congestion to manage, flow-fairness means that one user can dominate
>> the queue with many flows, which is exactly one of the problems we'd
>> like to avoid. Host fairness could improve on this, or better yet,
>> member fairness using the member database, as members can have more
>> than one IP/MAC. But, fq_codel is what's available now, and generally
>> usable enough in this case to get started with AQM.

[...]



> On Mar 9, 2021, at 01:25, Bob Briscoe <ietf@bobbriscoe.net> wrote:
[...]
> PS. I agree it's v strange for an ISP to share capacity between its members by how many flows they are using.
[...]



I just want to note two things here:

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.

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?

Best Regards
	Sebastian