IETF 108 Network Tokens Side Meeting

Information for IETF 108 Side Meeting.

When

Thursday, July 30, 4pm-5pm UTC

Zoom Link

https://us02web.zoom.us/j/82879910636

Video Recording

https://www.youtube.com/watch?v=2Lu5px8o7-8

Agenda

• 4pm-4:30pm : Overview, Implementation, Status (Yiannis Yiakoumis, Selfie Networks)[slides]
• 4:30pm-4:40pm : Regulatory Perspective (Frode Sorensen, Nkom)[slides]
• 4:40pm-5pm : Discussion and Next Steps (Everyone)

Minutes

IETF 108 Network Tokens Side Meeting - Notes

Yiannis: Starting again now that we’re recording - this is the first side meeting for Network Tokens. We had a previous discussions at the TSV open meeting and the Application Aware Networking meeting.

What we’re going to do is have two talks. I will provide a high level overview, an introduction, and then Frode will give the regulatory perspective around the traffic differentiation ideas and we’re going to leave room for discussion at the end.

We will have time to take questions after each talk and then time for discussion & next steps at the end. If you have a burning question, interrupt us or just write on the chat. With this, I’m going to start.

A little bit of background: I’m one of the cofounders at a company called Selfie Networks. I’ve been involved in a lot of traffic differentiation integrations between application providers and network operators and this is joint work with Nick McKeown who worked with me to develop the original ideas. Frode Sorensen is from Nkom and he was the tech lead for Europe’s Network Neutrality framework, and Tom Herbert is from Intel and has done similar work with FAST which you might have seen and we are sort of discussing how to merge these pieces of work together.

I think collectively as a group, we’ve been thinking alot about traffic differentiation and the interplay between app providers, network operators and end users, and to summarize our learnings so far is that the good thing is that traffic differentiation seems to be widely deployed worldwide, be it in zero-rating, QoS or firewall whitelists. It can improve user experience, it can help operators monetize their infrastructure, but one of the main challenges that we’ve seen and others have commented in similar discussion this week is that this is primarily done through traffic classification, and this comes with high implementation and operational overhead for everyone that is involved, and it is also in conflict with user privacy and encryption, particularly as transport protocols tend to encrypt their headers.

The ugly part here which is like a subtle topic, is that one of the biggest issues with traffic differentiation is that when we try to deploy such a service, it is unclear who controls what traffic gets differentiated. So is it the user, is it the network operator, the application provider, the DPI vendor, the operating system - we really don’t have a good way to debate and answer this question.

Just to translate this good/bad/ugly with some real numbers: We’ve been involved in many zero rating integrations, so what we’ve seen is that more than 160 operators worldwide having publicly available zero rating programs, more than 1000 applications participating in these programs and more than 3 billion users having access to them. All detection, all zero-rating is dependent on some sort of application detection based on IP addresses or SNI domain names, and from a subset of the integrations we did which were like 100, what we’ve seen in terms of success rate for these integrations were 15%, and this goes back to the implementation overhead and the security issues and privacy issues.

The average onboarding time for the ones that succeeded was more than 9 months, and if we look at these numbers only in Europe - where there is a clear policy and regulation about how zero-rating should happen, which is in a way that is inclusive, category-based and straight-forward onboarding - almost 90% of the zero-rating programs were non-compliant. And this goes back a lot on the challenges and the tussle between the different stakeholders here.

The interesting thing beyond the good, the bad and the ugly, is that even though traffic differentiation is quite controversial, there seems to be common ground and consensus on specific use cases.

So if you look at QoS as a use-case for traffic differentiation, there seems to be consensus that a user-centric application agnostic, privacy aware offering is consistent both with application providers, end users, network neutrality advocates and network operators.

If you look at zero-rating for the regions and the areas that allow zero-rating, a category-based, inclusive and money-free agreement between application providers and operators also seems to be acceptable. If you go to enterprise networks with a firewall whitelist or other type of services that might be of interest, there doesn’t seem to be a lot of interest and pushback, people are okay with any type of policy you want to have.

