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

From: Brian Trammell <[email-masked]>
Date: Thu, 22 May 2014 14:05:16 +0200

hi Michael,

(copying the udp35 list)

On 22 May 2014, at 12:56, Michael Welzl <[email-masked]> 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

---

From: Michael Welzl <[email-masked]>
Date: Thu, 22 May 2014 16:13:47 +0200

> (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…

"mix-ins" => do you have a pointer? Sorry if you presented it at an IETF and I forgot about that.

> (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  :-)

> 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'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.
> 

... and (1a) doesn't have the cross-area participation problem, it can be done in TSV.

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

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

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

> It seems like we're getting there...

Yes! Indeed that's the conversation we need to have

Cheers,
Michael

---

From: Brian Trammell <[email-masked]>
Date: Thu, 22 May 2014 18:38:10 +0200

> "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.

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

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

> ... 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 agree. Can you elaborate on (3): why, what? I'm not sure I'm with you here...

(see above, hope that's useful)

> => 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.

> 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…

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...).

Cheers,

Brian

---

From: Michael Welzl <[email-masked]>
Date: Fri, 23 May 2014 10:34:23 +0200

> 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…

That sounds very similar to this:  http://nena.intend-net.org/

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

> 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).

> 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…

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

---

From: Michael Welzl <[email-masked]>
Date: Mon, 26 May 2014 10:03:47 +0200

... 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... ?

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?

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:

> _______________________________________________
> Udp35 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/udp35

---

From: Brian Trammell <[email-masked]>
Date: Mon, 26 May 2014 11:00:10 +0200

hi Michael, all,

> - 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) w…

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

---

From: Michael Welzl <[email-masked]>
Date: Mon, 26 May 2014 11:50:53 +0200

> ...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) th…

Even if we limit this to the easy to agree on supply-side-only, I think we're talking about more than one document:
- what services should be offered?
- how to implement a system providing them (happy eyeballing etc.)?
- as part of "how to implement", signaling to make sure both sides know what's going on (you suggested it, fine by me)

> 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. y…

So this is the bit that concerns me. See my recent email to Spencer / the udp35 list: first and foremost I think it's going to be a problem to motivate folks (in particular, academics) to get active when it's not a WG, as a WG is seen as a sign of willingness on behalf of the IETF to do something in this space.

My thinking is mostly guided by:
- when can I give an update to the TAPS mailing list?  (because I think that's what everyone's waiting for)
- what do I tell them?
- how will they react?

I just don't feel very good about sending them a message that says: "A decision has been made. There is lots of interest, yet at this time a WG doesn't seem to be most constructive - the IAB wants us to go ahead as we are, to document the "supply side" of things and write 1-2 RFCs via the IAB stream". I can try that if that's really the best option, I'm just raising a concern.

> 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 toge…

That would sound good to me, based on the above;

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

Me too...  I just asked, but I'll shut up now  :)

Cheers,
Michael

---

From: [email-masked]
Date: Mon, 26 May 2014 11:17:56 +0100

Hi all,

I've been struggling to see the synergy between UDP 3.5 and TAPs - I'll
try and work through the emails again, but it seems to me that I need
help:  I don't yet see where you people think we have arrived.

To me, what I understand dimly of UDP 3.5 seems to be coming from that
areas that inspired work on applications-layer building blocks to assemble
protocols in user-land. At one time (history) the IESG/IAB turn focus
pushed towards kernel-transports and things changed track and the
development went in a different direction. I think the tide reversed some
time ago. In the IETF, RMT tried something different, and that's another
story. Some rethinking may be useful here, what I am not sure yet -
because I haven't really seen this presented.

I do see some synergy between the thread with the ideas of building TAPS
components to handle specific protocol mechanisms - SPROUT tried something
else, and IMHO exposed the weakness of this, in that everything becomes
tuneable and basic stability or ability to share capacity robustly is
compromised or at least needs to match some overall guidelines (or the
danger is we ignore the interactions needed for inclusive support of all
types of path and all types of apps sharing the path). But this idea of
modular design was not what I thought of as  the goal of TAPS.. (maybe my
vision was different?)

