Subject: [Taps] another charter rev

From: Aaron Falk <[email-masked]>
Date: Sat, 26 Jul 2014 12:30:51 -0400

Hi Folks-

I've been working on a few changes that I think clarify the charter,
particularly the document goals.  Since I wasn't part of the initial
discussions I may have misunderstood where there is agreement.  For
example, the role of the second document seems to be really about getting
consensus on some requirements for the third.  Please take a look at this
and send comments to the list.  If you are suffering from charter fatigue,
you may want to reference the attached diffs against the last rev I sent
(charter-20140722e) and the version in the IETF datatracker
(charter-20140717).

--aaron

------------------
Last updated 2014-07-26
Transport Services (taps)

The vast majority of 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 can only be
correctly provided with information from the application. This information
may be provided at design time, compile time, or run time. Four examples of
Transport Services are reliable delivery, no guarantee of order
preservation, content privacy to in-path devices, and minimal latency.

Other transport protocols such as SCTP, DCCP, MPTCP, 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 that
can accept blocks of data out of order, and LEDBAT provides low-priority
"scavenger" communication.

Application programmers face difficulty when they use protocols other than
TCP or UDP. Most network stacks only support TCP and UDP, and many
firewalls only pass TCP and UDP, so using other transport protocols risks
having an application not work in many environments. Applications,
therefore, must always be able to fall back to TCP or UDP, and once the
application programmer has committed to making an application work on TCP
or UDP, 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 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 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 TCP would
have avoided, and ensure that the applications can't benefit from other
transport protocols as they become available.

Alternatively, programmers may simply give up on using transport protocols
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 Websockets
protocol on the standards track.

The goal of the TAPS working group is to help application and network stack
programmers by describing an (initially abstract) interface for
applications to make use of Transport Services. The Working Group
deliverables emphasize definition of Transport Services important to
applications followed by experimental mechanisms to a) determine if those
Transport Services are available on the end points and along the path in
the network and b) fall back when desired services 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, prioritizing those provided by
existing IETF protocols and congestion control mechanisms. As a starting
point, the working group will consider services used between two endpoints.

2) Note that not all capabilities of IETF Transport protocols need to be
exposed as Transport Services. This document will recommend the minimal set
of Transport Services that support mechanisms must provide (such as those
in work item 3). The resulting document will also provide guidance on
making a choice among available mechanisms and protocols to obtain a
certain Transport Service.

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 a given connection. 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, but 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:

M9: Submit summary of the services provided by IETF transport protocols and
congestion control mechanisms to IESG.
M15: Submit end system transport services to IESG.
M18: Submit specification of how the transport services can be provided to
IESG.
M18: Recharter or close.