Great, thanks! Cheers, Michael
On 27. aug. 2014, at 16:27, Aaron Falk wrote: > > > > On Wed, Aug 27, 2014 at 3:01 AM, Michael Welzl <[email protected]> wrote: > Hi, > > Thanks from me too! I'm also fine with it, great job! > > > Here are a few SUPER small nits, and I think none of them is necessary or > "meaningful", it's just cosmetics, from carefully reading the whole thing yet > again: > > - par2: there's a double "and" - I'd replace "...and UDP-Lite and the > LEDBAT..." with "..., UDP-Lite and the LEDBAT..." > > This is an english thing. We're adding a list of protocols ending in > UDP-Lite to a congestion control mechanism (LEDBAT). I think it is correct > as written. > > - par 3: I think it would read better if "also" was inserted in the last > sentence, replacing "Layering decisions must be made" was replace with > "Layering decisions must also be made", but I'm not a native speaker... > > Yup. Fixed. > > - par 5: (starting with "Because even TCP and UDP"): isn't this paragraph > logically connected to the previous one? I think they could be merged. Also > (again, not a native speaker, so not sure) I'd replace "Because even TCP and > UDP" with "Since even TCP and UDP" just to avoid having two sentences start > with "Because..." so close to each other. But that's really not important and > just style. > > Combined the paras. See below. > > > 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 also 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. And, since 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
