Hi Brian, thanks getting into this discussion! In line below:
On 19. aug. 2014, at 11:32, Brian Trammell wrote: > 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 <[email protected]> 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 I think this is a significant change to the wording that we had during IETF open review, which was: M18: Submit specification of how the transport services can be provided to IESG. I'd be fine with the status of this document explicitly being Experimental, as it was before, see: https://sites.google.com/site/transportprotocolservices/charter-proposal/charter-before-london i.e. to change this back to: M18: Submit Experimental specification of how the transport services can be provided to IESG. ...but your wording seems to be an entirely different thing: exploring abstract interfaces? defining an experiment to evaluate them for applicability to app design patterns? This is really something else. Why do you propose such a change at this late stage? Who else wants that, and why? >> M18: Recharter or close. > > I recommend we keep this milestone as well. +1. That one wasn't ever debated I think. Fine. Cheers, Michael
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
