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

"Sørensen, Frode" <frode.sorensen@Nkom.no> Thu, 01 October 2020 09:23 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 53A3C3A0EE8; Thu, 1 Oct 2020 02:23:54 -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 ySY_mGBxQ8Dk; Thu, 1 Oct 2020 02:23:51 -0700 (PDT)
Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.116]) (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 D5CDE3A0EEC; Thu, 1 Oct 2020 02:23:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nkom.no; s=s1; t=1601544228; i=@nkom.no; bh=Ymy4GIRvxnFnnNpaKIx/0gAQq0+KO0pT+xAwWiWlCwQ=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=Uo8sdbuxvKrwfhgCc/1Slj1ZgtjCRLqTFjBTf/EEpkd7DwL7yxLcgJEJE53jshmrm rHjme7jLRhxfvqW5exfxKqbX0Jli++GZvzWlIr1I+74iL/5ACWRPL5Sc7XToSmpclH fbyQLd1+3KlXUcKQ7YdgyRFrz2LHaFrBeBPGJ+/GjXY0fxptvo3HlzWvq3B3OUmFEw R29M+JbRO/a7x/tr7eVcqLUPDiXJt4Gy+09aAIYhvEFPzvaBOxn1DircWWmPDXqw9e JupQB5v8U/4BiSJr4zA55bzhVF/84E3g3Q11mw2qz/ZRSZgz1L+KKdurleavEVB1ts vV8Mnr2dGnSdg==
Received: from [100.113.5.174] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-5.bemta.az-b.eu-central-1.aws.symcld.net id 95/9F-08547-E10A57F5; Thu, 01 Oct 2020 09:23:42 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFKsWRWlGSWpSXmKPExsWS+5KNV1d2QWm 8wcWlRhZfZ+VYnJo3jcVi0s4+NovGBQ2MFq9O7mR3YPVoOfKW1ePW1ZfMHkuW/GTymPV4InsA SxRrZl5SfkUCa8anO2+ZCy52MVasP7CNtYHxbgdjFyMnh5DAY0aJI91hXYxcQPZMRom/y2aDJ dgEnCUWfl/PDJIQEehnlPi48TIrSIJZoFziw4SJYEXCAgYSk+fNYQKxRQQMJebtPcMIYTtJ/F z/jA3EZhFQkbjX2QAW5xUwk1j7/gUTxLb9jBLd17YygyQ4BTwlNs6bBdTAwcEoICsxt4kXYpe 4xIyjd1hAbAkBAYkle84zQ9iiEi8f/2OFsGUlXv9qYoaoj5VYt7CFDWKXoMTJmU9YJjAKz0Iy ahaSsllIymYBbWYW0JRYv0sfokRRYkr3Q3YIW0Oidc5cdmTxBYzsqxgtk4oy0zNKchMzc3QND Qx0DQ2NdU10DY0N9BKrdJP0Ukt1k1PzSooSgbJ6ieXFesWVuck5KXp5qSWbGIERm1LI0rSD8f erD3qHGCU5mJREeTdPKY0X4kvKT6nMSCzOiC8qzUktPsQow8GhJMH7bR5QTrAoNT21Ii0zB5g 8YNISHDxKIrxHQdK8xQWJucWZ6RCpU4zeHAePzlvEzNHwF0SeXLUESH4Ek9/B5JG5SxcxC7Hk 5eelSonzGoGMEAAZkVGaB7cAlgQvMcpKCfMyMjAwCPEUpBblZpagyr9iFOdgVBLmnQsyhSczr wTujldAJzIBnVh1sQTkxJJEhJRUA1NhyUpRi1mb+VbGX9jJuckzo8S+XYgvuJb1+7ubp5lZu3 4usJxc9S/4mOUJNUXxhUVnejv/XL4wIcA/5yZn4+a5Jj3cPIn/2bZLKDCKcJz6uS+HuXmi5/W cVKEfNglMug0ufqeLym9rzY07sLqSwZTbyCDdv2TSxCBPhRI2Ztsl+5bNffHaa+mkcMaFFe9l bd8lFB/Tyvk1M2hVlAaj98/L6q0SHh/WlCe379/9b16IXn3J5/NRc6okNHa2fVN6VblFgeGrb 0Pr2bBcK9UTG/l/zgjX0NMyi7qWIpBkuiRGkKPHsXJdaWWh3zSXPUXtbUrPOUz/3D0ToHWZ4Z PdNanFc1ZydL7WzikR852vxFKckWioxVxUnAgAcneijf0DAAA=
X-Env-Sender: frode.sorensen@Nkom.no
X-Msg-Ref: server-21.tower-244.messagelabs.com!1601544220!1745847!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 31677 invoked from network); 1 Oct 2020 09:23:41 -0000
Received: from unknown (HELO smtp.nkom.no) (109.233.6.13) by server-21.tower-244.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 1 Oct 2020 09:23:41 -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 11:23:40 +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 11:23:40 +0200
From: =?utf-8?B?U8O4cmVuc2VuLCBGcm9kZQ==?= <frode.sorensen@Nkom.no>
To: Vittorio Bertola <vittorio.bertola@open-xchange.com>, "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>, "apn@ietf.org" <apn@ietf.org>
CC: "architecture-discuss@iab.org" <architecture-discuss@iab.org>, "network-tokens@ietf.org" <network-tokens@ietf.org>
Thread-Topic: [arch-d] Question List for APN: Q#8
Thread-Index: AdaV+p6hlEeaFy+VRQKsQQJkF8vE1wBxwDzQ///wxgD//8wr4A==
Date: Thu, 1 Oct 2020 09:23:40 +0000
Message-ID: <74f37c26111d41d09e3f05235885d3ce@Nkom.no>
References: <4278D47A901B3041A737953BAA078ADE19435D07@dggeml512-mbx.china.huawei.com> <0640dcf0b60249b1aac6527be43b1927@Nkom.no> <520064543.3360.1601540022746@appsuite-gw1.open-xchange.com>
In-Reply-To: <520064543.3360.1601540022746@appsuite-gw1.open-xchange.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_74f37c26111d41d09e3f05235885d3ceNkomno_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/94TNtpYECTmtS341WtySinoSGyI>
Subject: Re: [Apn] [arch-d] 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 09:23:54 -0000