So this is our starting point, and by looking that hey there is room to actually build traffic differentiation services that are well designed and they can adhere to a policy --

Audience: Yiannis, can you just explain what you mean by category based?

Yiannis: Yes, so the easiest example - in Europe if you are an operator, you can zero-rate music, but you cannot zero-rate Spotify as a program. So if you zero-rate music, then you need to have a process that every music provider can come and participate in this program.

Audience: Got it, thanks.

Yiannis: That’s the main idea. And so - there were questions that we posed to ourselves is can we expose and access traffic differentiation services in a way that is easy for operators to deploy and operate, it’s easy for end-users and application providers to access, is compliant with user privacy and net neutrality requirements based on the use case, and it works on modern infrastructure - and with this I mean encrypted client hello messages, multi-cloud deployments, third-party DPIs and so-on and so-forth.

A network token is the mechanism we have developed in order to meet these requirements.

At a high level, network tokens enable explicit and secure coordination between end users and application providers on the one side, and the network on the other side. They replace heuristics and DPI-based application signatures with a deterministic mechanism to drive this coordination. And one of the main insights that we’ve developed as we’ve been implementing and designing tokens, is that essentially this looks more as an access management problem rather than a traffic classification problem. So the whole design has been heavily influenced by OAuth/2 workflows, access tokens, JWT etc.

Going a little bit more into the details - tokens carry simple claims, so for example a token can be “Hey I am Skype” or “Hey I need low latency”. They may be encrypted or signed based on the trust relationships and requirements between the different stakeholders. They have built-in provisions against replay and spoofing attacks - so we use things like expiration time, binding fields and revocation to make sure that we’re securing against replay and spoofing attacks. They can be represented in different formats, like JWT, CWT or custom formats and lastly, tokens are inserted as extensions and attributes in existing protocols.

We’ve been able to insert tokens in IPv6 extension headers, TLS handshake extensions and in STUN attributes. One of the things that we need to figure out is let’s pick one to do some progress and I think there are trade-offs on where we do that.

Now - one thing that I’d like to emphasize is that tokens are policy-agnostic. So the policy is not dictated by the tokens as they are, but its dictated by token distribution, so who can issue and who can access tokens by the contents and the cryptographic functions that are applied to tokens, and finally by the end-to-end workflows that clarify how somebody can get a token, what permissions are needed, what credentials are needed, etc.

You can have different types of tokens, but there are two of them that seem to fit in most use cases that we’ve encountered so far. One is what we call an application-specific token, which essentially says “Hey I am this application” and can guarantee this, and the other one is a user-driven application-agnostic and privacy-aware token where the main idea is that a user can purchase or access a network service based on their relationship with the operator and then they can decide which traffic can go through that service.

As I said, the end-to-end workflow is very important to make this applicable and to clarify the policy that we’re trying to implement, so let me show you a sample workflow to visualize how this looks like.

Here we have a workflow around a user-centric application-agnostic tokens and we have three entities. One is the mobile operator that essentially exposes a premium network quality service through tokens and the two boxes that you see here with the green annotations are the data plane and the control plane. We have an application provider in this scenario is a video conferencing application which can benefit from the premium network quality service and a user who is a subscriber to both the operator and the application provider.

The workflow that we envision goes as follows: It starts with the application asking user permission to access the premium network quality service. And this is very similar to the way an application can get access to location or camera etc. Once this application has been given, an agent in the client goes and fetches the premium quality token with a user’s credentials. This agent can be at the operating system, it can be a 3rd party agent sitting in the phone or it can be in the application itself.

Once the tokens are given, the application developer gets access to them and they can attach the tokens to the flows of interest. And the idea is that it should be easy for the application developer, it’s essentially an API, and they can define what flows need these services in a fine granularity. Once this happens the network detects these tokens and provides the desired service.

Two important things to mention here, one is that this is a sample workflow, and you can have different types of workflows defined around network tokens, and the second one is that a lot of the challenges that we are thinking about how to make sure how to make sure this is not abused, or how to give this to the user in a friendly way, I think we have all the mechanisms to do this with the existing stacks on client devices. So we have means to give permission either through the operating system or something like OAuth/2, it’s easy, people are familiar with these types of workflows and application developers as well.

