The Transport Services (taps) WG in the Transport Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Transport Services (taps) ----------------------------------------------------------------------- Current status: Active WG Chairs: Aaron Falk <aaron.falk@gmail.com> Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com> Assigned Area Director: Spencer Dawkins <spencerdawkins.ietf@gmail.com> Transport Area Directors: Spencer Dawkins <spencerdawkins.ietf@gmail.com> Mirja Kühlewind <ietf@kuehlewind.net> Mailing list: Address: taps@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/taps Archive: https://mailarchive.ietf.org/arch/browse/taps/ Group page: https://datatracker.ietf.org/group/taps/ Charter: https://datatracker.ietf.org/doc/charter-ietf-taps/ Most Internet applications make use of the Transport Services provided by TCP (a reliable, in-order stream protocol) or UDP (an unreliable datagram protocol). We use the term "Transport Service" to mean an end-to-end facility provided by the transport layer. That service can only be provided correctly if information is supplied from the application. The application may determine the information to be supplied at design time, compile time, or run time and may include guidance on whether the facility in question is required or simply a preference by the application. Four examples of Transport Services are reliable delivery, ordered delivery of data, content privacy to in-path devices, and minimal latency. Transport protocols such as SCTP, DCCP, WebSockets, MPTCP, and UDP-Lite and the LEDBAT congestion control mechanism extend the set of available Transport Services beyond those provided to applications by TCP and UDP. For example, SCTP provides potentially faster reliable delivery for applications than TCP because it can accept blocks of data out of order, and LEDBAT provides low-priority "scavenger" communication. However, application programmers face difficulty when they use protocols other than TCP or UDP. Most network stacks ship with only TCP and UDP as transport protocols. Many firewalls only pass TCP and UDP and some only allow TCP when it carries HTTP as its payload. As a result, using other transport protocols or building a new protocol over raw sockets risks having an application not work in many environments. Applications, therefore, must always be able to fall back to TCP or UDP, or even to using HTTP as a transport substrate in some cases, and once the application programmer has committed to making an application work on TCP or UDP or HTTP, there is little incentive to try other transport protocols before falling back. Further, different protocols can provide the same services in different ways. Layering decisions must also be made (for example, whether a protocol is used natively or tunneled through UDP). Because of these complications, programmers often resort to either using TCP or HTTP or implementing their own customized "transport services" over UDP. When application developers re-implement transport features already available elsewhere they open the door to problems that simply using TCP would have avoided and ensure that the applications can't benefit from other transport protocols as they become available. And, since even TCP and UDP are not guaranteed to work in all environments today, some programmers simply give up on using TCP or UDP directly, relying instead on "HTTP as a Substrate". BCP 56 identified many issues with this strategy, but assuming that if "any protocol is available on a given network path and on the hosts that will be communicating, that protocol will be HTTP" is a reasonable strategy for today's Internet. The IESG has agreed with this viewpoint enough to publish the WebSocket protocol on the standards track. The goal of the TAPS working group is to help application and network stack programmers by describing an (abstract) interface for applications to make use of Transport Services. The Working Group deliverables emphasize defining Transport Services that are important to applications followed by experimental mechanisms to a) determine if the protocols to provide the requested services are available on the end points and supported along the path in the network and b) fall back, i.e., select alternate, possibly less-preferred, protocols when desired protocols are not available. The Working Group will not define a richer set of Transport Services for applications, although the TAPS deliverables could inform proposals for future chartered work on Transport Services. The Working Group will: 1) Define a set of Transport Services, identifying the services provided by existing IETF protocols and congestion control mechanisms. As a starting point, the working group will consider services used between two endpoints. 2) Analyze, compare, and contrast properties and dependencies of selected IETF transport security protocols and other relevant security protocols as agreed upon by working group participants. Define a set of security-related Transport Services provided by such protocols. Engage with the Security area to solicit feedback and reviews on all relevant documents. 3) Specify the subset of Transport Services, as identified in items 1 and 2, that end systems supporting TAPS will provide, and give guidance on choosing among available mechanisms and protocols. Note that not all the capabilities of IETF Transport protocols need to be exposed as Transport Services. 4) Specify experimental support mechanisms to provide the Transport Services identified in work item 3. This document will explain how to select and engage an appropriate protocol and how to discover which protocols are available for the selected service between a given pair of end points. Further, it will provide a basis for incremental deployment. Work on this document will begin when the TAPS Transport Services have been specified. The following topics are out of scope for this Working Group: - Signaling-based Quality-of-Service (QoS) mechanisms - Definition of new encapsulations and tunneling mechanisms - Extension, modification, and creation of transport or security protocols - Language-specific APIs Milestones: Jul 2018 - Submit an Informational document defining a set of security-related Transport Services Nov 2018 - Submit an Informational document to the IESG recommending a minimal set of Transport Services that end systems should support Mar 2019 - Submit document(s) to be published as Proposed Standard to the IESG specifying one or more methods to provide applications with the Transport Services identified by the WG Jul 2019 - Recharter or conclude.
