Hi Aaron, Following some (i.e. extensive) hallway discussion in Toronto to Thursday, I'd make one following suggested changes to this draft charter, inline.
On 19 Aug 2014, at 02:37, Aaron Falk <falk-i...@dgftech.com> wrote: > Hi Folks- > > We received a bit more charter input from the IAB and I've incorporated it > into the draft below. Diffs against the last rev and the version submitted > for IETF comment are also attached (as usual). The IESG will be taking up > approval of the TAPS working group at their telechat on August 28 so > comments, including support, are appreciated. > > Regards, > > --aaron > > ------ > > Last updated 2014-08-18 > > > Transport Services (taps) > > The vast majority of 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. Additionally, it 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. > > Other 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 that can accept blocks of data out of order, and LEDBAT provides > low-priority "scavenger" communication. > > 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) Note that not all capabilities of IETF Transport protocols need to be > exposed as Transport Services. This document will recommend the minimal set > of Transport Services for inclusion in the abstract API. The resulting > document will also provide guidance on making a choice among available > mechanisms and protocols to obtain a certain Transport Service. > > 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. The associated milestone will be scheduled and 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 existing IETF 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 to the IESG an Informational document defining a set of services > provided by IETF transport protocols and congestion control mechanisms. > M15: Submit to the IESG an Informational document recommending a minimal set > of Transport Services that end systems should support. Per the third point of the charter, I think we want to add the third milestone back, but make clear that the effort is experimental; something like: M18: Submit to the IESG an Experimental document exploring abstract interfaces to Transport Services, and defining an experiment to evaluate such interfaces for applicability to common application design patterns and incremental deployability > M18: Recharter or close. I recommend we keep this milestone as well. Cheers, Brian
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
