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

"zhangs366@chinaunicom.cn" <zhangs366@chinaunicom.cn> Tue, 22 September 2020 06:06 UTC

Return-Path: <zhangs366@chinaunicom.cn>
X-Original-To: apn@ietfa.amsl.com
Delivered-To: apn@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0AF513A13E8 for <apn@ietfa.amsl.com>; Mon, 21 Sep 2020 23:06:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 544I96V3QYME for <apn@ietfa.amsl.com>; Mon, 21 Sep 2020 23:06:05 -0700 (PDT)
Received: from sendg.mailex.chinaunicom.cn (sendg.mailex.chinaunicom.cn []) by ietfa.amsl.com (Postfix) with ESMTP id 5139C3A13E9 for <apn@ietf.org>; Mon, 21 Sep 2020 23:06:04 -0700 (PDT)
X-AuditID: 0a000f35-ac985a8000005a7f-93-5f69944ac2dd
Received: from M10-HQ-MLCEN02.cnc.intra (Unknown_Domain []) by sendg.mailex.chinaunicom.cn (Symantec Messaging Gateway) with SMTP id 8E.22.23167.A44996F5; Tue, 22 Sep 2020 14:06:02 +0800 (HKT)
Received: from M10-HQ-ML12.hq.cnc.intra ( by M10-HQ-MLCEN02.cnc.intra ( with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 22 Sep 2020 14:02:21 +0800
Received: from LAPTOP-9AHEORUQ ( by M10-HQ-ML12.hq.cnc.intra ( with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 22 Sep 2020 14:02:13 +0800
Date: Tue, 22 Sep 2020 14:02:15 +0800
From: "zhangs366@chinaunicom.cn" <zhangs366@chinaunicom.cn>
To: apn <apn@ietf.org>, huitema <huitema@huitema.net>, pengshuping <pengshuping@huawei.com>
CC: =?UTF-8?B?5pu555WF?= <caoc15@chinaunicom.cn>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 7, 174[cn]
MIME-Version: 1.0
Message-ID: <2020092211271508522412@chinaunicom.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart233387378542_=----"
X-Originating-IP: []
X-ClientProxiedBy: M10-HQ-MLF01.hq.cnc.intra ( To M10-HQ-ML12.hq.cnc.intra (
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsXC9fOKgq7XlMx4g6XXeSy+zsqxmNw4m92i cUEDowOzR8uRt6wet2acYvFYsuQnUwBzFJdNSmpOZllqkb5dAlfGm3exBddPMlc8f/SdrYHx 6xLmLkZODgkBE4kHf54wdTFycQgJnGeUmNfzkBXC2cEoMeX0VqjMOkaJ0xvbWUFaWARUJTZO WM8OYrMJWEucOrKXEcQWEYiV+PCoD6yGWcBA4uiSNSwgtrCAmcSWC9+ZINbxSsxof8oCYQtI 3NwygQ3CVpLY1dkNZvMKCEqcnPmEBcI2lrh48SnUzDCJyffXgNUIAd3wZ04z1EwFiV1/TgHd wAFkZ0m8uJoxgVFoFpJJs5B0zwKqYhbQlFi/Sx8irCgxpfshO4StIbHgzj5GCFtbYtnC18wL GNlWMUoG+7pbGFsY6Pob6yVnZOYlluZlJufn6iXnbWIExQoDv+kOxo+3PugdYmTiYDzEKMHB rCTCq2aUHi/Em5JYWZValB9fVJqTWnyIUZqDRUmc105hVZyQQHpiSWp2ampBahFMlomDU6qB KbT6xitLr0VbN/xSXb3PUvp4uOClOcK89q3B/9NXPv7ccY7xsQu7U/RLvo//lN7rr3afIfXH PCigvuO83mQRrWCLqedFvjZemfjhx88MfsH7V78sVespEflWH5vdlnx5YcZTFi8OxmxFHj79 y75pNxYc+t8jfzCw9Nzndx83zXlSdi2Q/wzjn79imq33xM5X235+EDHjXHjJ5LSfS3X83XM4 Gp5P8ksQZjg38ZCZ9oInTj2y+m3BPaKBfbNd0sM36SyeuL7YYkv51n2nH+j9jDvFs+idRtFX r1UMscscm4pnNZX7JjUfVIrnvH+wUmPidvsv0bVr875femNT5SNr9oA7P030UyiXhohr9aUZ SizFGYmGWsxFxYkA/P8rLQQDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/PDeLgNdBBq05Yi7byzXubQML9Bo>
Subject: [Apn] Fw: Re: [arch-d] Questions for APN: Q#5
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: Tue, 22 Sep 2020 06:06:08 -0000

Hi Christian,  Shuping,

  *   Thank you for your comments! Please find my supplementary content in line.

Best regards~
Zhang Shuai

From: Pengshuping (Peng Shuping)<mailto:pengshuping@huawei.com>
Date: 2020-09-22 09:36
To: Christian Huitema<mailto:huitema@huitema.net>; apn@ietf.org<mailto:apn@ietf.org>
CC: architecture-discuss@iab.org<mailto:architecture-discuss@iab.org>; network-tokens@ietf.org<mailto:network-tokens@ietf.org>
Subject: Re: [Apn] [arch-d] Questions for APN: Q#5
Hi Christian,

Thank you for your comments! Please find my responses in line.
Hope they also address the concerns of John and Joel.

From: Christian Huitema [mailto:huitema@huitema.net]
Sent: Monday, September 21, 2020 2:54 PM
To: Pengshuping (Peng Shuping) <pengshuping@huawei.com>om>; apn@ietf.org
Cc: network-tokens@ietf.org; architecture-discuss@iab.org
Subject: Re: [arch-d] Questions for APN: Q#5


I am reading your use cases, and my immediate reaction is that this developments should not be addressed solely in the routing or IP layers. You are proposing to enrich the network service proposed to transport and applications, which amounts to creating new APIs. Such works affects multiple layers, and should be coordinated between multiple layers.

[Shuping] The APN work to be focused on in the RTG Area is within a controlled limited network domain. To be more specific, when the information indicating application’s requirements is carried within the IP data packet header, APN aims to figure out how the network services can be provisioned according to the carried information, including traffic steering into and along an explicit traffic engineered network path as well as traffic monitoring, etc.. As to where the information is added, it is out of the working scope of the APN in the RTG Area.

Please refer to the first slide in this link which I have presented in APN side meeting @IETF108. It shows a clear scope of the APN work to be conducted in the RTG Area.


The presentation at the RTG WG @IETF108 can also be found here.


I also see that the description of application requirements is very thin. The drafts mention augmented reality and online games, and focus largely on latency requirements for these applications. The latency has two main components: delays in the wires, and queues in the routers. The APN draft for example mentions players of games using servers on another continent, and thus experiencing large latency. But that latency is largely due to the distance. That distance is not going to be magically reduced by smarter queue processing. The same is even more true for video conferencing or telepresence applications. I live near Seattle. If I want to talk to my mother in France, the bits have to be carried across America and the across the Atlantic ocean. No amount of smart routing will change that. Application developers are well aware of these issues, and have designed their applications in consequence.

[Shuping] Between A and B there are usually multiple paths and these paths can possess various characteristics, including delay and reliability, etc. The proper paths can then be selected according to the applications’ requirements and the traffic can be steered into the selected network path/tunnel/policy to guarantee their SLA requirements. To accelerate the latency-sensitive applications such as gaming, acceleration tunnels are usually built, especially for the oversea case because you can see the improvement more clearly. Please find more information in this draft https://tools.ietf.org/html/draft-zhang-apn-acceleration-usecase-00. Operators are actually building such acceleration tunnels themselves.

[Shuai] Indeed, based on our deployment experience, the dedicated game acceleration path is very helpful on improving the QoE of the involved gamers. We look for more collaborations to provide better services to our customers.

There is a lot of tension between Internet Architecture and the "application aware" proposal. The Internet was built on a fundamental decision to not be application aware. Instead, the routers carry packets of bits, independently of which application uses these bits. That way, new applications can constantly be invented, without requiring modifications in the network or permissions from the network operators. This has proven to be key for the development of the Internet. I don't think that we want to change that. Even if we did I don't think that the discussion should take place solely in some specialized routing working groups.

[Shuping] Again APN is aimed to work within a controlled and limited operators’ network domain not for Internet. Within this domain, network operators can provide network services (e.g. traffic steering and monitoring) according to the “application knowledge” carried in the data packets. This knowledge has already been used by most, if not all, operators since the introduction of traffic engineering mechanisms back in 90’s. APN is to automate these mechanisms, which will involve the work on the data plane encapsulations (i.e. IPv6, MPLS, VxLAN, etc.) and routing protocols extensions in the routing working groups.

Best regards,


-- Christian Huitema

On 9/20/2020 7:19 PM, Pengshuping (Peng Shuping) wrote:
Dear all,

#5. What are the valuable use cases/usage scenarios of APN?

Drafts have been posted on various use cases such as Game Accelerating, Edge computing, SD-WAN etc.

1)       https://tools.ietf.org/html/draft-li-apn-problem-statement-usecases-01
2)     https://tools.ietf.org/html/draft-liu-apn-edge-usecase-00
3)     https://tools.ietf.org/html/draft-zhang-apn-acceleration-usecase-00
4)     https://tools.ietf.org/html/draft-yang-apn-sd-wan-usecase-00

Use cases have also been presented and discussed during the APN side meeting@IETF108. Please find the slides.

There have been some discussions on these use cases in the APN mailing list as well. Please find the archives.

More interesting use cases are waiting to be explored. Please let us know if you have any other use cases. Thank you!

Best regards,

From: Lizhenbin
Sent: Monday, September 14, 2020 10:35 PM
To: apn@ietf.org<mailto:apn@ietf.org>
Cc: Pengshuping (Peng Shuping) <pengshuping@huawei.com><mailto:pengshuping@huawei.com>
Subject: Question List for APN

Hi Folks,
Thanks very much for your attention to APN work. After much preparation work, we summarized the key questions to be clarified for APN which also were always asked. In fact in the past discussion and the APN side meeting of IETF108, many of these questions were discussed and clarified. Here we propose these questions together for your convenience.

The questions to be clarified are as follows:
#1. Which layer is for APN to do the application-aware work?
#2. Does APN provide services within a limited-domain or Internet?
#3. Which area in IETF would the APN work fit better?
#4. What is the relationship between APN and other attempts in IETF’s history?
#5. What are the valuable use cases/usage scenarios of APN?
#6. Is the fine-granularity operations needed/desired in the network?
#7. Why not just use DSCP?
#8. Does APN violate network neutrality?
#9. Will APN raise security issues since application-aware information is carried in the APN packets?
#10. Will APN raise privacy issues since application-aware information is carried in the APN packets?

Shuping Peng will send the detailed answers for these questions in the mailing list in the following one or two weeks. The questions and answers may be not only be sent in the APN mailing list, but also be copied to the architecture discussion mailing list and the network token mailing list for more cross-area feedback if necessary.

If you have any comments on these questions and answers, we can go on to discuss through the mailing list.

Best Regards,
Zhenbin (Robin)

From: Apn [mailto:apn-bounces@ietf.org] On Behalf Of Lizhenbin
Sent: Tuesday, August 18, 2020 7:22 PM
To: apn@ietf.org<mailto:apn@ietf.org>
Subject: [Apn] Welcome to APN Mailing List

Hi Folks,

Welcome to join the APN mailing list. We are glad to have more discussion through the mailing list as the follow-up of the IETF108 APN side meeting.
In the process of APN work, many historic work items such as SPUD, PLUS, etc. have been proposed. It has been tried to be clarified that APN focuses
on the network layer and limited domains. Concerns on the security and privacy issues also have been proposed many times about the work. It also
has been tried to be clarified that in the trustable limited domains the security and privacy issues can be under control. These are the reasons why APN
work is based in the RTG area instead of ART/TSV areas.

But because of too much historic work to be clarified and its proposing the cross-area discussion for which RTG/APP/TSV/INT/SEC/IRTF are involved, it is
necessary to have more discussion to clarify the scope and work items for APN. We wish the mailing list would be helpful to the work and promoting the
cross-area communication to understand each other better.

You can get yourself up to speed with our discussions so far by seeing the materials at < https://github.com/APN-Community/>gt;, especially the materials
From the virtual IETF 108  APN side meeting at < https://github.com/APN-Community/IETF108-Side-Meeting-APN>gt;. This link also gives you pointers to
some of the relevant Internet-Drafts.

Over the next few weeks we will try to guide discussion by introducing some questions for debate. But please also raise your own issues and concerns
and contribute to the exchanges on this list.

Look forwarding to have more fun discussion in the mailing list.

Best Regards,
Dan & Zhenbin


Architecture-discuss mailing list



如果您错误接收了该邮件,请通过电子邮件立即通知我们。请回复邮件到 hqs-spmc@chinaunicom.cn,即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to hqs-spmc@chinaunicom.cn ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.