Subject: Re: [tsvwg] The List (of application-layer desired features)

From: Roberto Peon <[email-masked]>
Date: Tue, 3 Sep 2013 17:35:25 -0700

I understand the points you make, and am sympathetic. I feel the same way
when I see people abusing HTTP to provide async notifications, etc.
The fact is, however, if it isn't deployed, no matter how nice it would
theoretically be when it is, it isn't useful and people WILL work around
the problem.
That is true regardless of whether the problem is at the application layer
(e.g. HTTP), or at the transport layer (e.g. TCP), or elsewhere.
The primary motivation is to get things working, and making things that
lack redundancy, or are elegant comes in at a distant second.

Deployed is the most important feature, thus things which quickly move
protocols and protocol changes from theoretical to deployed are by far the
most important things.
The longer this takes, the more likely that the work-around becomes
standard practice, at which point we've all "lost" the game.
-=R

On Tue, Sep 3, 2013 at 5:00 PM, Joe Touch <[email-masked]> wrote:

> Hmmm.
>
>  On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     For those of you who missed it, at the HTTPBis/TSVG joint session, a
>>     question about what applications want from the transport (I really
>>     want to put quotes around that) came up.
>>
>>     Here is a rendition of what was on the note that I jotted down in
>>     response to this question, and which I passed to people at the mic.
>>
>>     (Apps-folks want the following) Deployed in 1996:
>>
>
> Here's what at least one transport person wants from apps-folks:
>
> - don't reinvent the wheel (muxing exists at IP, vs. wanting to support it
> inside HTTP)
>
> - don't claim an existing protocol won't work because of your *current*
> assumptions (Berners-Lee's famous words claimed that he didn't want FTP
> because it was heavyweight for retrieving just one file, and that's what
> he'd want most of the time)
>
> - when you use an existing protocol, use it correctly (HTTP should have
> Nagle *OFF* because it's a multi-byte interactive protocol, and TCP "CLOSE"
> shouldn't be the only/preferred way to signal EOF)
>
> - if you want the benefits of a protocol extension, support its
> development (TCP-AO isn't available in host OSes yet, but I also don't see
> the web folks clamoring to implement it)
>
> Joe
>
>
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 04 Sep 2013 02:42:43 +0100

Not really on topic for this but...

On 09/04/2013 01:35 AM, Roberto Peon wrote:
> Deployed is the most important feature

No. "A very important" feature, yes. "The" most
important, no, not in all cases.

To take one example:

Passwords are by far the most commonly deployed
web user authentication mechanism. That is only
because we believe we lack a better solution and
is a crap situation that gets more crap the more
that passwords are deployed. In that case, more
deployment == more crap.

And maybe I'm wrong, but I mostly seem to hear the
deployment-is-all argument from folks with existing
large deployments, which of course makes it a
suspiciously self-serving argument. That is no
criticism of the people making that argument, e.g.
I have eventually realised how often I've fallen
into similar traps myself. But its still notable.

S.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 3 Sep 2013 18:59:06 -0700

To me, it seems like "violent agreement" :)

In your example case, the deployment of more passwords == more crap.
That would imply that it is of immense importance to have a replacement
deployed yesterday, else the current practice becomes increasingly wide
spread...

-=R

---

From: Roberto Peon <[email-masked]>
Date: Wed, 4 Sep 2013 00:33:04 -0700

I agree? :)

Are you thinking that folks are complaining and not attempting to change
things? I don't see that-- I see a lot of people motivated to improve
things as much as they can.

As an example, when we started SPDY, we considered many different areas to
tackle, including lower layer protocols. We decided we wanted to do
data-driven analysis on what part of latency was due to the application
layer, and found room for significant improvements, which we implemented,
made freely available, and deployed. In my opinion, it was the willingness
of the community to propose changes and deploy experiments in short periods
of time which got us to whrer we are today.  We learned early on that the
real world is very difficult to predict and as a result, concrete
experience and data were paramount in making things succeed. We then
iterated, in concert with a number of other parties, discovering bugs in
specs, implementations, and adapting to a rapidly changing world (mobile
devices). When we had exhausted all of the reasonable things to do that we
could think about, we looked for the next bottleneck, which currently seems
to be the layers below the application layer.

