On 27 Aug 2014, at 09:22, Anna Brunstrom <[email protected]> wrote:
> Looks good to me as well. > Thanks for all your efforts with the charter! I agree with Anna! Best regards Michael > > Anna > > On 2014-08-27 00:27, Aaron Falk 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. >> >> >> >> >> _______________________________________________ >> 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
