NFV and SDN are not the only factors that are forcing changes on network engineers; new protocols are coming, too.
“May you live in interesting times.”
The old Chinese proverb rings true as the current set of changes sweep through the networking industry. Not only are we learning about NFV and SDN, there are new transport protocols that will require new education and new troubleshooting tools. I became aware of the new protocols when reading about WebRTC (browser-based real-time collaboration – video in the browser). (See “Speeding Up the Internet” for a related post about speeding up the Internet.)
Wait! New transport protocols? What’s wrong with TCP and UDP? Well, there are several things that could be improved. Instead of repeating them here, you can read about them in RFC4960, Stream Control Transmission Protocol, Section 1.1. And these problems don’t include the impact of bufferbloat on TCP throughput.
UDP has its own problems. Software developers have to build message handling, fragmentation and reassembly, and congestion control into their applications. That’s a lot of work and a lot of code to include in each application.
The new protocols are the Stream Control Transmission Protocol (SCTP—see RFC4960), SPeeDY (SPDY—see “SPDY: An experimental protocol for a faster web”), and Quick UDP Internet Connections (QUIC—see “QUIC, a multiplexed stream transport over UDP”). SCTP was created to transport PSTN signaling over IP networks without the problems of TCP. SPDY was created, primarily by Google developers, to improve the performance of HTTP on the wire. It performs HTTP multi-stream compression and encryption with SSL/TLS over TCP. QUIC is a successor to SPDY that uses UDP as its transport in order to avoid some of the problems inherent in TCP. According to Google, about half of all Chrome browser interactions with the Google search engine are using QUIC. Another interesting tidbit about QUIC is that using UDP allows its congestion control mechanisms to be developed outside the OS kernel. Making changes to kernel networking code is nearly impossible, so moving the task into user space code allows researchers to easily deploy new technologies without requiring an OS upgrade. This is very cool.
These new protocols are good. They address many of the problems and inefficiencies of traditional protocols. We will need to understand how these new protocols work and how to troubleshoot them, just as we had to understand TCP’s windowing functionality over long fat pipes in order to achieve high throughput flows.
There are other changes that these protocols bring. Firewalls and load balancers will need to understand and handle the new protocols. Stateful firewalls, in particular, will need to be modified to handle QUIC, which runs over UDP and can start a connection between a client and server in one or two round-trip times. The encryption and compression of data on the wire will require that network analysis tools be updated to understand and decode the new protocols. Tools that sniff packets on the wire, like Wireshark and Application Performance Management systems, will need to adapt to the new protocols. I’m sure we’ll also need new troubleshooting tools to supplement the existing tools.