In TAPS, I was quite excited at the potential to find a set of robust ways
that the transport framework could figure out how to best use a network
path - and then choose an appropriate transport. There has long been a
need for a transport transition/selection framework.  Sure if the
framework succeeds, it would really open itself to enabling the building
block method in user-land (with all that involves). The thing that is
really bewildering me (I may be wearing different spectacles to you) is
why you think the expertise lies in RAI and APPS to work out how to do
this?

I think it is IMPORTANT to get these concepts/boundaries clear. I probably
don't understand the "derails" in London (maybe because I partly
contributed to them), but most of what I heard within the BoF seemed to be
helping define what should/should not be done. But maybe I missed some
later discussion?

I think it is important that TAPS meets in some way at the IETF (losing
this chance could stall things - and hawaii may turn out to be an odd ietf
meeting for many outside the IETF). My understanding on how and why the
group meets would depends on understanding more of this thread.

Gorry

>> - 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.
>
>> 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
>>
>>
>>
>>>>>>> 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.
>>>>>>
>>>>>> (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
>>>>>
>>>> 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.
>>>
>>>>>> (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.
>>>
>>>>>>> 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.
>>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> I'm not convinced building (4) makes a lot of sense without (3a).
>>>>>> But discussing that further is what this list is for. :)
>>>>>
>>>>>> 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:
>>>>> => 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.
>>>>
>>>>> 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
>>>

---

From: Brian Trammell <[email-masked]>
Date: Mon, 26 May 2014 17:48:10 +0200

> help:  I don't yet see where you people think we have arrived.

So there are a couple of things we're trying to address here:

(1) TAPS forsees a selection/negotiation mechanism, but if we have a selection/negotiation mechanism that ends up telling us "sorry, on this path you get to use SOCK_STREAM because I (the kernel) only support that and SOCK_SEQPACKET for reliable transports, and this path isn't SCTP-transparent" then we've built a bunch of machinery to tell us that transport is broken, which we knew in the first place. And I'm afraid this will be the case more often than not. We need tools in the toolbox beyond those we already have, and "roll-it-yourself over UDP" is one of those tools.

(2) We need to look into ways we can rescue "roll-it-yourself over UDP" from creeping middlebox breakage. Happy/angry* eyeballs is one approach here, but there may be things that can be done in a UDP shim layer that can help too.

I think we need to make progress down the path of solving these problems in parallel with figuring out the right way to decompose the dimensions of transport.

(* "angry eyeballs" -- the logical conclusion of escalating aggression in happy eyeballs across multiple dimensions; in other words, we can only go so far down this path alone before we have to be very careful that we're not part of the problem.)

> protocols in user-land.

This is one reason "UDP" is in the name: if you want raw sockets in userland without privilege on the machine, UDP is what you get. We can try to fix the privilege problem here in the meantime, but probably not within the IETF.

> At one time (history) the IESG/IAB turn focus

Brainstorming in front of a whiteboard on this point is one of the main reasons we want time in a smaller room in Toronto.

> types of path and all types of apps sharing the path).

One of the things we'd want to see come out of the UDP35 effort is a recommended restriction of the parameter space for congestion control when rolling your own: "here's how to compose a transport protocol without breaking the Internet or rediscovering CC by yourself".

> But this idea of

This is... not so much a complimentary vision, as an activity to start addressing what we think the next problems will be once one goes down the TAPS path...

> path - and then choose an appropriate transport.

...these being: (1) a transport framework that only has one transport to choose from is not extremely useful, and (2) a transport framework that requires new kernels and libraries everywhere is less quickly deployable than one relying only on application-layer changes.

> There has long been a
> block method in user-land (with all that involves).

... which is why I'd like those building blocks to be ready for the framework once it's done.

> The thing that is

It's not RAI and APPS that we need to work out how to make it work, it's that we need people who aren't wearing transport spectacles to help figure out what's useful. These areas represent the communities who will choose to use (or to ignore) TAPS.

> helping define what should/should not be done. But maybe I missed some

Much of what I labelled "derail" was the API discussion, because we spent too much time talking about the details of non-transport APIs (and about whether the IETF should be doing APIs at all) as opposed to the abstract interfaces necessary. But that might also be a function of my expectations...

> meeting for many outside the IETF).

