Subject: [Taps] So, is this the -00 charter yet?

From: Spencer Dawkins <[email-masked]>
Date: Thu, 29 May 2014 18:20:33 -0500

The folks on the mailing list who have responded so far, seem to be 
converging ...

Is 
https://sites.google.com/site/transportprotocolservices/charter-proposal 
still the most recent charter version?

Is it time to do a Mailing List Last Call before I put the charter 
proposal forward in the datatracker? :-)

Spencer, who finally remembered to change the subject field :-)

---

From: Michael Welzl <[email-masked]>
Date: Fri, 30 May 2014 08:55:24 +0200

On 30. mai 2014, at 01:20, Spencer Dawkins <[email-masked]> wrote:

> The folks on the mailing list who have responded so far, seem to be converging ...
> 
> Is https://sites.google.com/site/transportprotocolservices/charter-proposal still the most recent charter version?

Yes.

> Is it time to do a Mailing List Last Call before I put the charter proposal forward in the datatracker? :-)

I think it's worth a try! Folks, if you have any comments, bring them up within the next 3 days, including today - i.e. by the end of Sunday.

Cheers,
Michael

---

From: [email-masked]
Date: Fri, 30 May 2014 08:13:09 +0100

This seems like a good Charter to me:
https://sites.google.com/site/transportprotocolservices/charter-proposal

Gorry

> I think it's worth a try! Folks, if you have any comments, bring them up
> within the next 3 days, including today - i.e. by the end of Sunday.
>
> Cheers,
> Michael
>
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps
>

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 30 May 2014 09:41:36 +0200

> https://sites.google.com/site/transportprotocolservices/charter-proposal
Full ACK.

Best regards
Michael

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 30 May 2014 09:24:49 +0100

+1

On Fri, May 30, 2014 at 8:13 AM, <[email-masked]> wrote:

> > On 30. mai 2014, at 01:20, Spencer Dawkins <
> [email-masked]>
> > wrote:
> >

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Fri, 30 May 2014 10:34:30 +0200

Good for me

Marie-José Montpetit
[email-masked]
[email-masked]

> On May 30, 2014, at 9:41, Michael Tuexen <[email-masked]> wrote:
>

---

From: Toby Moncaster <[email-masked]>
Date: Fri, 30 May 2014 10:23:49 +0100

+1

---

From: Anna Brunstrom <[email-masked]>
Date: Fri, 30 May 2014 11:27:57 +0200

+1

Anna

---

From: Aaron Falk <[email-masked]>
Date: Fri, 30 May 2014 10:29:20 -0400

My proposed wording change (which at least Gorry accepted) is not in the
current draft.  Repeating:

Revise working group goal #2 to read "specify a set of transport services
that end systems **implementing TAPS** need to provide and provide guidance
on choosing among available mechanisms and protocols to obtain a given
transport service."

Otherwise looks good.

--aaron

---

From: Michael Welzl <[email-masked]>
Date: Fri, 30 May 2014 16:48:41 +0200

sorry, agree too, will fix asap (but can't for a few hours)

Sent from my iPhone

> On 30. mai 2014, at 16:29, Aaron Falk <[email-masked]> wrote:
> 
> My proposed wording change (which at least Gorry accepted) is not in the current draft.  Repeating:
> 
> Revise working group goal #2 to read "specify a set of transport services that end systems **implementing TAPS** need to provide and provide guidance on choosing among available mechanisms and protocols to obtain a given transport service."
> 
> Otherwise looks good.
> 
> --aaron
> 
> 
>

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Fri, 30 May 2014 15:55:35 +0000

On 5/30/14, 8:29 AM, "Aaron Falk" <[email-masked]> wrote:

>that end systems **implementing TAPS** need to provide and provide
>guidance on choosing among available mechanisms and protocols to obtain a
>given transport service."

There's no protocol for TAPS yet, so nobody is going to "implement TAPS".
Suggested change: "end systems need to provide" -> "applications want to
use".

-- 
Joe Hildebrand

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Fri, 30 May 2014 15:57:43 +0000

>proposal forward in the datatracker? :-)

I would suggest modifying #3 to allow for success on the charter if the
experimental protocol is overcome by events.  I'm not convinced, for
example, that publishing that protocol as an RFC will have value over
there being multiple I-Ds with different ideas until we come up with
something standards-track.

