Re: [Apn] Question List for APN: Q#8

"Sørensen, Frode" <frode.sorensen@Nkom.no> Thu, 01 October 2020 07:17 UTC

Return-Path: <frode.sorensen@Nkom.no>
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 277063A0DCF; Thu, 1 Oct 2020 00:17:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nkom.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 t5lW7awooZZo; Thu, 1 Oct 2020 00:17:05 -0700 (PDT)
Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.65]) (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 79B9E3A0D87; Thu, 1 Oct 2020 00:16:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nkom.no; s=s1; t=1601536609; i=@nkom.no; bh=yiD458EF5JJ5v0pjfLTVGr+8LO4cJLpULMQpsrPpekc=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=eSfda+Jsg31F+/gHDfzsipqNo0AS4IjcdATGBrupzEm4C+Nsyz82zA/vplyDYR6xM JZ5kFV6wwO5SN8TrV5a05mIzls9eJ5J+HkpsEWg7np5l1Us0RjK/MGhU5bsKG2BAV1 tLVRV8uo68V7HPJQG18pjuNNmGAso3ty7Zb3HFg+cN49Pk5XMhUxagMN24FeXld6Es 8tjDw5X6zlY1VutS7PE2Ov/E7RuNxhB/q3QpwDf6OFSpiDRK/5ebsVhh/E9ARqWIv6 ZmIfvtZmsJGCv24vXXoxX7J3qyVx8zfYhI8wbSSjLEZxJ0cRcPjK1bAwBrGhANM3Me 31g4FfxHHC2tA==
Received: from [100.112.198.108] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-b.eu-west-1.aws.symcld.net id 5F/89-01492-162857F5; Thu, 01 Oct 2020 07:16:49 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNKsWRWlGSWpSXmKPExsWS+5KNVzehqTT e4Mk8bYuvs3IsTs2bxmIxaWcfm0XjggZGBxaPliNvWT1uXX3J7LFkyU+mAOYo1sy8pPyKBNaM r7cesBe8OsZUcfZjO3MD495DTF2MXBxCAo8ZJfaf38sM4cxklNi56DV7FyMnB5uAs8TC7+uZQ WwRgUiJLU1HwOLMAuUSJ5esZgGxhQXUJab+6mCEqNGQ+HxyLxOEbSQxd/0BVhCbRUBFYsGk+U BzODh4BcwkbnUZgJhCAqESey9bg1RwCoRJPPgOMpGDg1FAVmJuEy/EInGJGUfvgC2SEBCQWLL nPDOELSrx8vE/VghbVuL1ryZmiPpYiUd7PoDV8woISpyc+YRlAqPwLCSjZiEpm4WkbBbQZmYB TYn1u/QhShQlpnQ/ZIewNSRa58xlRxZfwMi+itE8qSgzPaMkNzEzR9fQwEDX0NBI19DSUtfQQ i+xSjdJL7VUtzy1uETXUC+xvFivuDI3OSdFLy+1ZBMjMCZTCo4L7WB88/qD3iFGSQ4mJVFen9 jSeCG+pPyUyozE4oz4otKc1OJDjDIcHEoSvCcqgXKCRanpqRVpmTnA9ACTluDgURLhfVcPlOY tLkjMLc5Mh0idYvTmOHh03iJmjoa/IPLjqiVA8juY3Dx3KZA8AiKFWPLy81KlxHnTGoBGCICM yCjNg1sAS3OXGGWlhHkZGRgYhHgKUotyM0tQ5V8xinMwKgnzvgeZwpOZVwJ3xyugE5mATqy6W AJyYkkiQkqqgenGrMmW6gIrTtZuuv6xRM2K+yqLts2SKO/kJ7LJaz8ytFbfjMzsv6ywScO2YW LstH0XfL9FzxJROdm5+fn7tEDJy6f/Ljx4a9E7s+UPb3unXdl5P3XSoiTm3Chdm29RbMFrDT2 mHHkU3xrX0lvzt1FIKGuN1cQi94e2S+fI8ksnZ/m85Wt1LvJYt9F1Z9GDpryJOn/fm62ezvdw y6zs3omTk9eKsTSysL5nf3NSqsqLPXTJg6fN8zbIrb14+c9d4cPWWVuXfjUsEyg5mfn6B9OCH m1P5qtLp0z61ryB9cel/5L6Tv+FxRqv/3vpqHjCa+99Rda0LeJa/0oP79776CuvjWP57MXvYm ef95+a8Oa8EktxRqKhFnNRcSIAi1knI+4DAAA=
X-Env-Sender: frode.sorensen@Nkom.no
X-Msg-Ref: server-29.tower-284.messagelabs.com!1601536607!1723949!1
X-Originating-IP: [109.233.6.13]
X-SYMC-ESS-Client-Auth: outbound-route-from=pass
X-StarScan-Received:
X-StarScan-Version: 9.60.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9814 invoked from network); 1 Oct 2020 07:16:48 -0000
Received: from unknown (HELO smtp.nkom.no) (109.233.6.13) by server-29.tower-284.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 1 Oct 2020 07:16:48 -0000
Received: from exmbx2016.npta.no (192.168.231.97) by exmbx2016.npta.no (192.168.231.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Thu, 1 Oct 2020 09:16:47 +0200
Received: from exmbx2016.npta.no ([192.168.231.97]) by exmbx2016.npta.no ([192.168.231.97]) with mapi id 15.01.1979.006; Thu, 1 Oct 2020 09:16:47 +0200
From: =?utf-8?B?U8O4cmVuc2VuLCBGcm9kZQ==?= <frode.sorensen@Nkom.no>
To: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>, "apn@ietf.org" <apn@ietf.org>
CC: "network-tokens@ietf.org" <network-tokens@ietf.org>, "architecture-discuss@iab.org" <architecture-discuss@iab.org>
Thread-Topic: Question List for APN: Q#8
Thread-Index: AdaV+p6hlEeaFy+VRQKsQQJkF8vE1wBxwDzQ
Date: Thu, 1 Oct 2020 07:16:47 +0000
Message-ID: <0640dcf0b60249b1aac6527be43b1927@Nkom.no>
References: <4278D47A901B3041A737953BAA078ADE19435D07@dggeml512-mbx.china.huawei.com>
In-Reply-To: <4278D47A901B3041A737953BAA078ADE19435D07@dggeml512-mbx.china.huawei.com>
Accept-Language: nb-NO, en-US
Content-Language: nb-NO
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.9.1.49]
Content-Type: multipart/alternative; boundary="_000_0640dcf0b60249b1aac6527be43b1927Nkomno_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/-m7f1ljQXbUHHhER2JV7IT56GqU>
Subject: Re: [Apn] Question List for APN: Q#8
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: Thu, 01 Oct 2020 07:17:14 -0000