One point is the design priorities and the trade-offs. When we started designing tokens, we thought that privacy and security and trust relationships between the different entities are the hardest thing to get right, and so this is our first priority and we believe that if we don’t solve this, then it’s pretty hard to do something beyond an academic exercise. So our goal is to deal with privacy, security and trust relationships first.

The second one is a path to adoption. So part of the challenges come from like what are the incentives for somebody to do something, how you can have partial deployments in place, so that the second thing that we consider, and the third one is implementation efficiency.

There are some trade-off considerations that we are encountering as we are designing tokens and we’re implementing them. I will just briefly mention the main ones: one is do we have a random token or do we have a structured token? I think if you do random tokens you can have small tokens and easy processing at the data path. If you do structured tokens and start doing encryption etc it means that tokens get longer and they require more heavy processing on the network which can imply decrypting these tokens etc.

This also has impact on the state that you will need at the network, a random token will be very heavy on token state, structured tokens you will have to do per flow most likely and this means that you can eliminate all token state because tokens can be self-contained, but you will have per connection state. So I think one interconnected tradeoff is random/structured tokens vs per packet/per-flow.

Another one is where to insert tokens, as you can imagine there are strong opinions within IETF. One clear demarcation is do we put this in layer 3 - IPv6 in particular -, do we put it in Transport - TLS or STUN - or another option.

Our last trade-off is what is the role of the operating system is around network tokens. Obviously the operating system can sort of be a natural place to broker the permission and the trust between applications and users on one side and the network on the other side, but there are ways to do this without the operating system and this sort of brings up who brokers this relationship between the different entities.

Current status: There is an internet draft that we pushed to IETF datatracker. Right now it contains everything from background and motivation to the overall architecture, generic tokens, specific tokens, insertion into protocols. We’re well aware that we will have to break this into multiple documents, I would just put it there in a single one so people can easily read and provide feedback. We have a blueprint implementation that exposes a QoS service for 4G and 5G networks through user-centric tokens. We use these tokens to provide premium network quality for video conferencing calls that use WebRTC, and most of this code is in open source and we do it in partnership with the Open Networking Foundation and their partners, and there is a mailing list at network-tokens@ietf.org.

There is a lot of related work SPUD/PLUS, PAN, APN, FAST, SWORN - I think, I‘m catching up with the content and the learnings from these groups. One thing that I’ve seen both from what I’ve been reading and my discussion with individuals both at IETF and outside is that it’s pretty important to prioritize and narrow down on a specific use-case, so that people get comfortable with the trust relationships and the privacy, etc that are supported for this specific use case. So this is one of the things that we really want to prioritize.

Focus on privacy security and trust relationships for this use-case. Engage with the related groups and we’re actively working on implementation and PoC, and if you want to work with us on this just contact me directly.

I know that many of you might be thinking about cellular networks and how this relates to cellular networks - both zero-rating and 5G slicing in QoS are pretty hot topics in that community. One point that I’d like to make in terms of standardization, I think tokens you can think of them as two different standardization efforts. One that happens at IETF is establishing an interface between applications and end-users on the one side, and the network on the otherside and I think this is a better fit for IETF.

3GPP has to do more with how do network tokens fit within the 3GPP architecture. One of the good things is that most of the functionality fits under the existing 3GPP interfaces for traffic detection function and DPI and if we could add tokens to packet filters and traffic flow templates as standard fields, this would help a lot. We haven’t done any work with 3GPP yet - if you’re interested in taking part on this, let me know.

That’s all that I want to do - what I want to do is close with a question, which is what is the use case that you’re interested in. I think this maybe the most important next-step that we have to consider and so what service are you mostly interested in, is it QoS, zero-rating, firewall, in-network telemetry, something else, what type of token consensus seems to be the best fit for your use-case, do you agree with the consensus statements and what insertion point do you see as more viable.

And with that, I’m just going to open it up to questions to everyone. I think Li Zhenbin you have a question?

