Charter before London

Transport Services (TAPS)

Status: Proposed Working Group

Last Updated: 2013-12-03

Chair(s):

TBD

Transport Area Director(s):

Spencer Dawkins <spencerdawkins.ietf@gmail.com>

Martin Stiemerling <mls.ietf@gmail.com>

Transport Area Advisor:

TBD

Mailing Lists: taps@ietf.org

Description of Working Group

Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion control mechanism offer a large number of services to applications in addition to the long-standing two services provided by TCP and UDP. For an application programmer, using protocols other than TCP or UDP is hard: not all protocols are available everywhere, hence a fall-back solution to e.g. TCP or UDP must be implemented. Some protocols provide the same services in different ways. Layering decisions must be made (e.g. should a protocol be used natively or over UDP?). Because of these complications, programmers often resort to either using TCP or implementing their own customized solution over UDP, and chances of benefiting from other transport protocols are lost. If an API provided a way for applications to request transport services without specifying the protocol, a transport system underneath it could automatically try to make the best of its available resources. It could use available transport protocols in a way that is most beneficial for applications, and this approach could give more freedom for diversification to designers of Operating Systems.

The Working Group will:

1. identify services provided by existing IETF transport protocols and congestion control mechanisms, based on Standards-track and Experimental RFCs that were developed in the IETF's Transport Area, resulting in list #1
2. identify network requirements of a set of common APIs that applications use to communicate, resulting in list #2
3. determine how services from lists #1 and #2 can be mapped onto each other, resulting in a list of transport services that the WG will specify
4. Specify how the defined transport services can be provided using native IETF transports and encapsulated transports, including the definition of mechanisms to validate that a transport (or transports) can be supported on a path.

The Working Group is expected to work closely with the APP and RAI areas to continuously check whether the defined transport services match the requirements of application developers. It will also coordinate closely with other Transport area groups.

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

• Signaling that could improve the operation of the transport layer
• Quality-of-Service (QoS) and tunneling mechanisms and services

Deliverables:

• Informational RFC summarizing the services provided by IETF transport protocols and congestion control mechanisms as well as the requirements of common APIs
• Proposed Standard RFC specifying a set of services that a transport API should provide
• Informational RFC describing an example API
• Experimental RFC specifying how the defined transport services can be provided using IETF transports
• Proposed Standard RFC specifying on which basis transport services are identified and defining IANA procedures for including new services

Milestones:

• M3: Adopt first WG draft on how transport services are identified