Re: [Int-area] Per-Application Networking Considerations
"Luis M. Contreras" <contreras.ietf@gmail.com> Thu, 18 February 2021 09:45 UTC
Return-Path: <contreras.ietf@gmail.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F9C3A0E9F for <int-area@ietfa.amsl.com>; Thu, 18 Feb 2021 01:45:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, 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=gmail.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 HXVfBmLc7ViH for <int-area@ietfa.amsl.com>; Thu, 18 Feb 2021 01:45:49 -0800 (PST)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E6203A0EA1 for <int-area@ietf.org>; Thu, 18 Feb 2021 01:45:49 -0800 (PST)
Received: by mail-qk1-x736.google.com with SMTP id 81so1484700qkf.4 for <int-area@ietf.org>; Thu, 18 Feb 2021 01:45:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GLRWMe0+WvBF2dqKS2G3KrNkE4FC3QhjeVcSYPDE3rg=; b=UPm+W/apUKIWcOM5KDPbS2CrQ9JWW0jIs9VhSlFZEeH7jpeIjkSfr1grHH9m7zEa/v cLPHQUNxlbozO+6tP9SvGujm933QeJo/RCYmz3y+bNmQVbSbFxmWNFa2RcyXetn9Gc4J G9+AlADCKu/H+KUG6aT4UIVrzXxV/LB0zjihQez6SS/HCGE77C4y79TajCOCxXiYgU84 c38KkueQ5ski926QCosvLTNlrTre+J/H1yWuc0gYy1LYvbpQ9ZCVuZnumwfdTJWJRVtH OAwaz0qCjvAUs9/Fn+z3V8kX/xUymLkS5dbeJTskK2L2mwtfyeacFW/cClaYwUdZjGad CU8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GLRWMe0+WvBF2dqKS2G3KrNkE4FC3QhjeVcSYPDE3rg=; b=mqr92v1tAHB9d9lImxUXALnISpFfZt9AaTaCEHO1r1rahjuhajViWe8YRSMHCaTR+8 H83W3cMLPSH5GmBhkRN5pwuguRRTIqCaJrPp/IEokj6MEEbuz5oFdJ3JUL9+gZLW5A2z tIBvjSVcY3/6Vt3DuFBum0niZ7cHA3TWAG///+uqFQ7lWbXr7FpeBMf8nfoY0J0gCDby RmMxJLx9Su22YjIjIiZTjLTiAaBlUY72DUxtYkaHdRoxfMfgDTAtcXdg8CTCmJVt2riJ STaK/5QExjYslpBKLMfcby1iXNciV+onYl2EDIt0oNePFKAQcjY1ZxY44aJ0PbMifUto /k4g==
X-Gm-Message-State: AOAM533l7MaExvVSxZoHr3FxriPVFkhC+vIdo0+2FFNr4lFMt5oQJq70 RX966cEMUqHbu+GC0+KbyeG+AcjEY71f4y6xf0MC7iLJb4w=
X-Google-Smtp-Source: ABdhPJwUNC0XtEFGeDUOhlJirGHO4R2uJVwlxCSwxsJHxJwx0PfRv32BQbldDx/hjo3pgBSFChwW1U83dtwW/EF8UNs=
X-Received: by 2002:a37:804:: with SMTP id 4mr3364489qki.207.1613641548548; Thu, 18 Feb 2021 01:45:48 -0800 (PST)
MIME-Version: 1.0
References: <160549933225.16448.15210422391776585953@ietfa.amsl.com> <7CDDE2AD-62C9-4E0A-9D7E-4698CD8009E1@apple.com>
In-Reply-To: <7CDDE2AD-62C9-4E0A-9D7E-4698CD8009E1@apple.com>
From: "Luis M. Contreras" <contreras.ietf@gmail.com>
Date: Thu, 18 Feb 2021 10:45:37 +0100
Message-ID: <CAE4dcx=Ku5H_imJN4yYtQCy90=HoOn=VntgBt39m_LFW-m_eJg@mail.gmail.com>
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: "int-area@ietf.org" <int-area@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004bcce605bb993399"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/4GD36KlrTP3qEwfAMWwxGt8fY_A>
Subject: Re: [Int-area] Per-Application Networking Considerations
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Feb 2021 09:45:52 -0000
Hi all, I have gone through the document and I would like to share some comments on it. .- Introduction / regarding the examples provided: These cases could not have the same regulatory treatment. This is an important consideration because there could be limitations in some cases/situations. .- Specifically regarding the zero rating example: In my view this is more administrative than technical, in the sense that the networking behavior does not change. It is only a matter of OSS/BSS to account that traffic as chargeable or not. .- Introduction / “Thus, if an application is to receive different treatment, the host or the application itself should be involved in requesting specific network treatment”: This has different implications. For instance, if the application itself takes the decision without knowledge/approval of the user, it could impact / interfere in other applications in the same device / access line. How this potential problem can be controlled? .- Section 2 / in the 1st paragraph you provide the idea of applications requesting and obtaining particular treatment: (1) how do you foresee the application requesting differentiation?; and (2) how such differentiation is verified?. Probably good to dig into for the different mechanisms listed, but also for whatever new that could be defined from this effort. Additionally, the applications could have other mechanisms in place such as congestion control. Maybe necessary to differentiate effects from some mechanisms and the ohers (and/or to see how to gracefully coordinate them). .- Section 3 / “In a situation where the network operator has influence on the implementation of the user host”: To be fair, probably the same comment should be made with respect to the operating systems on the devices (for instance, with respect to congestion control mechanisms implemented). .- Section 3 / “… by ensuring that the mechanism used to communicate requests to the network only specifies traffic classes and not individual applications.”: This is important. The actual model, based on best effort and/or overprovisioning does not scale. Having view of traffic classes is great, but not all the applications can be high-priority. Somehow there should be some capacity (quota?) allocated per traffic class. But again it could be the case that such capacity is exhausted. What happens then? I mean, there are two points to discuss: (1) interchange information for assisting on stable situations, and (2) how to handle congestion because e.g. network failures, sudden demands, or even over-prioritization from the applications. .- Section 4 / reference to “appropriate policies” in the 1st paragraph: The policies are implemented based on identifiers, e.g. origin-destination, labels, etc. Now new kind of policies could be required based on the class of service (so the “identifier” would be now the class of service, not the application itself, due to privacy and other concerns described later). .- Section 4 / “… instead of the application originating the traffic” & “… specify general categories ”: The same should be required in the host or device. .- Section 5 / regarding categories of traffic that “… need to be sufficiently broad … ”: The broader, the less informative would be. The risk is to give room to (mis)interpretations. A proper balance of prescription and description is needed to ensure the expected behavior in the network. .- Section 6 / “if the host's user is informed that particular applications are seeking or designated for particular treatment and consents to it.”: This can only be done by the application. The operating system of the device does not necessarily knows what is the treatment required by a given application. Maybe would be necessary to distinguish what should/must/can be done by the application, the host/device, and the network .- Section 7 / “Any API should not involve revealing an application or user identity to the network via metadata without network authentication.”: This could be problematic for charging purposes in e.g. wholesale scenarios. .- Section 7 / “"this is my application identifier "”: however in the sentence before you refer to “my app” anyway. Thanks Luis El mar, 17 nov 2020 a las 5:22, Tommy Pauly (<tpauly= 40apple.com@dmarc.ietf.org>) escribió: > Hello INTAREA, > > We published a draft this week that we’d like to briefly introduce for > discussion within the intarea WG, draft-per-app-networking-considerations. > This is an informational document that discusses the implications of a > trend we’ve noticed towards putting more application identifiers or > per-application logic in the network layers. Many different proposals touch > on the idea of differentiating traffic based on application, but we believe > it would be useful to have a general statement about the privacy trade-offs > and design considerations in this space. Moreover, we think that a broad > technical group like intarea may be the right place to discuss and review > this work. > > > https://www.ietf.org/archive/id/draft-per-app-networking-considerations-00.html > > Your reviews and thoughts are appreciated! > > Best, > Tommy & Lorenzo > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **New Version Notification for > draft-per-app-networking-considerations-00.txt* > *Date: *November 15, 2020 at 8:02:12 PM PST > *To: *Lorenzo Colitti <lorenzo@google.com>, Tommy Pauly <tpauly@apple.com> > > > A new version of I-D, draft-per-app-networking-considerations-00.txt > has been successfully submitted by Tommy Pauly and posted to the > IETF repository. > > Name: draft-per-app-networking-considerations > Revision: 00 > Title: Per-Application Networking Considerations > Document date: 2020-11-15 > Group: Individual Submission > Pages: 7 > URL: > https://www.ietf.org/archive/id/draft-per-app-networking-considerations-00.txt > Status: > https://datatracker.ietf.org/doc/draft-per-app-networking-considerations/ > Html: > https://www.ietf.org/archive/id/draft-per-app-networking-considerations-00.html > Htmlized: > https://tools.ietf.org/html/draft-per-app-networking-considerations-00 > > > Abstract: > This document describes considerations for and implications of using > application identifiers as a method of differentiating traffic on > networks. Specifically, it discusses privacy considerations, > possible mitigations, and considerations for user experience and API > design. > > Discussion Venues > > This note is to be removed before publishing as an RFC. > > Source for this draft and an issue tracker can be found at > https://github.com/tfpauly/per-app-networking-considerations. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > -- ___________________________________________ Luis M. Contreras contreras.ietf@gmail.com luismiguel.contrerasmurillo@telefonica.com Global CTIO unit / Telefonica
- [Int-area] Per-Application Networking Considerati… Tommy Pauly
- Re: [Int-area] Per-Application Networking Conside… Luis M. Contreras
- Re: [Int-area] Per-Application Networking Conside… Toerless Eckert
- Re: [Int-area] Per-Application Networking Conside… Jiayihao