Li Zhenbin: I have much interest in your implementation - can you go to that slide you mentioned you implemented some of these use cases in the ?

Yiannis: Yes.

Li Zhenbin: So I want to know, because I know that this is just the data plane, or have you also implemented some of this client and controller, this inter-workings?

Yiannis: Yes, so the implementation we have right now has the following components: It has a data plane that can process tokens, it has a client/phone functionality that can get the tokens, share the tokens, and also it has some control plane functionality that on the one side orchestrates / talks with the dataplane to make sure that the tokens are there and can be verified, and also distributes the tokens to the endpoint.

Li Zhenbin: Ok so you do you use P4 on the dataplane?

Yiannis: Right now we’re using the BESS-based data plane that ONF has, which is on the upf-epc, and we’re looking to do an implementation on top of P4.

Li Zhenbin: Ok so I want to know if you have some data analysis of how this works, will this have much effect on the forwarding performance?

Yiannis: So far from what we’ve seen, no.

Li Zhenbin: Ok

Yiannis: Happy to take this offline, this goes a little bit into the details of the specific implementation but happy to take this offline.

Any other questions?

DKG: So - this is Daniel, DKG, Daniel Kahn Gilmore I apologize for being a bit of a tourist here, this is the first that I’m really grappling with the questions - although it’s not the first, because I was involved in SPUD/PLUS discussion and all of that.

I’m curious to know what the perspective of the network tokens project is on the fact that using the internet seems to require typically, multiple networks, and as you rightly identified, trust relationships is a big part of this work. And its not like there’s one network between me and the other endpoint I’m talking to, there are potentially, like I don’t know how many there are.

So is there a frame that the network tokens project sees for dealing with this? Or is it like we’re just talking to the local network?

Yiannis: So I think a couple of points to think about this - the first one is that there are several use cases where you just need one network for the service, so if you think about zero-rating, there is only one network that does the charging. If you think about firewalls, there is only one network that does the policy. So in these scenarios, you want one network, what you want from the other network is not to ruin you, which means do not drop or do not mangle the token.

Also if you think about low-latency if you combine this edge nodes that are inside the operators network, then even a QoS thing could be part of one network.

DKG: But as the end-user I have no way of distinguishing between those things, right? Even as a technically sophisticated end-user it can be difficult to distinguish.

Yiannis: Yes, I think one thing we’ve seen happening in practice, is that application developers on mobile phones they can see what is the operator, what is the sim card of the phone, and they can adjust their behavior based on this. And I think as a user, you don’t do this on a very short timeline, it’s more of like “yes, I want my calls to have high quality” and then there can be some manual on & off.

The other way to think about this is that I think having tokens that can support multiple networks is an open topic. We think there are a few options to do them. One would be to have a token that can be interpreted by multiple networks, or have multiple tokens within a flow, or have a token that can have multiple recipients using the capabilities that JSON Web Tokens have with different keys for each recipient etc. And so I agree with you that it’s an important question to ask - we are more focused on solving this for one network right now, the network that is likely closer to the end-user, and -

DKG: But my question is, so I agree with you that the multiple network thing is more complicated mess in terms of trust relationships and user experience than single relations and single networks. But my point is I guess, is I don’t understand how the user is even going to understand between the networks. You said firewall was an example of a single network case, but I’m often behind multiple firewalls.

Tom Herbert: So look at it this way: So the whole premise here is that the application requests service from the network. So there’s some agent in the network. Application creates a request saying “I need low latency and these parameters, here’s the destination”, gives that to the agent in the network. The agent in the network determines whether or not that service profile can be manifested.

DKG: But how does the end user know which network they’re talking to?

Tom Herbert: The end-user doesn’t need to. All the end-user really needs to say is what the destination is. This all needs to be transparent to the end user. The only thing the end user gets, the end user requests some service, and it gets a reply if the service can be met.

DKG: So it sounds like we are building techniques for anyone in the network to attack a given connection, or change a given connection, and the user will have no idea who is doing those things, this is not a recipe for a trust model

Tom Herbert: I think the user is asking its local network, and that’s where the trust relationship comes in.

