Does your network have a trade imbalance?

Network traffic, by nature, is often unbalanced. For example, a client that requests a video on demand may receive ten times more bandwidth than it sends for that service. Likewise, most web applications are very one-sided, with the bulk of the traffic being from server to client. The opposite is true for many backup applications, where the bulk of the traffic originates at the client and terminates at the server.

The United States is like your network – suffering from a trade imbalance. For every packet we ship to a foreign network, we are receiving four or five in return. Just as there are barriers to trade, we apply barriers to our inbound traffic. The barrier for most of us is the actual size of our Internet service interface. Packets queue up and drop at our carrier’s equipment prior to even being seen by our equipment. If you purchase a 50Meg download speed, any packets that arrive at a faster rate (even for a sub-second of time) will be dropped without prejudice. This is a barrier, restriction and tariff on your services that limit your business. The only solution – buy more bandwidth!

Being an engineer, I wanted to understand just how complicated customs tariffs are. So, I downloaded the actual table of tariffs and discovered there are 19,758 tariffs on imported goods that are tracked by the World Trade Organization. I also realized that there are many other barriers to trade beyond tariffs including legal requirements, defined limits and regulatory requirements. To get a full picture on a bidirectional trade results in a lengthy document with very hard to understand notions of fairness.

As network engineers, we do not have the ability to classify and apply policies (tariffs & other barriers) to ensure fairness between all uses of a network. Our only response is to increasingly get larger network interfaces to stop people from complaining. We need the ability to understand on an application-by-application basis our trade imbalance and apply the necessary policies to make sure our businesses get the best value from their network resources. The very first step in solving a trade imbalance is to understand the actual trade, assign values to each type of trade, and then begin to apply policies to create fairness.

Network technologies have long understood that often client-to-server direction carries much less bandwidth than the server-to-client direction. Most speed tests and carriers today actually measure and quote internet speeds in both directions, download and upload. This means that networks need to be engineered twice – once for each direction. This is true for reachable routes, bandwidth, access control lists and so on.

Current network routers are stateless, and do not understand client-server connections. The connection of the client request with server response is missing. The true traffic planning/policing/sizing must be done on the “return path direction” for every outbound client session. Generic rules could be applied by protocol, but we need an understanding that some services are more important than others. YouTube over HTTPs should not get the same bandwidth as Skype for Business over HTTPs. One size bandwidth for all does not work unless you constantly are willing to purchase more bandwidth. 

If routers were able to track and understand client requests, and associate them with server responses, then routers could manage return bandwidth on a service-by-service basis. The science of dropping the correct packet at the correct time from the correct flow is possible with smart routing software. Think of this as “exact timely discard” as opposed to “random early discard,” or the more frequently used “tail drop.”

Outbound requests for bandwidth-intensive services could have policy restrictions specifically designed to preserve bandwidth for others. For example, a video player from a non-critical business application could be limited to 120kb on a session/by/session basis if there is available return bandwidth. Many of these applications have automatic detection of available bandwidth and adjust to fit. By providing a “constraint” on ingress, a service can be managed. This reserves bandwidth for other business-critical applications without.

It’s clear what’s missing. Routers need to understand applications. The language of applications is sessions. Routers need to have application-specific routing policies to help manage fair and balanced usage of the network. We need advanced next-generation packet processing platforms that are smart and can help the network do what the business needs.