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 <aaron.f...@gmail.com> > > Assigned Area Director: > Spencer Dawkins <spencerdawkins.i...@gmail.com> > > Mailing list > Address: taps@ietf.org > 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 > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
