Some more points:
The text does not state if/how the WG will take the impact of known
unavoidable network path issues (NAT/FW/Proxy) and known application domain
architectures (eg: browser as middleware, "web" centric applications) into
account. IMHO, TAPS must not create ivory tower analysis that ignore these
aspect or create recommendations / directions incompatible with them,
and this should be in the charter.
I can not understand how QoS can be outside the scope of the WG when
a lot of transport protocol services differences are exactly about that.
What other than QoS mechanisms are the congestion control mechanisms
mentioned upfront ? LEDBAT is a transport for a specific QoS experience.
Is TAPS planning to ignore all protocol/queuing differences in transport
meant to deal with QoS ? Why ?
I am positively surprised though to see that IP multicast transport
is in charter given the IAB/IESG policy that every new WG too lazy
to consider IP multicast must also explicitly rant in its charter about
t being unnecessary and complex and therefore excluded from the charter.
( I thought in face of the BCP 56 paragraph i could also put
something into the mouth of IETF bodies - especially because i actually
did hear that position expressed repeatedly in public by members of
those bodies ;-P ).
Cheers
Toerless
On Fri, Jul 18, 2014 at 05:14:08AM -0700, The IESG wrote:
> A new IETF working group has been proposed in the Transport Area. The
> IESG has not made any determination yet. The following draft charter was
> submitted, and is provided for informational purposes only. Please send
> your comments to the IESG mailing list (iesg at ietf.org) by 2014-07-31.
>
> Transport Services (taps)
> ------------------------------------------------
> Current Status: Proposed WG
>
> Chairs:
> TBD
>
> Assigned Area Director:
> Spencer Dawkins <spencerdawkins.ietf@xxxxxxxxx>
>
> Mailing list
> Address: taps@xxxxxxxx
> To Subscribe: https://www.ietf.org/mailman/listinfo/taps
> Archive: http://www.ietf.org/mail-archive/web/taps/
>
> Charter:
>
> In the TAPS charter, the term "Transport Service" means any
> service provided by the transport layer that can only be
> correctly implemented with information from the application.
>
> 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).
>
> Other transport protocols such as SCTP, DCCP, MPTCP,
> 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 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 only support TCP
> and UDP, and many firewalls only pass TCP and UDP, so using
> other transport protocols risks having an application not
> work in many environments. Applications, therefore, must
> always be able to fall back to TCP or UDP, and once the
> application programmer has committed to making an application
> work on TCP or UDP, 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 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 TCP would
> have avoided, and ensure that the applications can't
> benefit from other transport protocols as they become
> available.
>
> Alternatively, programmers may simply give up on using
> transport protocols direcly, 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 Websockets protocol
> on the standards track.
>
> The Working Group deliverables will help an application
> programmers identify the important Transport Services for
> applications and determine if those Transport Services are
> available on the end points and along the path in the network.
> 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:
>
> - Identify Transport Services provided by existing IETF
> protocols and congestion control mechanisms. The resulting
> document will provide guidance on making a choice among
> available mechanisms and protocols to obtain a certain
> Transport Service. As a starting point, the working group will
> consider: ordering/sequence preservation, degree of
> reliability, and latency vs throughput, but is not prohibited
> from considering others.
>
> - 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.
>
> - Specify experimental mechanisms to provide a given Transport
> Service. This document will explain how to select and engage
> an appropriate protocol and how to discover which protocols
> are available for a given connection. Futher, it will provide
> a basis for incremental deployment.
>
> The following topics are out of scope for this Working Group:
>
> - Quality-of-Service (QoS) and tunneling mechanisms and services
>
> - Definition of new encapsulations and tunneling mechanisms
>
> - Extension or modification 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 summary of the services provided by IETF transport
> protocols and congestion control mechanisms to IESG.
> M15: Submit end system transport services to IESG.
> M18: Submit specification of how the transport services can be
> provided to IESG.
>
> Milestones:
>
> TBD