DKG: Okay - you didn’t say local network earlier, and how and I supposed to know it’s coming from the local network?

Tom Herbert: Because this is an out-of-band thing. The user is configured, there is an agent running on each client that knows how to contact the local network, that creates a trusted relationship, so the local network can provide trusted tokens back to the user.

DKG: Many clients are connected to multiple networks today, and a user doesn’t necessarily know which network they’re connected to. When you use WiFi, you have no idea what you’re connected to.

Tom Herbert: Well again, it’s not so much the user, it’s the application, presumably this would be front-ended by an application library and the library could determine based on the destination which network is in use and if it’s possible that the same flow could use multiple networks, then maybe the application creates tokens for multiple networks and then applies the correct tokens per network. I mean it’s an interesting point, it does convolute things.

Yiannis: Daniel - one typical way we’re thinking about this, is as a user, I’m subscribed to a low-latency path from my operator and a best effort path to my operator. And I’m telling the operator that I want my game to access the low-latency path. So that’s the decision that I’m making as a user. From that point on, the game developer can identify which network to use a token for, which flows to use a token for etc. So I think the low-level details of which flows on which networks etc can be dynamically taken care of by the application developer or the operating system. What the user gives is the high level permission “I purchased this service, I’m willing to pay and I want this application to get this service.

Yiannis: I think we’re going to have to pause here and give time to Frode to talk on the regulatory side of things, and then we’ll have another 20 minutes for discussions, so if you can hold your questions for afterwards that would be great.

---

Frode: I will give a short presentation about regulatory considerations, trying to explain why these network tokens initiative is interesting for regulators.

A brief introduction about the regulatory considerations: In general it’s important to realize the regulations are not provided by the regulators - the regulators are provided by the law makers, and the role of the regulators is to supervise the market based on these regulations. The general goal of the regulation is typically the social benefit of the services, including the preservation of internet innovation while at the same time, it’s important to avoid any limitations to technology development.

A quick recap of the European perspective: Coming from a European country, I will present and discuss based on the regulation we have in Europe and the Open Internet Regulation consists of two pieces of text: the regulation, which is the law itself, and in addition to that, the regulatory organization called BEREC has developed guidelines describing more details about how to interpret the regulation.

In addition to focus on open internet, there is also as many of you know already, a focus on privacy in Europe. We have a general regulation of privacy and also in the open internet there are specific statements about privacy that have to be taken into account. And here I have provided references in case you want to go into the details of these texts.

Turning over to Open Internet considerations - It’s important to realize that also under the open internet regulations there is the possibility to do Quality of Service differentiation. Equal treatment does not mean that there are not identical treatments to any treatment. An easy example to understand is that in fixed access networks, you can have different speeds on the access, and this can also be provided in mobile networks even though this is not usual in all countries, but in a few European countries this is already available. But it could also be differentiation based on other Quality of Service parameters and speed, for example latency. As the only requirement that is in addition to general net neutrality is that this differentiation has to be application-agnostic.

The rest of my presentation will focus on how to understand the term “application-agnostic”.

An easy example is you can do differentiation between different subscriptions - which means that when you are a particular user, all of your applications can run on the Quality of Service level of your own subscription. Then there is also this discussion about whether its possible to differentiate between different applications within a single subscription. And this is possible to do under the European regulation, and this is also similar to the Net Neutrality & Quality of Service by Barbara van Schewick already.

How can one understand that differentiation within one subscription is in line with the Open Internet regulation. The European framework, as understood by BEREC, provided some clarifications to this in the revision this year which was published a month ago, and the way we understand application-agnostic is that any application can run on any QoS level. It doesn’t mean 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.

This means that should not be predefined by the network, and it could be selected by the end user and the end user would typically do this through the application as has been discussed already in presentations earlier today.

A practical implementation of this could be two different ways of doing it, it could either be configurable in the application - typically telephony application, speech transfer over the internet, where the end-user configures this application to run on a higher quality of service level than the ordinary traffic is sent. Alternatively it could be selectable for each session where the end user could choose whether to use ordinary quality or a higher quality level where he sends his traffic.

