Re: [Udp35] Trying to learn about udp35

[Jana Iyengar <[e-mail]>]

Brian, all,

I'm reviving this thread after a while -- apologies for responding so late.
Was there a kickoff call (or a doodle poll to set up the kickoff call?) I
may have missed it entirely, and apologies if I did.

Transport definitely needs architectural reimagining, and I am very happy
to see this conversation begin.

There's advise for future transport work that can come out of conversations
here, and this could influence the nature of work done at the IETF. In
terms of transport protocol work, TSV currently largely focusses on TCP
(RMCAT is a departure, and a good one; we finally have an app driving
design, however frustrating that may seem.) There may be some good from
thinking about general transport mechanisms -- Brian suggested
reordering-resiliency, and that is a great example of a transport problem
that could totally be chased in a general manner, independent of TCP. One
of the hard problems in the past, IMO, has been separating mechanisms from
actual implementations in protocols, and *maybe* one outcome of this
conversation is general guidelines that can help new transports not have to
translate everything out of TCP-ese.

Outside of just transport mechanisms, there's deployment issues that we've
faced in the past. We've still not solved that problem, but I think we may
be better equipped to attack that question now than we were in the past...
at any rate, I'm very glad to sit and discuss these and various other
relevant questions.

(FWIW: There's overlap with other areas that we cannot ignore -- for
instance, there's substantially more overlap of transport with security,
IMO, than we currently let ourselves think about at the IETF.)

Thanks for starting this effort, and I look forward to brainstorming. Do we
have a time yet? I still haven't booked my flight, and I'd like to make
sure I don't get in too late.
- jana


On Thu, May 22, 2014 at 7:24 AM, Michael Welzl <[e-mail]> wrote:

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