ACCORD (Alternatives to Content Classification for Operator Resource Deployment) BoF - IETF 95 Thursday April 7, 2016 10:00-12:30 Pacifico A Status: not WG forming BoF Responsible AD: Spencer Dawkins BoF proponents: Ted Hardie, Brian Trammell, and Joe Hildebrand BoF chairs: Gonzalo Camarillo and Pete Resnick Minutes of the meeting by: Gonzalo Camarillo, Pete Resnick Raw notes by: Natasha Rooney and Niklas Widell Introduction - Chairs --------------------- During the agenda bash Ling Li asked to present a "use case for content tagging for reverse tagging". The chairs agreed to add the presentation to the agenda. Review of current 3GPP architectural use of content-based classification for radio resource allocation - Kevin Smith ---------------------------------------------------------- Bob: People may want to check the following draft. This presentation is partially based on it: draft-johansson-cc-for-4g-5g-00 Mat Ford: How open are the activities of this GSMA group? How do we handle its interactions with the IETF? Kevin: We are a set of operators and we have drafts we want to submit (e.g., network management of encrypted traffic). So, we will be submitting drafts but we are happy to talk offline as well if needed. Jana: where do you see transport hints fitting in your model? Exchange of information between the UE and TCP optimizer or the UE and the radio scheduler? Kevin: the network ill provide information to the endpoint. Jana: I see, so you are thinking about having the network provide information, not having it consume it. Dan Druta (at a later intervention responding to this question): we are interested in both providing and receiving information. With respect to using different bearers, people should note that turning up and down bearers for a user is costly on multiple levels. Mcr-soho from the jabber room: could the steps in the bearer channel become visible (via TTL decrement) as routers? That would help in debugging. Kevin: good suggestion. Aaron: Marnew workshop had talk on effects of internet encryption. Does the operator community still think encryption breaks network management? Dan Druta: in general current network management methods are being disrupted. HTTPS has been around for years but the proportion of HTTPS traffic has increased. So, we are open to alternatives to network management to help with this. Patrick: In Marnew, we had some assertions about network optimizations but not actual data about them (how much they matter). One of the clear outcomes of that workshop was for 3GPP to present data about this. I have not seen that data. Natasha: we are trying to get data but it is very difficult (it is an action point I have). I am still working on this. Gonzalo: we understand those types of performance meanurements can be sensitive to some operators and vendors. Thanks for working on it. Tom Herbert: what information are we looking at sending to the network? Is it just video vs non-video, or is it something beyond that? Gonzalo: let's wait for the presentations on potential solutions. Jana: is it possible to have multiple UEs per bearer (no), and multiple bearers per UE (yes). Alternatives for current or future architectures: Zero-bit AQM alternative - Jana Iyengar --------------------------------------- Dan: bearers are not volatile, they are very stable. Resources allocated to it may be volatile. Jana: FQ-CoDel does not require content-based classification. Bob Briscoe: within a user's traffic, scheduling has a policy behind it. You need a policy to schedule individual flows. The end system should be able to schedule its own flows. You want to help the user and not overpower them. You can do flow policing, but not scheduling. I wouldn't want a per flow for the user. We're working on DualQ to reduce the number of queues per user, you're talking about putting 1000s per user. That may not scale. Jana: my main argument is to do AQM first. FQ-CoDel is an example. Bob: FQ-CoDel is AQM and a scheduler. Chris Seal: statement that TCP doesn't work well on wireless is not true for our network. We do not use TCP optimizers and passive retrasmissions are low. Also, please note that 4G and 3G are very different. For example, 3G has some state transitions that are not present in 4G. Xavier Marjou: depending on where the device is located (far from the access point vs close to the access point) the cost of carrying the bytes vary. Devices located at the edge of the cell are expensive. Can AQM help between expensive and cheap bytes? Marcus: that's a radio resource scheduler problem, not AQM. Jan: AQM only helps with packets that are in the buffer. Mirja: the problem here is mobile scenarios have one queue per user, so these suggestions are hard to deploy. TCP proxies are not awful, it would be better if we don't have them, but if people have those proxies we have to advice how to use them. Deployments in the end points are going to be hard. All the AQMs try to minimize buffers but mobile networks need buffers. Our work is not done yet. Jana: there is a lot of work that has been done. We have to try things out (i.e., experiments) to see what works. These solutions could provide some help. Mirja: with some info you may be able to make the situation even better. The question is how much information we need. (see next talk) Jana: we will only know whether we can do better if we know how well we can actually do with the current techniques. We need to experiment in order to know that. Q: yes FQ-CoDel is a scheduler, yes it has policy, sometimes you can get the benefits. We have seen this can help a lot. This can work with as low as 16 flows per batch per customer. 1-bit alternative signal - Brian Trammell ----------------------------------------- Cullen: the only thing that practically works is something where there are incentives not to lie. Every option will have positives and negatives. Some people say this won't work across two organizations. But why wouldn't it work across two organizations but work within an organization. I am not sure it will work within an organization either. What you are describing here is DSCP in practice. Brian: the transport will need to be intelligent to understand that assumptions (e.g., a device sends everything as high priority and actually gets worse performance). Gorry: we have some interconnection work like this going on in TSVWG. It is extremely painful to deploy and it is not easy to do. Bob Briscoe: the problem we are facing is that in a particular user's queue you quite often have either all low latency traffic or all non low latency traffic. You have a big aggregate to fo the trade off on. It is a low utilization of the bearer. Brian: that observation holds now but may not hold in the future. We will see more concurrency per user in the future (e.g., webRTC). Bob: there is none concurrency now. The number of flows on a bearer may be less than one. Diffserv is not the answer here because it is design for aggregated traffic in networks. In addition, for some applications latency becomes loss and loss is latency (e.g., voice traffic). We may not like neither loss nor latency. Tom Herbert: How will developers do this? Brian: you will have socket options. Application developers will do this via using library. Tom: we could extract information from the TCP layer that may give us a hint. Maybe loss at the TCP level means latency for the application. So, you may not be able to prefer either loss or latency. Brian: part of it may be due to the currently-deployed transport protocols. It may not be all physics. Tom: If I run multiple connection control protocols over the same connection we will have conflicts and interference. Optimizing that is going to be difficult with so little information. Dan Druta: I agree with the general proposal but the devil is in the details. The zero bit and the one bit proposals may be complementary. DSCP idea could be considered a proof of concept rather than a real solution (Brian: yes). Using DSCP is a thing that others can override. The point is you want to give a hint as an application provider about what your traffic is like, so then we can put it in queues. This is very important for operators and users as it impacts radio and battery consumption. The principle is good. We need to work on the details. Question: different operators use different scheduling schemes and different code points. We need to control the borders. We need it for queue management. QoS does not create bandwidth so we need to over provision anyway. Mobile operators already have QoS mechanisms for the traffic in their network segment. So, the proposal here may make sense only on the edge, per flow. Mirja: in order to map this into a mobile network you can use two bearer per user. Brian: we could use as a bearer selection. Sounds interesting, let's work on this. Spencer: probably not talking as the Transport AD. We'll need to do three things: (1) more exchanges on mailing lists like ACCORD, (2) get some useful information like what Natasha is trying to get and (3) do some experimental RFCs. We will need to push on the three. Martin: people should do something with the tool set we have right now and run tests with this. We could do experiments in a network slice in order not to disturb other users. Let's see what works and what doesn't. Brian: we're doing stuff in the MAMI project for this. If you like to help us design measurement studies, please contact us. Presenting a different use case slide: reverse charging - Ling Li ----------------------------------------------------------------- Clarification: I also presented this in the UTA WG. We are studying if there are other ways to resolve this. Dan Druta: this is a use case that has been discussed. What requires additional consideration is trust. And endpoint could claim it is eligible for reverse charging when it is not. Jana: I do not know how you could do this reliably, but this is related to zero rating. This violates net neutrality. I would be very careful to bring something like this into the IETF. Dan: what is IETFs problem with this? If it breaks net neutrality... Patrick: obscuring this information is the point of TLS. It is not an inconvenient coincidence. Delay, throughput, and reliability; RFC 791 TOS bits refresher - Ted Hardie --------------------------------------------------------------------------- Ted: a user can get multiple bearers. It is up to the operator to decide how bearers relate to resources. Bob: even if you have two types of traffic is unlikely that they go on at the same time. We have done measurements on this and when video happens it only happens at a small point in time. It is not running all the time. Suresh: when the UE attaches to the network it gets a default bearer. The UE can get additional dedicated bearers. How different bearers interact with each other is up to the operator. Also, the UE does not keep asking for more bearers is that they may cost money. Ted: UEs usually get an default bearer and a VoLTE bearer if the are using the operator-provided VoIP service. Jana: the fact that everyone gets the same bearer is a good idea, so the bearer is a shared resource for one user? Ted: Yes, it is a shared resource for the flows of a particular user. Bearers are like virtual circuits. The conversation before was about what size the bearer should be. Mirja: You do not want to tell the network what do it. Instead, you want to tell the network "what is the characteristics to expect from my traffic". Ted: In SPUD we do not want to tell the network what type of traffic this it. Instead, we want to tell the network what kind of treatment we want. The La/Lo stuff does this. In some cases, I prefer to get admission control than to get the wrong network. Discussion ---------- Mirja: back to what Tom Herbert said earlier: interfaces to the network may be different than the interfaces to the application. Brian: once we have solved the bearer problem another may come along. We need an architecture for the signals we need so that they go wherever they need to go. We can model the bearer problem as multi-path communications. The work we have done there may be applicable to this. Or it may not. We need to look into that. 1:57:44 Roland: Diffserv is not only about DSCP. It is also about domains. DSCP could work. You need to signal from the application what tradeoff you prefer in case of resource conflict. This could be a first approach but we need several mechanisms. Indication of intent, signalling, differentiation in the network, different transport protocols, etc. This problem has many aspects. Information from the network can also help endpoints make better decisions. Dan Druta: the more we keep these problems separated the better the solutions will be. Bearers have templates, they are not just about the size of the network. It is expensive to create and delete bearers in real time. It is something that is control by the radio access network. It is not only about size, it is about tuning the network. More than QoS, we need relative priorities based on type of content. Joe Hildebrand: if the radio access network was creating multiple bearers this would similar to the multipath in layer 4 and homeland stuff we looked at in layer 3. Jana: the network gives me a default bearer. In addition, the network can give me additional bearers to help me. If you want the enpoint to tell the network what do to you have to modify multiple parts of the network, you need to modify several things. With a zero-bit approach there are also things to be changed (i.e., network and the traffic source) but there are currently incentives to change them (controllers at the endpoints). There are many things we can do now, rather than change the bearer situation. This fits the Internet model. For example, in video conferencing the lo/la classification is difficult to be done. Gonzalo: a comment about scope. This is a non-WG forming BoF so it is OK to have open discussions. Nevertheless, our discussions have gone beyond resolving management problems caused by encryption. We have been talking about using techniques that have not been used before regardless of encryption. It will be useful for the ADs to consider these different topics in order to scope future discussions. Patrick: the issues with having TCP run over mobile networks is perhaps more about TCP working over heterogeneous networks including interconnections. We have some good new work going on here (e.g., AQM work), and IETF is looking at encrypted transports. That is all work that does not leak any information to the network (leaking information can be dangerous). So, I would like to see the IETF prioritise and explore those solutions first before others. Dave Dolson: can we think about scheduling before we put things in different bearers? We have not talked about scavenger traffic so far; that is an example where I do not want to prioritize latency or loss. Spencer: we need to think in terms of how good things would need to be in order for network operators to remove TCP accelerators and solutions like that. They would do something else that does not rely on that type of technique. Pete: we need to decide how this group will go forward. There is a lot of inter-technology discussions and we will probably need a lot of experimentation. We will probably need IAB involvement, as well as the involvement of other organizations. Cullen: right now people classify things into two types based on desired behavior. We probably need a small set of bits for that. Dan's point about not allowing things to be modified on the path is very valid. This is all more complicated than just a lo/la classification. Regarding video traffic, there are different types of video (e.g., streaming vs interactive video). Note that both video can be audio low latency but audio is also very low bitrate as well. I think there is a handful of these categories and there are not too many of them. Ted: I agree we need to look into scheduling before looking into bearers. In RCTWeb we have been looking into that as the browser handles different types of traffic. The behaviour of the app becomes the behaviour of the router - making this alignment is key. Netflix guys said sometimes the characteristics you need from the network change mid flow. For example, downloaded video is very latency sensitive at the beginning of the flow and then changes afterwards when the playout buffer is full enough. You can also change application while talking to a server. We need to feed this to 3GPP and consider this ourselves regarding how we talk with connection controllers and queue selectors. Erik Nordmark: there is room for experimentation here. We should also consider dynamic behaviors of the radio scheduler and the carrier. It is stable or can its parameters be adjusted? We need to understand this better. Bob Briscoe: a number of us have been working on this problem and haven't really stated this as this problem. We have been trying to do good traffic management, but vendors do not want to do that because they prefer to sell their boxes. There is a lot of research on this and they are mostly zero-bit solutions. There is a lot of work already done on this. This is not a new problem. Pete: this work is mostly research that is published separately, right? Bob: Yes, but there are examples of work that made it to the IETF such as connex and AQM. Jana: there is also plenty of work that is deployed out there right now. Jari: this is an important problem. There are many new things happening on the Internet. We need to think about the big picture. More encrypted traffic is not the only change happening on the Internet right now. We should consider a broader set of changes. Whatever we do, it is important to get operators and content providers working together. Jana: this is not a new problem. It is the same problem in a new context. We are trying to do this for all networks. Please, look at solutions out there because they may also apply to mobile networks. If we choose to expose bits, they are going to be abused. I know this for experience. Ling: We need to make sure requirements are fair for subscribers. I like mechanisms where there are no incentives to lie. Dan Druta: the main message of this meeting has been "trade-off". We have not discussed the network sharing congestion information. We need to look into them as well. We need to experiment with various tools to address our use cases. We have an opportunity to shape communication protocols because we are running in a different context. Teco Boot: this is not specific to 3GPP networks. It also applies to large wifi networks and to satellite networks. I also agree we have existing solutions we could use. We need to look into new ways to get users, applications, and services to interact. AD Questions ------------ During the meeting, the chairs pointed out that the scope of the discussions went beyond providing alternatives to network management techniques that were broken by encryption. Discussions also included general ways to improve performance in radio networks. At the end of the session, Spencer (the responsible AD), asked the following questions to the audience: Was this BoF helpful (did it address a real problem)? Several people raised their hands. Marnew attendees think this moved the conversation beyond past September? Several people raised their hands. A few indicated they did not think so. How many people have read the Marnew report? Several people raised their hands. Are you or will you subscribe to the ACCORD mailing list? Several people raised their hands. Will you help with the ACCORD work? Several people raised their hands. The meeting ended.