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

"Pengshuping (Peng Shuping)" <> Tue, 22 September 2020 01:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10E553A0C4E for <>; Mon, 21 Sep 2020 18:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qU5wrh27E12b for <>; Mon, 21 Sep 2020 18:36:38 -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 2A8553A102E for <>; Mon, 21 Sep 2020 18:36:38 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id B773840CBEE41A4CBC41; Tue, 22 Sep 2020 09:36:31 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 22 Sep 2020 09:36:31 +0800
Received: from ([]) by ([]) with mapi id 14.03.0487.000; Tue, 22 Sep 2020 09:36:26 +0800
From: "Pengshuping (Peng Shuping)" <>
To: Christian Huitema <>, "" <>
CC: "" <>, "" <>
Thread-Topic: [arch-d] Questions for APN: Q#5
Thread-Index: AdaPumjAL0AfHwz2R52a1JwnRfIt6f//zR6A//57+IA=
Date: Tue, 22 Sep 2020 01:36:26 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4278D47A901B3041A737953BAA078ADE193E9F1ADGGEML532MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [arch-d] Questions for APN: Q#5
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: Tue, 22 Sep 2020 01:36:41 -0000

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 []
Sent: Monday, September 21, 2020 2:54 PM
To: Pengshuping (Peng Shuping) <>om>;
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 Operators are actually building such acceleration tunnels themselves.

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.


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
Cc: Pengshuping (Peng Shuping) <><>
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 [] On Behalf Of Lizhenbin
Sent: Tuesday, August 18, 2020 7:22 PM
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 <>gt;, especially the materials
From the virtual IETF 108  APN side meeting at <>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<>