A few words about zero-rating since zero-rating is also mentioned in the presentation of Yiannis and also in the network token internet draft: Zero-rating is also considered under the European OI regulation and is further clarified by the BEREC guidelines published this year. When zero-rating is assessed under the regulatory framework, its done based on several different criteria. There is not a clear-cut answer to whether zero-rating is allowed or not in a national market, but it has to be assessed based on different criterias. And one of the most important criteria is whether the program is open.

The definition of open means that if a provider, if an internet service provider has a zero-rating program, it has to be open to any applications within the same category. For example, if music streaming is available as a zero-rating application, it should be applicable to all providers of music streaming, whereby all music streaming applications are zero rated. This is also clarified in the BEREC guidelines where it says clearly that “Open zero-rating programs are less likely to restrict end-users choice or undermine innovation on the internet than zero-rating of a single application or programs that are not open.

So this is just a brief introduction - most of the discussion today has been on QoS related aspects and there was also a question in chat which I may answer depending on how Yiannis wants to run the meeting.

Yiannis: Yeah please go ahead Frode - so is there a specific question?

Frode: Yeah there was a question about charging of QoS. I turned back to the previous slide and as it says here, you can run applications on QoS levels and I guess the question was related to whether there is an incentive to provide this kind of internet service access from service a provider and probably that would only be interesting in case of charging of the application and the BEREC view on this is that its possible to do charging of the local user, which means if I as a subscriber select a higher QoS level that can be charged to my side of the communication. As it says on this slide, this QoS level should not be predetermined by the network or the network operator, which means that it cannot be charged to the application provider, which is the other side of the communication channel. It can only be charged to me locally as an end-user.

I hope that answers the questions but I can take follow-up.

Yiannis: I think Tom Hill has a question, and then Joey I don’t know whether you answered the question in your chat but Tom Hill, Tom is your question answered, or is there another one?

Tom: Possibly, if I may just float the potential loophole, and you may shoot me down here - assuming an application developer/provider/vendor produces an application, a game for example, it wants low latency. And upon installation it sends a message to the user and says “This will require a setting of a premium service, it doesn’t work without it. Do you still want to install it?” If they click “Yes” to install it, is that user choice? And you know, if so, could this be a case of net neutrality exemption by the back door? I’m a bit concerned that if we give more power to this, that applications will find a way of taking advantage of it.

Yiannis: I would say the same question is with an application that asks access to your location or to your camera, or to you know

Tom: But we’re not talking about location or cameras, we’re talking specifically about net neutrality.

Yiannis: Yes, my camera has more risk to me to be careful about this than like, the network settings.

Tom: My question was Yiannis really to the speaker because I’m asking about the regulation and how the regulation will see this.

Frode: I can give a quick answer - the regulation itself is not that detailed, so it doesn’t answer your question explicitly. But this aspect you mentioned has been discussed among regulators and I think the general view is that this should be configurable by the end-user but it should also have a default configuration where it is not prioritized and not charged - so it has a default configuration where all traffic is sent on the same QoS level. I think that’s the general view, and I think that should to a large extent solve the concern you express.

Tom: It poses another question, but I will yield my time. Thank you.

Yiannis: So Joey, do you still have a question or are you covered by the chat?

Joey: Thank you, I did ask them in the chat, I think I’m good for now.

Yiannis: So Lars goes next:

Lars: Hey - so I have a slightly different question that hasn’t been discussed so much and so we’ve done integrated services a long time ago and we’ve done NSYS? Which is a signaling protocol to replace RSCP?. You describe what a flow expects from the network in something called a flow spec, which has a lot of the same things that you talk about, like jitter, delay, maximum bandwidth and so on. One of the problems we found with these things in the past is that almost no application can fill out a flow spec. If you think about this Zoom call that we’re on, it probably has like 10 or 12 or 20 or 30 different flows. What would an application writer put in that flow spec so that it could be expressed to the network? All of these things work well with best-effort right, so it’s very difficult to actually write down for a given application what do you expect from the network for this particular flow. It’s typically you want the lowest delay, or the fastest throughput, and there’s not really anything else here you want to express that makes any sense in general. So the problem we had in the past is that people wrote these insane specification that allowed you to express very very complicated flow specs that in reality nobody could use. So that is problem and I wonder if you’ve thought about this, because you have that problem.

