Minutes for ACCORD at IETF-95
minutes-95-accord-1

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.