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

Vittorio Bertola <vittorio.bertola@open-xchange.com> Thu, 01 October 2020 08:13 UTC

Return-Path: <vittorio.bertola@open-xchange.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 2FB4E3A0E28; Thu, 1 Oct 2020 01:13:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=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=open-xchange.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 gftH8FzUfi6Q; Thu, 1 Oct 2020 01:13:46 -0700 (PDT)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 478023A0E26; Thu, 1 Oct 2020 01:13:45 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx4.open-xchange.com (Postfix) with ESMTPS id DEA476A317; Thu, 1 Oct 2020 10:13:42 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1601540022; bh=hALy52NA76Sn39NauHz+jazQMKhsTvxre6Ucvpg6HvA=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=oL433ZCpJvg/cDWboMkwZxxQwSnArgP/tCoebnUhudZJfKPRY0/zgAT5PYRVZYWUH r/+HdEzaCkZr/Z8+lSuAcjtR48w9aW4WxGKisXsszS+6nfMiHUOFVMuYjcX5IiBBDT vTz5hhRKWMl5NqxNEKE2kB4KhA7yKJP29QVR1SQUBbW6il8mzUrQhtMIkepvDgOuZB 5Bgpm3Flj/k7P2e3u8au7gl6lsXwVvzDpEHB/JIwlmc83XJNHfmWVsKi/7OXLsN98q 87DUR5VC0XU/EZ1gPw3B8WQ0nLCaxISdIquqt1ccGLgv5wPwjZmtEOqtEG3OdxgRtG dYln/Krf6SCgw==
Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id CEEFB3C0243; Thu, 1 Oct 2020 10:13:42 +0200 (CEST)
Date: Thu, 1 Oct 2020 10:13:42 +0200 (CEST)
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: =?UTF-8?Q?S=C3=B8rensen=2C_Frode?= <frode.sorensen@Nkom.no>, "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>
Message-ID: <520064543.3360.1601540022746@appsuite-gw1.open-xchange.com>
In-Reply-To: <0640dcf0b60249b1aac6527be43b1927@Nkom.no>
References: <4278D47A901B3041A737953BAA078ADE19435D07@dggeml512-mbx.china.huawei.com> <0640dcf0b60249b1aac6527be43b1927@Nkom.no>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_3358_2096005527.1601540022732"
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.4-Rev10
X-Originating-Client: open-xchange-appsuite
Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/deOGadgiIB8svNQ4H-oF1NvQHc0>
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 08:13:48 -0000

>     Il 01/10/2020 09:16 Sørensen, Frode <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