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

Christian Huitema <> Mon, 17 August 2020 15:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D59193A0DAA for <>; Mon, 17 Aug 2020 08:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.847
X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M0yeFF-W_uzN for <>; Mon, 17 Aug 2020 08:47:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B530B3A0EC8 for <>; Mon, 17 Aug 2020 08:47:08 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1k7hKw-0004n1-R6 for; Mon, 17 Aug 2020 17:46:49 +0200
Received: from (unknown []) by (Postfix) with ESMTPS id 4BVd59229czVns for <>; Mon, 17 Aug 2020 08:19:57 -0700 (PDT)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1k7gvV-0002TW-4b for; Mon, 17 Aug 2020 08:19:57 -0700
Received: (qmail 14629 invoked from network); 17 Aug 2020 15:19:57 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 17 Aug 2020 15:19:56 -0000
To: Joseph Touch <>, Toerless Eckert <>
References: <> <> <> <> <>
From: Christian Huitema <>
Autocrypt:; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
Message-ID: <>
Date: Mon, 17 Aug 2020 08:19:59 -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: <>
Content-Type: multipart/alternative; boundary="------------2071ABA806FF67575C1C2484"
Content-Language: en-US
Authentication-Results:; auth=pass smtp.auth=
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+fX7qYHlpECSsoxLtktFfjAAAFO05s+oip5EC/YK rMQ9+O9t+TYaqvvx766D6vBkj4PuYZsDfA+C63qRuwF/FjcGPDzNg5nLVJLqiE3T2fGty7mOo0r3 6TvtZGZKJo7Ywel+UOUPX0VHiKUyAtskn6r56i8KMZYGrZmgW9KwYivcW5A61Ks3CiInn/dDFS2W PS2yGYffiENaEvSwZ91SD/eSc+7o0ZSfcEjJYb2rnSV2fRCARv6mkfvK/UihTJjyS3/OdDr2WLJq FULjiIcCiyuiCgTQeC2dL1Bxyk8yV+29SYS0kEOL0o9EBIpturfzKMtFD1+RO9x9UH6x/+ZJK1fw q9G5tr1naPLrD+uYvNqtQnWYBq6S+OMHcfXl6o0I271KKTjECb0PwpN4olPuA0AI937kIM09yvSV B0zYhsH8AJscf1pPDHIpzyRJIAFazjKWyDxxCxxrsm1URHCkCrGekkK4G+F9iVA2rkbFj7qgW3L2 E1fQaKDDAkslbTQXAHOWL1MD8t8dBWLQjRG9dLB8kAixxLw9Tqj+m4GeC+uhnIAYOuoLOTrs2MSY MOWrSMXjQ74yPwmHuVj8tPrdUT9Gs8+ADlOi46n1PALad1UBUTOcTD53rSwSTIedTYkUaByAMod+ Su3cUNt/0umLnsd0MJoiu8eNlY3cwoWTHujvw4nfv4Rl05n4RPg8dvzcszF60JczxCjNbhVGwrVA ijGFu7zpwlGzT4HD3EMMzICh8kMVKPqpdskk5LxBR/9t1zMMNgZ00xRl+f8iOCsvtWSXGxqnOR+D xGR3qCP3ei1hX999s+yzMCxnaIvRTEOY/XUFLzItWCgLp9eSUEiS8gk+ZPjEzm1SsR8v3aJbN/NZ fa/X7fXWg6J5cHei57l/ibtd
Archived-At: <>
Subject: Re: [arch-d] A Public Option for the Core
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Aug 2020 15:47:11 -0000

On 8/17/2020 7:47 AM, Joseph Touch wrote:
> Hi, Toerless,
>> On Aug 17, 2020, at 12:46 AM, Toerless Eckert <
>> <>> wrote:
>> Btw, IMHO: Having an application tell the network exactly what it
>> wants from the network is quite a challenging task for applications.
>> ...
>> Hence we thought of a framework where the application would instead
>> attribute traffic as to what it is, e.g.: application FOO, wihthin
>> FOO floX,
>> e.g.: X = audio/video/...  Aka: Whatever the application developer
>> was able/
>> willing to tell.
>> Then one can have a trusted layer that would map this information to
>> actual network service requirements/advisory information.
> That’s an implementation detail inside the endpoint. The *network*
> should not be doing that inference:
> a) because it is typically made to favor the provider, not the user
> b) because it’s often incorrect, either because the needed info isn’t
> available (encryption) or deliberately obscured (running DNS over
> ports other than 53)

At the bottom are issues of knowledge and trust. As Toerless points out,
knowledge itself is hard. Application developers have a hard time
understanding the network service that they actually want. Even examples
that appear trivial, like video, are not: the video refresh rate and the
desired definition depends on whether the video is displayed as a post
stamp, as a square in a grid, or full screen, not to mention adaptive
coding to actual images. Asking applications to label their traffic
leads to compromises.

From the provider point of view, trusting the labels set by applications
is fraught with a different kind of compromise. What if every
application pretended to be a real time service requiring super high
quality of service? What prevents the application from lying? Would that
lead to collapse? Those fears are very much there, which is why network
providers tend to rely on DPI, and not use application labels much.

In theory, labels could be trusted if the users were paying for the
extra service. In practice, paying for extra service happens very
rarely. First, there is the knowledge issue, why would applications
incur extra costs without knowing why? Then, there is the
interconnection issue. Most network paths involve several network
providers. The one with a business relation with the user might be paid
for the extra service, but what about the others? That would require an
agreed framework allowing for example traffic providers to charge the
ISP for the labelled traffic that they emit. Good luck with that.

> My broader concern is the latter part of the second one: I don’t like
> the impact of anti-inference strategies on network architecture. It
> tends to force designers to reinvent the Internet at other layers
> (inside HTTP, e.g.).

Or to encrypt everything, which is very much the current trend. And to
add padding and cover traffic to try defeat fingerprinting. And possibly
to deploy end-to-end FEC.

> Ultimately, there are only a few things the network can do with a
> packet: forward it, queue it, or drop it. Having classes of service
> that don’t map directly to those behaviors is an invitation for
> unnecessary state and complexity anyway.
> Back to neutrality, though, the point is that the *network* should be
> neutral to the user and use of a service, not that there should be
> only one service.

I don't know that. Given the knowledge and trust issue,
one-size-fits-all looks actually very practical. That does mean a
compromise, because the network should allow those applications that
want low latency to get it, but should not limit the bandwidth that
applications can use if it is available. That probably requires more
research and development in active queue management, and in congestion
control algorithms that can cooperate with active queue management and
deliver the profile that fits the application.

-- Christian Huitema