Congratulations! Marie-José Montpetit [email protected]
> On Sep 24, 2014, at 05:59, Michael Welzl <[email protected]> wrote: > > Hooray! Thanks everyone for your efforts!! > > >> On 24. sep. 2014, at 01:33, The IESG wrote: >> >> A new IETF working group has been formed in the Transport Area. For >> additional information please contact the Area Directors or the WG Chair. >> >> Transport Services (taps) >> ------------------------------------------------ >> Current Status: Proposed WG >> >> Chairs: >> Aaron Falk <[email protected]> >> >> Assigned Area Director: >> Spencer Dawkins <[email protected]> >> >> Mailing list >> Address: [email protected] >> To Subscribe: https://www.ietf.org/mailman/listinfo/taps >> Archive: http://www.ietf.org/mail-archive/web/taps/ >> >> Charter: >> >> 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. >> >> Milestones: >> Jun 2015 - Submit an Informational document to the IESG defining a set >> of services provided by IETF transport protocols and congestion control >> mechanisms >> Dec 2015 - Submit an Informational document to the IESG recommending a >> minimal set of Transport Services that end systems should support >> Mar 2016 - Submit an Experimental document to the IESG specifying one >> or more methods to provide applications with the Transport Services >> identified by the WG >> Mar 2016 - Recharter or conclude. >> >> >> _______________________________________________ >> Taps mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
