Transport Services can play a vital role in transport protocol evolution
The Transport Services (TAPS) Working Group addresses one of the trickiest challenges that application and service developers face while designing and deploying an application or service: choosing a transport protocol to use. Different applications and services have different requirements. Some, for example, can be tolerant of delay but not of lost data, like file download; others are very sensitive to delay but can accept some data loss, like interactive video. Over time, the IETF has standardized several transport protocols in order to address different application requirements, including TCP for reliability, UDP for unreliable and unordered data, Stream Control Transmission Protocol (SCTP) for multiplexed data streams, and Datagram Congestion Control Protocol (DCCP) for congestion control without reliability. Developers need to understand the capabilities of the various IETF protocols to determine which one is the best fit for their applications and services. If they identify a protocol that is not vanilla TCP or UDP, it may not work end-to-end. Frequently, middleboxes, such as Network Address Translations (NATs), firewalls, and load balancers, block or break unfamiliar protocols. As a result, developers have a strong incentive to choose only between TCP and UDP, and many potential improvements in Internet transport protocols are impeded.
TAPS addresses this situation by defining the relationship between the application and the transport layer in terms of services. In the TAPS model, an application specifies the service features it requires from the transport, and a TAPS mechanism selects the best possible transport protocol to serve the purpose, possibly using probing to verify end-to-end transparency. In this way, the applications can take advantage of modern transport protocols, thereby enabling the network provider and/or stack developer to utilize new protocols and protocol features without breaking the applications.
TAPS does face several challenges. The TAPS Working Group must understand application developers’ requirements on transport. The approach used is to create an abstract interface between application and transport, where application preferences and requirements can be expressed. However, there will be situations where an application would like to influence the way transport works in a very protocol- or OS-specific way. One example would be an application that wishes to influence path selection where there is more than one path available. The transport might not have the knowledge about the cost associated with a certain path that the application may have. Another example is an application capable of handling certain adaptations that might be seen as a job for transport protocol, such as Dynamic Adaptive Streaming over HTTP (DASH) adaptive bitrate for streaming services. These sorts of optimizations are needed, and in turn, the understanding of both applications and transports are needed in order for the TAPS model to be successful. This combination of expertise can be rather rare in our community.
Because TAPS creates an abstraction layer between the application and transport, we need to understand the existing interfaces of each transport protocol. One of the current issues is the lack of proper interface descriptions in RFCs, as well as the differences between what is implemented in the protocol stack and what is specified in the RFC.
There exists a chicken-and-egg problem with new transport protocols. The lack of transparency inhibits application developers from making use of the new protocols, as they require additional fall-back mechanisms for the parts of the Internet where they don’t work. However, without the pressure of new protocols being used, there is little incentive for middlebox operators and vendors to fix their behavior and permit protocols other than TCP and UDP. The TAPS Working Group endeavors to break that deadlock by making it easier for application developers to probe and fallback (e.g., by using a TAPS library). This solution would facilitate the use of new protocols where the network permits and would make partial transparency useful.
The IETF recently published the HTTP/2 standard and there are proposals to start working on new transport protocols, such as QUIC and PLUS. While HTTP/1 is still dominant in the Web world and TCP/SCTP is still evolving, the TAPS Working Group can promote that both application and network developers try new transport protocols with new features and help evolve the upcoming transport protocols. It is a unique opportunity for the entire community—including application developers, service providers, protocol stack developers, and network vendors—to collaborate in TAPS to ensure the natural evolution of transport protocol.