These are notes from a “Elephants and Mice”presentation on elephant flow detection and mitigation in software switches. The slide deck is embedded at the bottom of the post.
Elephant flows are very large data transfers that a problem in packet networking because they overflow buffers and queues in the hardware and software devices which impacts all applications where the congestion occurrs.
The premises is to prove how to detecting elephant flows in software switch (OpenvSwitch) and mitigation using hardware switch (whitebox Ethernet using Cumulus Linux NOS).
|measure flow rate over time||possible in OVS since small number of flows in a single physical server relative to a network switch|
|set IP DSCP tag in IP header to signal elephant flow to the physical||this means that the physical networks mist support DSCP and be able to action DCSP tags at every point in the physical path|
|What can physical switch do to manage DSCP market packets||three possible actions are offered|
|1. Lower drop/wred threshold to slow down transmit rate|
|2. use an allocated queue in the silicon|
|3. use flow entries to select an alternate path.|
Now the deck outlines the test network and servers. Then explains the test methodology & provides data on the results. Combined graphs shows that Mice flows return to normal operation while the Elephant operates at same performance levels.
Looking more carefully at the presentation notes I note that ordinary traffic moved over 1GbE link and elephant traffic over a 10GbE link. Can’t work out why a 1GbE link was used but don’t this distorts the results since mice flows would not exceed 1GbE.
I consider that the purpose of the presentation is to highlight the value of integration between virtual overlay and physical underlay networks. The authors are in a competitive position to the approach taken by Cisco ACI which is making a significant marketing effort around the custom silicon needed to implement ACI Features but Cumulus Linux uses low cost whitebox alternatives to achieve the same outcome.
Does this invalidate Cisco’s claim that “commodity + proprietary” silicon is the best solution ? It’s not possible to answer this since ACI is not shipped and there are no publicly available details on how the solution differs.
But it does prove the value of at least some integration between the underlay and overlay networks for a specific use case.