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

[Brian Trammell <[e-mail]>]

hi Michael, all,

On 26 May 2014, at 10:03, Michael Welzl <[e-mail]> wrote:

> ... so, now:
> 
> 1) we agree that a few things need to be done ASAP no matter what (define the "supply side")
> 2) we may have to refine our views a little bit about what needs to be done immediately
> 
> - and this should not be done as an update to the TAPS charter, leading to a WG-forming TAPS BoF in Toronto, because... ?

...since the responsible ADs are the ones who make the decision here, if their opinion differs from mine, what they say goes; but...

...because IMO (1) it's not clear that having a TAPS WG in the TSV area would give us the best combination of efficiency and wider participation from the communities (represented by RAI and APP) that would use it, (2) I'm afraid we'd have the same derails we had in London which would take cycles away from work we already have a pretty clear boundary drawn around, (3) there are _clearly_ things outside the scope of TAPS that are nonetheless related (essentially anything under the "signaling" heading, which itself seems split into two things) s.t. we need more understanding about those relationships, and (4) the current scope of agreement is a single document (albeit a somewhat large and quite important one), which would appear to me to draw heavily on the present draft-monpetit-* (unless the current group had something else in mind), for which WG formation seems kind of a heavyweight process.

Indeed, for a TAPS WG we'd need to find two non-author co-chairs, who would have to work pretty hard to avoid a derail on the API issue at a Toronto BoF, and keep the charter that comes out of the BoF focused enough that all the new contributions you'd get would further the current work on this document. My reticence here comes from a suspicion that this will be hard to do.

I don't see how "not creating a working group" equates with "delaying the work"; indeed, you've already got a mailing list, a core team of contributors, documents in pretty good shape, etc.; i.e. you've already pretty much built a working group. Now, if there is some (political) reason that the work needs to be seen as being done within a WG in the IETF, let's talk about that. But otherwise it seems to me we could publish this one document on the IAB stream as a product of the (soon-to-be-renamed TCP/)IP Evolution program in the IAB with somewhat less overhead, and use this (more architectural) document after publication as background for engineering work done in (a) future WG(s).

> Don't get me wrong, I understand the need for the meeting on Saturday in Toronto, indeed there are more things that we should try to agree on, but since we already agree (to some level of detail) what TAPS should be doing, why do we delay it?

I'm not at all adamant about this; if there's wider agreement now that the "dimensions-of-transport" work is probably best done in a TSV area working group, we could also parallelize this: put together a smaller charter as a starting point for a Toronto WG-forming BoF to which the outcome of Saturday's discussions could be input.

(But on that point I defer to the responsible ADs. :) )

Cheers,

Brian

> If the idea of having a WG seems problematic (slowing things down for reasons I don't understand), is that still the case with the scope on "supply side"? I don't quite get that.
> 
> Cheers,
> Michael
> 
> 
> 
> On 23. mai 2014, at 10:34, Michael Welzl wrote:
> 
>> 
>> On 22. mai 2014, at 18:38, Brian Trammell wrote:
>> 
>>> 
>>> On 22 May 2014, at 16:13, Michael Welzl <[e-mail]> wrote:
>>> 
>>>> 
>>>> On 22. mai 2014, at 14:05, Brian Trammell wrote:
>>>> 
>>>>> 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
>>>> 
>>>> "mix-ins" => do you have a pointer? Sorry if you presented it at an IETF and I forgot about that.
>>> 
>>> Nope, not yet; the idea is still not quite fully-formed. Essentially, instead of providing an implementation of an API that has various knobs for various features (the SCTP approach), we provide a set of standards/implementations that each implement a small set of choices for dimensions as a coherent whole, which are all designed to play nicely with each other. This is sort of a "userspace transport construction kit" as opposed to a layer which selects an existing transport.
>> 
>> That sounds very similar to this:  http://nena.intend-net.org/
>> 
>> 
>>>>> (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.
>>>> 
>>>> I'm not sure I buy the need and/or feasibility of 3a, but I'm also not sure we need to agree about this, at this point in time. Probably it's enough if we agree on the starting points  :-)
>>> 
>>> Yep. (3a) is also something which is can be done almost completely independently of the rest, so will probably be a separate thread within the "udp35" work.
>> 
>> ACK, let's stop discussing it for now to keep this discussion focused.
>> 
>> 
>>>>>> 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 agree (although my proposal for a starting point was even narrower; I'm fine with broader, whatever works...)
>>> 
>>> I think (2) may simply be a set of recommendations in the document describing (1); we need to acknowledge that the dimensions of transport services are not orthogonal.
>> 
>> I agree - I wasn't so concerned about (2) though, I actually meant that we might not even have to do (1b) yet. Perhaps, as long as we stick with *existing* applications, as you wrote, that could be fine - but how to draw the line? We're talking about using a future API, so we ARE talking about a change to the app. Then again, for an intermediate first step, I think the more futuristic fancy use cases set us on a track that leaves TSV territory and may be a much longer term activity, a broader (but also more interesting!) story (consider the breadth of http://tools.ietf.org/html/draft-montpetit-transport-use-cases-01 and http://tools.ietf.org/html/draft-deng-taps-datacenter-01 for example).
>> 
>> 
>>>>> 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.
>>>> 
>>>> ... and (1a) doesn't have the cross-area participation problem, it can be done in TSV.
>>> 
>>> I'm still not 100% convinced but this is not a point we need to settle right now. :)
>>> 
>>>>> I'm not convinced building (4) makes a lot of sense without (3a). But discussing that further is what this list is for. :)
>>>> 
>>>> I agree. Can you elaborate on (3): why, what? I'm not sure I'm with you here...
>>> 
>>> (see above, hope that's useful)
>>> 
>>>> 
>>>>>> 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?
>>>> 
>>>> Sorry for not making it clear enough: with "socket API extensions only" I meant something that's low-level, i.e. no mapping onto higher-level APIs, no general services, but exposing the things that transport currently do, at the abstraction level at which they do it, without exposing the protocol. Exactly the exercise we did in:
>>>> http://heim.ifi.uio.no/~michawe/research/publications/futurenet-icc2011.pdf
>>>> http://heim.ifi.uio.no/~michawe/teaching/dipls/stefan_joerer.pdf
>>>> 
>>>> => I think this is the stuff we really need to do no matter what, it's your (1a). It's not enough to solve the problem we want to solve, but we won't get anywhere without having done that.
>>> 
>>> Got it. Yep. Agreed.
>>> 
>>>>>> - 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...
>>>> 
>>>> I'm fine with doing these things early - but pretty much anything beyond your (1a) (plus signaling, as you suggest - see the second email, coming..) will make things more complicated community-wise as this then goes across areas. (1a) is a much simpler case.
>>> 
>>> The only question remaining in my mind about this work item, then, is whether or not it makes sense to separate 1a (a "supply side" survey of existing services) from 1b (which would be an expansion beyond what's already been done...).
>> 
>> I like the "supply side" phrasing! Indeed that's what 1a is. I think the separation from 1b makes sense to get started, unless we can define rules that place clear limits on 1b.
>> 
>> (one such rule that limits applications to what they are today could be: "only consider what's already being offered by existing higher-level APIs" => and, lo and behold, you're back at the TAPS charter  ;-)   ).
>> 
>> Cheers,
>> Michael
>> 
>> _______________________________________________
>> Udp35 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/udp35
> 
> _______________________________________________
> Udp35 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/udp35