Hi all,
Having read through the updated charter that Aaron circulated, I also
find the removal of the third milestone a significant change and would
like to see it back. From the discussion on the TAPS list, I think this
has been a big part in motivating the interest for this work.
I also agree with Michael that if we want to indicate that the work is
experimental (which is fine) we should just insert the word
"Experimental" in the original milestone again. Brian, the meaning of
your proposed new wording is very unclear to me as well.
Cheers,
Anna
On 2014-08-19 11:41, Michael Welzl wrote:
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]
<mailto:[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
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
