Re: [arch-d] A Public Option for the Core

Christian Huitema <huitema@huitema.net> Mon, 17 August 2020 17:43 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C303A0D95 for <architecture-discuss@ietfa.amsl.com>; Mon, 17 Aug 2020 10:43:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.849
X-Spam-Level:
X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 BfEJ0u-BX5Tu for <architecture-discuss@ietfa.amsl.com>; Mon, 17 Aug 2020 10:43:54 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 26D2E3A0D89 for <architecture-discuss@ietf.org>; Mon, 17 Aug 2020 10:43:51 -0700 (PDT)
Received: from xse475.mail2web.com ([66.113.197.221] helo=xse.mail2web.com) by mx168.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1k7jAY-0012l1-MJ for architecture-discuss@ietf.org; Mon, 17 Aug 2020 19:43:42 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4BVgs51Qz6zCGxS for <architecture-discuss@ietf.org>; Mon, 17 Aug 2020 10:24:41 -0700 (PDT)
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1k7isD-0008Q1-34 for architecture-discuss@ietf.org; Mon, 17 Aug 2020 10:24:41 -0700
Received: (qmail 10115 invoked from network); 17 Aug 2020 17:24:40 -0000
Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.0]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <architecture-discuss@ietf.org>; 17 Aug 2020 17:24:40 -0000
To: Toerless Eckert <tte@cs.fau.de>
Cc: Joseph Touch <touch@strayalpha.com>, architecture-discuss@ietf.org
References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <FB381338-A278-45B2-A40B-3A065E3A3ED1@strayalpha.com> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> <60B2B44D-5E6D-4CB2-AD63-1A8CB846BFA3@strayalpha.com> <0e575946-dfd4-7753-8c34-47987d0b3c7e@huitema.net> <20200817164256.GB62842@faui48f.informatik.uni-erlangen.de>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
Message-ID: <439caeb9-481d-6123-ba59-ce25717cd4ae@huitema.net>
Date: Mon, 17 Aug 2020 10:24:43 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <20200817164256.GB62842@faui48f.informatik.uni-erlangen.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 66.113.197.221
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Uc1Z+hCSaILZIw3vLzlsGSpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDsYLBcJLyHnVrULITPs15U6ts NHuRxlWqWR9fNqLY1ai4Dcwf+CZK8NXgy3In+fX7xVMi9kSynkyW1vKeVUyeulO05s+oip5EC/YK rMQ9+O9t+TYaqvvx766D6vBkj4PutP0Dzal8myJ8vVhoWnSKP2MRQY4sL7fGBhvCp6oW0F28pnvZ XWSe7jV34Pxn0vH1Lz/y+awqhw7CmTPsWtYsCV/oEQh3zFZ7AJOfdc5NLopVCPmS+MVojfDUugvn Zl+jhHQOLtWk4clq0P6Ltvr/5Zl+BJt+8hYKwgejR0Z9YPn97p3CKmEi95YYeXPNWMiahaC2TJpF rGrq1WX76kTmg5w7R2/M+XaT5BLifEp8KpWu41J1t4cteGI4vH6PuMQp0kaOEXLuWd+6zLg4wp8u XxPcpGyeyPXKNTABBN67jV7JvFCbAD7w3FUirQwmJIqD2OUMeHyTpNN0eXybX/w7/3ZCM0u5uBlK VwmNWN494pWaZ30sdVozPGNttYaP6Q9/2E4JvzZwv3PGBEOc6AcTtGid8j6h6mzVhFB3UGjfs8Kk 1FZ5SzpWjtNrAe6rpkdW7+aVm/NqgKA5dyCxkhdL5g7yNAxIoTne18wgCHBWXWNdeu+6D1xe6+c7 Ft92TZYqkFl4iutyAZRMsedMRRS9foYXc9qTwyHkpkddwmvVLSYan9u1XhzpF3vNmn81pQyLs79q wWQ9VXX3j3CiZ1dw4xxwEiTVJqDh0qKoKsXx5lkVnK0YS3gd+LN4VG99hjvtzI2M6ZNcTIsrWx+O Oa5/69PEFdzaPktprEQ3qb+cP5JBtL9ewJnoHKUNLZpf7DfZZjMv6PN41V03H2/ZNJy1m5Scu7sV encPI85bGjWXuocpzCXI8Q8ncbCRI7u+gO19UCFcnal6WejB4YisLPSIrrdvK/cKOEqlCIPGIfYQ DNJ9yy88fxdoE98JfCUCbwYa
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/Ap3yJ_aMv2PTUdnSeFZtfRN_9_4>
Subject: Re: [arch-d] A Public Option for the Core
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Aug 2020 17:43:57 -0000

On 8/17/2020 9:42 AM, Toerless Eckert wrote:
> ...
> Instead of just talking about some of the tools (CC, ACM), it would be
> nice to try to set goals first, to see if we could get agreement there:
>
> -> I would like traffic to get the same throughput under congestion
>    whatever its RTT is.

I agree, but there is a fundamental issue. Flows with short RTT will
react faster to changing conditions than flows with shorter RTT, so
short term averages will always show some benefit to short delays.

> -> I would like for traffic to get bandwidth share indpendent of the
>    number of 5 tuple flows it utilizes (no gaming the system). But
>    rather fair per subscriber (weighted by how much the subscriber pays).

Yes. Basic fairness means all subscribers should be treated the same. At
the same time, there are some interesting questions. Assume that the
same function could be implemented as an app on my PC and or as a self
contained IOT device. Should the IOT device that has its own IP address
get more bandwidth than the app that shares the IP address with other
apps on the PC? I suppose that this is only a problem for local area
networks, since after that all traffic gets to share the subscribed
bandwidth, but I could see some needs here.

>
> -> I would like to be able for traffic to indicate preferences for
>    lower latency or higher throughput... If you ask for lower latency,
>    you get less throughput.

No. That's where we differ. We have tried designing this sort of
two-classes system in the past, modelling that as a game between the
application and the network, and trying to define strategies that were
robust against player's misbehavior. There is no sign that applications
would be ready for that.

On the other hand, there is plenty of research and deployment experience
for CC algorithms that deliver low latency if the network cooperates:
LEDBAT, BBR and L4S come to mind. There is also evidence of algorithms
that can lead to large delays especially in presence of buffer bloat:
Reno and Cubic. Let's assume that delay-sensitive applications use a
delay-minimizing CC algorithm. If the network "isolates" each
application in its own queue and serves them fairly, then the LEDBAT
users get low delay and the Cubic users get high bandwidth, and
everybody is happy.

>
> -> Goodput always > 95%
I don't know how to measure that. But yes of course, we don't want
congestion collapse.
>
> That would be a start for the most simple "one-size-fits" all i could
> imagine. But there is a lot more things i would like to factor in beyond
> that.

Sure. But I like your general approach.

-- Christian Huitema