The story begins with a mouse named Mickey and an elephant named Dumbo. Oh. Sorry. Wrong audience. ;-)
In networking, a flow is a sequence of packets that can be defined by a 5-tuple comprised of the following: Source IP, Source Port, Destination IP, Destination Port, Protocol number (TCP, UDP, etc). The 5-tuple contains the protocol ID, so it is independent of whether the flow is TCP, UDP, or even one of the other protocols like ICMP or OSPF.
We identify mice flows as small volume, short-lived flows. Elephant flows are just what you would expect, in contrast to mice flows: large, long-lived flows. 2010 research suggests that mice flows comprise more than 90% of all flows in a data center network, but carry less than 10% of the total number of bytes transmitted on the network. Mice flows are typically less than 10KB in size and therefore fit into just a few packets. Elephant flows are just the opposite, constituting only 10% of the flows, but carrying 90% of the transmitted bytes.
If we automatically identify mice flows and give them priority over elephant flows, we can optimize compute transactions that are waiting on a small chunk of data. By optimizing the network forwarding for these small flows, we can improve the performance of many multi-tier applications. A Cisco presentation on ACI references a 30% reduction in application completion time by doing dynamic packet prioritization of small flow packets over elephant flow packets.
Identifying Mice and Elephants
What defines a mouse flow? The exact threshold can be a bit squishy. The figure from the research mentioned above was 10KB. Cisco’s ACI classifies small flows as anything less than 15 packets (see Cisco Application Centric Infrastructure Fundamentals), which could be over 20KB for 1500 byte packets or 125KB for jumbo frames. The network equipment must keep track of flows in order to do the prioritization.
How does the network equipment identify mice flows? It’s any flow that’s just starting and has sent less than the mouse flow threshold (15 packets in the Cisco ACI example). An elephant flow is anything larger. This means that an elephant flow will get mouse flow treatment for the first 14 packets. At the 15th packet, it is reclassified as an elephant flow and no longer receives priority treatment.
How does this work for things like audio and video? These applications are not classified as mice flows, even though some of them may need priority treatment. Keep reading; I’ll get to that point.
Adhering to Policies
Dynamic packet prioritization augments the policies that are put in place by the network administrators. Our current tools for packet prioritization do not take into account the duration of a flow. Our QoS tools classify the packet by examining its characteristics (5-tuple, packet size, deep packet inspection, etc), and marking the packet with a QoS designation. The QoS marking indicates how the packet should be handled (voice, video, signaling, transactional data, network management, basic service, and low priority). The idea behind dynamic packet prioritization is that the network will automatically identify short flows and give them priority within their respective traffic class.
Looking more carefully at dynamic packet prioritization, the mechanism is really suited to handling data transactions, not for streaming protocols. It is a lot more like the express checkout lane at the grocery store than other prioritization mechanisms like DSCP or CoS. By prioritizing only small flows and performing that optimization within each traffic class, it optimizes transaction throughput.
An interesting observation is that elephant flows should start faster because the first 14 packets are prioritized. It would be interesting to see some research on the impact of dynamic packet prioritization on elephant flows. There is the fast startup from the first 14 packets, but then there is the prioritization of small flows over the duration of the elephant flow’s lifetime. Leave a comment if you’re aware of any research in this area.
Voice, video, and many collaboration flows will quickly exceed the small packet count threshold of a mouse flow. That’s not a problem because these flows will be handled by the normal QoS policy definitions. We don’t want a priority classification and forwarding mechanism that can’t be controlled by policies.
But what about applications that have been written to multiplex many transactions over a single TCP connection? These applications are avoiding the delay in the TCP three-way-handshake as well as reducing the left-over TCP state that the operating system must age-out after a connection is closed. These flows will be small until they reach the 15-packet threshold (for Cisco ACI), at which point they will transition to elephant flows.
How Does Dynamic Packet Prioritization Help?
Ok, so we have this new mechanism. How does it help?
First of all, it is a mechanism that doesn’t rely on complex configurations. It “just works” in equipment that supports it. The first implementations are in the data center, where there are many small packet flows in multi-tiered applications. Dynamic packet prioritization also seems like an ideal mechanism to implement in SD-WAN devices.
I haven’t heard of other implementations than Cisco’s ACI. That doesn’t mean that they don’t exist, so ask your vendor. It seems like a great way to speed up applications.
Learn more about systems management and network design trends and technologies at Enterprise Connect 2017, March 27 to 30, in Orlando, Fla. View the Systems Management & Network Design track, and register now using the code NOJITTER to receive $300 off an Entire Event pass or a free Expo Plus pass.
