Tariffs, trade balances and networking – help the network do what the business needs.
By Patrick MeLampy
This blog was originally posted on the Network World blog: No WANs Land
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.
Patrick MeLampy is the Co-Founder and Chief Operating Officer at 128 Technology.
The original post can be found here.