other. Table 2.1 list the communication units and PDUs the respective protocols use at their interfaces to the layers they provide transport service for (upper) and to the layers they use transport service from (lower). The corresponding comparison of the functionality provided by the protocols is shown in Section 2.10, Table 2.3.
For the remainder of this section, we revisit how these protocols compose, whether they can maintain communication units that allow to use application-aware mech-anisms at lower layers and highlight some trade-offs originating from granularity issues.
2.4.1 Application Layer
Most application layer protocols such as HTTP and XMPP are designed to be layered over TCP, the only widely available protocol that supports reliable trans-port. Therefore, these protocols use a byte stream as PDU towards the lower layers, as expected by TCP. Despite that HTTP requests and XMPP messages have clear message boundaries, these messages are indistinguishable for TCP and all layers be-low and, thus, inaccessible for optimizations at the layers bebe-low. This is the result of designing these protocols into an existing ecosystem instead of designing them as complete end-to-end systems described in Section 2.2.
Table 2.1: Internet Protocols’ Granularity and Interfaces
Layer Protocol Granularity PDUs
Upper Lower Upper Lower Application HTTP message stream messages bytes
XMPP message stream messages bytes
SIP message message messages varyingsip
DTLS message message messages messages
TLS stream stream bytes bytes
Transport RTP/SRTP varyingprf message messages⊚ messages
QUIC stream assoc. bytes⊛ PDUs
UDP message message messages IPT PDUs
DCCP message message messages IPT PDUs
TCP stream assoc. bytes IPT PDUs
MPTCP stream assoc. bytes IPT PDUs
SCTP message assoc. messages⊛ IPT PDUs
Network IPsect assoc. assoc. set IPT PDUs IPT PDUs
IP assoc. assoc. set IPT PDUs IP PDUs
NEMO/IFOM assoc. assoc. set IP PDUs IP PDUs
⊛Multiple parallel streams are supported.
⊚Messages are extracted from content by content-specific profiles.
IPTIP Transport PDUs — Protocols assume being layered on top of IP.
IPIP Packet — Regular IP packets
sipSIP transport can adapt to stream or message.
prfDetermined by content specific profiles - usually message or stream of messages.
t IPsec used in Transport Mode.
2.4 Analysis: Communication Units and PDUs The signaling protocolSIPis internally strictly message based. SIP comes with its own small transport layer that adapts SIP to the transport services of UDP, TCP, and SCTP. It maintains the message granularity as long it is run over message based transports.
Security add-ons such asTLSandDTLS are designed to slide in between applica-tion and transport. They use the PDUs of the transport’s upper layer interface also towards the application layer and, thus, can be used as add-ons for new and existing applications without requiring to changes to the communication units or pattern.
2.4.2 Transport layer
Next, consider the classic and most widely used transport protocols: TCP and UDP.
UDP is a message based multiplexing protocol that allows wrapping application messages. This usually results in sending one IP PDU per application message.
Thus, it maintains the messages granularity, but forces the application to make sure its message size does not exceed the MTU of the path or rely on IP fragmentation.
The Datagram Congestion Control Protocol (DCCP) is a drop-in replacement for UDP that adds congestion control.
TCPprovides a byte stream abstraction that resembles a bi-directional Unixpipe.
To maintain the properties of a pipe, it provides a rich set of transport services, including reliable transmission, in-order delivery and congestion control. MPTCP extends TCP with multi-path capabilities.
Note that the bundling reliable stream and unreliable message is rather a historic artifact than a conceptional one. The popularity of TCP and UDP and the lack of easily available alternatives forced protocols to adapt to either of these two options.
As a consequence, protocols that need transport services like reliable transport mes-sage transport (e.g., for HTTP requests) either use TCP or implement all required transport services on top of UDP. This comes with some trade-offs. For example, multiplexing independent messages into a reliable stream can cause unnecessary head-of-line blocking: The transport has no way to extract the messages and, in the presence of packet loss, can only deliver a prefix of the stream data without violat-ing the in-order property. Thus, it is forcviolat-ing the application to wait for completely unrelated messages. See Section 2.10.2 for more discussion.
SCTP is one attempt to provide a much more flexible abstraction: It transports multiple streams of messages within a single association with all transport services TCP provides. The different streams prevent head-of-line blocking of independent messages while providing in-order delivery for dependent messages. SCTP maintains the messages for the upper layer, but multiplexes and chunks these messages within a single association and, therefore, does not maintain the message granularity to the lower layers. It is very versatile, but cannot be used as a drop-in replacement for other transport services, since it uses a different abstraction and has a relatively complex programming interface. Moreover, it is blocked by many firewalls and only available on a few OSes. This limits its deployment.
QUIC is the newest addition to the transport protocol family. QUIC was origi-nally designed by Google as an application-aware drop-in replacement for TCP that prevents head-of-line blocking in HTTP. At the moment, it is in heavy flux and in the process of becoming a generic, state-of-the-art transport protocol. QUIC pro-vides multiple independent byte streams towards the upper layers, which makes it a feasible drop-in replacement for TCP while avoiding head-of-line blocking between different streams. As the creation of streams within an existing association is cheap, the messages for the upper layer can be maintained by sending each message over a new stream. The messages granularity is intentionally hidden from the lower layers by encrypting the whole protocol.
A very special case with regards to communication units takes RTP as it tries to maintain communication units of the upper layers. RTP uses application specific profiles which take the applications’ byte streams and chunk them into semantic messages. These messages can then be policed in application-aware ways, e.g., to implement congestion control, and multiplexed in a way that respects timing constrains. The protocol messages are assumed to be transported via UDP, but no UDP specific data is included into the RTP PDUs.
Some words about the lower layer PDU interface of the transport protocols discussed so far: TCP, MPTCP, UDP, DCCP and SCTP include an IP pseudo header in their checksum calculations and, thus, are required to be run over IP or an IP-like adaption layer. QUIC does not take parts of the lower layers into account and can be run on any message based transport.
2.4.3 Network Layer
With regards to network layer protocols, we only consider IP, IPSec in transport mode and, the Mobile-IP variants NEMO and IFOM. We chose the later three because these provide interesting examples with regards to their communication units and functionality. We ignore other VPNs as they, for our purpose, can be considered additional paths.
If strictly looking at the layering, IP2 can only distinguish hosts and upper layer protocols. Therefore, application awareness at this granularity is pretty limited.
As the OS on the endpoint still has state to match the IP PDUs to the transport protocols and their addressing/multiplexing, we still assume a per-association gran-ularity for any functionality at the network layer despite that strict layering would only give us corse per-association-set granularity.
A good example how this per-association granularity is used is the transport mode of IPsec as well as Flow Bindings in Mobile IPv6 and Network Mobility [27] (NEMO).
Internet Protocol Security [28] (IPSec) slides in between IP and other trans-port protocols to provide integrity and confidentiality protection. The decision whether to use IPsec is often done on a per-association level by OS level policies.
2IPv4 and IPv6 are identical with regards to their communication unit granularity.
2.5 Path Selection