Subject: [Taps] Feedback from Internal WG Review: Transport Services (taps)

From: Spencer Dawkins <[email-masked]>
Date: Tue, 24 Jun 2014 16:28:00 -0500

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 <[email-masked]>
To: 	[email-masked] <[email-masked]>, [email-masked] <[email-masked]>

My feedback below...

> -----Original Message-----
> From: IAB [mailto:[email-masked]] On Behalf Of IESG Secretary
> Sent: Monday, June 16, 2014 8:01 AM
> To: [email-masked]; [email-masked]
> 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 <[email-masked]>
>
> Mailing List
>   Address:	[email-masked]
>   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

---

From: Olivier Mehani <[email-masked]>
Date: Wed, 25 Jun 2014 10:41:34 +1000

Hi,

(First post on taps@: I heard of this group yesterday, and it resonates with
problems that have been bugging me for a while. I hope my comments are
not out of line.)

On Tue, Jun 24, 2014 at 04:28:00PM -0500, Spencer Dawkins wrote:
> Joel Jaeggli asked whether TAPS should be IPv6-only, given that
> stack innovation only happens above transport for IPv4 because it's
> so ossified.

One of the reason IPv4 is so ossified is for the same reasons that
current transports are: the socket API is too specific in selecting an
address family, much in the same way as it is too specific in selecting
a transport protocol at the moment.

From experience porting applications to use IPv6, most of the time
changes consist in adding some address family flexibility in the
connection management code. However, this flexibility needs to be
re-implemented for each application, while it (c|sh)ould be abstracted
in lower layers. And we have domain names to map human-friendly strings
to network addresses.

I think this is a single problem: applications should not have to
specifically chose the address family they use, much in the same way as
they shouldn't have to chose the transport by name. 

> falling back to HTTP proxy traversal (websockets, etc), and that
> would be IP version-agnostic anyway.

I agree. Assuming IPv6-only feels like creating headaches for the
future, when(ever) IPv6 is not the only solution around. On the other
hand, being network-agnostic would allow to create some practical
migration paths, and transparent upgradability, to IPv6 or other
network-ish layers.

-- 
Olivier Mehani <[email-masked]>
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE  F5F9 F012 A6E2 98C6 6655
Confidentiality cannot be guaranteed on emails sent or received unencrypted.

---

From: Michael Welzl <[email-masked]>
Date: Wed, 25 Jun 2014 09:54:22 +0200

Hi,

I'll give my views below, thinking/hoping that they match what the group thinks. In this email, I try to answer not only Olivier's points, but also the points raised by Joel Jaeggli and Dave Thaler.

> a transport protocol at the moment.

Indeed. So the ossification problem is related to the API, and orthogonal to the ossification of transport-over-IPv4 that Joel notes above  (note, I'm not saying it's orthogonal to the *IPv6 deployment* problem - I agree with you that "this is a single problem" - but more on that below).

=> Answering Joel's point:
imagine we had IPv6 everywhere. Imagine that, e.g., native SCTP would seamlessly operate over that IPv6 network. Then, the problem that TAPS intends to address would still exist:  many applications won't use SCTP because TCP and UDP are exposed, and today, applications are bound to the services offered by these two protocols. Application programmers would have to start using the - rather complex - SCTP interface. Granted, in this scenario, at least the programmer wouldn't have to implement a fall-back to TCP - but (s)he'd end up with an application that e.g. works well in FreeBSD but not in Linux (because the kernel-level Linux SCTP implementation is pretty bad). So, how to solve this? Maybe run SCTP in user-space. But then, what about another protocol that's available there - e.g. what about QUIC, doesn't that do a better job for what I'm trying to solve? Also note: whatever decision the app programmer takes means that the app would have to be updated in the future if a new, better protocol comes along. It's really the strict app - transport protocol binding that must be broken.

We want application (or middleware!) programmers to be able to specify the service they're interested in: Unordered yet faster reliable packet delivery. Priorities. Partial (timer-bound) reliability. etc. etc., so that the decisions + work of the application programmer in the above example can be delegated to a system that automatically tries to do the best possible job.

Architecturally, what such a system would look like isn't necessarily agreed upon; what we do all seem to agree is that we need to identify the services provided by today's transports if we want to move in this direction. This is what TAPS wants to do.

> they shouldn't have to chose the transport by name. 

If we were the POSIX group in charge of updating the socket interface once and for all, I would agree with you: let's do this whole thing right, and update the API such that addresses are hidden too.

The problem is that TAPS isn't about updating the socket interface (anymore).  We can't "fix the API" for the whole Internet, we can only hope that people implementing APIs get this right (some already do - e.g., IIRC, Java only exposes names but not the IP address).

To get the transport part right, one needs to first identify the services provided by today's protocols, and have some idea about how to use them. To get the "abstract away the address" part right, one might need guidance as in RFC 6555, but given that this RFC already exists, what else would you want us to do towards solving that problem?

> migration paths, and transparent upgradability, to IPv6 or other

=> Answering Dave's point:

I hope I'm not getting this wrong, but this seems to be an architectural point. The way it stands now, I don't think TAPS is bound to one such architectural direction - e.g., there could be a TAPS implementation that uses HTTP proxy traversal etc., and there could be one that doesn't.

