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

Another thing that I think Roberto implied but didn't explicitly call out
is mitigating application incentives to open multiple connections

On Tue, Aug 6, 2013 at 1:30 AM, Roberto Peon <grmocg@gmail.com> wrote:

> The most interesting part of this list, for me, was that I was nearly 100%
> sure that every item on this list had been discussed and designed by folks
> participating in TSVWG.
> The part that I'm unsure that people realized is the extent of the hunger
> to have something deployed "yesterday" so that the features could be
> reliably used today.
>
> A colleague reminded me that "prioritization" means different things in
> the different areas (thanks, and thanks Allison for pointing it out in your
> preso!). On this note, it meant both QoS like things and hints to the
> application layer.
>

Prioritization also includes stuff sitting in socket buffers.


>
> Something which I also failed to describe well was that "cheap"/"fast"
> channel/connection setup to CPU/mem, yes, but perhaps more importantly to
> the importance of minimizing latency in connection/channel setup,
> especially while including features like security.
> -=R
>
>
> On Tue, Aug 6, 2013 at 1:15 AM, Roberto Peon <grmocg@gmail.com> wrote:
>
>> Actually sending to the right list for TSVWG...
>>
>> -=R
>>
>>
>> On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon <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:
>>> -----------------------------------------
>>> - Prioritization
>>> - Partial Reliability
>>> - "Shared" congestion between multiple streams
>>> - Security
>>> - No HOL blocking on stream X when loss on stream Y
>>> - Cheap/Fast  channel/connection setup
>>> - Wide, "safe" deployment
>>> - Competes with TCP/HTTP/1.1 (performance-wise)
>>> - Multipath/roaming robustness, i.e. the "driveway" problem
>>>
>>>
>>> I'll reiterate that by far the most important feature is "is deployed".
>>> Nothing else matters until that is true, at least at the
>>> application-layer.
>>> -=R
>>>
>>>
>>>
>>
>