Subject: [secdir] [new-work] WG Review: Transport Services (taps)

From: The IESG <[email-masked]>
Date: Fri, 18 Jul 2014 05:14:21 -0700

A new IETF working group has been proposed in the Transport Area. The
IESG has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2014-07-31.

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

Chairs:
  TBD

Assigned Area Director:
  Spencer Dawkins <[email-masked]>

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

Charter:

In the TAPS charter, the term "Transport Service" means any 
service provided by the transport layer that can only be 
correctly implemented with information from the application.

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

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 direcly, 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 Working Group deliverables will help an application
programmers identify the important Transport Services for 
applications and determine if those Transport Services are 
available on the end points and along the path in the network. 
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 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: ordering/sequence preservation, degree of 
  reliability, and latency vs throughput, but is not prohibited
  from considering others.

- 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. Futher, it will provide 
  a basis for incremental deployment.

The following topics are out of scope for this Working Group:

- Quality-of-Service (QoS) and tunneling mechanisms and services

- Definition of new encapsulations and tunneling mechanisms

- Extension or modification 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.

Milestones:

TBD

_______________________________________________
new-work mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/new-work

---

From: Paul Wouters <[email-masked]>
Date: Fri, 18 Jul 2014 09:23:13 -0400 (EDT)

On Fri, 18 Jul 2014, The IESG wrote:

> Subject: [secdir] [new-work] WG Review: Transport Services (taps)

> Transport Services (taps)

The name "taps" really implies it might be doing something related
tp "tapping traffic". It is a very unfortunate name, and I would
recommend coming up with another name for this work.

Paul