Dear TAPSters,

I've gotten two pieces of feedback during Internal WG review. They both 
raise the same issue, but head in opposite directions in resolving that 
issue.

Joel Jaeggli asked whether TAPS should be IPv6-only, given that stack 
innovation only happens above transport for IPv4 because it's so ossified.

Dave Thaler suggested (below) that if the work wasn't constrained to 
TCP/UDPish transports, it could also address all the stuff that's 
falling back to HTTP proxy traversal (websockets, etc), and that would 
be IP version-agnostic anyway.

Does the group have thoughts on this?

Thanks,

Spencer

-------- Original Message --------
Subject: 	RE: [IAB] Internal WG Review: Transport Services (taps)
Date: 	Tue, 17 Jun 2014 16:24:14 +0000
From: 	Dave Thaler <dthaler@microsoft.com>
To: 	iesg@ietf.org <iesg@ietf.org>, iab@iab.org <iab@iab.org>



My feedback below...

> -----Original Message-----
> From: IAB [mailto:iab-bounces@iab.org] On Behalf Of IESG Secretary
> Sent: Monday, June 16, 2014 8:01 AM
> To: iesg@ietf.org; iab@iab.org
> Subject: [IAB] Internal WG Review: Transport Services (taps)
>
> A new IETF working group is being considered in the Transport Area.  The
> draft charter for this working group is provided
> below for your review and comment.
>
> Review time is one week.
>
> The IETF Secretariat
>
> Transport Services (taps)
> --------------------------------------------------
> Current Status: Proposed Working Group
>
> Chairs:
>
> TBD
>
> Area Director:
>
> Spencer Dawkins <spencerdawkins.ietf@gmail.com>
>
> Mailing List
>   Address:	taps@ietf.org
>   To Subscribe:	https://www.ietf.org/mailman/listinfo/taps
>   Archive: 	http://www.ietf.org/mail-archive/web/taps/
>
> Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and the
> LEDBAT congestion control mechanism extend the set of transport services
> that are available to applications, beyond those provided 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.
>
> For an application programmer, it is hard to use protocols other than TCP or
> UDP: most network stacks only support TCP and UDP, many firewalls only
> pass TCP and UDP,

As the IAB discussed at our retreat (and in various RFCs) many firewalls
only pass HTTP.  As such, I believe it's critical that this work not be constrained
to assume TCP or UDP, but must also deal with things needing to go through
HTTP proxies (e.g., websockets).

> and requiring 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.

Same issue here.  Falling back to TCP or UDP is not sufficient.

>  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 solution over UDP.

... or over HTTP

> That can
> result in applications re-implementing features already available elsewhere,
> and chances of benefiting from other transport protocols are lost.
>
> There are many ways in which this problem could be addressed; while it may
> not yet be clear what the best way forward could be, any approach to
> provide a richer set of transport services to applications will have to begin
> with the identification of the services that current transport protocols
> provide.
>
> The Working Group will:
>
> - Identify services provided by existing IETF transport 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.
>
> - Specify a subset of those services identified in item 1, which
>   end systems supporting TAPS need to provide and provide guidance
>   on choosing among available mechanisms and protocols to obtain
>   a given transport service.
>
> - Specify experimental mechanisms to deliver a transport service.
>   This will explain how to select and engage a protocol, and how
>   to discover the availability of protocols on an interface (both
>   end system and path support), in order to provide a basis for
>   incremental deployment.
>
> The Working Group will coordinate closely with other Working Groups and
> IRTF Research Groups.

The above sentence is useless.  Either remove it or name specific
WGs/RGs.

>
> The following topics are out of scope of this Working Group:
>
> - Quality-of-Service (QoS) and tunneling mechanisms and services
>
> - Definition of new encapsulations and tunneling mechanisms


I wonder if the charter should also specifically state that it will not do
any concrete (i.e. programming language specific) APIs.  I'm thinking
it should say so, to avoid lots of discussion on that topic, which seemed
to derail the bof.

>
> Milestones:
> M7:  Submit summary of the services provided by IETF transport
>      protocols and congestion control mechanisms to IESG.
> M13: Submit end system transport services to IESG.
> M14: Submit specification of how the transport services can be
>      provided to IESG.

-Dave