Monday 3 June 2013

OpenFlow and latency

One of the questions that came up about OpenFlow last week was about latency.  It was a good question and exposes the lack of clarity about the role between the switch and the controller.

The switch is the data plane. It's role is to move data packets from A to B
The controller makes decisions for the switch whether to move specific packets from A to B or whether they should go from A to C or even block them.

In order for the controller to make this decision, the switch consults with the controller when a new packet arrives. Now this is where the confusion arose. The switch only refers the first packet it doesn't know how to handle. The controller then communicates a rule and the switch continues to use that rule until either it expires or is told to use a new rule. Subsequent packets in the flow do not need the controller to be involved. The switch does the work.

If the switch referred every packet to the controller then:
  1. The bandwidth pipe to the controller would need to be huge since all the traffic would be copied to the controller
  2. The latency would increase by at least the round trip time to the controller
  3. The controller would need higher availability,  scale massively and have more real-time performance than the switch
 The first packet referred to the controller does indeed increase the latency by at least the round trip to the controller but subsequent packets do not. Once the switch knows how to handle subsequent packets the controller does not need to be involved.

The end result is the pipes to the controller do not need to be big.  It needs to be big enough to handle the packets for how many new flows per second there are x the span of control of the controller. If you have an environment where there are lots of long duration flows (eg video serving) there will be les work for the controller to do compared to say web surfing which tends to be lots of short duration packet exchanges.

There is little information to help network planners dimension the link to the controller so this is one area where there is an opportunity for academics to do research and potentially for tools to be developed.  It is likely that the tools would be closed loop taking the traffic profiles and extrapolating for dimensioning.

No comments:

Post a Comment