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

Lars Eggert <lars@eggert.org> Tue, 22 September 2020 06:44 UTC

Return-Path: <lars@eggert.org>
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 B05693A1420 for <architecture-discuss@ietfa.amsl.com>; Mon, 21 Sep 2020 23:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
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 3jA2alRnFHKU for <architecture-discuss@ietfa.amsl.com>; Mon, 21 Sep 2020 23:44:54 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 952443A141E for <architecture-discuss@iab.org>; Mon, 21 Sep 2020 23:44:53 -0700 (PDT)
Received: from [IPv6:2a00:ac00:4000:400:d505:2b78:dd03:a6b1] (unknown [IPv6:2a00:ac00:4000:400:d505:2b78:dd03:a6b1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 04334667FA0; Tue, 22 Sep 2020 09:44:45 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1600757086; bh=+71BzC4BAembPVuGZCEGDrV88cxbkvyfjqx3VXPIgNg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=tUqjWv6qF6fPPPT1Rpitybd1MFnPWaiEiOgN4cRfbXtvc1tnis1qKLuy0nBG8eQR5 o+UhYW/jnwo+d+C87NE9DaDCYtJIR382oIdf4gpkb4MU2ZdWNKSUBQiLoy7HPo0jHr le8vsdJmtf2Y0t1H+qqfew6nvNTohOt8ruFM14eQ=
Content-Type: multipart/signed; boundary="Apple-Mail=_82D31366-E43E-4AB7-B04B-FD2AB58B2DAE"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Lars Eggert <lars@eggert.org>
X-Priority: 3
In-Reply-To: <2020092211271508522412@chinaunicom.cn>
Date: Tue, 22 Sep 2020 09:44:45 +0300
Cc: apn <apn@ietf.org>, huitema <huitema@huitema.net>, pengshuping <pengshuping@huawei.com>, 曹畅 <caoc15@chinaunicom.cn>, "network-tokens@ietf.org" <network-tokens@ietf.org>, "architecture-discuss@iab.org" <architecture-discuss@iab.org>
Message-Id: <4FEADB2A-A062-44B4-8D36-3651EBDD1ACD@eggert.org>
References: <2020092211271508522412@chinaunicom.cn>
To: zhangs366@chinaunicom.cn
X-MailScanner-ID: 04334667FA0.A13FD
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/bnaHfklgCXoWsCEfuaZ8-yate2E>
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 06:44:56 -0000

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.

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.

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.

Thanks,
Lars