Re: [Udp35] TAPS BOF and moving the transport API forward

[Brian Trammell <[e-mail]>]

hi Michael,

(copying the udp35 list)

On 22 May 2014, at 12:56, Michael Welzl <[e-mail]> wrote:

> Hi,
> 
> Here's a suggestion. I'm cc'ing the mailing list because in case you disagree this isn't helpful - after all I'm missing context of what happened at your retreat. But I do have a suspicion that we're all on the same page here, so I'll try a simple suggestion:
> 
> When I first approached the IETF, my take was to go bottom-up: define the services of existing IETF transports, create a protocol-independent socket API from that. Not because I think that this is what the long-term solution should be, but because I think this is needed as a starting point.

I see the starting point differently, though also bottom-up:

(1) define the dimensions of transport services...
   (1a) provided by existing IETF transports, and/or
   (1b) required by existing applications (e.g., there's a gap in RTCWEB here plugged by SCTP/DTLS)
(2) determine other combinations of these transport service dimensions that make sense (e.g. Minion occupies another spot in this space) 
(3) make recommendations for combining these dimensions in user-space transport protocols (in a way that leads to interoperable implementations of these; this is the "mix-ins" idea); this requires us to
   (3a) define a standard method for implementing user-space transport protocols that is deployable on the present Internet, preferably in a way that does not explicitly escalate the middlebox arms race.
(4) (possibly) make recommendations for the interface that implementations of (3) should provide to applications.

> At the Vancouver bar BOF, I was surprised that folks wanted more: support of higher-level APIs, not just being bound to current RFC-defined transports, etc. This is good, but it does create a larger space of work, and is potentially a much longer-term story, which is why I didn't think we could go there in the first place.
> 
> => would it now perhaps be the right time to split this into:

It seems to me that splitting the effort in to "things we can/should do now" and "things we are not sure about" is a very good idea. I have some detail-level disagreements with where to draw the line, I think.

> 1) an IETF TAPS WG that does a *socket* API extension only, based on an analysis of given transports, and a recommended way of implementing this (happy eyeballing ++ )

It seems like (1) and (2) above mostly overlap between the way we've been looking at this in udp35 and the path TAPS has taken; this intersection could be the scope for a WG-forming BoF or a direct WG formation, after a bit more discussion to nail down the differences. I'm concerned (as in the previous message) that doing this in a TSV area WG will keep us from getting good cross-area participation, so another possibility is forming an IAB program around this activity.

In any case (1) should definitely continue moving forward regardless of venue.

I'm not convinced building (4) makes a lot of sense without (3a). But discussing that further is what this list is for. :)

> 2) an IRTF activity of some sort that is a home for:
> - how to map higher-level APIs onto a lower socket API
> - how to define more general services ("give me low latency instead of high bandwidth")

I'm not sure what's different between these two points and "socket API extensions only" in the TAPS WG scope above?

> - what services could/should be defined, based on use cases, which aren't yet available

This third point covers my point 1b/2, and I think is also necessary to do earlier rather than later...

It seems like we're getting there...

Cheers,

Brian