* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Taps Status Pages

Transport Services (Active WG)
Tsv Area: Mirja K├╝hlewind, Spencer Dawkins | 2014-Sep-23 —  
Chairs
 
 


2016-07-17 charter

Transport Services (taps)
-------------------------

 Charter

 Current Status: Active

 Chairs:
     Aaron Falk <aaron.falk@gmail.com>
     Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>

 Transport Area Directors:
     Spencer Dawkins <spencerdawkins.ietf@gmail.com>
     Mirja K├╝hlewind <ietf@kuehlewind.net>

 Transport Area Advisor:
     Spencer Dawkins <spencerdawkins.ietf@gmail.com>

 Mailing Lists:
     General Discussion: taps@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/taps
     Archive:            https://mailarchive.ietf.org/arch/browse/taps/

Description of Working Group:

  Most Internet applications make use of the Transport Services
  provided by TCP (a reliable, in-order stream protocol) or UDP
  (an unreliable datagram protocol).   We use the term "Transport
  Service" to mean an end-to-end facility provided by the
  transport layer. That service can only be provided correctly if
  information is supplied from the application. The application may
  determine the information to be supplied at design time,
  compile time, or run time and may include guidance on whether
  the facility  in question is required or simply a preference by the
  application. Four examples of Transport Services are reliable
  delivery, ordered delivery of data, content privacy to in-path
  devices, and minimal latency.

  Transport protocols such as SCTP, DCCP, WebSockets, MPTCP, and
  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 than TCP because it can
  accept blocks of data out of order, and LEDBAT provides low-priority
  "scavenger" communication.

  However, application programmers face difficulty when they use
  protocols other than TCP or UDP. Most network stacks ship with only
  TCP and UDP as transport protocols.  Many firewalls only pass TCP
  and UDP and some  only allow TCP  when it carries HTTP as its payload.
  As a result, using other transport protocols or building a new protocol
  over raw sockets risks having an application not work in many
  environments. Applications, therefore, must always be able to fall back
  to TCP or UDP, or even to using HTTP as a transport substrate in some
  cases, and once the application programmer has committed
  to making an application work on TCP or UDP or HTTP, 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 also 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 HTTP 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 using TCP would have avoided and ensure that the
  applications can't benefit from other transport protocols as they
  become available. And, since even TCP and UDP are not guaranteed to
  work in all environments today, some programmers simply give up on
  using TCP or UDP directly, 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 WebSocket protocol on the standards track.

  The goal of the TAPS working group is to help application and network
  stack programmers by describing an (abstract) interface for applications
  to make use of Transport Services. The Working Group deliverables
  emphasize defining Transport Services that are important to applications
  followed by experimental mechanisms to a) determine if the protocols to
  provide the requested services are available on the end points and
  supported along the path in the network and b) fall back, i.e., select
  alternate, possibly less-preferred, protocols when desired protocols
  are not available. 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:

  1) Define a set of Transport Services, identifying the
     services provided by existing IETF protocols and congestion
     control mechanisms. As a starting point, the working group will
     consider services used
     between two endpoints.

  2) 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.  Note that not all the capabilities of IETF Transport
     protocols need to be exposed as Transport Services.

  3) Specify experimental support mechanisms to provide the Transport
     Services identified in work item 2. This document will explain
     how to select and engage an appropriate protocol and how to
     discover which protocols are available for the selected service
     between a given pair of end points. Further, it will provide a
     basis for incremental deployment. Work on this document will
     begin when the TAPS Transport Services have been specified.

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

  - Signaling-based Quality-of-Service (QoS) mechanisms

  - Definition of new encapsulations and tunneling mechanisms

  - Extension, modification, or creation of transport protocols

  - Language-specific APIs

  TAPS is not chartered to perform detailed analysis of the security
  aspects of transport protocols. While security can be a transport
  service, 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.

Goals and Milestones:
  Nov 2016 - Submit an Informational document to the IESG defining a set of services provided by IETF transport protocols and congestion control mechanisms
  Mar 2017 - Submit an Informational document to the IESG recommending a minimal set of Transport Services that end systems should support
  Nov 2017 - Submit an Experimental document to the IESG specifying one or more methods to provide applications with the Transport Services identified by the WG
  Mar 2018 - Recharter or conclude.


All charter page changes, including changes to draft-list, rfc-list and milestones:



Generated from PyHt script /wg/taps/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -