Status

TAPS BECAME AN IETF WG ON 24 September 2014.

This website only documents the history of TAPS creation.

This site was used as a coordination point for a pre-standards activity aimed at creating an IETF Working Group that should define the transport services that are exposed to Internet applications.

A WG-forming Birds-of-a-Feather (BOF) session was held at the 90th IETF meeting (Toronto, July 20-25, 2014). Slides are available.

Before, a non-WG-forming Birds-of-a-Feather (BOF) session was held at the 89th IETF meeting (London, March 2-7, 2014). Slides and minutes are available, and what happened was also reported in the IETF Journal (pages 19 / 20).

The associated mailing list is taps@ietf.org and the mailing list info page is https://www.ietf.org/mailman/listinfo/taps

The list was moved to this official @ietf.org address on 6 March 2014. Archives prior to this date can be found at https://sympa.uio.no/ifi.uio.no/info/transport-services

This is the description that was used for submission to the first BOF in London:

Transport Services (TAPS)

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.

This WG will identify the services provided by existing IETF transport protocols and congestion control mechanisms as well as network requirements of common APIs that applications use to communicate. By finding a mapping between these two lists, the WG will define services that a transport API should offer. Then, the WG will specify how these transport services can be implemented 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.

Background information for holding a BOF:

RFC5434 outlines the steps needed for a successful BOF; it also explains that the deadline for submitting a BOF request is approximately 6 weeks before the meeting, i.e. mid-January. BOF procedures are explained here.

The site is intended to exist until an official IETF activity is started to take care of this issue.

It is maintained by Michael Welzl as an activity of the FP7 RITE research project and the bilateral research exchange project AURORA, which is funded by the Norwegian Research Council and the French Ministry of Foreign Affairs.