Subject: [Udp35] Trying to learn about udp35

From: Jana Iyengar <[email-masked]>
Date: Tue, 13 May 2014 08:47:24 -0700

Hello all,

I'm writing to learn more about udp35 and the secret cabal meeting that is
allegedly happening Saturday evening before the IETF. Can someone post a
link or some summary of the goals of this group?

Thanks much!
- jana

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 13 May 2014 19:17:10 +0000

More detail coming.  Waiting to get a few more people in, and we'll figure
out how to get everyone up to speed.

On 5/13/14, 9:47 AM, "Jana Iyengar" <[email-masked]> wrote:

>I'm writing to learn more about udp35 and the secret cabal meeting that
>is allegedly happening Saturday evening before the IETF. Can someone post
>a link or some summary of the goals of this group?

-- 
Joe Hildebrand

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 19 May 2014 12:13:09 -0500

On 05/13/2014 10:47 AM, Jana Iyengar wrote:
> Hello all,
>
> I'm writing to learn more about udp35 and the secret cabal meeting 
> that is allegedly happening Saturday evening before the IETF. Can 
> someone post a link or some summary of the goals of this group?
>
> Thanks much!
> - jana

Hi, Jana,

If I understood correctly, the plan is that we'll schedule a conference 
call Real Soon Now to level-set folks, just as soon as someone sends out 
a doodle poll so we can figure out when :-)

So, please stay tuned ...

Spencer

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 20 May 2014 10:54:41 -0700

Thanks for the update, Spencer; I'll look for the poll. I would like to
make travel arrangements soon, and I'm waiting to hear about when the
pre-IETF meeting will be held so that I can book accordingly. I'd like to
book soon, so I hope to hear about the schedule soon ... but if nothing's
been finalized yet, I understand.

On Mon, May 19, 2014 at 10:13 AM, Spencer Dawkins <
[email-masked]> wrote:

>> is allegedly happening Saturday evening before the IETF. Can someone post a
> call Real Soon Now to level-set folks, just as soon as someone sends out a
> doodle poll so we can figure out when :-)
>
> _______________________________________________
> Udp35 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/udp35
>

---

From: Brian Trammell <[email-masked]>
Date: Wed, 21 May 2014 12:30:38 +0200

hi Jana, all,

Apologies for silence to date on this point; I'm traveling way too much this month. The basic problem statement is hidden in the slide deck I presented at the IESG/IAB meeting in Cancun, attached. We'll want to have a level setting call (most probably early next week) to expand upon this.

Cheers,

Brian

On 20 May 2014, at 19:54, Jana Iyengar <[email-masked]> wrote:

> Thanks for the update, Spencer; I'll look for the poll. I would like to make travel arrangements soon, and I'm waiting to hear about when the pre-IETF meeting will be held so that I can book accordingly. I'd like to book soon, so I hope to hear about the schedule soon ... but if nothing's been finalized yet, I understand.
> 
> 
> On Mon, May 19, 2014 at 10:13 AM, Spencer Dawkins <[email-masked]> wrote:
> 
> I'm writing to learn more about udp35 and the secret cabal meeting that is allegedly happening Saturday evening before the IETF. Can someone post a link or some summary of the goals of this group?
> 
> Thanks much!
> - jana
> 
> Hi, Jana,
> 
> If I understood correctly, the plan is that we'll schedule a conference call Real Soon Now to level-set folks, just as soon as someone sends out a doodle poll so we can figure out when :-)
>

---

From: Michael Welzl <[email-masked]>
Date: Wed, 21 May 2014 19:05:57 +0200

Hi all,

Glad to be onboard!

