Do you remember when we used multi-protocol routing for IPX, AppleTalk, and TCP/IP running on the same network? In the 1980s and early 1990s many enterprises had multiple protocols running on the physical network infrastructure as "ships in the night." Cisco routers became highly adept at multi-protocol routing and the company grew in prominence as a result. Then in the early 1990s, TCP/IP won out and the internet took shape as the global network we enjoy today.
The TCP/IP protocol uses a very simple four-layer model (Application, Transport, Internet, and Link Layer). TCP/IP's layers are much simpler to remember than the seven-layer Open Systems Interconnection model (OSI model) conceived in the 1980s. To remember all those layers some use the pneumonic device (All People Seem To Need Data Processing) to remember (Application, Presentation, Session, Transport, Network, Data Link, Physical). IPv4 was the only protocol at the narrow waist of the TCP/IP hour glass, but now IPv6 has added a second protocol to the internet layer.
The internet has been under constant development since its inception in the 1970s. TCP/IP has continued to be optimized from its original design. Protocol designers have continued to create new internet transport layer protocols improve how internet applications perform. These protocols try to improve upon TCP and UDP and add congestion control and optimized throughput forwarding performance.
Some of these protocols are esoteric and handle rare corner cases. Some of these protocols may already be in use for your internet connections and you don't even realize it. This article will break down these new Internet Protocol optimizations and show which ones are most impactful for your organization and can improve your Internet application experience.
Multipath TCP (MPTCP)
Most networks do not have any redundancy and, therefore, there is only one available path from the source of a connection to the destination. However, the internet is very "meshy" and there are many different possible paths between any two nodes. Network equipment has historically handled multiple equal-cost paths in one of two ways: either packets are broken up without regard for connection and sent over both paths, or all the packets sent for a single connection takes one path and different connections are sent over diverse paths. The first method can cause problems for traditional TCP connections, while the second method works well with TCP.
+ MORE ON NETWORK WORLD 25 years of TCP/IP +
Multipath TCP (MPTCP) (RFC 6824) addresses the first problem of having a single TCP connection use multiple paths where the packets can be split up randomly among the different paths. In this way, all the resources of the multiple links contribute to throughput and connection resiliency is a byproduct of having multiple paths. You can think of this as the TCP equivalent of the transport independence concept in many of the Software-Defined WAN (SD-WAN) products on the market. MPTCP is implemented in Apple iOS and Mac OS X as well as several popular server load balancers.
Data Center TCP (DCTCP)
Traditional TCP congestion control tolerates packets getting dropped in transit and reduction in the TCP congestion window size which reduces the transmission rate. Over the years, the TCP has been the focus of many research projects to optimize the congestion control algorithms. Explicit Congestion Notification (ECN) (RFC 3138) is a method of signaling congestion encountered in transit before packets actually get dropped.
As the source sends packets toward the destination, if congestion is encountered, the network device marks the ECN bits in either the low-order 2 bits after the DSCP marking in the IP header, or flags within the TCP header. When the destination receives the packets indicating that congestion is imminent, the destination relays that alert back to the source to slow its transmission to avoid future packet loss and resulting retransmission and throughput reduction.
Implementation of ECN has been problematic on the internet due to middle boxes not properly handling the ECN marking process. ECN is being applied to other protocols, such as RTP/RTCP (RFC 6679) and for SCTP (see below). The protocol designers at the IETF are looking at other ways to use ECN to help avoid congestion. IETF RFCs such as "Congestion Exposure (ConEx) Concepts and Use Cases" (RFC 6789) and "Problem Statement and Requirements for Increased Accuracy in ECN Feedback" (RFC 7560) document some potential options.
This has led to the development of a new protocol called Data Center TCP (DCTCP) that makes improvements on congestion notification for data center switching environments. DCTCP alerts early on congestion and tries to quantify the amount of congestion to signal to the source to reach the optimal forwarding rate. DCTCP has been documented in an IETF draft and it has been researched by Stanford University and Microsoft with Windows Server 2012. Cisco's Nexus 3548 switches use DCTCP and there is interest by other data center switch manufacturers.
TCP AnyCast
You may already be familiar with the concept of anycast, where the principle of uniqueness of IP addresses is violated and multiple systems use the same address. Those identical systems advertise that single IP address into a dynamic routing protocol. Clients wanting to communicate with that service communicate with the "closest" instance of that synchronized content. If one of the services fails, it withdraws its route advertisement, the routing tables converge, and service is restored. Whereas unicast communications is one-to-one, anycast is more like one-to-nearest. The internet already uses anycast extensively with the root DNS name servers.
Anycast has historically worked well for quick stateless communications like DNS queries, but hasn't worked so well for long-lived TCP sessions that might be affected by a server failure and route convergence. There have been discussions for several years about how to extend this anycast concept to TCP communications. Back in 2006 there was a NANOG 37 presentation titled "TCP Anycast -- Don't believe the FUD", by Matt Levine (CacheNetworks), Barrett Lyon (BitGravity), and Todd Underwood (Renesys). More recently, Matt Levine, from CacheFly, wrote about "Measuring Throughput Performance: DNS vs. TCP Anycast Routing". LinkedIn has been testing TCP Anycast and last year they published a paper titled "TCP over IP Anycast - Pipe dream or Reality?".