-- 
Joe Hildebrand

---

From: [email-masked]
Date: Fri, 30 May 2014 17:15:27 +0100

I thought the discovery part the exciting goal of the Charter?

I may have misunderstood, the suggested edit, so can you be clearer what
you are saying - are you saying if the mechanism is accepted we could
directly go to a PS?

Gorry

---

From: [email-masked]
Date: Fri, 30 May 2014 17:18:33 +0100

I think that's a big change in what I have seen discussed on this list..
I'm really unclear about what you think doesn't exist in the set of
transport specs?

Gorry

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Fri, 30 May 2014 16:24:30 +0000

>I thought the discovery part the exciting goal of the Charter?

Yes.  But, you don't need an RFC to discover things.  Often I-Ds are fine
for that.

>you are saying - are you saying if the mechanism is accepted we could

That's one possibility.  There are several other reasons you might not
want to publish the work as an RFC when the time comes.

The biggest issue, however, is that as far as I know, there are no
concrete proposals for what that protocol will look like.  As such,
history in the IETF shows that your chances of failure in the
design-by-committee process are quite high.

<hat type='IAB'>
I'm trying to ensure that we're not setting a working group up to fail.
</hat>

-- 
Joe Hildebrand

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Fri, 30 May 2014 16:38:28 +0000

>I'm really unclear about what you think doesn't exist in the set of

One that I can deploy in enough places that isn't TCP.

- SCTP is awesome.  It has all of the features and the corresponding
complexity.  I think we have evidence that it will never deploy at
Internet scale except perhaps when encapsulated in UDP.

- However, UDP is blocked on a good number of corporate networks.  The
reason given is that there is no good way to reason about directionality
or session length.  There are likely a few other bits needed.

- My recent analysis of DTLS suggests that encapsulating SCTP in DTLS over
UDP (as the WebRTC folks are currently doing) is not likely to add enough
session semantics to get past this deployment issue.

- New layer 4 protocols are unlikely to do better than SCTP in terms of
deployment.  There are now too many old kernels and middleboxes that know
only UDP and TCP that we're unlikely to ever make significant progress
unless we migrate innovation into unprivileged userspace.

It may be that one possibility would be to do a real layer 5 protocol over
UDP, and move transport-like innovation above that.  If we did a protocol
like that, would it satisfy the current charter?

-- 
Joe Hildebrand

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 30 May 2014 17:43:41 +0100

> Yes.  But, you don't need an RFC to discover things.  Often I-Ds are fine
I don't agree - implementing discovery mechanisms for enhanced interop 
of existing transport protocols based on unpublished IDs seems rather 
crazy to me. I can't believe the transport area has to limit the number 
of RFCs to such an extent that a WG can't publish a spec for people to 
implement techniques - albeit Experimental in status until widespread 
deployment (if the bar for PS is set that high - as it often is in TSV).

> want to publish the work as an RFC when the time comes.
I can believe this for any charter item, but I don't see the argument 
against this line?

> I'm trying to ensure that we're not setting a working group up to fail.
Maybe I am hearing you wrong: My problem is that I'd argue that you are 
failing the WG before it starts, by somehow saying you can do the 
analysis and setup the stack, but that the group won't publish the 
networking specs that allow it to be used across a path to another 
system? Or are you saying the group shouldn't be chartered until it has 
a candidate solution for this? - Either way I think either I or you may 
be confused.

Gorry

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Fri, 30 May 2014 16:46:05 +0000

>a candidate solution for this? - Either way I think either I or you may

No, I'm suggesting the group recharter when it has a candidate solution.
Rechartering is relatively easy, particularly if you're showing signs of
success on the existing charter.

-- 
Joe Hildebrand

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 30 May 2014 18:27:01 +0100

> like that, would it satisfy the current charter?
On the last point - I'm not going to comment on the issues with your 
proposed
approach - because that's a different topic.

I don't recall this being brought up at the BOF at all, and I personally 
don't see that as the initial goal of this group. Others may feel 
completely different though, I'll let them comment.

I still don't get your point:

