Re: [Udp35] Trying to learn about udp35

[Michael Welzl <[e-mail]>]

On 22. mai 2014, at 14:09, Brian Trammell wrote:

> hi Michael, all,
> 
> (Crossing threads here, another reply to follow; in the meantime, inline...)
> 
> On 22 May 2014, at 10:27, Michael Welzl <[e-mail]> wrote:
> 
>> Hi,
>> 
>> Thanks a lot for your response, I greatly appreciate that!  In line:
> 
> <snip>
> 
>>>> If this means having a WG-forming BoF in Toronto, then I guess it's about time to get this organized.
>>> 
>>> 
>>> While it's clear that the TAPS charter as formulated addresses the same problem, and that most if not all of the various technical pieces remain the same, it's not clear to me personally that binding the solutions to these problems to a (single) IETF-defined API is the best way to ensure this work sees wide implementation and adoption. There are other paths: providing building blocks to API designers, just accepting the fact that people are already designing APIs and providing them guidance (especially on how not to break things, e.g. CC), doing one of these latter things and building an API on top of that, etc... and this is part of what we want to talk about in Toronto.
>> 
>> So this is really the crux of the debate, and the reason why I said "let's please not rinse and repeat":
> 
> I think what we have here is a somewhat misunderstood case of emphatic agreement. :)
> 
>> - at the Bar BOF in Vancouver, we got feedback saying "this shouldn't be one API, in one place. There should only be services defined, and they can then be supported in various ways; anyway people aren't using the socket interface much, anymore"
> 
> (This bit is true, and it is false. There aren't a lot of application programmers writing things to the sockets API anymore. But if you're a platform/library person writing an API implementation for app developers, and you want to use kernel TCP -- i.e. you don't own the kernel you're writing to -- you're still limited by it.  But this is a detail.)
> 
>> - then, we incorporated this in the charter ( https://sites.google.com/site/transportprotocolservices/charter-proposal-before-bof ), by writing that we'll specify services, and only *describe* at least one *example* API with one possible implementation.
>> 
>> - because the London BoF was non-WG-forming, the charter wasn't presented; I think this led to some misunderstanding of Gorry's presentation, which showed *one possible implementation* of this - folks took it to mean that this is the only architecture we're proposing, we want to do one single API, and some ended up saying the same things that were already said at the Bar BOF.
> 
> So here's where we run into the problem, and this is more about _framing_ than content, and something we identified as the reason the London BoF missed an opportunity to get more feedback. In my opinion even speaking of these things in terms of APIs is risky, because the effect of doing so within the IETF will be that people show up and debate the pros and cons of this engineering detail of this API, versus that engineering detail of that API, versus whether we should be in the API business at all, and the core work gets lost in the noise.

Ok. I understand, and I agree.


>> So now we're already sitting with this charter that, *before* London, already incorporated much of the feedback that we received in London again. And now you write "not sure that a (single) IETF-defined API is the best way ..."   :-)    => see. That shows me that my "square one" concern was at least not completely unfounded.
> 
> At least as it reads to me, the charter on the transportservices site (this is the latest, yes)? reads as if the goal is to survey application APIs then specify a meta-API for all transport services APIs; given the derail in London, I'm afraid the example API will be an expensive distraction in the best case.

Yes it's the latest; yes I see, and agree. We can remove it.


>>>> I can imagine that we want to do more than what we have written into our charter, but what I'm suggesting is not to wait with piece A of the puzzle just because we in fact want pieces A, B and perhaps C too, and we have to still find out if/how to do pieces B and C. I'm having a hard time imagining that piece A just won't fit, whatever B and C may look like, so why not get A done?!
>>> 
>>> The charter, especially its formulation of the problem statement, is a good starting point; to borrow your terminology, I'll try to follow up tomorrow or Friday with specific suggestions on how we might (lightly) tweak A to better fit aspects of the problem space we didn't really get into either in our premeeting or during the BoF in London.
>> 
>> Great, thanks!
> 
> (see comment below, more to follow...)
> 
>> 
>>> I note that the first concrete deliverable we've identified is essentially item 1 on the proposed TAPS charter; this analysis work should absolutely continue regardless of progress in forming any future WG -- indeed, formation of a working group would be likely to slow this work down, as opposed to speeding it up. Such an item could be published on the IAB stream if a WG isn't formed in the meantime. 
>> 
>> Okay... indeed that was my thinking - that at least some of the outputs in the TAPS charter should be done anyway, no matter what the bigger plans are.
> 
> We absolutely need the first deliverable (Informational RFC summarizing the services provided by IETF transport protocols and congestion control mechanisms as well as the requirements of common APIs) soon, regardless of venue/stream. Personally I wouldn't limit it to the interfaces provided by common APIs, if only because (1) a lot of these APIs provide additional services above and beyond what a transport layer should and (2) being limited to the transports currently available, they may miss dimensions where innovation could be possible.
> 
> A concrete example of (2): One of the comments from the routing ADs during the retreat is that a transport that was extremely reordering-tolerant (which to some extent requires either reordering or latency tolerance on the application's part) would enable new services based on maximizing intra-(micro-)flow path diversity -- think a "spread-spectrum Internet" to increase pervasive surveillance resistance in the core. 

Well.... so if you open up for "whatever applications want, based on use cases we can describe", you find yourself in an endless sea of possibilities. I agree that this is where things get really useful and exciting, but this is also where it's going to be hard to go ahead with people from one area, and harder to imagine a WG with a clear scope and end. THIS could be the IRTF bit IMO.


> (Side note: the fact that this came from routing -- an area that appears at first glance to consider transport irrelevant, and certainly has a relatively small contributorship overlap with TSV working groups -- means that there's scope to get good feedback across areas that we'll miss if we do this as a TSV-area WG with mostly the usual suspects in the room. Which is one reason we started running with this as an IAB activity post-London.)
> 
> I also think it's unwise to take "signaling improvement" out of scope for the eventual full effort (though it's entirely possible that it's necessary to separate this from the service-taxonomy and service recommendation work). I suspect that the reason to specifically exclude this and QoS is that those two taken together are AEON things.

No, the reason was just to avoid ratholing into a signaling debate (but indeed AEON nicely complements all this). Signaling is also one of the points I'm least sure about, as it could be used to make the inevitable Happy Eyeballing more scalable.


> But one of the real risks I see is that continued middlebox path impairment makes it harder and harder for anything other than straight TCP (or worse, straight HTTP) to work end-to-end, such that we'll need (1) a "NAT/middlebox-friendly" shim layer (which would itself have to be based on TCP or UDP) to support further innovation in transport plus (2) a way to do raw sockets in userspace without privilege, (which pretty much means UDP), in order to support explicitly non-TCP transports (i.e., what QUIC has done). Okay, not really signaling, but layering. And again, this might be a separate effort under this general umbrella, coordinated with TAPS, as opposed to something TAPS itself must address.

Yes, separate, and it also sounds like you're making this too complicated, frankly (I think best effort + happy eyeballing + fall-backs can go a long way). Anyway, separate please.


>> As for a WG slowing things down, I wasn't aware of that being possible but that's just me not knowing as much about IETF internals as (all of) you.
> 
> A better way to put this might be that it's better to bring a fully formed idea into a WG to flesh out the ideas and engineering details than it is to do green-field engineering from first principles in a new WG. While TAPS is much closer to the former than the latter at this point, I think there's still enough disgreement/confusion about the scope of all this post-London that I think it would be very useful for a smaller group to sit down and draw boxes around the uncertainties 
> 
> Hence the meeting in Toronto. :)
> 
> On which: if there's anyone who can't make Saturday afternoon/evening, we can try to reschedule, but we'd strongly prefer to be able to do this before the official festivities start.
> 
> Cheers,
> 
> Brian



Cheers,
Michael