Citius, Altius, Fortius (“quicker, higher, stronger”), is the Olympic motto that pushes athletes to give their utmost while competing.

With dozens, or even hundreds, of applications in fixed or mobile devices, all connected at the same time and competing for bandwidth, one might say the telecommunications sector is almost as competitive as the sports world. This competition grows when several users, machines and other IoT devices share the same network. What mechanisms exist to bring order to this chaos?

TCP/IP Protocol

Most of the merit lies with the TCP/IP protocol design. Almost half a century after its conception, it remains the undisputed option to connect network devices (no small feat considering the pace at which technologies have evolved since then). Two TCP mechanisms are the key to its success: Slow Start and Congestion Avoidance. Despite not being able to go into detail here, it is enough to know they manage data transfer speeds depending on the network’s availability. It is as if each of our applications was a courier that had to send its vans (IP packets) along a highway. It doesn’t matter how many lanes there are, we all know a traffic jam is possible. The magic of TCP is that it is able to give each courier a fair number of vans that can drive around, based on the highway’s capacity and avoiding any jams that could cause delays (this translates into less deliveries, but guarantees all of them are made on time).

UDP Protocol

Unfortunately, this isn’t enough to provide a good user experience for 2 reasons. On the one hand, TCP is not the only protocol used. The most relevant alternatives are UDP, often used in telephony over IP, and traffic management protocols like DNS, NTP or SNMP. Going back to our previous example, UDP and the other protocols would be service vehicles driving on the highway (like police cars, ambulances, or maintenance vehicles). They do not increase transport capabilities but are necessary for the system to work. The “problem” is that these protocols do not have the TCP mechanisms to adjust traffic to bandwidth availability. Quite the contrary, they generate traffic at the rate they need it (regardless of any external elements). On top of this, storing this traffic in a buffer to transfer it when there is higher availability is seldom feasible. Telephony over IP traffic is a good example to illustrate this.

On the other hand, even amongst applications using TCP, sharing the bandwidth in an equitable manner is not always enough, since some are more critical than others. For example, sending an e-mail with a slight delay (a few seconds) is not a problem, but in transactional applications (telephony over IP or videocalls) fractions of a second can be the difference between a frustrated and a satisfied customer.

QoS  – Quality of Service

Here is where QoS – Quality of Service techniques come into play. They are the set of rules added to the network so that different applications can use it while maximizing user experience. QoS is necessary because networks do not have unlimited capabilities. As such, they are inserted in so-called “bottle necks” (which is where the congestion is generated, usually at the entry and exit points of the highway).

Despite there being a wide range of QoS techniques, we will focus on three of them:

1. Prioritization: Involves processing first the traffic coming from applications that are more critical to the user. This reduces latency and improves user experience (e.g., prioritizing telephony over IP is key, and doing the same for transactional applications is recommended).
2. Bandwidth reservation: Guaranteeing a minimal flow for certain applications in the event of a bottleneck becoming congested (ToIP is, once again, a clear example since a small package loss would mean holding a conversation is impossible). However, when using TCP, most applications recover quickly from limited packet losses or (in worst case scenarios) learn to operate with less availability.
3. Traffic shaping: Linked to prioritization, since the unlimited prioritization of important traffic can lead to non-priority traffic being blocked and to application downtime. We prioritize, but up to a limit.

Applying QoS to access devices in IP networks is mandatory, but it is not enough if we don’t control the rest of the network (since bottlenecks can take place at the core). For instance, let’s take a network where hundreds or thousands of remote users want to simultaneously access one resource located at the datacenter. Here, we will find a “downstream DC bottleneck” and the network will be the one to randomly queue up/discard packages. This will affect applications that support latency/discards and those that don’t equally.

The solution is obvious. Apply QoS at the core as well. This is what MPLS networks do, and, thanks to them, we can build predictive models where user experience is guaranteed.

Internet or MPLS

The use of Internet lines as an alternative/support to MPLS transport is a reality. Among other advantages

• There is more competition
• They are cheaper
• There are more connectivity options
• They can be deployed faster
• They offer better direct access to top SaaS applications, etc.

However, we cannot forget that, without controlling the core as well, our predictions will not be accurate enough to guarantee user experience in critical applications. Thus, they are a good option to support MPLS networks and increase bandwidth (dealing with traffic that is not very sensitive to changing network conditions). Another option is to contract lines with a much higher throughput than expected to minimize or prevent bottlenecks.

Teldat’s SD-WAN solution incorporates all QoS mechanisms generated by the Company’s know-how from more than 35 years of experience in demanding corporate networks (implemented in SD-WAN devices and MPLS networks to build predictable networks and guarantee user experience).