But let me be more specific here: the TAPS charter has 3 items listed under "The Working Group will". The first two (identifying the services, specifying a subset of these services) shouldn't be limited to one specific architecture. The third, however, is:

***
***

...but the idea here is that the group would specify *one* way of doing it, not the only possible way.

Thus, I think we should discuss things like "should this be able to fall back to HTTP proxy traversal etc.?" in the WG, when we deal with this work item.

I hope this was helpful. In case anything I wrote here doesn't match what others in the group think, please do speak up!

Cheers,
Michael

---

From: [email-masked]
Date: Wed, 25 Jun 2014 10:05:08 +0100

I think I mostly agree with Michael, in that I think the initial goals
need to be focussed, and while there are many things that may spring from
this ... some of which would be really good, we shouldn't attempt a
redesign of everything at once. See in-line.

> Hi,
>
> I'll give my views below, thinking/hoping that they match what the group
> thinks. In this email, I try to answer not only Olivier's points, but also
> the points raised by Joel Jaeggli and Dave Thaler.
>
>
> Indeed. So the ossification problem is related to the API, and orthogonal
> to the ossification of transport-over-IPv4 that Joel notes above  (note,
> I'm not saying it's orthogonal to the *IPv6 deployment* problem - I agree
> with you that "this is a single problem" - but more on that below).
>
> imagine we had IPv6 everywhere. Imagine that, e.g., native SCTP would
> seamlessly operate over that IPv6 network. Then, the problem that TAPS
> intends to address would still exist:  many applications won't use SCTP
> because TCP and UDP are exposed, and today, applications are bound to the
> services offered by these two protocols. Application programmers would
> have to start using the - rather complex - SCTP interface. Granted, in
> this scenario, at least the programmer wouldn't have to implement a
> fall-back to TCP - but (s)he'd end up with an application that e.g. works
> well in FreeBSD but not in Linux (because the kernel-level Linux SCTP
> implementation is pretty bad). So, how to solve this? Maybe run SCTP in
> user-space. But then, what about another protocol that's available there -
> e.g. what about QUIC, doesn't that do a better job for what I'm trying to
> solve? Also note: whatever decision the app programmer takes means that
> the app would have to be updated in the future if a new, better
>  protocol comes along. It's really the strict app - transport protocol
> binding that must be broken.
>
> We want application (or middleware!) programmers to be able to specify the
> service they're interested in: Unordered yet faster reliable packet
> delivery. Priorities. Partial (timer-bound) reliability. etc. etc., so
> that the decisions + work of the application programmer in the above
> example can be delegated to a system that automatically tries to do the
> best possible job.
>
> Architecturally, what such a system would look like isn't necessarily
> agreed upon; what we do all seem to agree is that we need to identify the
> services provided by today's transports if we want to move in this
> direction. This is what TAPS wants to do.
>
I'd say it was fine to specifically say this will be designed for IPv6 -
but then I do not see the rationale about why this couldn't support IPv4
as well. It would seem wrong to constrain yourself to just an IPv6 layer
3, when the focus is on providing the best choice for network traversal.
Preferring IPv6 over IPv4 may be a logical choice when both networks can
support the same transport services.
> If we were the POSIX group in charge of updating the socket interface once
> and for all, I would agree with you: let's do this whole thing right, and
> update the API such that addresses are hidden too.
>
> The problem is that TAPS isn't about updating the socket interface
> (anymore).  We can't "fix the API" for the whole Internet, we can only
> hope that people implementing APIs get this right (some already do - e.g.,
> IIRC, Java only exposes names but not the IP address).
>
> To get the transport part right, one needs to first identify the services
> provided by today's protocols, and have some idea about how to use them.
> To get the "abstract away the address" part right, one might need guidance
> as in RFC 6555, but given that this RFC already exists, what else would
> you want us to do towards solving that problem?
>
I brought up the API, and it seems we have moved away from the this to
focus initial energy on mechanisms - I now really think this is the
correct piece of work to progress first - and one that clearly has a
strong need for transport expertise.

>> migration paths, and transparent upgradability, to IPv6 or other
Yes - IPv6 can be important, but binding transport to only be layered
directly on IPv6 seems wrong.
> I hope I'm not getting this wrong, but this seems to be an architectural
> point. The way it stands now, I don't think TAPS is bound to one such
> architectural direction - e.g., there could be a TAPS implementation that
> uses HTTP proxy traversal etc., and there could be one that doesn't.
>
> But let me be more specific here: the TAPS charter has 3 items listed
> under "The Working Group will". The first two (identifying the services,
> specifying a subset of these services) shouldn't be limited to one
> specific architecture. The third, however, is:
>
> ***
Indeed. And any "way" will rely upon workable robust protocol mechanisms...

> Thus, I think we should discuss things like "should this be able to fall
> back to HTTP proxy traversal etc.?" in the WG, when we deal with this work
> item.
>
>
> I hope this was helpful. In case anything I wrote here doesn't match what
> others in the group think, please do speak up!
>
> Cheers,
> Michael
>
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps
>
Gorry