To me, this seems like a good charter to proceed with. Gorry
> See charter rev below. Change highlights: > - reverted to earlier 2nd doc description > - added back 3rd doc milestone > - minor cleanup > > I'm only attaching the diff to the last rev because it's rather a pain to > generate the other one. > > --aaron > > Transport Services (taps) > > > 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 can only be correctly > provided with information from the application. This information may be > provided at design time, compile time, or run time and may include > guidance > from the application on whether the facility in question is required or > simply a preference by the application. Four examples of Transport > Services > are reliable delivery, no guarantee of order preservation, 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 (than TCP) reliable delivery > for applications 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 > support HTTP over TCP. 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 HTTP in many 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 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. > > Because 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, prioritizing those 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 a given connection. 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, but 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: > > M9: Submit an Informational document to the IESG defining a set of > services > provided by IETF transport protocols and congestion control mechanisms. > M15: Submit an Informational document to the IESG recommending a minimal > set of Transport Services that end systems should support. > M18: Submit an Experimental document to the IESG specifying one or more > methods to provide applications with the Transport Services identified by > the WG. > > M18: Recharter or close. > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps > _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