Are you saying that you think the WG needs to recharter before it 
designs a *NEW* transport protocol working over UDP? - I'd agree to 
that. Designing a new protocol over UDP is a serious task.

You seem to suggest the "new protocol" is going to magically work where 
for instance SCTP/UDP was doomed never to work. I don't buy the argument 
you can make a magic protocol that all middlebox vendors will love. An 
interesting debate, and I think your analysis is really interesting - 
but surely one to be started in the IRTF?

So what technical reason do we have for not allowing the group to look 
at mechanisms and find solutions that can be published in the RFC series?

Gorry

---

From: Michael Welzl <[email-masked]>
Date: Fri, 30 May 2014 20:30:58 +0200

Hi,

> unless we migrate innovation into unprivileged userspace.

So - what you write here reflects one line of thinking. I come from an entirely different line of thinking: the IETF is ultra-conservative in what it supports because everything has to work *across the whole Internet*.  There may well be many, many paths out there that support a great deal of the things you mention below - and many won't. You shouldn't have to worry about a non-supportive path if you're on a supportive path! The Internet has, however, never been good with downward-compatibility: *trying* things, and using something else otherwise.

Now, why is that? Because we bind applications to protocols with a thick rope, and thus an application programmer has to implement all the logic of trying e.g. "native SCTP, oh, doesn't work, what about SCTP/UDP? oh, doesn't work either, ok, TCP then" - which, of course, noone does. It's just too much work - the pain vs. gain trade-off isn't right for the app programmer. If we stop binding applications to protocols, the machinery underneath could be trying protocol #1 and falling back to protocol #2 etc. In a **best effort** world (and that was the point of my presentation at the IAB workshop on Internet Technology Adoption and Transition), that's not a problem for many of the services - you just end up with a less efficient implementation: unordered delivery => fine to get it in order. Special type of congestion control => not cool but okay if you get AIMD instead. Partial reliability => well full reliability isn't as performant, but your application won't break if it assumes best effort. And so forth!

Why isn't this happening today, given that apps aren't necessarily using the socket interface?

As Brian mentioned in one of his recent emails, that's not quite true - middleware developers are using the socket interface.
Their thinking is guided by what this interface gives them today: TCP, UDP. If one was to build a better middleware (which could well help applications - see draft-hurtig-tsvwg-transport-apis-00 for some reasoning), where would we start? With identifying the services that protocols provide today.

> like that, would it satisfy the current charter?

I'll call this one possibility #2 and throw a third possibility on the table to make this open enough: Minion. You make everything look like TCP on the wire.

For all three possibilities, it's a useful starting point to identify all the services provided by today's protocols (charter item #1) - after all, even if you were to build everything yourself, these services are in there for a reason. There was preceding IETF debate. This doesn't mean that your possibility #2 needs to implement all of them, but surely knowing which ones are now a part of the protocols is useful for guidance.

For all three possibilities, it's useful to have a narrower set of services that really should be made available

The third part, discovery, isn't useful for possibility #2 and #3. Well okay. It still is useful for possibility #1 which is what I propose and what the group has pretty much been about.

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Fri, 30 May 2014 20:49:02 +0200

... I forgot to include a point which is important to the argument:

why is e.g. native SCTP not supported much?

at least one good reason not to support it is: noone uses it (except for telephony signaling).

why isn't anyone using it?

see below.

Without such a "try, else fall-back" scheme (which is what we'd specify in item 3 of the charter), SCTP/UDP isn't going to be deployed either, except for special cases in special ways (rtcweb).  I'd argue it's even less about the encapsulation and more about making the protocol easy and robust to use. 

Cheers,
Michael

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 30 May 2014 16:47:02 -0500

> success on the existing charter.

Hi, Joe et al.

So I'm not quite visualizing the proposal. Even rough text would help.

Guessing in anticipation of text arriving ... is the idea that the 
working group to be would develop however many proposals as seem useful, 
and then

IF one is blindingly obvious as the right thing to do
   THEN publish as PS
ELSE  IF people are willing to "experiment" with drafts
   THEN experiment, and publish what works as PS
ELSE publish one or more Experimental RFCs and let 100 implementations 
bloom?

Or, if not, could you clue me in?

Thanks,

Spencer, who is quite pleased with the discussion so far