Subject: [Taps] Today's shipment: the TAPS charter!

From: Michael Welzl <[email-masked]>
Date: Fri, 13 Jun 2014 09:09:59 +0200

Dear Spencer,

Finally I'm in a position to ship the fully list-agreed version of the TAPS charter. It's at:
https://sites.google.com/site/transportprotocolservices/charter-proposal
and at the bottom of this email.

Cheers,
Michael

=============================

Transport Services (TAPS)

Status: Proposed Working Group
Last Updated: 2014-06-10

Chair(s):
TBD

Transport Area Director(s):
Spencer Dawkins <[email-masked]>
Martin Stiemerling <[email-masked]>

Transport Area Advisor:
TBD

Mailing Lists: [email-masked]

Description of Working Group

Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite, and the LEDBAT congestion control mechanism extend the set of transport services that are available to applications, beyond those provided 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.

For an application programmer, it is hard to use protocols other than TCP or UDP: most network stacks only support TCP and UDP, many firewalls only pass TCP and UDP, and requiring 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. 
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 solution over UDP. That can result in applications re-implementing features already available elsewhere, and chances of benefiting from other transport protocols are lost.

There are many ways in which this problem could be addressed; while it may not yet be clear what the best way forward could be, any approach to provide a richer set of transport services to applications will have to begin with the identification of the services that current transport protocols provide.

The Working Group will:
	• identify services provided by existing IETF transport 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.
	• specify a subset of those services identified in item 1, which end systems supporting TAPS need to provide and provide guidance on choosing among available mechanisms and protocols to obtain a given transport service.
	• specify experimental mechanisms to deliver a transport service. This will explain how to select and engage a protocol, and how to discover the availability of protocols on an interface (both end system and path support), in order to provide a basis for incremental deployment.

The Working Group will coordinate closely with other Working Groups and IRTF Research Groups.

The following topics are out of scope of this Working Group:
	• Quality-of-Service (QoS) and tunneling mechanisms and services
	• Definition of new encapsulations and tunneling mechanisms

Milestones:
	• M7: Submit summary of the services provided by IETF transport protocols and congestion control mechanisms to IESG.
	• M13: Submit end system transport services to IESG.
	• M14: Submit specification of how the transport services can be provided to IESG.

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 13 Jun 2014 22:45:28 -0500

> and at the bottom of this email.

I put this on the telechat agenda two weeks hence for INTERNAL review. 
Then it goes for IETF Last Call, if I understand correctly.

Spencer

---

From: Michael Welzl <[email-masked]>
Date: Thu, 19 Jun 2014 17:07:54 +0200

Dear all,

Note that we asked for a TAPS BOF slot too, to be able to reserve a meeting slot before the deadline; this was approved, see http://wiki.tools.ietf.org/bof/trac/
So I think TAPS will meet, in some form, with some purpose. I don't quite know how to prepare for this yet, but I do know that anyone interested in TAPS should consider travelling to Toronto. So prepare a trip!  :)

Cheers,
Michael

On 14. juni 2014, at 05:45, Spencer Dawkins <[email-masked]> wrote:

> I put this on the telechat agenda two weeks hence for INTERNAL review. Then it goes for IETF Last Call, if I understand correctly.
> 
> Spencer