OpenFlow Meeting Notes 6-1-2010

From OpenFlow Wiki

Apologies for any missing names - the meeting moves fast.

Jean Tourrilhes from HP Labs presented a proposal for rate limiting (File:Rate-limiter-proposal.pdf). There seemed to be agreement that a rate limiter or policer, regardless of its exact name, would be of value, but there were some questions about the degree of flexibility needed for marking, as well as the mechanism's behavior in some edge cases.

• [D. Ward/Jean] naming discussion: rate limiting vs shaping vs policing; apparently policing is the phrase more associated with DiffServ
• questions about whether bandwidth or packet rate should be used, and what happens when both are specified for a rate limiter id: is this an error?
• [Martin] is buffering assumed?
  • Answer: Buffering is handled by the queuing mechanism (in this case, slicing subsystem)
• drop rate > mark rate: error?
• burst size: pkts or bytes?
• [Martin] Customer desire is shaping as much as policing.
  • [Jean] sure, if over, mark and then buffer in the subsequent lookup (assumes multiple tables)
• how is the max number of rate limiters conveyed to a controller writer?
  • [Jean] overloaded some field in the implementation. But not strong preference.
• comments that this mechanism becomes more useful in combination with a multiple tables proposal, where a first table can mark, while a second can enqueue based on the mark output.
• [David Ward] Suggestion to split the structures into a general rate limiter and one specific to the actions taken for packets in the three levels (ok/exceed/violate), such as IP ToS, IP exp, etc. The proposal is tied to marking DSCP bits, and could use more flexibility/extensibility to represent other current or future fields.
• Most of the described proposal has been implemented in the HP switch. (modulo the DifServ type markings)
• [KK Yap] When a rate limiter is removed which is an action of a current flow, what happens? Should the request be denied? Should the flows using the rate limiter be actively evicted?
• [Jean] Current implementation marks the deleted rate limiter as a zombie to prevent reuse until all flows that point to this rate limiter time out. Actively removing could be an expensive operation.
• Is there a way to clear stats?
  • [Jean] No, this is why 64-bit counters are used. This is consistent with OpenFlow.
• Who would use this?
  • Leon: interested, but would need multiple table support
  • Rob: rate-limiting to the controller to reduce DDoSes
  • James Kempf: media control; pushing down end-host algorithms from Alex Snoeren
  • Martin: generally useful
• [David Ward] Lack of flexible actions for marking is the main quibble.

After Jean's presentation, Nick talked about IP. He made a personal request to the audience that everything talked about in these meetings is to be done on an IP-free basis, so as not to prevent future standardization of OpenFlow by some standards body.