Re: [hybi] channel alternatives

[Roberto Peon <[e-mail]>]

On Fri, Nov 13, 2009 at 9:41 AM, Ted Goddard <[e-mail]>wrote:

>
> On 2009-11-13, at 10:09 AM, Roberto Peon wrote:
>
>  Speaking as the person who would be responsible for much of the work of
>> sticking sctp in for google, the greatest challenges are seemingly the home
>> routers/nat devices. Both server and client-side changes are trivial when
>> using the sockets API.
>>
>
> Start by tunnelling SCTP over UDP?  Home users would
> be willing to open a UDP port on their router if it
> improved their browsing experience.


It'd be great if this would be deployed :). UDP certainly seems like one of
the most likely ways to deploy SCTP.
Given how much pain various browsers (including mobile browsers) have caused
me, though, I remain pessimistic about users doing anything en-mass unless
things completely cease to function without it. They don't know the
technology that makes things work, and they don't want to. They just
(understandably) want it to work, and leave the rest to the
specialists/experts!


>
>  Note that our research Haas found that multiplexing itself may actually be
>> harmful... it is multiplexing plus client assigned priorities that seems to
>> be the winning combination.
>>
>
> A priority header could also be added alongside an
> HTTP request identifier.


Certainly that could work too.. so long as you always get priorities with
multiplexing, you get some of the benefits that we've exhibited
experimentally with SPDY. Note that while multiplexing+priorities helps
everyone, it helps high-bandwidth clients more (as they're more likely to be
affected by head-of-line blocking).
Header text compression is the big win for users on slower links.


>
>
>  If all my wishes came true tomorrow, Sctp would be widely deployed, would
>> give userspace applications easy access to a representation of bytes in
>> flight, cwnd, and other important connection properties...and would support
>> channel bases priorities.
>>
>> The connection properties are interesting for varying server and client
>> behavior to better serve the user. I really want to send data to someone
>> using a satellite uplink fir data differently than a mobile user, or someone
>> with a nearly lossless 100 Mb link!
>>
>
> That's true, the application should react differently
> depending on the capacity.  Discovering the capacity
> quickly would seem to require a combination of client
> and server hints together with feedback from the
> connection.  The application-level API for this might
> not be simple -- it may be analogous to the transition
> from single threaded to multi-threaded APIs.  Do you
> have a version of this in a SPDY API?
>
> Ted.


Unfortunately no-- that is too low level. SPDY looks like HTTP for the
application users.
As far as accessing that info, we have modified linux kernels that allow for
userspace access to some of that information. We hope that we can
communicate some of this back to the client (as servers are FAR more likely
to change to a new kernel, etc. than the majority of users out there) and
thus both sides can profit from the information... but it is just an idea
right now. No implementation yet exists (we're too busy trying to open
source and deploy what we have already!).

-=R


>
>
>
>
>
>>  On Nov 13, 2009 8:47 AM, "Ted Goddard" <[e-mail]> wrote:
>>>
>>>
>>> On 2009-11-12, at 7:45 PM, Thomson, Martin wrote:
>>>
>>> I’m also increasingly of the view that channels-based protocols aren’t
>>> necessarily the right way to solve head-of-line blocking problems.  There
>>> are other methods that do not demand the same overheads.  For instance, a
>>> simple request identifier can be used for request-response correlation.
>>>
>>> A request identifier (say, as an HTTP header) appears to
>>> have a number of useful properties:
>>>
>>>  - it can be optionally specified, so only clients
>>>   supporting the feature need be aware of it
>>>  - it can be ignored by the server, so server implementation
>>>   is also optional
>>>  - there is no latency for channel setup; uniqueness of the
>>>   identifier can be a client responsibility, so there is
>>>   no negotiation cost
>>>  - the same identifier can be applied to chunked responses,
>>>   allowing large responses to be interleaved
>>>
>>> Would an existing HTTP proxy be confused by interleaved,
>>> "identified" chunks?
>>>
>>> I’m actually more excited about the prospect of getting HTTP over SCTP.
>>>
>>> What if google began providing their current services over
>>> SCTP?  This will need a critical mass to get started.  (There
>>> is also the small problem of missing SCTP client stacks.)
>>>
>>> Ted.
>>>
>>>
>>> _______________________________________________
>>> hybi mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/hybi
>>>
>>
>>
>
>