Yiannis: Yes - so I think we don’t have any concept of a flow spec, right. I think the way that we separate the two is that the network says “Hey, I have this service” and it’s up to the network operator

Lars: But how does the network operator express its offering

Yiannis: Yes - so I think this service is “I have a premium network quality service”, and someone has to go and understand what the premium network quality service means for this operator, and decide whether they want to use it or not. We want to be very very careful to leave the control of the network to the operator, and then enable the endpoints to use this services. If they don’t like these services, they shouldn’t be using them and shouldn’t pay for them. But for one specific example, on the video conferencing stuff, first of all the network already has - most cellular networks as an example - they already have voice over LTE which uses a dedicated bearer to provide specific QoS characteristics for voice calls. You can also combine this with the provisioned path that does not have buffer bloat etc, so that its better suited for low latency.

Lars: Sure, but that particular service that you talk about is actually not accessible for internet protocols.

Yiannis: Yes - so voice over IP right?

Lars: So the 3GPP voice over IP runs over IP, but the bearer is set up separately right, so it’s actually not something that Zoom can take advantage of.

Yiannis: That’s exactly what we’re trying to do.

Lars: I understand the operators would love to have these sort of different offers that are sort of pay to play, right. But again, the problem that you described earlier that the applications have to specify the expectations and the operators say here’s what different levels mean. It’s the same problem but just in reverse, right? An application still needs to understand what these different service levels offer and then decide what it wants to use, which is kind of difficult.

Yiannis: I think in that specific example that you mentioned, this is the exact motivation that we have, that hey the network can already do something, and this is on a bearer, and we want to provide a mechanism for this thing that is vertically integrated and requires awareness from the operating system, the application driver, the network, about everything, we want to desegregate this and open this up. And frankly you can do this with the existing 3GPP. We are doing this now with an LTE network using dedicated bearers and we can pass traffic that is not voice over IP.

Lars: So if you’re in a hotel right, you can often get the free WiFi and you can get the premium WiFi, and there’s some description of what the difference is. I often cannot figure out if premium is worth it, right. And the network specific characteristics that are expressed like you have this much bandwidth or this much .. its pretty much meaningless when it comes to application QoE. So a user cannot - yes you can always click the “I wanna pay more”, but the question is “would not paying be any worse?”

Yiannis: That’s the challenge for operators to come and design a service that is meaningful and is value added for their users. If they can do it, they will succeed, right? And we’re not saying this is out of scope for this work, we’re saying lets assume an operator has a service that can add value to the end users and the applications, how can we expose this. I agree with you that in many cases this might not be worth it, and people might not use it and I think we are saying that hey - there is this discussion and in some cases its worth it and people buy the plans. So people buy zero-rating plans quite a lot. And so if the operators can get up to the challenge and offer a QoS service that is meaningful for users - and this is not like a hotel relationship that is one day, this is a long-term relationship where you can build credibility about a service - then what we want to do is expose and access this service in a proper way that respects privacy and net neutrality etc. You’re right that the service itself might not be worth it. And if the service isn’t worth it then no reason to expose it. But we believe that there is a good chance that the services are going to be interesting enough for people to use them.

Lars: I’ll let somebody else speak, I’ve said my piece for a while.

Tom Herbert: So I put my comment in chat, but my understanding is providers already do this today in the sense that they’re doing DPI and they’re determining which application is sent and they’re using that information to put it into different services. Am I mistaken?

Yiannis: Any operator that wants to comment here?

Magnus: This is Magnus Westerlund; not an operator but still - There’s some thats based just on traffic is going, a lot of classification is based on saying ”No, we know your services are going from the client to these particular servers” and that’s what you use for the flow classification.

Tom Herbert: Yeah but that’s more than just routing, this is actually looking at and trying to determine what the application is in order to differentiate what they’re doing based on the application. So it’s hard to see this as different, but obviously the thing that is troublesome about that is that this is per-application, not some abstraction of what the application needs. So for net neutrality, this is probably worse.

