Ads 468x60px

Featured Posts

19 de septiembre de 2016

Moving the Web from TCP to UDP



Networks are increasingly reliable today and maybe there are features of the TCP protocol that they are no longer useful. At the beginning, UDP could only be used by fast, streaming and real time applications where it doesn't matter to loss packets. However, reliable networks, like we have today, can also use the UDP protocol to transmit data over Internet for applications other than fast, streaming or real time where we even can't loss any packets. How can we use the UDP protocol to transmit data over the Internet in a reliable way? We have discuss in this blog about how to accelerate applications with HTTP/2 and Multipath TCP, but this time we are going to talk about the new experimental transport layer protocol called QUIC and developed by Google in 2012.

Every network engineer knows that a TCP connection has to perform a 3-way handshake, which means three packets have to be transmitted to start to send data packets. In addtion, if we want to encrypt the communication, we need to negotiate TLS, which means more packtes have to be transmitted before sending data packets. Obviously, 3-way handshake and TLS negotiation spend time to make a connection. Although, TCP Fast Open (TFO) was developed to improve the establishment, it isn't widely adopted yet. Therefore, the QUIC protocol is beyond TFO because it can start a connection and negotiate all the TLS parameters in one or two packtes, and what's more, Google is behind this project.

Zero RTT Connection Establishment

How does the Internet stack look like? As we can see in the next image, QUIC replaces TLS and a little bit of the HTTP/2 protocol, and it is over the UDP transport protocol. QUIC replaces TLS because it can make the crypto handshake, and QUIC replaces a little bit of HTTP/2 because it can make multiplexing and connection management which was usually done by HTTP. QUIC works over the UDP protocol, thus it implements congestion control and loss recovery.

QUIC Stack Standardized
 
One of the advantages of QUIC is the multiplexing connection because while in the TCP protocol we had to wait (buffered) each packet to order it before giving it to the application layer, and if there are missing packets we have to ask them for retransmision, the QUIC protocol isn't dependent on the order in which packets are received and if a packet is lost, it will only impact to an individual resource and it doesn't need to retransmit the entire connection.

Multiplexing

Another advantage of QUIC is the Multipath UDP. Due to the fact we don't have to establish a TCP connection we, as clients, can transmit data over different networks and technologies at the same time incrising bandwidth and availability as we have with Multipath TCP.

Multipath UDP
 
Another advantage of QUIC is the Forward Error Correction (FEC) feature which is something like a RAID 5 in datastores because QUIC can send redundant data in each packet to prevent retransmision when a packet is lost.

Forward Error Correction

How does QUIC work? As we can see in the next pictures, the first one is from a TCP connection which perform the 3-way handshake before the Client Hello packet. However, in the second picture we can see, over the UDP port 443, QUIC requests and responses, sending the Client Hello packet from the beginning of the connection, which make QUIC protocol faster than TCP establishment connections.

TCP Communication

QUIC Communication
 
We'll see in the near future if QUIC is widely adopted but anyway what it is a fact is the implementation of HTTP/2 along with SPDY, Multipath and Multiplexing which are concepts and technologies that we have to take into account when we deploy new services today. All of them improve the content delivery and we should know how they work to adapt our services and networks to this new paradigm.

Regards my friend and remember, drop a line with the first thing you're thinking.

12 de septiembre de 2016

Nagle's Algorithm



Nagle's algorithm is another feature to improve the performance of TCP/IP networks. There are many protocols, standards and technologies we should know, as network engineers, to understand the behaviour of our networks and thus improving the efficiency of our services like retransmitting only lost segments with SACK, be careful with hot potato and cold potato routing, implements Long Fat Networks (LFNS) in slow links or taking advantage of Multipath TCP. This is only some of the protocols, standards and technologies we should take into account to not going crazy when the behaviour and performance of our networks is not like it have to be.

Nagle's algorithm (RFC 896) was published in 1984 by John Nagle and it remains a standard feature of TCP today. It was designed to improve the efficiency of networks, using more bandwidth as possible at the expense of adding delays. It wants to reduce network congestion caused by “small packet problems” with TCP applications because there are applications and services that they send small packets, for instance 1 byte of useful data, over the network which is inefficient due to the fact that for sending only one byte we need to send from 20 to 60 bytes of headers as well. Therefore, many small packets have to be sent if we want to send only one byte of useful data. How it works with the Nagle's algorithm? Data are buffered and when there are enough information to transmit, it is sent it.

Nagle and non-Nagle comparative

Pros and Cons of the Nagle's algorithm? We can take advantage of transmiting the same amount of information with less packets and less overhead, as a result, we increase bandwidth efficiency which is useful in slow links with high latency. However, Nagle's algorithm is not useful in realtime and high interactive applications like chats or videoconferences where we should disable Nagle's algorithm or use the UDP protocol.

67 bytes to send 1 byte of useful data
 
To sum up, this is another standard which is useful to improve network efficiency in high demanding and business networks but we should know when it is recommended to be enabled and disabled because it can improve our network but also deteriorate it if we don't analyse properly the services, data and behaviour of our network. Anyway, if we need this feature we should look for this RFC when we are going to implement a new service or install a new appliance. For instance, F5 load balancer supports the Nagle's Algorithm in their TCP profiles.

Nagles Algorithm in F5 Profile

Regards my friend and remember, drop a line with the first thing you're thinking.
Related Posts Plugin for WordPress, Blogger...

Entradas populares