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

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 <grmocg@gmail.com> wrote:
> 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
>>>
>>>
>>>
>>
>

Received on Wednesday, 4 September 2013 15:22:47 UTC