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.