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

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" <touch@isi.edu> wrote:

>
>
> On Sep 3, 2013, at 5:35 PM, Roberto Peon <grmocg@gmail.com> wrote:
>
> 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.
>
>
> 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
>
> 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 <touch@isi.edu> wrote:
>
>> Hmmm.
>>
>>  On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon <grmocg@gmail.com
>>> <mailto:grmocg@gmail.com>> 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
>>
>>
>>
>>
>