As for the slide deck, it looks very interesting but it also reminds me of much that we have already discussed in the TAPS effort. Note that this non-WG-forming BOF in London was preceded by a bar BOF, which was preceded by more work ... e.g. we have worked out a draft charter at some point, and agreed to do things pretty similar to what seems to be proposed in these slides. Now surely I'm missing the bigger picture here, but I'd like to make a plea to not go back to square one but instead continue from where things already are at (see https://sites.google.com/site/transportprotocolservices/ ). If this means having a WG-forming BoF in Toronto, then I guess it's about time to get this organized.

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

Cheers,
Michael

On 21. mai 2014, at 12:30, Brian Trammell <[email-masked]> wrote:

> <udp35-cancun.pdf>

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Wed, 21 May 2014 17:25:50 +0000

I think we're way too early for a WG-forming BoF.  Let's get together
informally to discuss what has been done to date, and see if there's a way
to progress forward.

I think Brian and I had discussed doing this Saturday night before the
Toronto meeting, but I'm open to other suggestions.

On 5/21/14, 11:05 AM, "Michael Welzl" <[email-masked]> wrote:

>Hi all,
>
>Glad to be onboard!
>
>As for the slide deck, it looks very interesting but it also reminds me
>of much that we have already discussed in the TAPS effort. Note that this
>non-WG-forming BOF in London was preceded by a bar BOF, which was
>preceded by more work ... e.g. we have worked out a draft charter at some
>point, and agreed to do things pretty similar to what seems to be
>proposed in these slides. Now surely I'm missing the bigger picture here,
>but I'd like to make a plea to not go back to square one but instead
>continue from where things already are at (see
>https://sites.google.com/site/transportprotocolservices/ ). If this means
>having a WG-forming BoF in Toronto, then I guess it's about time to get
>this organized.
>
>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?!
>
>Cheers,
>Michael
>
>
>> Apologies for silence to date on this point; I'm traveling way too much
>>this month. The basic problem statement is hidden in the slide deck I
>>presented at the IESG/IAB meeting in Cancun, attached. We'll want to
>>have a level setting call (most probably early next week) to expand upon
>>this.
>> 
>> Cheers,
>> 
>> Brian
>> 
>> <udp35-cancun.pdf>
>>> Thanks for the update, Spencer; I'll look for the poll. I would like
>>>to make travel arrangements soon, and I'm waiting to hear about when
>>>the pre-IETF meeting will be held so that I can book accordingly. I'd
>>>like to book soon, so I hope to hear about the schedule soon ... but if
>>>nothing's been finalized yet, I understand.
>>> 
>>> 
>>> If I understood correctly, the plan is that we'll schedule a
>>>conference call Real Soon Now to level-set folks, just as soon as
>>>someone sends out a doodle poll so we can figure out when :-)
>>> 

-- 
Joe Hildebrand

---

From: Michael Welzl <[email-masked]>
Date: Wed, 21 May 2014 23:30:41 +0200

On 21. mai 2014, at 19:25, Joe Hildebrand (jhildebr) <[email-masked]> wrote:

> I think we're way too early for a WG-forming BoF.

What makes you say that? It's the first time I hear it and it doesn't match my impression.

Cheers,
Michael

---

From: Brian Trammell <[email-masked]>
Date: Thu, 22 May 2014 00:22:08 +0200

hi Michael,

a brief reply now to be followed by a more in-depth one...
 
On 21 May 2014, at 19:05, Michael Welzl <[email-masked]> wrote:

> Hi all,
> 
> Glad to be onboard!
> 
> As for the slide deck, it looks very interesting but it also reminds me of much that we have already discussed in the TAPS effort. Note that this non-WG-forming BOF in London was preceded by a bar BOF, which was preceded by more work ... e.g. we have worked out a draft charter at some point, and agreed to do things pretty similar to what seems to be proposed in these slides. Now surely I'm missing the bigger picture here, but I'd like to make a plea to not go back to square one

This is absolutely not the intention; to some extent what we've done since London is look at the problem from a slightly different angle ("what are the architectural implications of the difficulty of evolving transport, and why is it hard to evolve?" as opposed to "how can we improve the interface to transport so that we can offer new services?"), and we've come to basically the same idea of the problem that TAPS has -- yes, indeed, the interface is part of the problem. This convergence is a good thing...

> but instead continue from where things already are at (see https://sites.google.com/site/transportprotocolservices/ ). 

...and now that we're here, we'd like to brainstorm in Toronto about the way forward. We want to make sure the work that's been done in the TAPS effort is successful.

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

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

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.

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. 

Cheers,

Brian

---

From: Michael Welzl <[email-masked]>
Date: Thu, 22 May 2014 10:27:38 +0200

Hi,

Thanks a lot for your response, I greatly appreciate that!  In line:

> ...and now that we're here, we'd like to brainstorm in Toronto about the way forward. We want to make sure the work that's been done in the TAPS effort is successful.

Sounds good to me!

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

So this is really the crux of the debate, and the reason why I said "let's please not rinse and repeat":

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

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

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

Great, thanks!

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

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

Again, thanks for your response, it does shed some light on things.

Cheers,
Michael

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 22 May 2014 03:37:03 -0500

Hi, Michael (and all),

I've seen notes from Joe and Brian, but I'm replying to yours.

The most important thing I've seen someone say is ... please don't stop 
the analysis work you're doing on piece A, on the TAPS mailing list. We 
set up a separate mailing list for big-picture noodling about several 
pieces and how they fit together, so that our conversation here wouldn't 
be a distraction for TAPS.

Creating one or more working groups isn't the end game, so let's not be 
distracted by that, either. Figuring out how to solve an important 
problem that people have been banging their heads against for a few 
decades, and get applications to take advantage of transport mechanisms 
that aren't TCP and aren't UDP so that evolving transport makes a 
difference to the way the Internet works, is the end game, at least in 
my mind. We don't need to have a BOF at all, if we can come up with a 
plan without one.

If not having a working group creates obstructions, please let us know. 
For now, TAPS has an e-mail list and can do the analysis work there. You 
don't have an approved charter yet, but TAPS doesn't need one to talk. 
You don't need an approved charter to have a design session in Toronto, 
assuming that you don't need 100 people charging their laptops and 
reading e-mail in the same room while people make Powerpoint 
presentations to make progress. If TAPS needs something else to move 
forward, please tell us.

I think the TAPS conversation in London was successful in setting a 
direction. My read is that at least some of the other IESG and IAB 
members agree with that. I note that TAPS was one of only two topics 
from the IESG for the joint IESG/IAB session at the retreat a couple of 
weeks ago, and joint IESG/IAB face-to-face time is precious enough that 
we don't spend it on stuff that doesn't matter.

The IAB folk can correct me if I'm wrong, but one of the UDP35 topics is 
that IAB folk are proposing that the IAB charter a program in this space 
*in addition to TAPS*, and I would like to see them providing a home for 
architectural work beyond "here's a protocol spec or two", which is what 
an IETF working group would provide. I'd like to have the IAB's 
perspective inform any engineering work the IESG charters in the IETF.

For the purposes of the UDP35 discussion, I don't want the Saturday 
afternoon session in Toronto to be the tail that wags the dog. The 
reason we mention it at all was to let people know we'd like to have 
that session before everyone books their tickets to arrive Sunday morning:-)

We need to be talking now, mostly in e-mail. We do need to level-set 
early in that conversation, and that's harder to do via e-mail. I would 
like to see a kickoff call among the folks on this mailing list, and 
sooner rather than later. I hope scheduling it during the week of June 2 
is realistic.

If no one else sends out a doodle poll this week for a kickoff call the 
week of June , I'll do it Monday.

Does this make sense?

Thanks,

Spencer, who will be traveling for the next several hours ... so please, 
don't wait for me to talk amongst yourselves :-)

---

From: Michael Welzl <[email-masked]>
Date: Thu, 22 May 2014 11:50:42 +0200

Hi,

First of all, thank you Spencer for sharing this!

More below:

On 22. mai 2014, at 10:37, Spencer Dawkins wrote:

> The most important thing I've seen someone say is ... please don't stop the analysis work you're doing on piece A, on the TAPS mailing list. We set up a separate mailing list for big-picture noodling about several pieces and how they fit together, so that our conversation here wouldn't be a distraction for TAPS.
> 
> Creating one or more working groups isn't the end game, so let's not be distracted by that, either. Figuring out how to solve an important problem that people have been banging their heads against for a few decades, and get applications to take advantage of transport mechanisms that aren't TCP and aren't UDP so that evolving transport makes a difference to the way the Internet works, is the end game, at least in my mind. We don't need to have a BOF at all, if we can come up with a plan without one.
> 
> If not having a working group creates obstructions, please let us know. For now, TAPS has an e-mail list and can do the analysis work there. You don't have an approved charter yet, but TAPS doesn't need one to talk. You don't need an approved charter to have a design session in Toronto, assuming that you don't need 100 people charging their laptops and reading e-mail in the same room while people make Powerpoint presentations to make progress. If TAPS needs something else to move forward, please tell us.

This seems problematic. I have given this quite some thought now. At first, I thought I'd just create a list of things we need, and we can get going. Here's what came to my mind:

1. Motivation. People need to know the context of what's going on, I need to send them a "formal" email telling them some conclusion after the BoF; right now nobody does anything as everybody is just waiting. By "need to know the context" I mean that TAPS needs to know which RFCs will be produced, with what status. We'd have to refine the charter just to have a plan - e.g. right now we have a number of drafts, what do we do with them? Merge some, kill some? That would depend on the plan, which is the charter. But can we be sure that RFCs are really going to be published, and really get the status we wish for, when it's only a "wish" and not an approved charter? I think not being a WG will leave people unsure about these matters.

- Management. There need to be chairs, ideally not myself.

More about motivation: I recently visited another University which is interested in this work. Being IETF-experienced academics, they could be very helpful in TAPS, and I see them as representative for a larger group of (potential) TAPS participants. When I talked to them about TAPS, their whole take was "isn't the IETF getting obsolete? Will this EVER happen? Aren't we better off just doing research on our own?" but yet they were very interested **BECAUSE** of the prospect of this being a WG, which, to them, is an indication of the IETF really wanting to make a change.

However, if I imagine how they'd react to "this is just a mailing list now, we can meet anyway and perhaps publish RFCs too without being a WG, let's just get work done" then I'm not very hopeful. After all, a WG also comes with a certain visibility that reflects in e.g. project reviews and project proposals written by academics. In other words, being involved in a WG has more value to them (any academic - and academics, I think, could play a valuable role here) than being involved in a less formal activity.

To conclude: you wrote "if not having a working group creates obstructions, please let us know" => frankly, I actually do believe that this approach will create significant disappointment and will let us lose some key people early on. Now I can imagine that WGs can be slow, with too many people involved, discussions ratholing, etc. etc. - but then there is the positive value of a certain visibility, an IETF-approved charter, some trust on behalf of the folks involved that what comes out has at least SOME chance of deployment...  all in all, I do think we really should create a WG, and maybe eliminate slow-ness by just narrowing the charter accordingly.

> I think the TAPS conversation in London was successful in setting a direction. My read is that at least some of the other IESG and IAB members agree with that. I note that TAPS was one of only two topics from the IESG for the joint IESG/IAB session at the retreat a couple of weeks ago, and joint IESG/IAB face-to-face time is precious enough that we don't spend it on stuff that doesn't matter.
> 
> The IAB folk can correct me if I'm wrong, but one of the UDP35 topics is that IAB folk are proposing that the IAB charter a program in this space *in addition to TAPS*, and I would like to see them providing a home for architectural work beyond "here's a protocol spec or two", which is what an IETF working group would provide. I'd like to have the IAB's perspective inform any engineering work the IESG charters in the IETF.
> 
> For the purposes of the UDP35 discussion, I don't want the Saturday afternoon session in Toronto to be the tail that wags the dog. The reason we mention it at all was to let people know we'd like to have that session before everyone books their tickets to arrive Sunday morning:-)
> 
> We need to be talking now, mostly in e-mail. We do need to level-set early in that conversation, and that's harder to do via e-mail. I would like to see a kickoff call among the folks on this mailing list, and sooner rather than later. I hope scheduling it during the week of June 2 is realistic.
> 
> If no one else sends out a doodle poll this week for a kickoff call the week of June , I'll do it Monday.

Sounds all good to me...

Cheers,
Michael

> 
> Does this make sense?
> 
> Thanks,
> 
> Spencer, who will be traveling for the next several hours ... so please, don't wait for me to talk amongst yourselves :-)
>

---

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

hi Michael, all,

(Crossing threads here, another reply to follow; in the meantime, inline...)

> Thanks a lot for your response, I greatly appreciate that!  In line:

<snip>

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

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

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

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.

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

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.

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

(see comment below, more to follow...)

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

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

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.

> 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

---

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

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

Ok. I understand, and I agree.

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

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

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

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.

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

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

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.

Cheers,
Michael