Transport Services (TAPS) Birds-of-a-Feather

The Stream Control Transmission Protocol (SCTP), Datagram Congestion Control Protocol (DCCP), MultiPath Transmission Control Protocol (MPTCP), and User Datagram Protocol-Lite (UDP-Lite) protocols and the Low Extra Delay Background Transport (LEDBAT) congestion control mechanism offer a large number of services to applications, in addition to the long-standing two services provided by TCP and UDP. For example:

• SCTP provides reliable and potentially faster-than-TCP delivery of data chunks to applications that may be able to accept such chunks out of order.
• DCCP provides various forms of congestion control for applications that need it, but prefer their packets be dropped rather than retransmitted, as the latter can lead to delay.
• LEDBAT provides a scavenger-like background transfer mode, in which LEDBAT traffic does not get in the way of other transfers that use TCP, for instance.

As useful as these services may be, implementing them can be difficult: not all protocols are available everywhere, hence fall-back solutions are often required. In addition, some protocols provide the same services in different ways, and layering decisions must be made (e.g. should a protocol be used natively or over UDP?). As a result, some programmers resort to using TCP or implementing their own customized solution over UDP (e.g., Google with Quick UDP Internet Connections (QUIC)¹ and Adobe with Real-Time Media Flow Protocol (RTMFP)²), at which point the chances of benefiting from other transport protocols are lost.

The intention of the Transport Services (TAPS) initiative is to identify the services provided by IETF transport protocols and congestion control mechanisms, as well as the network requirements of applications and the APIs they use to communicate. By mapping the connections between these lists, a later working group (WG) may define services that a transport API should offer. It could then specify howthese transport services can be implemented using native IETF transports and encapsulated transports, including the definition of mechanisms to validate that a transport (or transports) can be supported on a path.

The TAPS initiative began in August 2013 with a mailing list and an accompanying Web page. We held a Bar Birds-of-a-Feather (BoF) at IETF 88 in Vancouver, where it was already clarified that TAPS should be careful to provide what application programmers really need, rather than being too focused on the Berkeley Sockets application programming interface (API). Accordingly, several Internet-drafts were written, including use cases and an overview of how higher level APIs could better be supported by enhanced IETF transport services. By breaking the dependency of applications on specific protocols, TAPS has the potential to make the currently rigid transport layer more flexible (figure 1). In December 2013, a presentation was given at the Internet Architecture Board (IAB) Workshop on Internet Technology Adoption and Transition in Cambridge, UK, explaining how the evolutionary benefit of TAPS is connected to its best-effort nature. These activities culminated in a BoF meeting at IETF 89. This BoF was designated “non-WG-forming” to enable the IETF community to discuss the various angles of this large problem space without having to spend time on charter wordsmithing. Discussion was lively at this two-hour long session that included 129 attendees and a debate at which more than 6,650 words were spoken at the microphone.

The following four individuals presented their viewpoints at the TAPS BoF:

1. Jon Crowcroft outlined the potential of this activity by calling it “socket science” and relating it to security.
2. Martin Sustrik presented how middleware, such as his own ZeroMQ, could benefit from transports other than TCP; most notably, he explained how the strict reliability of TCP is a poor match for pub/sub communication. Middleware layers are increasingly common and often have enough information about what the user is trying to achieve to be able to make informed transport choices on their behalf. Updating middleware offers an easy deployment path, in which applications could exploit some of the benefits of TAPS without having to be changed unless recompiling with a new version of the middleware (figure 2).
3. Gorry Fairhurst presented a possible implementation of TAPS.
4. Margaret Wasserman presented the API of the Multiple Interfaces (MIF) WG. This API is clearly related, and it seems obvious that a TAPS API should be somehow connected to the MIF API.

Each presentation was accompanied by an active debate—not everyone in attendance was in agreement with every presented way of providing transport services. The major concerns that were raised include:

• Predictability. The flexibility shown in figure 1 comes at a cost—application programmers may need a predictable behavior, whereby a certain way of using an API consistently leads to the same protocol choice underneath. It was suggested that such decisions are better made at development time than at runtime.
• Safety. The importance of testing was emphasized; changing the transport protocol must not break an application.
• Binding mechanisms. Going beyond the TAPS proposal, the support of name-based transports instead of IP-address-based transports was suggested as an option.
• Layer versus API. Several participants stated that TAPS should not be focusing on an API. It was suggested that (1) TAPS be thought about in terms of a layer, and (2) it be left to the operating systems that interface with applications to build the API and to produce the layer that we want with the information we want and whatever APIs are needed.

An ongoing conversation about next steps is occurring among the Transport Area (TSV) area directors (ADs) who sponsored the TAPS BoF, the Applications Area and Real-time Applications and Infrastructure Area Directors, and interested IAB members. The group’s mailing list ([email protected]) currently has 120 subscribers, and can be joined at https://www.ietf.org/mailman/listinfo/taps. The accompanying webpage is at https://sites.google.com/site/transportprotocolservices.

Note: Activities of some TAPS participants (i.e., Michael Welzl and Gorry Fairhurst) were partly funded by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700). The views expressed are solely those of the author.

Footnotes

1. http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf
2. RFC 7016, “Adobe’s Secure Real-Time Media Flow Protocol”