Thanks Vittorio,

That’s correct, if one does a full discussion of the European net neutrality regulation, there are two parallel ways of differentiating QoS for the internet access service: “level of QoS” under Article 3(2) and “categories of traffic” under Article 3(3), as elaborated in paragraphs 34b-34d in BEREC Open Internet guidelines.

However, in my former email, I wanted to share some general thoughts about the architecture that is discussed in the APN mailing list, and that under the net neutrality considerations, when discussing the concept of application-agnosticism, one should also take into account user-control.

Regarding the “categories of traffic” that you describe, it is still a QoS-oriented approach and not a purely application-oriented approach, since a “category of traffic” is based on the QoS requirements, which means any application with similar QoS requirements would have to be treated the same way, not limited to video streaming.

I don’t suggest to have the full solution, of course, and I do not intend to make a long discussion about this topic. I just think one should realize that it is a complex question, due to different understandings of the principle of net neutrality, as well as due to different jurisdictions.

Best,
Frode


Fra: Vittorio Bertola <vittorio.bertola@open-xchange.com>
Sendt: torsdag 1. oktober 2020 10:14
Til: Sørensen, Frode <frode.sorensen@Nkom.no>no>; Pengshuping (Peng Shuping) <pengshuping@huawei.com>om>; apn@ietf.org
Kopi: architecture-discuss@iab.org; network-tokens@ietf.org
Emne: Re: [arch-d] Question List for APN: Q#8


Il 01/10/2020 09:16 Sørensen, Frode <frode.sorensen@nkom.no<mailto:frode.sorensen@nkom.no>> ha scritto:

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.
ISPs can also differentiate QoS on their own, as long as this is done "only on the basis of objectively different technical quality of service requirements (for example, in terms of latency, jitter, packet loss, and bandwidth) of the specific categories of traffic, and not on the basis of commercial considerations" (Recital 9 of the regulation). If an ISP wants to prioritize video streaming over other traffic they can do so, as long as they do so for all video streaming providers in the same way and they don't get paid for this.

Moreover, these European guidelines are then applied at the national level, so there are considerable differences across countries; and several ISPs just pretend they don't exist, e.g. with regard to "zero rating" offers.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com<mailto:vittorio.bertola@open-xchange.com>
Office @ Via Treviso 12, 10144 Torino, Italy