It's becoming recognised that many of the problems with the current Internet are caused by fundamental properties of Internet Protocol (IP). So we need a different way of routing packets, and to define it early in the process so that the rest of the system can take advantage of the improved service it provides.

What might a better form of routing for the 21st century look like? What can we do now that wasn't viable when IP was developed, around 1980?

The majority of access to the Internet is now via mobile devices, so it needs to be mobile-friendly: in addition to the problems with addressing, security, and QoS (Quality of Service, how reliably packets are delivered) that are by now well-known, it needs to make efficient use of the communication channel (because radio spectrum is a scarce resource and is expensive) and minimise power requirements. Current-generation (4G) mobile systems use IP in the radio access network, and the protocol layers that have been added for security and mobility mean that at some points in the system every packet has three IP headers, an overhead of typically 120 bytes, even if the packet only carries a small number of bytes of information. Header compression can reduce these overheads, but requires significant processing which drains the battery on mobile devices and adds delay.

Back when IP was developed, it made sense that all the processing of packets should be by software, because anything that needed more than a very few logic gates was expensive and communications links were slow enough that the software could process the packets as fast as they could arrive. Also, memory was a scarce resource, so it was reasonable to keep as little "state" as possible.

Now, memory and logic gates are plentiful. The smallest Xilinx FPGA (programmable logic chip) contains the equivalent of several thousand of the 74-series chips that were used for logic in the 1980s, as well as memory and multiply-accumulate functions. Since 1980, dRAM memory chip sizes have increased by a factor of about a million, although memory interface speeds (and processor speeds) have only increased by about a thousand. Line speeds on transmission links have gone up by a factor of many thousands.

Thus in the 21st century we can keep much more state but need to minimise the amount of processing each packet needs.

IP regards each packet as a separate entity, to be routed according to the information in its header. But in practice nearly all packets are part of some kind of sequence or "flow", such as a TCP or RTP session. (TCP is the protocol used for data communication functions such as web browsing; RTP is used for live transmission of media such as audio and video.) An application creates a "socket", identifies the entity with which it wants to communicate, and thereafter simply uses a "handle" (typically a 32-bit number) identifying the socket to show how a transmitted packet should be routed. Extending that model through the network (so that instead of the IP header there is simply a handle or "label" identifying the flow) removes the need for header compression. When the flow is set up, the application's requirements can be signalled explicitly, rather than using the kind of guesswork that is common in IP networks. This kind of routing was one of the better features of ATM (a 1990s telecom technology); it makes an appropriate division of labour between the "control plane" software that decides the routes and the logic that forwards the packets, and also allows multiple addressing schemes to be supported. Furthermore, it supports all levels of identification of a communication partner, from complete anonymity (not even an address being disclosed) to requiring authentication before data transfer begins. When a mobile device changes its point of attachment, each flow can be transferred without affecting the rest of its route. Multi-protocol label switching (MPLS) is a similar technology used in current networks, though providing much less communication of the application's requirements.

That covers addressing, security, mobility, and efficiency, but what about QoS?

There are basically two kinds of digital traffic, which I call "IT" and "AV". Typical IT (information technology) functions are moving a file from one place to another, or sending a request to a web server and getting a reply. Requests happen at unpredictable intervals, and the amount of data for each is also unpredictable, so a "best effort" service is appropriate. Unreliable delivery can be tolerated, with lost packets being retransmitted.

The typical AV (audio-visual) function is transmission of live audio, video, or similar content. Here there is a constant stream of data, at a fixed (or anyway bounded) bit-rate, and the timing of the arrival of every packet is important; we are all familiar with the clicks, pauses, and distortion that occur when listening over the current Internet. Round trip latency (delay) is critical for many applications, especially some of the new applications proposed for 5G (the new generation of mobile systems), and typically there isn't time to retransmit lost packets. Resource reservation is needed to ensure reliable delivery with bounded latency, and packet flows must be synchronised if the lowest latency is to be achieved.

On wired links it has been found to be quite easy to implement a synchronised AV service offering latency of less than ten microseconds per hop, with all the bytes on the wire that are not occupied by AV packets being used for a label-switched IT service. A similar regime should be possible on wireless links. The AV packets don't need flow labels, because they are identified by their time of arrival, so no part of the packet needs to be read in order to route it; this may make routing in the optical domain easier. For more details see http://www.ninetiles.com/Flexilink_details.html

An interesting possibility is that larger file transfers might also use the AV service, setting up a unidirectional flow at a rate which is negotiated by the sender, the recipient, and the network. This eliminates the need for most of the problematic features of TCP, with the recipient simply sending a control plane message at the end of the transfer, confirming receipt or requesting a repeat of certain packets.