The technical term “flow” gets used a lot in our industry – you’ll see it come up in almost any discussion of switching, data centers, software-defined network (SDN) or bring-your-own-device (BYOD). The problem is that while flows are used as a simple shorthand for what can be a (very) technical subject, there’s no one accepted definition of exactly what a flow is or what a speaker means when invoking the term. At its most simple definition, a flow defines a communication or conversation between two or more endpoints on a network. That’s fine for most purposes, but using that definition almost anything can be considered to be a flow. When discussing issues like scaling in SDN or application identification, the term “flow” often means much, much more. Usually this means a much deeper visibility into the data in that flow, but exactly what that means tends to become a very technical discussion that makes the eyes of non-experts quickly glaze over. Vendors will quite honestly claim their switches are ‘flow-aware’ when they only track the most basic information about a given communication between endpoints, but this can be misleading.
I’ve found that a good analogy that can be used to understand flows is that of an airport. For most vendors, each flight is treated as a flow. For example, the airport understands that a Delta flight from Paris is coming in to Boston at 7:00PM and has 250 passengers on board. At that level of granularity the airport may only be dealing with a few hundred flights/flows each day. This may be fine for some applications, but this level of granularity isn’t really adequate to meet the needs of the individual customers on each plane. For vendors with hardware dedicated to flow processing (such as Enterasys), every individual passenger is treated as a flow. So in the same example, the airport understands that Jim Anderson (male, 37 years old) is on that Delta flight (actually operated by Air France), he came from Brussels, Berlin and Vienna before he got to Paris, he’s going to be catching a connecting flight to Los Angeles, he’s a US citizen with a Chicago address and needs no special visa permissions, he’s traveling with two checked bags and a carry-on, and he’s traveling on business. He (and every other passenger on that flight) is treated as an individual flow and therefore the airport needs to handle millions of these individuals/flows every day.
The advantage of this level of granularity is the ability to far more effectively route these flows (or packets) to their destinations with speed and efficiency. Continuing the analogy, if Jim’s connecting flight is canceled then the airport in the first example simply abandons him as it can only think in terms of planes. Jim never gets to his destination and has to start his trip all over again. In the second example, however, the airport knows where Jim is going and can reschedule his connecting flight, reroute his luggage, avoid routing him through Cuba (where he doesn’t have a visa) and possibly even put him up in a preferred hotel of his choice if necessary – potentially all automatically. Note that in both of these cases we’re still talking about routing “flows”, but the meaning of the term is dramatically different depending on the desired result.
Exactly what a flow is determines the suitability of a system to meet specific networking needs and administrators need to understand that not all flows are created equal. For today’s high-volume and high-agility networks, flows are often the key to efficiency and they’re essential to cutting-edge solutions like SDN. In the example above, Jim (or the information he represents) could be automatically rerouted as necessary in an SDN environment. This automated, programmatic traffic management is the true value of SDN, but it requires the ability to support millions of flows rather than just a few hundred. This kind of volume is usually dependent upon the underlying network hardware as software overlays tend to introduce unacceptable latency.
There is, of course, a lot more to the concept of flows than this high-level analogy, but it’s a useful way to think about the subject. The lesson for administrators and designers is fairly straightforward:
- Understand what you need your network to do
- Understand what kind of flow capabilities that will require
- Understand what definition of flow will meet those requirements
- Understand whether a vendor’s solution meets these needs