Subject: [Taps] updated draft TAPS charter

From: Aaron Falk <[email-masked]>
Date: Wed, 23 Jul 2014 09:07:38 -0400

Hi folks-

I've revised the charter based on the comments that have been submitted and
AD guidance. See the attached diff for the simplest presentation of the
changes. Mostly the revision clarifies the intent to match the discussion
and tweaks some of the scope boundaries.  I believe this reflects all the
submitted comments with the following exception.

We considered and rejected the suggestions to include exposure of Internet
and lower layer functionality (e.g., MPLS, SFC).    As the revision
clarifies, TAPS is about providing an abstract API for transport
facilities. Lower layers will of course be involved, but how transport
interacts with these lower layers is out of scope beyond the experimental
mechanisms described in the third doc.

I am still expecting (hoping for) some additional input from Dave Thaler on
the text for HTTP as transport.  Additionally, the IAB may provide input as
part of their BoF evaluation reporting, so more changes may come.  Comments
(including the 'thumbs-up' variety) are welcome.  Keep in mind the charter
review period ends on 7/31.

--aaron

*---------*
Last updated 2014-07-22e

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.

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 abstract interface for applications to make
use of Transport Services.  The initial 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:

- Identify Transport Services, prioritizing those provided by existing IETF
protocols and congestion control mechanisms. The resulting document will
provide guidance on making a choice among available mechanisms and
protocols to obtain a certain Transport Service. As a starting point, the
working group will consider services used between two endpoints; examples
include ordering/sequence preservation, degree of reliability, degree of
privacy/observability, and latency vs throughput.

- 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.

- Specify experimental mechanisms to provide a given Transport Service.
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.