Looks good to me as well.
Thanks for all your efforts with the charter!
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
