In Affinity, Affinity Networking, Application Centricity, DevOps, Enterprise Data Center, Featured, Industry Insights, Network Evolution, SDN

Perhaps somewhat lost in a ridiculously hyper week of datacenter announcements last week was this article from some of the network minds at VMWare. The article describes a division of flow types in datacenter environments (they probably exist elsewhere too but probably less pronounced). Elephant flows are those flows that are long lived between sets of applications and are responsible for the majority of traffic exchanged in a data center network. Their counterparts, mice flows, are very short lived, bursty flows that are responsible for the bulk of the total flows.

The challenge is one of managing elephant and mice flows on top of a single network infrastructure. The goal ultimately is to reduce interference between the two types, and between themselves, to get to optimal use of the available bandwidth and fairness for all. It’s not a trivial problem. Mice are plentiful by definition, and really hard to detect: they are gone before you may have a chance to react. Elephant flows are easier to find with sFlow/netflow like mechanisms, and they usually hang around long enough to react to. I will argue however that most elephant flows can (and should) be declared as such by an application ahead of time.

There has actually been quite a lot of research done on the recognition and then proper treatment of elephant flows. If you have a few minutes, google away and you will find research papers from many impressive organizations, going back 10 years or more. It is hard to solve any problem that consists mostly of outliers. Trying to design a one size fits all solution will always target and therefore benefit the average the most. And unfortunately neither elephants nor mice are average. Mike Bushong has discussed the problem with aggregates in this blog post this summer.

Of course (partial) solutions have been brought to the elephant and mice problem, some of them with decent success. The Network Heresy article has the solutions bucketed into 4 categories:

  1. queue elephants and mice separately

  2. route elephants and mice differently (adaptive for elephants, ECMP for mice)

  3. chop elephants into pieces so they become mice

  4. physically separate elephants from mice

#1 and #3 are the most commonly used solutions, but the solutions live in separate spaces. #1 is a network categorization, marking, QoS and queueing solution. It requires the elephant flows to be known either to the network, or appropriately marked by the application that owns the flow. Trusting application markings has always been challenging, so it usually ends up being explicitly recognized by the network and queued separately from the mice. #3 is an application based solution. It requires the application understanding what type of flows it generates, and deliberately avoid elephant flows. We do not believe we should push limitations of the network into the design of applications.

The Plexxi way to properly handle elephants and mice would be through a combination of 2 and 4, actually separate them logically (routing/forwarding) and even physically (dedicated network links). As I mentioned above, we believe that in a data center environment, the needs of conversations need to be explicitly expressed. Applications are known entities, their communication needs need to be engineered, not left to chance. Throwing applications on a heavily overbuilt any to any network and hope for the best is not network engineering. And given the amount of research done on elephants and mice alone suggests the network needs to do things differently. In a Plexxi network, logical and physical forwarding topologies will be calculated taking into consideration Affinities that define elephants.

There are several points the authors of the article make that I can fully stand behind:

  • “.. Often elephants can be determined a priori without actually trying to infer them from network effects.” – Exactly our point, and we have Affinities to declare them as such.

  • “… identification of elephants should be decoupled from the physical hardware and signaled over a standard interface.” – Absolutely. Measurement and flow feedback should support user and policy based declaration of elephant flows.

  • “… for modern overlays. flow-level information, and QoS markings are all available in the outer header and are directly visible to the underlay physical fabric.” – Totally agreed and we would like to take that even further (again at no surprise if you have been reading our musings). The overlay and underlay need to work closely together to provide the best possible communication solution

Ultimately elephants and mice are only one of many types of network problems that should be resolved by the network solution, not by the magic of the network engineer diving deep into the bag of hand crafted tricks some hardware and software solutions give them, but through proper orchestration at a much more abstract level that ties together the need of the application to the service the network provides for that. And an overlay infrastructure in between does not change that, it may provide extra knowledge and power to orchestrate the conversations so that mice and elephants do not have to be afraid of each other (which of course is a myth, but alas).

[Today’s dual fun fact: An elephant sleeps an average of 2 hours during a 24 hour period. And they have poor eyesight.]

To read more on this topic, check out:

Showing 2 comments
  • Peter Phaal
    Reply

    Great article. While I agree that many large flows can and should be declared by applications ahead of time, there are practical difficulties with existing applications and trusting information from end systems. Timely detection (detecting them quickly enough to take action) of elephant flows through measurement is an important part of the puzzle. The articles groups sFlow and NetFlow together, but they have very different characteristics when it comes to timely detection and tracking of large flows:

    http://blog.sflow.com/2013/01/rapidly-detecting-large-flows-sflow-vs.html

    There is a live demonstration at the SC13 conference right now:

    http://blog.sflow.com/2013/11/sc13-large-flow-demo.html

  • Marten Terpstra
    Reply

    Peter, I agree that measurement systems (like sFlow) can provide valuable feedback to any mechanism separating elephant flows from others. The actual size, duration and other information collected by sFlow can be used to fine tune decisions made on how to move these flows throughout the network.

Leave a Comment

Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Start typing and press Enter to search