Dear Shuping, dear all,

Many thanks for elaborating the different questions regarding APN. I would like to share some food for thought regarding question 8.

Net neutrality comes in different flavours, and while some understands net neutrality as all traffic being treated equally within one single traffic class (usually labelled “best effort”), it is also a reasonable approach to consider a scenario with multiple traffic classes with different performance levels under certain conditions.

This approach does not suggest that  multiple traffic classes necessarily should be provided over the internet. The approach is rather an explanation that net neutrality should not stifle technology development, and could under certain conditions be compatible with multiple QoS levels in case that should be provided by some ISPs.

E.g. regarding the European net neutrality regulation it is commonly understood that multiple traffic classes/QoS classes with different performance levels could be accepted – as long as the traffic classes are application-agnostic, which means that any application may populate any traffic class as selected by the end-user.

In this regard it is essential that the end-user controls the selection of QoS level, and that this is not controlled by the ISP, nor indirectly controlled by the application provider. The ISP offers the different QoS levels, and the end-user requests the QoS level for the application’s traffic over the internet access service.

In this scenario the ISP does not need to know which application that runs in the endpoint, only which QoS level the application’s traffic runs on. Such an architecture would not be application-aware, it would be application-agnostic. One could however say it would be QoS-aware.

Furthermore, the European net neutrality regulation concerns the open internet access service, not the closed internal services running on the ISPs infrastructure. The latter is often referred to as “specialised services” were the ISP may run specific applications, as opposed to the general internet access service over which any application must be able to run.

And there are limitations regarding the provision of specialised services to avoid circumvention of the regulation. Specialised services are only allowed under two main conditions; (a) that the services have quality requirements which cannot be provided via the internet access service, and (b) that the network capacity is sufficient to provide them in addition to any internet access services provided.

Best,
Frode


Fra: Network-tokens <network-tokens-bounces@ietf.org> På vegne av Pengshuping (Peng Shuping)
Sendt: tirsdag 29. september 2020 02:54
Til: apn@ietf.org
Kopi: network-tokens@ietf.org; architecture-discuss@iab.org
Emne: [Network-tokens] Question List for APN: Q#8

Dear all,

#8. Does APN violate network neutrality?

Answers: It’s important to realize that under the open Internet regulations there is still the possibility to do the differentiation. An easy example to understand is that in the FBB scenario, you can have different speeds on the access.

Moreover, any application can run on any QoS level. It is not necessary that all applications have to run on the same level, but any application can choose which QoS level it will run on, in the case where you have multiple QoS levels available.

APN offers application-aware network services open to all the applications, and it lets applications to decide themselves whether to go on board or not and which SLA levels they would like their traffic to be entitled.

Best regards,
Shuping


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