WG Action: Formed Transport Services (taps)

[The IESG <[e-mail]>]

A new IETF working group has been formed in the Transport Area. For
additional information please contact the Area Directors or the WG Chair.

Transport Services (taps)
------------------------------------------------
Current Status: Proposed WG

Chairs:
  Aaron Falk <[e-mail]>

Assigned Area Director:
  Spencer Dawkins <[e-mail]>

Mailing list
  Address: [e-mail]
  To Subscribe: https://www.ietf.org/mailman/listinfo/taps
  Archive: http://www.ietf.org/mail-archive/web/taps/

Charter:

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) Specify the subset of those Transport Services, as identified 
   in item 1, 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.

3) Specify experimental support mechanisms to provide the Transport 
   Services identified in work item 2. 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, or creation of transport protocols 

- Language-specific APIs 

TAPS is not chartered to perform detailed analysis of the security 
aspects of transport protocols. While security can be a transport 
service, TAPS is being chartered almost simultaneously with TCPINC, 
which is developing the TCP extensions to provide unauthenticated 
encryption and integrity protection of TCP streams, and TAPS will 
work with TCPINC to ensure that TAPS will be able to accommodate 
the protocol extensions that TCPINC defines. 

Milestones:
  Jun 2015 - Submit an Informational document to the IESG defining a set
of services provided by IETF transport protocols and congestion control
mechanisms
  Dec 2015 - Submit an Informational document to the IESG recommending a
minimal set of Transport Services that end systems should support
  Mar 2016 - Submit an Experimental document to the IESG specifying one
or more methods to provide applications with the Transport Services
identified by the WG
  Mar 2016 - Recharter or conclude.