Many thanks for an interesting draft and follow-up discussion on the list. A couple of supplementary thoughts from my side:
1) Application-based vs. user-based (or user-controlled) I think the draft could benefit from distinguishing between these two terms. The intro section mentions that “use cases where network operators, or applications, might desire for application traffic to be treated differently by the network”. Applications don’t have desires per se, while such desires come from some person, which could be the end-user, the application developer or network operator (if the latter has influence on the implementation of the user host, as the draft explains). The discussion thread on the list is touching the distinction. The user-based approach, signalled from the application to the network, mentioned by Yiannis, is interesting. In my understanding, the user could either request specific QoS treatment per session, or the user could configure this in the application via some user-interface. In both cases, this selection would be user-controlled, as opposed to operator-controlled. 2) Application categories vs. traffic categories The draft uses the terms “categories” and “classes” several times, which is an essential part of the discussion. I think the text could benefit from distinguishing more clearly between whether the categories/classes are “application categories” or “traffic categories”. The distinction may be subtle, and an example might illustrate the point: It is essential whether the network operator is classifying the traffic (e.g. by using DPI) based on application characteristics – or the end-user is selecting any application for special treatment (whereby the corresponding traffic is marked). The former case could be understood as an application category (and would be application-specific), and the latter could be understood as a traffic category (and would be application-agnostic, since any application may belong to the traffic category). 3) Regarding application categories Application categories are easy to relate to when discussing principles, but are not that easy when it comes to practical implementation. This is already covered to some extent by the discussion thread below, regarding zero-rating in particular. A major challenge is how to define the categories and how to decide which category specific applications belong to. One might of course establish procedures regarding such questions (as elaborated in the email thread), but it is likely that there will anyway be borderline cases, and conflicts may occur. To that end, traffic categories which are user-controlled and application-agnostic will be significantly different from application categories. Therefore, I think it would be valuable to further clarify the description regarding categorization in the draft. In my view, the draft describes an important topic, providing an implementation-independent overview of per-application networking, and discussing principal implications of such networking, which could be useful when considering different concrete implementations. I support continued development of the draft. Best, Frode ---------- Original Message ---------- From: Yiannis Yiakoumis <[email protected]<mailto:[email protected]>> Date: Thursday, June 17 2021 at 2:30 AM PDT Subject: Re: [Int-area] Comments on "per-app networking considerations" draft To: Lorenzo Colitti <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> On Tue, Jun 15, 2021 at 7:46 AM, Lorenzo Colitti <[email protected]<mailto:[email protected]>> wrote: On Tue, Jun 15, 2021 at 8:49 PM Yiannis Yiakoumis <[email protected]<mailto:[email protected]>> wrote: The big challenge with category-based differentiation is definition and enforcement of categorization. There is significant experience from Europe's zero-rating implementation, where regulators approved category-based zero-rating, and more than 30 network operators implemented it (based on DPI). In my experience, a decentralized approach (where each operator defines categories themselves, and enforces them through a heavyweight implementation process like DPI) doesn't work well, especially for smaller apps that don't have the resources to work with operators, and end-up being in a bigger disadvantage when their large competitors participate in such programs. As a reference point, we've seen 10% success rate and 8-months average integration time for an eligible music streaming company to participate in Europe's music zero-rating programs, when the most popular apps were available in most of them from the very beginning (more details on this here). That's a good point. I think it would definitely be useful to note in the draft that categories can sometimes be difficult to define, coordinate, and enforce. A good step forward would be to define a metric around time/cost to participate, and what advances would help reduce this. Tommy/Lorenzo --- what are your thoughts on category definitions? Have you seen any other paradigm we could follow/re-use in terms of category definitions and eligibility? Could Apple/Play stores playing a role in such an effort? I think categories/manual review/abuse reporting in app stores could play a role here, as could on-device analysis of app behaviour and traffic patterns. That said - the intent of this draft is not to stray too far into solution space; the primary intent is to call attention to the implications of per-app networking, and I think that's valuable in itself. The idea is that while designing solutions may be a lot more work, at least having a document that says, "here are the implications" will help provide food for thought for folks considering implementing these practices. Agreed that this document shouldn't go into solution space. This doesn't prevent us from having some high-level metrics/goals that would have directly impact the projected implications, and help evaluate whether a solution is good or not down the road. I think the document would benefit from explicitly mentioning incentives of different stakeholders, and what mitigation mechanisms exist to align incentives with protections of privacy and neutrality. For example, a gaming zero-rating category incentivizes operators to ensure that only "gaming traffic" would go through there, otherwise there is an incentive for users/apps to mark their traffic as gaming to get a free ride. In contrast, in a low-latency category operators can use a pay-per-use pricing structure, and therefore not care much about what traffic goes over it. It's true that if apps can simply announce themselves to be whatever category they believe is going to give them better treatment, then they have an incentive to do so. We might want to put some text into the draft about this, and noting that possible ways to make this work would be using trusted/neutral third parties, or with existing business relationships (roughly equivalent, if you will, to a finer-grained way of doing QoS signalling). I think it might be difficult to word that text in a way that is technical enough and concrete enough for an IETF draft though; there's a risk that it would be either too vague or too specific. Think you could suggest something? It feels that this is too important (and with strong ramifications on the overall architecture) to ignore. If categories require strong definition (i.e, they dictate if an application is eligible to participate), then a neutral authority can be essential to protect both privacy and neutrality. This is not necessary If categories are loose (i.e., they define network characteristics but any application could participate subject to cost/caps etc). I could attempt to add some text on the draft if it is of interest. In that direction, another approach to mitigate neutrality and privacy considerations (especially for pay-per-use types of services like QoS) is a user-based approach. The only thing that needs to be communicated is the desire of a user to forward a packet through a certain path. In that sense it can be application-agnostic, and therefore address all concerns around both privacy and net neutrality. Are you envisaging that the user would make these selections manually? That seems very difficult to explain to users. Perhaps I don't understand? Yes, I think there are ways to get the user involved on the selection process. User experience is a UI/UX problem which there are ways to solve. One way to structure this is as a low-latency permission in your phone OS (similar to location, camera, etc); a developer can ask for this permission and a user can simply approve/deny/revoke. It is straight forward for the users and familiar as a workflow. A few of us have been thinking along these lines and we do have early implementations that do this. I see that the document has expired. Is there interest to continue the effort in follow-up meetings? We definitely want to continue to update the document and seek adoption if there is interest in the WG. Great to hear and looking forward to the discussion! Yiannia
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
