SDN & the Problem With Data Set Transfers

Large data set transfers turn out to be a perfect application for SDN as operators seek fine-grained visibility and control over their traffic physical device behavior.

Bruce Gregory, CEO, Corsa Technologies

December 9, 2015

3 Min Read
SDN & the Problem With Data Set Transfers

Large data set transfers, such as large file transfers between research centers and supercomputing facilities, cause congestion that can wreak havoc on networks. Such transfers disrupt the normal traffic flow in a network, and it is difficult to accurately predict how long it will take to transmit the data (although it is usually a very long time).

Here is the issue: Since these large data set transfers are typically TCP flows that live for a long time, they fill available buffers across the network and disrupt the buffering and queuing of "regular" day-to-day traffic of a campus. This regular traffic is random, short-lived flows that can be more latency sensitive than the large flows. They don't require a lot of bandwidth, but they do need to complete in a timely fashion.

Perfect SDN application
Large data set transfers turn out to be a perfect application for SDN. First, they require the ability to provide either bandwidth reservation or dynamic bandwidth allocation that meets SLA requirements across a heterogeneous network. Second, the network still needs to accommodate the small flows of regular traffic acceptably.

This is most easily served by a logically centralized control plane that understands application requirements, network topology, capacity and current state. In other words, a software-defined network. The SDN control plane then provisions bandwidth where and when it is needed.

Not just any SDN
Any true SDN solution can provide the intelligent network control described above. Typically, a large transfer is not a random event. You know when you are about to launch a migration and can signal that information, either programmatically or through a GUI, to the SDN controller. The controller can then configure the forwarding plane to act appropriately.

The trick is doing so at the performance levels required for large production networks. For example, companies often prototype a solution using OVS, but find the solution doesn't scale when they try to roll it out to their production WAN.

Making SDN work on a 100G WAN is really hard. SDN solutions that work fine in top-of-rack applications run into scalability and manageability issues in such a demanding environment. They simply are not designed for this level of performance.

Designing SDN for performance networks
The key is to implement a programmable hardware approach that allows an SDN control plane access to a data plane that has been tailored to exactly the functionality the control plane requires. The system should leverage metering and QoS capabilities in order to enable operators to deal with these types of large flows. Operators then have the ability to define per-flow classification requirements as needed. They can also set appropriate meter rates and markers and police traffic.

When handling large flows, operators can also set up the committed and peak information rates and burst sizes to reflect the priority of the large flows and to provide a bandwidth guarantee. The large flow completes in a known time, and without disrupting the delivery of smaller flows within the regular traffic.

This is not a theoretical model; the technology exists today to design and implement an SDN system for performance networks that can pick out an individual flow from a 100G river of traffic and provide the necessary control for that flow's specific needs. This is analogous to picking a grain of sand from the middle of the desert.

We hear one thing over and over from operators: They want the ability to have very fine-grained visibility and control over their traffic physical device behavior, and they want it via open interfaces on their physical devices to allow them to progress at the pace of the industry as a whole, rather than the pace of a single equipment vendor.

The customers have spoken. Are we all listening?

— Bruce Gregory, CEO, Corsa Technology Inc.

About the Author(s)

Bruce Gregory

CEO, Corsa Technologies

Bruce is leveraging a long history of early-stage start-up successes across multiple industries to lead Corsa as it emerges onto the world stage. Bruce served as President & CEO of Extreme Packet Devices (EPD), where he oversaw the growth of EPD from its genesis to a successful acquisition by PMC-Sierra in 2000. Prior to EPD, Bruce was the VP of Technology at Cadabra Design Automation, an EDA company that was acquired by Numerical Technologies in 2000.

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like