In the end, I know that I don't care what the solution is called, or if it
has existed for years, or is some new fangled thing. I don't care whose
name is on it or not on it. I care that it does what is necessary well
enough that there is a compelling case to try it out... And then I care
that I can deploy it to users without undue delay or unpredictable
consequence.

In the end, it must work. If it isn't deployed, it won't. If what exists is
crappy, then I hope it gets replaced in a timely fashion (so we reap both
short term and long term benefits).
Make no mistake though, crappy always beats out nonexistent.

-=R
On Sep 3, 2013 11:58 PM, "Joe Touch" <[email-masked]> wrote:

>
>
> On Sep 3, 2013, at 5:35 PM, Roberto Peon <[email-masked]> wrote:
>
> FTP was deployed when it was dismissed as a viable solution. Nothing else
> I've noted below was not available before the web existed except TCP-AO.
>
> Don't forget there was a time when HTTP wasn't deployed either. Change
> starts when you change, not by complaining about how hard it is to do so.
>
> Joe
>
>> - don't reinvent the wheel (muxing exists at IP, vs. wanting to support
>> it inside HTTP)
>>

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 4 Sep 2013 08:21:59 -0700

This is IETF so we are only talking about deployable solutions. If not
someone should point out as early as possible. Maybe we can move on to
solve the real problems now.

Here is a problem I don't think there is a good practical solution:
multi-flows. Currently browser uses some heuristics to determine
number of parallel connections to trade-off latency and congestion,
because the transport does not provide a good service for that. HTTP/2
reduces one factor by limiting #connections per host to 1 but that's
not enough. IMHO the transport (tcp, sctp, quic, or anything you
prefer) should just take connection priorities dynamically from the
app, and schedule connections more intelligently at the receiver. It's
not the app's job or can he do a good job at higher layer.

There is an old work called congestion manager but it's not useful b/c
it's sender based.

On Wed, Sep 4, 2013 at 12:33 AM, Roberto Peon <[email-masked]> wrote:
> things? I don't see that-- I see a lot of people motivated to improve things
> as much as they can.
>
> real world is very difficult to predict and as a result, concrete experience
> and data were paramount in making things succeed. We then iterated, in
> concert with a number of other parties, discovering bugs in specs,
> implementations, and adapting to a rapidly changing world (mobile devices).
> When we had exhausted all of the reasonable things to do that we could think
> about, we looked for the next bottleneck, which currently seems to be the
> layers below the application layer.
>
> has existed for years, or is some new fangled thing. I don't care whose name
> is on it or not on it. I care that it does what is necessary well enough
> that there is a compelling case to try it out... And then I care that I can
> deploy it to users without undue delay or unpredictable consequence.
>
>> theoretically be when it is, it isn't useful and people WILL work around the
>> problem.
>>
>>

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 4 Sep 2013 10:52:01 -0700

On Wed, Sep 4, 2013 at 10:12 AM, Joe Touch <[email-masked]> wrote:
>
>
> On 9/4/2013 8:21 AM, Yuchung Cheng wrote:
> ...
>
>> because the transport does not provide a good service for that.
>
>
> Transports don't read minds.
>
>
>> HTTP/2 reduces one factor by limiting #connections per host to 1 but
>> that's
>> not enough.
>
>
> That's not an appropriate solution - and it's the sort of "mis-use" I was
> referring to. It only serves to push muxing up the stack.
The transport(s) that can keep muxing down the stack don't always run
on the Internet. This is what Roberto's argument is about.