Magnus: Well, if you’re gonna zero-rate, you know they’re gonna zero-rate lets say YouTube, HBO and a few others in your country, and you know where are the services because thats the information you ask the provider saying “Okay where is your traffic gonna come from, tell us that and you’ll get zero-rated if the traffic comes over from that source address”, and thats your classification.

Tom Herbert: There’s a big difference between prioritizing for “YouTube” vs prioritizing for “high bandwidth video services”. And it may end up being the same thing, but obviously the market for that is very different, right.

Yiannis: Okay - I think we’re reaching to the end of the hour. One thing that we are looking to do is continue this work. As I said, we’re very interested on a use-case, on a specific use-case with very specific characteristics, because I think you know one argument is valid for zero-rating and not valid for QoS and vice versa. So I think one thing we want to do is pick a very specific use-case. If you have use-cases, either talk now, or talk to the mailing list or contact us directly. Very very interested to understand the use-case and see where to focus etc.

The other thing - and Magnus might also comment here - I think we’re looking at how to proceed & next steps. The plan is to hold another side meeting at the next IETF for sure, and hopefully have enough consensus to go for a BOF on 110. Is there interest in this from people here, if you can +1 to keep participating into this discussion, if you can +1 in the chat.

Magnus - any specific comments from your side as a Area Director

Magnus: Uhhhhhhhh

Yiannis: Sorry for putting you on the spot!

Magnus: Well from a high level, you’ve got my feedback and I think you need to tease apart these different problems and try to drill down and say when it comes to the security model, what can you say, what does it imply, there’s all these aspects of this that need to be teased apart and clarified, like this we can do, this we know how to do, whats hard is this, whats needed is that, and trying to arrive at saying what’s actually needed for realizing this and what’s the challenges and I think that’s where you need to improve your drafts etc so people can read and understand those aspects.

Yiannis: Any other comments by anyone? I think we’re reaching the end, we have a couple more minutes.

Li Zhenbin: Okay - in fact, we have fruitful discussion in the APN side meeting because now if we collect all the work together, it will very huge work mixing inter area and transport area and ??? area and also the routing area. So from my point of view, this work is very difficult to be done in IETF. So from my point of view, at least for me, I think at least we can distinguish the scope. The first one we focus on the network layer, so this is maybe the differentiated, how to get the application information but it is just encapsulated in the network layer.

Another scope of work I think has much relation with the application layer or the transport layer. This means the end-to-end negotiation and also to apply for the application specific information such as the network token.

So I think this maybe we can some distinguishing work. But the challenge for the transport layer work and the application layer work, I’m a little worried about the risk and the past work such as SPUD and PLUS. I mean a possible way is that we can focus on some of the specific use cases, I agree with this very much. But I think that this is better if we can identify some of these use cases, make it try to convince the people to agree with these use cases. So then we can work on this while, in parallel, two possible solutions based on the network tokens. That’s my point.

Yiannis: Okay. I think the comments on considering how we can combine this work with APN is very relevant, so I think between now and the next IETF meeting, does the APN community looking to have BOF on 109 or further down the road?

Li Zhenbin: In fact I introduced this work, in fact IETF 107, we tried to apply for the BOF but it was not accepted, because of the IETF leadership reminded us of the existing SPUD/PLUS work.

Tom Herbert: I have a question, do we have a mailing list for APN?

Li Zhenbin: We will soon

Tom Herbert: Okay, so first step into getting into BOF, you need to have the mailing list, and then we need to get traffic on the mailing list, and then we can probably do a non working-group form of BOF, seems reasonable. And maybe 109, ??? can probably specify that.

Yiannis: Okay everyone I think we just ran out of time. Thank you very much for contributing here. Just as a reminder, there is a mailing list around network tokens, there is a website, please contribute to the discussion, I think it’s important to show that there is interest and there is traction to keep things going. If you have any follow up questions I’m happy to talk to you offline as well. Thank you very very much. We will upload the video & minutes from the meeting on the wiki page for the meeting.