Subject: [Taps] TAPS charter rev 20140826

From: Aaron Falk <[email-masked]>
Date: Tue, 26 Aug 2014 18:27:06 -0400

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.

---

From: Brian Trammell <[email-masked]>
Date: Wed, 27 Aug 2014 08:32:33 +0200

hi Aaron,

Thanks for putting this together!

This charter looks good to me.

Cheers,

Brian

On 27 Aug 2014, at 0:27, Aaron Falk <[email-masked]> wrote:

> I'm only attaching the diff to the last rev because it's rather a pain to generate the other one.
> 
> --aaron
> 
> 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. 
> 
> 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.
> 
>  
> <charter-diff-20140818-20140826.pdf>_______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Michael Welzl <[email-masked]>
Date: Wed, 27 Aug 2014 09:01:35 +0200

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..."
- 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...
- 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.

That's it!

Cheers,
Michael

---

From: [email-masked]
Date: Wed, 27 Aug 2014 08:06:59 +0100

To me, this seems like a good charter to proceed with.

Gorry

> _______________________________________________
> Taps mailing list
> [email-masked]

---

From: Anna Brunstrom <[email-masked]>
Date: Wed, 27 Aug 2014 09:22:49 +0200

Looks good to me as well.
Thanks for all your efforts with the charter!

Anna

On 2014-08-27 00:27, Aaron Falk wrote:
> 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:
>
> 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.
>
> 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.
>
> 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.
>
>
>

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 27 Aug 2014 09:36:40 +0000

Yes it looks really good!

Marie-José Montpetit
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>

On Aug 27, 2014, at 3:23, "Anna Brunstrom" <[email-masked]<mailto:[email-masked]>> wrote:

Anna

--aaron

The Working Group will:

- Language-specific APIs

Milestones:

_______________________________________________
Taps mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/taps

_______________________________________________
Taps mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/taps

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 27 Aug 2014 12:06:54 +0200

> Thanks for all your efforts with the charter!
I agree with Anna!

Best regards
Michael

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 27 Aug 2014 14:22:08 +0200

Thanks for working on this. Looks go to me. Looking forward to actually 
do the work in a w-g!

Mirja

On 27.08.2014 00:27, Aaron Falk wrote:
> 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.
>
> 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.
>
> 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).
>
> 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.
>
> protocol will be HTTP" is a reasonable strategy for today's Internet.
> The IESG has agreed with this viewpoint enough to publish the WebSocket
> 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:
>
> 2) Specify the subset of those Transport Services, as identified in item
> 1, that end systems supporting TAPS will provide, and give guidance on
> 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.
>
> streams, and TAPS will work with TCPINC to ensure that TAPS will be able
> to accommodate the protocol extensions that TCPINC defines.
>
> Milestones:
>
> methods to provide applications with the Transport Services identified
> by the WG.
>
> M18: Recharter or close.
>
>
>

-- 
------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Communication Systems Group
Institute TIK, ETH Zürich
Gloriastrasse 35, 8092 Zürich, Switzerland

Room ETZ G93
phone: +41 44 63 26932
email: [email-masked]
------------------------------------------