[Apn] 回复: [Network-tokens] [arch-d] Questions for APN: Q#5

刘 鹏 <liupengyjy@outlook.com> Wed, 30 September 2020 01:14 UTC

Return-Path: <liupengyjy@outlook.com>
X-Original-To: apn@ietfa.amsl.com
Delivered-To: apn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611363A07CE; Tue, 29 Sep 2020 18:14:15 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com
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 x8RpY1StNCo3; Tue, 29 Sep 2020 18:14:13 -0700 (PDT)
Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253011.outbound.protection.outlook.com [40.92.253.11]) (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 928143A064B; Tue, 29 Sep 2020 18:14:12 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gCU7ehglEU5gbWJ7A+jhm1SURU5gwHlmA68591wcm8z4Ur1qOha365vT54oM6a2Cu9kQYEodGzuUpOyOagQo/JWXz2CqKJ2bJkvBPHpS2sfiqRRGWc7IQOw4/+U64Qvf6UjsX0/pWM6msNBfyPc7aRweck+mMPWk7n80iDkoPO2tdDjMcZWBuq38+Z+gq4+lHoX4SyUEyVRKQddJCji21McsTEQLY12iR1h6OyZd3XD2c4kA10p1rqnM3POlI/YQ+f1hsKQVrS7Kq7xUVAxaiES7ZwAa52/ooVGSwY37jBD8RsSL6/HstH8aCcKrlvMw1H/8xJCVpKKQO6HQegAkOg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VZ8D5lHG/2dE4FD6qcmqe+F+S/Jrs3QDOQz8WcbJhLo=; b=JLzXzrUzQZGvsmxmadsgWLEEjDDo/DAT3ZOVDZ8a2EA/t9vMVrNVERBjnZS++1cxRwT2O9ujsXzTkeqFvRgeOI/JgHMqZAPd0BHNM9uP6feHs+e4Vf/k+JcOIOe4SHaDKaBfY66xevL4W4wtLjBYZOrtD17+kJPn2m/VQCx4weD6hK1V4GCR9/M7JmdJXQ4pSlr8r1yBLdZvMUOiG6mDWLStRJjQJ0MO9Z7TZVEv6fSGwqYUcyJRPUoPgRV1vgiinsbttX2SvVesjIQe3cw8dS5Kee3m+j9ggVNwWzdPTInrHCXJqYMqEmx8/Ph1KIG7iGXVX89X8I13EjERbUaj8w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VZ8D5lHG/2dE4FD6qcmqe+F+S/Jrs3QDOQz8WcbJhLo=; b=drrp/PsrYx3e+4fIoOX1NaqncJTMKYLvYSuJ7XP8GzTWo/nGr0TYWhBG5gYny98jherBMMjam1ZkeP8qz2hGIaOvE6P9iE3kg/C5XgS5EnbP7wao9++Z6ozE4g3izIZ252DPCNGnQJrAym1oug2/01k1Dj8oLXT84ynDPmLGj8/liwO4nzwIk0+ex1/gOlm2lb1FykEcUu+/QVZDCRymZys6JpSqx/G/657S9L80Lcevr/U7TUWt2b6UtubtdBYa2Yo6plDOsolzldIrultOERdCI6MHaNOTNWYEhRoQeA6nRAU+pZyREI5yLsVFiDQjkkd91I1Fn8RVFicPhUSroA==
Received: from SG2APC01FT017.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebd::4a) by SG2APC01HT046.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebd::318) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21; Wed, 30 Sep 2020 01:14:03 +0000
Received: from PU1PR06MB2215.apcprd06.prod.outlook.com (2a01:111:e400:7ebd::45) by SG2APC01FT017.mail.protection.outlook.com (2a01:111:e400:7ebd::203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.34 via Frontend Transport; Wed, 30 Sep 2020 01:14:03 +0000
Received: from PU1PR06MB2215.apcprd06.prod.outlook.com ([fe80::619a:8008:12e5:b295]) by PU1PR06MB2215.apcprd06.prod.outlook.com ([fe80::619a:8008:12e5:b295%7]) with mapi id 15.20.3433.032; Wed, 30 Sep 2020 01:14:03 +0000
From: =?gb2312?B?wfUgxfQ=?= <liupengyjy@outlook.com>
To: Yiannis Yiakoumis <yiannis@selfienetworks.com>, Christian Huitema <huitema@huitema.net>
CC: "network-tokens@ietf.org" <network-tokens@ietf.org>, =?gb2312?B?styzqQ==?= <caoc15@chinaunicom.cn>, "zhangs366@chinaunicom.cn" <zhangs366@chinaunicom.cn>, "architecture-discuss@iab.org" <architecture-discuss@iab.org>, apn <apn@ietf.org>, Lars Eggert <lars@eggert.org>, pengshuping <pengshuping@huawei.com>
Thread-Topic: [Apn] [Network-tokens] [arch-d] Questions for APN: Q#5
Thread-Index: AQHWlQY3DBAwyN0ASEatZKDCXVHqkamAY2pW
Date: Wed, 30 Sep 2020 01:14:03 +0000
Message-ID: <PU1PR06MB2215E8906E9425F34D1BE7E3DA330@PU1PR06MB2215.apcprd06.prod.outlook.com>
References: <2020092211271508522412@chinaunicom.cn> <4FEADB2A-A062-44B4-8D36-3651EBDD1ACD@eggert.org> <a8542256-b0e7-f6d7-abb1-e2f379215849@huitema.net>, <kfirxvib.fe0473da-51f1-4bd7-91fe-290064021626@we.are.superhuman.com>
In-Reply-To: <kfirxvib.fe0473da-51f1-4bd7-91fe-290064021626@we.are.superhuman.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:818819A8E98AA41F3D97A82002884EDBD15151BAFF1165FC69B4D987C80075D5; UpperCasedChecksum:02603F890B1F6DCA7BFFA318EE13433DFFA49F333783C75A1BA169BD1CDB33DA; SizeAsReceived:7444; Count:44
x-tmn: [JOYzLzx1+ITGe05Mh7fCutdBXKemZUhB9qo7KmUkn0s=]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: a601c63d-e375-4624-e855-08d864de1e9a
x-ms-traffictypediagnostic: SG2APC01HT046:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: UpgbO0T/C3fCTLyZzIjevdbHM92BIBR/S8i9mie2nLPA8a8vsdr1kFKwjDyvbokgBpkCZtu15+aSBdXlYchjFw5cEHSfVuVsO/rqoLMdKlobOf8qMP+3qklZqbV5QfTOH50Zc8emfqGHQT14oUGQNj/NzLO8B5PI2h1kTaYzDWbK48krp/szkt68p8XlUb8RUd0iq8cdFbblqtpkP5gjrldawt4c3/B3WOwdxe40DjpNRu1+QGwuBgzVdt7fG9wr
x-ms-exchange-antispam-messagedata: xBUn6qHwo0V877c54QHAPbKW4lhvHsQeqwKHBscBkb6jWig498XJpadYprF9sQMkKy1pgufIxktbrNiU1Z9OnJqrG0+iijGV7W0ga+oZR6hFpQ3zezMNMp+Dl3qXb8n6P1kWoxB0djFvgAM5+53yiw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_PU1PR06MB2215E8906E9425F34D1BE7E3DA330PU1PR06MB2215apcp_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: SG2APC01FT017.eop-APC01.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: a601c63d-e375-4624-e855-08d864de1e9a
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2020 01:14:03.1151 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT046
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/UR65GjxSZrrla_CcWeY0H0dWPVA>
Subject: [Apn] =?gb2312?b?u9i4tDogIFtOZXR3b3JrLXRva2Vuc10gIFthcmNoLWRd?= =?gb2312?b?IFF1ZXN0aW9ucyBmb3IgQVBOOiBRIzU=?=
X-BeenThere: apn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Application-aware Networking <apn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apn>, <mailto:apn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apn/>
List-Post: <mailto:apn@ietf.org>
List-Help: <mailto:apn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apn>, <mailto:apn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2020 01:14:15 -0000

Hi Yiannis,

I agree that offering low-latency SLA for 1% of the traffic is easier and cheaper than all internet traffic. It's better to guarantee the SLA of some critical traffic first. However, it should also strike a balance between benefits and costs.

Some new technologies such as network slice, APN may help to solve the problem and meet the demand of fine-grained traffic. Therefore, I think fine-grained traffic requirements are necessary, which can help to save network resources, and over configuration may waste network resources.

Regards,
Peng (China Mobile)


Peng Liu | 刘鹏
China Mobile | 移动研究院
mobile phone:13810146105
email:  liupengyjy@chinamobile.com/liupengyjy@outlook.com

________________________________
发件人: Apn <apn-bounces@ietf.org> 代表 Yiannis Yiakoumis <yiannis@selfienetworks.com>
发送时间: 2020年9月26日 7:22
收件人: Christian Huitema <huitema@huitema.net>
抄送: network-tokens@ietf.org <network-tokens@ietf.org>rg>; 曹畅 <caoc15@chinaunicom.cn>cn>; zhangs366@chinaunicom.cn <zhangs366@chinaunicom.cn>cn>; architecture-discuss@iab.org <architecture-discuss@iab.org>rg>; apn <apn@ietf.org>rg>; Lars Eggert <lars@eggert.org>rg>; pengshuping <pengshuping@huawei.com>
主题: Re: [Apn] [Network-tokens] [arch-d] Questions for APN: Q#5


late in the discussion, but wanted to share some thoughts:

One of the first successful proof-points for SDN was Google claiming<https://cs144.github.io/handouts/cs144_mogul_2019_nov.pdf> that they moved their WAN utilization to ~100%, instead of over-provisioning. It saved them lots of money. Two of the design principles that led them there were
i) moving from "all packets are equally important" to "allocate resources based on application-level priorities" and
ii) moving from "TCP flows regulated by "fair share" mechanisms" to "measure demands, and shape flows at the endpoints".

