Re: [Udp35] Trying to learn about udp35

[[e-mail]]

Hi,

> 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.)
>
Why do you say this? I don't think this is the case, TSV has been working
on UDP, SCTP, multicast methods, various NAT-related things, etc.It's far
from being TCP, but that may well be a perception held by people outside
the area.

>  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.
>
Could be really useful - because there's also work outside of TSV which
uses UDP, but then tries (in some cases partially) to reinvent existing
transport methods.

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

> 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
>>
>>
> _______________________________________________
> Udp35 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/udp35
>