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

[Spencer Dawkins <[e-mail]>]

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

On 05/26/2014 10:48 AM, Brian Trammell wrote:
> On 26 May 2014, at 12:17, [e-mail] wrote:
>
>> 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.

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!

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

>
>> 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.
> 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
>> 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.
> Brainstorming in front of a whiteboard on this point is one of the main reasons we want time in a smaller room in Toronto.
>
>> 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).
> 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
>> modular design was not what I thought of as  the goal of TAPS.. (maybe my
>> vision was different?)
> 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...
>
>> 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.
> ...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
>> 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).
> ... which is why I'd like those building blocks to be ready for the framework once it's done.
>
>> 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?
> 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.
>
>> 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?
> 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...
>
>> 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).
> (...I'll not be able to make Hawaii, for one...)
>
>> My understanding on how and why the
>> group meets would depends on understanding more of this thread.
> 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.

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-forming BoF for TAPS with a smaller scope, as well, and some of the discussions on Saturday could feed into that BoF as well.

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