Re: [arch-d] [Apn] Questions for APN: Q#5

Christian Huitema <huitema@huitema.net> Tue, 22 September 2020 15:29 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 E28083A16ED for <architecture-discuss@ietfa.amsl.com>; Tue, 22 Sep 2020 08:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 pYJfEx7z9VnP for <architecture-discuss@ietfa.amsl.com>; Tue, 22 Sep 2020 08:29:31 -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 7AF0A3A16E2 for <architecture-discuss@iab.org>; Tue, 22 Sep 2020 08:29:31 -0700 (PDT)
Received: from xse339.mail2web.com ([66.113.197.85] helo=xse.mail2web.com) by mx165.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1kKkEQ-000Bn7-3V for architecture-discuss@iab.org; Tue, 22 Sep 2020 17:29:28 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4BwlbS4gRNz22gP for <architecture-discuss@iab.org>; Tue, 22 Sep 2020 08:29:24 -0700 (PDT)
Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1kKkEO-0000Aq-Hd for architecture-discuss@iab.org; Tue, 22 Sep 2020 08:29:24 -0700
Received: (qmail 20135 invoked from network); 22 Sep 2020 15:29:24 -0000
Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.46.182]) (envelope-sender <huitema@huitema.net>) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for <architecture-discuss@iab.org>; 22 Sep 2020 15:29:24 -0000
To: Lars Eggert <lars@eggert.org>, zhangs366@chinaunicom.cn
Cc: apn <apn@ietf.org>, pengshuping <pengshuping@huawei.com>, 曹畅 <caoc15@chinaunicom.cn>, "network-tokens@ietf.org" <network-tokens@ietf.org>, "architecture-discuss@iab.org" <architecture-discuss@iab.org>
References: <2020092211271508522412@chinaunicom.cn> <4FEADB2A-A062-44B4-8D36-3651EBDD1ACD@eggert.org>
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: <a8542256-b0e7-f6d7-abb1-e2f379215849@huitema.net>
Date: Tue, 22 Sep 2020 08:29:12 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <4FEADB2A-A062-44B4-8D36-3651EBDD1ACD@eggert.org>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="MHJcwJqdV3KhUT0458gr4CR08fB7Tu61a"
X-Originating-IP: 66.113.197.85
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/gcnlw0Z1apovzGPsYhEeBL1aoZmqpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDeW3+HZ7LK0h6oEMb2VkOa5vM xCtZSe87wnSOA0YTnlDnx8yeplRO3sLIqUlSH7OGWjX/IZGjNLvCKbcIWngdSIMlhcTgOXSCz8qb ysTVYVkMDlXDa3aVnxGK2HywWN/nAHcHFv/DsfOS3vMKpW7OV1M9LD4J6QJNigNrycDHdbmOo0r3 6TvtZGZKJo7Ywel+UOUPX0VHiKUyAtskn6r56i8KMZYGrZmgW9KwYivcW5A61Ks3CiInn/dDFS2W PS2yGYffiENaEvSwZ91SD/eSc+7o0ZSfcEjJYb2rnSV2fRCARv6mkfvK/UihTJjyS3/OdDr2WLJq FULjiIcCiyuiCgTQeC2dL1Bxyk8yV+29SYS0kEOL0o9EBIpturfzKMtFD1+RO9x9UH6x/+ZJK1fw q9G5tr1naPLrD+uYvNqtQnWYBq6S+OMHcfXl6o0I271KKTjECb0PwpN4olPuA0AI937kIM09yvSV B0zYhsH8AJuuTXXyzfCvW5HtPAOKXEj7rIEmHmAkDEpaSZgC4bDF3AuEZbIKWBh7MDza4lPS5IjC sP6ETOm+oWhuUgZE7K+3fINnxlPOnErMIpfpA3rVH7bWyx3TYYlKtowRLzFS5WeBk4QknL1NHAiI h0kG5nFSeSlPwHz2scBdtNbrmXZO45YqEie9PqZ85hiF2gqwwZeqmNyzMA+ZYFAhtqOuV40Gc+op ssGaMqgS09HfQuslS1z1pRXWhjh9fdbl44I0Df25P7Tr7DA2ZkDX3hsXV4OBEVXEbJCIF9oevEqH kzZ7BvN4PbnkyTlOmu+sqcsY3XoPGIVnp5TH7r29ZjWOfyD4rnnSv2dzL5wMg5rjmgOQhmUVrBsP GnNiJ83AD/4JscDaZrPqwesCTPjTYTd2k9+TUlP348Oim6i8PNK9YAzt5ulNC4wc2LkM7XQE4YLV klN6giDSqpQHYfnjwHBMA7P/
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/1Qr04jlDz-T7Sqg_5cJMvx8h5Qs>
Subject: Re: [arch-d] [Apn] Questions for APN: Q#5
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: Tue, 22 Sep 2020 15:29:33 -0000

On 9/21/2020 11:44 PM, Lars Eggert wrote:

> Hi,
>
> On 2020-9-22, at 9:02, zhangs366@chinaunicom.cn wrote:
>> [Shuping] Again APN is aimed to work within a controlled and limited operators’ network domain not for Internet.
> that significantly limits the attractiveness of this proposal to application vendors. They can either buy into APN and ship an app that only works in some (initially, very few to none) operator networks. Or, they can ship a slightly less optimal app that works on the entire Internet with its billions of users.
>
> More broadly, I'd like to point out that during the entire history of the Internet there were application classes that the deployed networks at the time were struggling to support. There were always claims that something like APN was needed, i.e, solutions that were intending to improve network performance and quality but that were also adding significant complexity and often required application changes.
Yes indeed. In the 90's the argument was around video conferencing,
which "obviously" could not work on a plain best effort service. And
then we got Skype.
>
> What always happened so far was that Moore's law solved these problems, by improving the performance and quality of the general Internet so that best effort was sufficient to support all these "special" applications a few years down the road.
Yes. Indeed the whole history of wireless is driven by Moore's law. For
example, the theory of MIMO has been known for some time, put the
application and the use of large number of input and output is only
possible because of progress in electronics.
>
> The same will happen with the use cases presented to motivate the need for APN. The general Internet may struggle to support them now, but in five years or so - which is about the time horizon for any APN enablement of any operator network to happen - these will just work.

More bandwidth solves a lot of these issues. But we can also expect
improvement in transport protocols and in queue management. Active Queue
Management techniques can isolate different data streams and prevent
stupid issues like "my daughter playing video games is degrading my
VPN". New congestion control protocols like BBR actively manage queuing
delays, resulting in significantly lower latency overall. And then
application just get smarter in their use of caches, redundancy, gap
filling, etc. All that is guaranteed to improve over time.

-- Christian Huitema