>
>
>> IMHO the transport (tcp, sctp, quic, or anything you
> RFC2140 avoids sets of connections from both getting more than their
> steady-state fair-share, and reduces the amount they step on each other.
> It's already deployed, but might benefit from some app-layer hints.
>
> IMO, this isn't a "transport" problem, though - it's more like a missing
> coordination layer (whether implemented with headers and state or just an
> API to the OS).
Any name is fine with me as long as the solution works.

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 4 Sep 2013 20:40:38 +0200

> on the Internet. This is what Roberto's argument is about.
I think "running always" is hard... Not sure if TCP does.
So what about UDP encapsulated stuff like SCTP/UDP?

Best regards
Michael

---

From: Roberto Peon <[email-masked]>
Date: Wed, 4 Sep 2013 12:43:07 -0700

I suspect that Yuchung meant 'widely deployed and available', when he says
'always'. That should certainly be true for TCP.

Personally, I think that UDP encapsulated stuff has a fighting chance.
Deployment is a matter of addressing any new features and protocol
technical issues of the current non end-to-end internet, and sticking a
binary on participating machines.
This is a reasonably bounded problem, thus, has a fighting chance.

I suspect that, without kernel support for interpacket delay measurement
and interpacket gap enforcement, any such protocols will do worse than they
would with such support, but hopefully that is about enhancement and not
required to make something new work well.

-=R

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 4 Sep 2013 23:58:02 +0200

On Sep 4, 2013, at 9:43 PM, Roberto Peon <[email-masked]> wrote:

> I suspect that Yuchung meant 'widely deployed and available', when he says 'always'. That should certainly be true for TCP.
That is definitely true for TCP.
However, why do you need an alternate solution to be "widely deployed". Can't it
be deployed within the browser?
For me it makes sense to require "availability" and "having a sufficient level of connectivity".
> 
> Personally, I think that UDP encapsulated stuff has a fighting chance. Deployment is a matter of addressing any new features and protocol technical issues of the current non end-to-end internet, and sticking a binary on participating machines.
> I suspect that, without kernel support for interpacket delay measurement and interpacket gap enforcement, any such protocols will do worse than they would with such support, but hopefully that is about enhancement and not required to make something new work well.
This sounds to me like a performance optimisation. I guess this might be one feature
of a larger set of features which improve the overall performance. However, the
connectivity must be there at all. My expectation is that anything running over
UDP might not have the same level of connectivity, but it should be acceptable.

Best regards
Michael
> 
> -=R
> 
> 
> On Wed, Sep 4, 2013 at 11:40 AM, Michael Tuexen <[email-masked]> wrote:
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 4 Sep 2013 15:20:28 -0700

On Wed, Sep 4, 2013 at 2:58 PM, Michael Tuexen <
[email-masked]> wrote:

> > I suspect that Yuchung meant 'widely deployed and available', when he
> says 'always'. That should certainly be true for TCP.

I think people are being too imprecise which leads to confusion. UDP is
widely deployed. A UDP based solution can be deployed within the browser.
TCP-AO is not widely deployed. It cannot be deployed within the browser.

For me it makes sense to require "availability" and "having a sufficient
> level of connectivity".

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 5 Sep 2013 00:24:29 +0200

On Sep 5, 2013, at 12:20 AM, William Chan (陈智昌) <[email-masked]> wrote:

> On Wed, Sep 4, 2013 at 2:58 PM, Michael Tuexen <[email-masked]> wrote:
> I think people are being too imprecise which leads to confusion. UDP is widely deployed. A UDP based solution can be deployed within the browser. TCP-AO is not widely deployed. It cannot be deployed within the browser.
Sure. Completely agreed. Thanks for the clarification.

Best regards
Michael

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 4 Sep 2013 17:55:10 -0700

On Wed, Sep 4, 2013 at 3:50 PM, Joe Touch <[email-masked]> wrote:

>
>
> On 9/4/2013 3:20 PM, William Chan (陈智昌) wrote:
>
>> On Wed, Sep 4, 2013 at 2:58 PM, Michael Tuexen
>> <Michael.Tuexen@lurchi.**franken.de <[email-masked]>
>> <mailto:Michael.Tuexen@lurchi.**franken.de<[email-masked]>>>
>> wrote:
>>
>>     On Sep 4, 2013, at 9:43 PM, Roberto Peon <[email-masked]
>>      > I suspect that Yuchung meant 'widely deployed and available',
>>     when he says 'always'. That should certainly be true for TCP.
>> widely deployed. A UDP based solution can be deployed within the
>> browser. TCP-AO is not widely deployed. It cannot be deployed within the
>> browser.
>>
>
> Although that's correct, there's no way to protect UDP. TCP-AO is for
> protecting individual TCP connections; if that's what you want, you need to
> update TCP.
>
> My point about TCP-AO is that it's not useful to continue to complain that
> something isn't widely deployed. If you need what it has, then why not
> start by helping deploy it? Then at least there's one less thing to
> complain about being missing in a few years.

So I actually don't think my browser needs TCP-AO, so that's probably a bad
example. But in any case, I don't know what I can do to help get it
deployed. Are you suggesting I periodically email Microsoft to ask them to
update their kernel networking stack to support it in their OS? What help
would you like from me here?

---

From: Roberto Peon <[email-masked]>
Date: Wed, 4 Sep 2013 17:59:01 -0700

The large difference being that I can't just deploy TCP-AO on 3rd party
machines. I have to wait for the vendors these 3rd parties use to do it
(e.g. the OS vendor), accept patches for it and deploy it, etc.
I have zero control over that, and zero control over the timeframe. That
means I can't plan for it or hurry it along.

Unfortunately, much of the time, my only options are either to complain
about it, or attempt to replace it.
-=R

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 4 Sep 2013 19:05:49 -0700

I think it's a fine thing to support long-term solutions that aren't
immediately deployable, assuming of course that's the right long-term
approach. But I think it's a mistake not to deploy something in the
meanwhile. Let's not let the perfect be the enemy of the good.

For example, I think it's great that SCTP can work over UDP. People may
argue that it should really be deployed in kernels, and it's probably true
that it'd perform better that way, but it's significantly more deployable
when you layer it on top of UDP. So I think it was a smart choice to deploy
rtcweb using SCTP over UDP, rather than arguing that we should wait for
SCTP/IP to be deployed in relevant OSes and NATs/intermediaries.

On Wed, Sep 4, 2013 at 6:05 PM, Joe Touch <[email-masked]> wrote:

>
>
> On 9/4/2013 5:55 PM, William Chan (陈智昌) wrote:
> ...
>
>      My point about TCP-AO is that it's not useful to continue to
>>     complain that something isn't widely deployed. If you need what it
>>     has, then why not start by helping deploy it? Then at least there's
>>     one less thing to complain about being missing in a few years.
>>
>>
>> So I actually don't think my browser needs TCP-AO, so that's probably a
>> bad example.
>>
>
> Sure.
>
>
>  But in any case, I don't know what I can do to help get it
>> deployed. Are you suggesting I periodically email Microsoft to ask them
>> to update their kernel networking stack to support it in their OS? What
>> help would you like from me here?
>>
>
> We need those who do need it in endsystems to either contribute code or
> support others to code it.
>
> There was a long discussion in RPKI about the fact that router vendors
> want it in host OSes (to run as RPKI servers), and who support it in their
> routers. They spent a lot of time complaining that it wasn't available in
> the host OSes, and a lot of time considering alternatives, rather than
> either coding it up or supporting someone (anyone) who could.
>
> That has happened before with other extensions. It's not useful to claim
> "it's not out there", especially when such a solution better or more
> generally useful. I.e., claiming that "it has to already be deployed" is a
> silly pre-requisite for *this* community; if it's that ephemeral a problem,
> IMO it's not usefully solved here.
>
> Joe
>

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 Sep 2013 22:14:13 -0500

Yes, deployable means: doesn't require middle-box updates
(NAAAAAAAAATs) and doesn't require OS vendors / kernel developers /
distros to develop, package, and deliver an implementation.  That
pretty much means: plain TCP and plain UDP.  Not IPsec (sure, IPsec
can run over UDP, but apps can't all run their own IKEs), not SCTP
(unless it's over UDP), not TCP-AO or anything of the sort.

Things like SCTP over UDP will do.  Lighter-weight protocols over UDP
too.  Just make sure to handle congestion.

DJB's MinimaLT looks pretty good.

Nico
--

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 5 Sep 2013 07:09:09 +0200

On Sep 5, 2013, at 4:05 AM, William Chan (陈智昌) <[email-masked]> wrote:

> I think it's a fine thing to support long-term solutions that aren't immediately deployable, assuming of course that's the right long-term approach. But I think it's a mistake not to deploy something in the meanwhile. Let's not let the perfect be the enemy of the good.
> 
> For example, I think it's great that SCTP can work over UDP. People may argue that it should really be deployed in kernels, and it's probably true that it'd perform better that way, but it's significantly more deployable when you layer it on top of UDP. So I think it was a smart choice to deploy rtcweb using SCTP over UDP, rather than arguing that we should wait for SCTP/IP to be deployed in relevant OSes and NATs/intermediaries.
Just to be clear: You can implement SCTP/IP and SCTP/UDP/IP either in the kernel or
in the application. For SCTP/IP some OSes require specific privileges, most NAT boxes
don't support SCTP/IP. So choosing something like SCTP/UDP/IP allows for deployment
within the application and make use of kernel implementations when available.
Therefore, the crucial point is middlebox support which requires the UDP encapsulation.

Best regards
Michael
> We need those who do need it in endsystems to either contribute code or support others to code it.
> 
> There was a long discussion in RPKI about the fact that router vendors want it in host OSes (to run as RPKI servers), and who support it in their routers. They spent a lot of time complaining that it wasn't available in the host OSes, and a lot of time considering alternatives, rather than either coding it up or supporting someone (anyone) who could.
> 
> That has happened before with other extensions. It's not useful to claim "it's not out there", especially when such a solution better or more generally useful. I.e., claiming that "it has to already be deployed" is a silly pre-requisite for *this* community; if it's that ephemeral a problem, IMO it's not usefully solved here.
> 
> Joe
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 5 Sep 2013 13:30:11 +0800

Sorry for not being precise earlier and thanks for clarifying it. Agreed.

---

From: Michael Welzl <[email-masked]>
Date: Thu, 5 Sep 2013 10:17:45 +0200

Hi,

Sorry to side-track, but this bit brings me to a question I had:

> RFC2140 avoids sets of connections from both getting more than their steady-state fair-share, and reduces the amount they step on each other. It's already deployed, but might benefit from some app-layer hints.

I'm a fan of RFC2140 and related work. I wonder what parts of RFC2140 are deployed, to what degree, where? Does anyone know?
In particular, I'm interested in ensemble sharing of cwnd, i.e. the parallel use of a single cwnd for multiple connections. Deployed? If yes, in which OS? If not, why not?

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Thu, 5 Sep 2013 10:22:29 +0200

Yuchung,

> There is an old work called congestion manager but it's not useful b/c

Why does that make it useless? What's missing - isn't it just client=>server signaling of: "I assume the bottleneck is my access link, so I'll tell you which flows belong together, and I'll tell you my priorities"?
But - if you knew which flows share a bottleneck, part #1 would be unnecessary, and then I'm not so sure if you need the client to tell the server about priorities, wouldn't the server know better?

Cheers,
Michael

PS: this makes me wonder about the GreatSnipe congestion manager you once presented in ICCRG - any news about that? Is it going to be a part of QUIC? I think it's very interesting work.