I can imagine offering low-latency SLA for 1% of the traffic (say video calls), is much cheaper and easier than doing this for all Internet traffic (with the cost varying whether you are in Europe/US or an emerging market, rural or urban, a WISP, a low-orbit satellite network, etc). Could anyone from operator-land comment on the economics of oversubscription/overprovision/SLAs in the mobile world?

(btw: we already have SLAs today --- VoLTE is IP traffic routed through dedicated radio and wired resources and has materially better network quality and reliability than plain VoIP, and when you sign-up for a broadband connection you can get 10Mbps/100Mbps/1Gbps etc).

If over-provisioning wins (in 10 years) it will likely be the outcome of the network community's  failure to find a good solution for traffic differentiation, rather than a verdict that these use cases were not important enough.

FWIW: there are many issues to debate around fine-grained traffic differentiation beyond overprovisioning (like security, scalability, privacy, net neutrality), and there are different approaches one could take (APN and network tokens have different design principles and priorities on these trade-offs).

Best,
Yiannis









=====================
Yiannis Yiakoumis
Co-Founder & CEO
https://selfienetworks.com | +1-650-644-7857


On Tue, Sep 22, 2020 at 8:29 AM, Christian Huitema <huitema@huitema.net<mailto:huitema@huitema.net>> wrote:

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

Hi,

On 2020-9-22, at 9:02, zhangs366@chinaunicom.cn<mailto: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

--
Network-tokens mailing list
Network-tokens@ietf.org<mailto:Network-tokens@ietf.org>
https://www.ietf.org/mailman/listinfo/network-tokens