Flow-Service Classification

From OpenFlow Wiki

High Level

We assume that a future version of OpenFlow (e.g OF Version 2.0) will support the ability to assign a Quality of Service to a flow. For example, a minimum or maximum rate, or a strict level of precedence.

Quality of Service is a big topic: On one hand, it is probably essential for OpenFlow to support some basic support for QoS; on the other hand, if we require too much, it will make OpenFlow too complex, taking away one of its biggest advantages.

We are therefore interested in finding a happy medium; a default set of QoS options that (in time) all OpenFlow switches will be required to support, hence providing a bare minimum that can be assumed to be present in every switch, router, access point and basestation. In addition, the spec should allow vendors to add more QoS support (e.g. by supporting more service classes, and/or additional policies) so as to differentiate their product from others.

Most switches and routers today provide some native support for Quality of Service. Some products support only DiffServ (a small number of queues and scheduling policies), while others support hundreds or thousands of queues and many policies. In practice, we would expect a flow to be "mapped" to a service class. In some vendor implementations there may be very few service classes (i.e. thousands of flows may share the same class); in other implementations, perhaps each flow belongs to its own class.

We propose to support three required QoS primitives:

• #1: Rate-promising or Minimum Rate:
  • Egress Rate-promise: Each flow contains an (optional) egress rate promise (e.g. "no less than 10Mb/s"). For switches that can't do this per-flow, it could be a queue shared by many flows, called the service class; the flow-entry could contain a "Rate Promise ID" to match it to a smaller set of queues that is less than one per flow. This capability is common today in existing switch chips and boxes; e.g. implemented by DRR or equivalent mechanism that is simple to implement in hardware.

• #2: Rate-limiting or Maximum Rate:
  • Egress Rate-limit: A flow can be assigned an (optional) egress rate limit that places an upper bound on how fast the flow will be transmitted to the egress or to the CPU. For switches that can't do this per-flow, it could be a queue shared by many flows; the flow-entry could contain a "Rate Limit ID" to match it to a set of queues that is less than one per flow. We would need to define exactly what is meant by "Maximum rate" (e.g. the period over which it is calculated). For example, it could be defined in terms of a simple, single leaky-bucket. There might be an existing standard, defined elsewhere, from which we could borrow the specification.

• • Ingress Rate-limit (i.e. policing): Each flow contains an (optional) ingress rate limit. If packets arrive faster than the limit, they are dropped at ingress. Many switches/routers already do this.

• #3: Strict Precedence:
  • A flow is assigned a precedence level. (Default: four levels?). A queue at a given precedence level is only served if all the queues with higher precedence are empty.

In each case, we will specify enough so that a switch/chip vendor can unambiguously implement it. We are starting the discussion early, so we can converge on a technique that can be easily implemented in hardware.

We assume that one or more of these primitives can be applied to a flow. For example, a flow could belong to a strict precedence class, which has a rate-limit. e.g. all of the routing table update flows might be assigned to Strict Precedence Class 0 (highest), and be collectively rate-limited to no more than 10% of the link rate.

How

• Upon connection with a controller, the switch reports its QoS capabilities: For each required primitive above, it would describe how many classes it supports.
• Each flow-entry in the flow-table can be mapped to a particular "class". This essentially means its packets will be placed at the tail of the queue holding all flows of the same class.
• The switch will (optionally) report other QoS classes that it supports.

Questions

• Is the "class" of a queue the right abstraction for QoS?
• Are there other default primitives that we simply must support? (Rather than allow them to be optional extras from each vendor).
• The current proposal specifically doesn't support hierarchical service classes (which are common in routers). Would this be acceptable in, say, a service provider network?
• Should the default requirement for QoS only apply to unicast, or should it apply to multicast flows too? (i.e. any flow going to two or more switch outputs).
• What are the per-class statistics that we should collect? e.g. number of packets dropped because over rate, actual rate of service, ... etc. Can anyone point to a good example standard that we could emulate or borrow from?