Re: [hybi] Websocket success rates and TLS extension.

[Mike Belshe <[e-mail]>]

On Sat, Apr 17, 2010 at 4:29 AM, Jamie Lokier <[e-mail]> wrote:

> Mike Belshe wrote:
> >    I think I know what Greg was referring to.
> >    With SPDY, we've observed that the key to minimizing latency is
> >    removing round-trips.  While bandwidth continues to go up (5Mbps,
> >    10Mbps, more!), RTTs are not going down.  The average RTT to Google
> >    today is over 100ms.  Even in the US, where broadband is prevalent,
> >    ~90ms.
> >    Today, each layer of the stack introduces a Round Trip:   DNS, TCP,
> >    HTTP
> >    With WebSockets, as spec'd:  DNS, TCP, HTTP, WebSocket
> >    So, any protocol which induces an extra RT (e.g. the websocket upgrade
> >    handshake) faces a 90ms per connection on the critical path tax which
> >    current HTTP does not have.  From our study of web pages, web pages
> >    typically have about 2.5 connections to unique domains that are on the
> >    critical path of the web page download.
>
> Let me add a data point: mobile browsing.
>
> I find typical 3.5G (HSDPA) RTTs to vary from 150ms to about 6000ms
> (6 seconds) while remaining functional.  It depends on time of day as
> much as location - it gives every appearance of depending on network load.
>
> With GSM, the minimum latency is more like 400ms, which is similar to
> land-line dialup.
>
> That is then multiplies by the number of round trips which involve the
> handset.
> As you can see, in the worst case, the loading time can be very long.
>
> Anything we can do to reduce the number of round trips, parallelise
> operations, and move round trips to upstream proxies that don't
> involve the handset would be a huge improvement.
>

+1


>
> >    This number can use more research, but I believe it is roughly
> >    right. (e.g. [3]www.facebook.com loads subresources from
> >    [4]fbcdn.com - so adding an extra handshake RT to the protocol
> >    means 2 extra RTs to load the page; the average site on the net
> >    today touches 8 domains).
>
> Why aren't those domains usually already in the user's DNS cache, with
> long TTLs?  Well, I already know, most users don't have a DNS cache :-)
> But that's a technical possibility...
>

Even if the DNS is cached, the TCP & HTTP each add an extra round trip for
each subdomain.


>
> >    which it has that.  We're pretty sure that a low-latency protocol
> >    needs to remove more RTs.  But perhaps there is something genius yet
> >    to be discovered :-)
>
> Well now you mention it :-)
>
> There is a mechanism to remove handshaking RTs.
>
> Send "conditional action" chunks along with negotiation headers.
> That would be a blocks of data, in a pre-agreed format, which the
> server will ignore if negotiation didn't succeed or didn't agree to
> use that data.
>

Agree with the concept, but the mechanisms to implement are not obvious; TCP
can carry data in the SYN and SYN-ACK, but this is seldom used, is not
exposed via the API on most platforms, and gets dropped at some percentage
rate around the internet.  And don't forget that the TCP handshake is often
a piece of how sites protect against DoS attacks.  Solve-able? maybe.  but
not trivial ;-)


>
> If that is defined that from the very first protocol version, clients
> can safely send messages without waiting for negotiation to complete.
> When it does complete, they will know which already sent messages are
> acted upon, and which are not.  It can then resend any in a different
> format if necessary.
>
> The above mechanism can be designed to be forward compatible to new
> extensions and protocol elements, provided a basic conditional chunk
> type is defined from the beginning.
>
> Baasic labelling can enable several different protocol features to be
> negotiated independently, including transport-level features for
> intermediary use.
>
> It is enough to simply say "this chunk type must be ignored" in
> the first protocol version.
>
> For negotiation up from HTTP to something else, it's necessary to find
> some way to embed conditional chunks in the HTTP negotiation which
> will be ignored by an HTTP server.
>

Seems likely do-able for websockets.


>
> I don't know if SSL/TLS has a place to put these type of messages
> to reduce TLS negotiation time.
>

SSL has an additional constraint that it authenticates the server and
encrypts the channel.  Sending data before completing authentication
requires some additional way to encrypt the data you're sending (since you
haven't authenticated and negotiated encryption yet).  Not impossible - just
harder.

Mike


>
> -- Jamie
>
>