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

From: Greg Wilkins <[email-masked]>
Date: Tue, 06 Apr 2010 10:11:35 +0200

At the IETF meeting the week before last Mike Belshe of the
google SPDY team  pointed me towards an interesting experiment
done by the google chrome websocket team - the results are
discussed here:

  http://www.ietf.org/mail-archive/web/tls/current/msg05593.html

This compares success rates of making websocket connections
via port 80, a high port 61985 and TLS over 443.

The sample was from a self selected subset of chrome users,
so it's probably not very representative of average users -
but it's better than nothing.

Overall success rates were:

  port 80    - 63%
  port 61985 - 86%
  port 443   - 95%

In conversation (not in the link above), Mike indicated that
most of the port 80 failures were after connection (hinting
at intermediary issues with websocket), while most of the
61985 failures were failed connections (suggesting the port
was just blocked).

To me, this suggests that if websocket is going to
be workable over port 80, then we definitely need to
engage the intermediary vendors so that the 37% failure
rate can be improved.

Having a fallback to TLS over 443 will also be vital to
initial deployments.

I also talked to Mike about the possibility of SPDY using
websocket as transport.   The issue for SPDY is that while
the framing of websocket is probably sufficient, they are
very sensitive to the time taken to initiate a connection.
Typically they want to use several connections to display
a page and every round trip establishing a connection
is latency on the critical path to render the page.

Because TLS negotiations represent round trips, they
don't want extra round trips for framing negotiations.
Hence they have proposed a TLS extension to allow
protocol negotiation during TLS handshake.

  http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00

This would allow a TLS connection to be negotiated
with an application protocol and further round trips
avoided.

I know supporting SPDY transport is probably outside of
the hybi charter - but I think it would not harm us
to consider their requirements when designing our
own.

cheers

---

From: Justin Erenkrantz <[email-masked]>
Date: Thu, 15 Apr 2010 23:41:14 -0700

> 61985 failures were failed connections (suggesting the port

That's a useful data point...

> engage the intermediary vendors so that the 37% failure

Yes.

> Having a fallback to TLS over 443 will also be vital to

Indeed.

> is latency on the critical path to render the page.

Sorry for being dense - there are too many "they" in this paragraph
for me to parse it properly.

> is latency on the critical path to render the page.

In this paragraph, I think "they" == "Web Socket" - as we have not had
the channel/multiplex discussion yet and some have said that it should
not be needed at all.  *If* there is multiplexing, then I think this
round trip setup-time is minimized.

But, I'm not quite clear if that's the intent of your statement.  -- justin

---

From: Mike Belshe <[email-masked]>
Date: Fri, 16 Apr 2010 01:56:56 -0700

> round trip setup-time is minimized.

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.  This number can use more research,
but I believe it is roughly right. (e.g. www.facebook.com loads subresources
from 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).   It's very hard to overcome a 180-225ms handicap with a short
webpage download.

The multiplexing does amortize the cost, but doesn't win back the latency.
 Current protocols (HTTP) just open an ass-ton of connections in parallel to
achieve the multiplexing, and this mostly suffices.  So we can build a more
efficient protocol (websocket/spdy/something else), but if you induce a new
handshake, you can still end up slower.  This is the problem which SPDY is
currently researching most.

So back to Greg's note:  the current websocket handshake requires a RT, and
it will be difficult to use websocket for low-latency uses 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 :-)

Mike

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Justin Erenkrantz <[email-masked]>
Date: Sat, 17 Apr 2010 00:45:58 -0700

> with an application protocol and further round trips

Sorry for coming back to this, but Mike's later posts reminded me of
this comment as a way to reduce round-trips.

This is interesting, but the ID doesn't really contain a useful
description of how it would be implemented - it punts that out of
scope and that's the more critical bit, I think.  I'm just not sure I
understand what the "selected_protocol" field would say at all.

Regardless of the vagueness of this ID, doing something to optimize
latency is important.  If this TLS extension makes it way into
OpenSSL, I'm sure httpd/mod_ssl could easily pick up on it.  Is an
implementation available or planned?

I don't know how hard it is for Java servers to support TLS extensions
- I'm sure you know, Greg.  =P  -- justin

---

From: Justin Erenkrantz <[email-masked]>
Date: Sat, 17 Apr 2010 00:52:17 -0700

> RTs.  But perhaps there is something genius yet to be discovered :-)

To just (re)state the obvious - if there is some extra bit coming
along with the TLS handshake (such as the extension Greg pointed at),
I think that'd reduce the RTs - or at least not add an additional one
on top of TLS.

To restate it even more verbosely...it'd be pretty straightforward for
a client that sticks a Web Socket handshake (or something) in the
tlsext for httpd/mod_ssl to immediately operate as if the upgrade is
successful.  Obviously, if you're talking to a server that doesn't
understand that tlsext, then you'd have to fallback to the GET
Upgrade: request mechanism.  But, it'd give us a nice opt-in for
latency reduction if both sides support the optimized sequence.

I do like this idea...  -- justin

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 17 Apr 2010 10:20:19 +0200

> - I'm sure you know, Greg.  =P  -- justin

It would probably need support from the JVM libraries before it
would be available to java programmers.   Potentially it could be
done with the current async SslEngine in java, but that's a difficult
beastie to deal with and even most infrastructure developers don't
go there.   But it strikes me as a reasonable optimization that
could be adopted over time.

The other idea I had on a similar RTT would be to allow the
101 response for an upgrade to contain a body.

This a browser could send

   GET /somethingUseful/andThenUpgrade
   Upgrade: WebSocket

and the response would return a useful entity, thus not wasting
a RT, and then upgrade after the response body.

Unfortunately I think this goes beyond the charter of
the current HTTPbis working group.

Cheers

---

From: Julian Reschke <[email-masked]>
Date: Sat, 17 Apr 2010 10:31:51 +0200

On 17.04.2010 10:20, Greg Wilkins wrote:
> ...
> ...

1xx messages only come with headers, right.

But then, can't you just put the payload into a new response header?

Best regards, Julian

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 17 Apr 2010 10:38:03 +0200

> But then, can't you just put the payload into a new response header?

Indeed!  it could even be the very first frame sent out over
the websocket connection.

So if the user was a SPDY/BWTP like sub protocol over
websocket, then the conversation could go something like:

>  GET /somethingUseful
   Upgrade: Websocket

<                  HTTP/1.1 101 Switching Protocols

<                  0x00 frame containing HTTP response
                        and something useful 0xff

>  0x00 frame containing next HTTP request 0xFF
>  0x00 frame containing next next HTTP request 0xFF
<                  0x00 next HTTP response 0xFF
<                  0x00 next next HTTP response 0xFF

etc.

That solves the non TLS RTT issue pretty well I think!

cheers

---

From: Jamie Lokier <[email-masked]>
Date: Sat, 17 Apr 2010 12:29:41 +0100

Mike Belshe wrote:
>    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.
>    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]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...

>    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

---

From: Mike Belshe <[email-masked]>
Date: Sat, 17 Apr 2010 19:08:56 -0700

> implementation available or planned?

Client & Server implementations already exist for OpenSSL.  A client
implementation exists for NSS.  I'm not sure if these have been landed into
the public repository yet, but Adam Langley is the contact on that.

Mike

---

From: Mike Belshe <[email-masked]>
Date: Sat, 17 Apr 2010 19:18:53 -0700

> involve the handset would be a huge improvement.

+1

> But that's a technical possibility...

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

> server will ignore if negotiation didn't succeed or didn't agree to

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 ;-)

> will be ignored by an HTTP server.

Seems likely do-able for websockets.

> 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