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

Jamie Lokier <> Sat, 17 April 2010 11:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA96D3A68AE for <>; Sat, 17 Apr 2010 04:29:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.299
X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-5.300, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jkzvv9uG9Zxr for <>; Sat, 17 Apr 2010 04:29:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6CC1B3A6863 for <>; Sat, 17 Apr 2010 04:29:53 -0700 (PDT)
Received: from jamie by with local (Exim 4.63) (envelope-from <>) id 1O36DV-0002GI-Ud; Sat, 17 Apr 2010 12:29:41 +0100
Date: Sat, 17 Apr 2010 12:29:41 +0100
From: Jamie Lokier <>
To: Mike Belshe <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.13 (2006-08-11)
Cc: "" <>
Subject: Re: [hybi] Websocket success rates and TLS extension.
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 17 Apr 2010 11:29:54 -0000

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.

>    This number can use more research, but I believe it is roughly
>    right. (e.g. [3] loads subresources from
>    [4] - 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...

>    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.

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.

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

-- Jamie