(...I'll not be able to make Hawaii, for one...)

> My understanding on how and why the

The intention of the meeting on Saturday is more or less to continue the discussion we're having right now, in person, in front of a whiteboard; the format is "by-invitation brainstorming session" as opposed to an IAB workshop, for example, mainly because the whiteboard's there, and larger workshops are less productive per unit time.

Beyond that, we're planning on introductory talks about the outcome of that meeting in dispatch, appsarea, and tsvarea. It sounds like there's an open request before the TSV ADs to have a WG-forming BoF for TAPS with a smaller scope, as well, and some of the discussions on Saturday could feed into that BoF as well.

Cheers,

Brian

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 26 May 2014 11:55:42 -0500

This looks like progress ... a couple of comments inline.

>> help:  I don't yet see where you people think we have arrived.

Brian's response to this is helpful, but to use the term "arrived" to 
describe the current state of discussion would be IETF consensus 
malpractice :-)

We're not "there" yet. Please don't be confused!

> (* "angry eyeballs" -- the logical conclusion of escalating aggression in happy eyeballs across multiple dimensions; in other words, we can only go so far down this path alone before we have to be very careful that we're not part of the problem.)process

This characterization of "angry eyeballs" is very consistent with what I 
took away from the RTCWeb interim last week - it's not that people 
wanted to do HTTP Connect, it's that they wanted to try everything to 
get through the end-to-middle-damaged Internet, and HTTP Connect was 
another arrow in the quiver. So, yeah, that's a good point.

> The intention of the meeting on Saturday is more or less to continue the discussion we're having right now, in person, in front of a whiteboard; the format is "by-invitation brainstorming session"…

On openness ... nothing we've talked about is a secret from the 
community. We created this mailing list because we had enough 
person-to-person e-mail flying around about next steps that we needed 
one, but this isn't a cabal. The IETF doesn't do that, except in places 
like Nomcom.

The IAB actually can restrict participation - open IAB workshop calls 
for participation/papers are a relatively recent innovation. So I'm 
hoping the IAB does consider this to be a workshop, but of course I 
don't control that ("please do the right thing").

> Beyond that, we're planning on introductory talks about the outcome of that meeting in dispatch, appsarea, and tsvarea. It sounds like there's an open request before the TSV ADs to have a WG-formin…

This is quite important - we already had a conversation in London, and 
there's no law that we have to have another BOF before chartering a 
working group. I've seen a couple of offhand comments about what might 
make sense ("stuff that needs to happen in any case"). We may not even 
need a BOF to charter that work - we chartered TRAM without a BOF, and 
DART, and we're headed the same way with TCPINC.

In order for that to happen, we need a focused charter that people can 
agree to.

Michael, can you and whoever else makes sense have a discussion about 
first steps on the TAPS list, with an eye toward a small charter that 
has enough meat for a working group to start work?

Thanks,

Spencer

---

From: Eliot Lear <[email-masked]>
Date: Mon, 26 May 2014 19:38:59 +0200

Hi,

> (2) We need to look into ways we can rescue "roll-it-yourself over UDP" from creeping middlebox breakage. Happy/angry* eyeballs is one approach here, but there may be things that can be done in a U…

Perhaps I misunderstand, but IMHO angry eyeballs requires that there be
the UDP way and The Better Way<tm>.  I have my own definition of The 
Better Way, which includes among other things, NAT friendliness,
directionality detection, and something that doesn't need a blasted UDP
header.  Security in the transport layer (as opposed to TLS) would be a
really cool nice-to-have, as well.

The reason this doesn't simply fit into the Department of Obvious Things
To Say is that it's all about middle boxes, and finding the appropriate
characteristics they feel comfortable both implementing and allowing to
be deployed (e.g., directionality and (don't choke) NAT friendliness
probably being a requirement).

Eliot

---

From: Brian Trammell <[email-masked]>
Date: Mon, 26 May 2014 23:16:44 +0200

hi Spencer, all,

a quick response to one point, inline; more later...

On 26 May 2014, at 18:55, Spencer Dawkins <[email-masked]> wrote:

> On openness ... nothing we've talked about is a secret from the community.

Indeed, the list archives are also open.

> We created this mailing list because we had enough person-to-person e-mail flying around about next steps that we needed one, but this isn't a cabal. The IETF doesn't do that, except in places like Nomcom.
> 
> The IAB actually can restrict participation - open IAB workshop calls for participation/papers are a relatively recent innovation. So I'm hoping the IAB does consider this to be a workshop, but of course I don't control that ("please do the right thing").

We're calling the Saturday evening thing a "side meeting" as opposed to a "workshop", as there was no call for position papers or vetting thereof, rather invitation sent to people we figured would have something to say, given where we think the problem lies (if you're on this list, you're invited, apologies if that's not been clear). 

To elaborate on what I said in my previous message: the _sole_ reason for doing it this way as opposed to with an open call is to limit the _number_ rather than the _set_ of people in the room, because we know what we have is kind of a vague and uncooked idea, and we would like a chance to talk it over with a small group of knowledgable people who've thought a lot about the space before taking it to the wider community. As we're seeing in this thread, there's a _whole lot_ of overlap with TAPS, and a few ideas we think are architecturally related but which don't quite fit, and we'd like to figure out the best way to get everything that needs to get done to address this problem done.

Cheers,

Brian

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 26 May 2014 16:47:03 -0500

> To elaborate on what I said in my previous message: the _sole_ reason for doing it this way as opposed to with an open call is to limit the _number_ rather than the _set_ of people in the room, bec…

Brian, thanks for connecting the dots. It is complicated.

I'd like to see _something_ to happen on the IETF side, between now and 
Toronto, without interfering with what the IAB is doing on the bigger 
picture.

That's why I'm encouraging Michael and co-conspirators to propose a 
minimal charter that would allow protocol work to get started.

Just to unmuddle the next muddle - I was hoping that we would have a 
UDP35 conference call really soon, so we can be preparing for the side 
meeting in Toronto, and not be starting from scratch on Saturday 
evening. I expected we'd talk through the notes you sent to the mailing 
list last week, as a starting point.

I had planned to send out a Doodle poll today, so we could get the 
conference call scheduled, but, without interfering with what the IAB is 
doing on the bigger picture am now thinking that you and Joe need to be 
there, so I should start with dates/times that work for you. Could you 
two suggest a few date/times?

Thanks,

Spencer

So, I think

---

From: Brian Trammell <[email-masked]>
Date: Tue, 27 May 2014 10:27:35 +0200

hi Spencer, all,

On 26 May 2014, at 23:47, Spencer Dawkins <[email-masked]> wrote:

> I'd like to see _something_ to happen on the IETF side, between now and Toronto, without interfering with what the IAB is doing on the bigger picture.
> 
> That's why I'm encouraging Michael and co-conspirators to propose a minimal charter that would allow protocol work to get started.

(no hat) Given where the discussion here has gone, I could support the formation of a TAPS WG along these lines, and contribute to the bits of this whole effort that fit under the charter within that WG.

> Just to unmuddle the next muddle - I was hoping that we would have a UDP35 conference call really soon, so we can be preparing for the side meeting in Toronto, and not be starting from scratch on Saturday evening. I expected we'd talk through the notes you sent to the mailing list last week, as a starting point.
> 
> I had planned to send out a Doodle poll today, so we could get the conference call scheduled, but, without interfering with what the IAB is doing on the bigger picture am now thinking that you and Joe need to be there, so I should start with dates/times that work for you. Could you two suggest a few date/times?

I've put together a Doodle for this: http://doodle.com/phxegtcdgw5hgaig -- this is based on my calendar availability only, today, tomorrow, and Monday, evenings CET / hopefully not-too-early mornings west coast US.

Cheers,

Brian

---

From: Michael Welzl <[email-masked]>
Date: Tue, 27 May 2014 12:16:56 +0200

Hi,

> On 26 May 2014, at 23:47, Spencer Dawkins <[email-masked]> wrote:
(snip)

> (no hat) Given where the discussion here has gone, I could support the formation of a TAPS WG along these lines, and contribute to the bits of this whole effort that fit under the charter within th…

Great!
I will do as Spencer suggests, and I'd like to encourage everyone here who's interested in this chartering work to join the TAPS mailing list at https://www.ietf.org/mailman/listinfo/taps  if you're not on that list already.

Cheers,
Michael

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 29 May 2014 17:55:13 -0500

> hi Spencer, all,

...

> I've put together a Doodle for this: http://doodle.com/phxegtcdgw5hgaig -- this is based on my calendar availability only, today, tomorrow, and Monday, evenings CET / hopefully not-too-early mornin…

Just checking, but I hope we converged on Monday :-)

Spencer