hi Aaron, Thanks for putting this together!
This charter looks good to me. Cheers, Brian On 27 Aug 2014, at 0:27, Aaron Falk <[email protected]> wrote: > 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. > > > <charter-diff-20140818-20140826.pdf>_______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
