Subject: Re: [hybi] WebSocket handshake (HTTP and SSO)

From: Benjamin Black <[email-masked]>
Date: Fri, 3 Sep 2010 22:08:25 -0700

The focus of the argument in favor of re-implementing authn in
Websockets mechanisms that already exist in HTTP is that the authn
process sometimes requires an extra round trip.  One.  Round.  Trip.
Sometimes.  The phrase you seek is "premature optimization".

Instead of talking about it in the abstract of a single, extra round
trip, I ask when this is relevant.  In cases where connections are
short-lived, intended for a single request/response, and credentials
can't be retained, this concern seems quite important.  Since the
entire process is one round trip, adding another could add
considerable latency.

Are Websockets intended for short-lived, request/reply applications?
If so, they are pointless as HTTP can handle these applications all on
its own.

Are they intended for applications in which:
  1) a user is not already authenticated
OR
  2) the credentials can't be passed to the Websocket system to use in
authentication?

Or, instead, are Websockets intended for long-running connections with
numerous round trips, often from applications that can collect
credentials and send them directly in the HTTP request that begins the
Websocket negotiation?  And, if this is so, why are we obsessing over
a single round trip adding all of 50ms to initial connection setup
instead of recognizing the existing mechanisms are perfectly workable
_as is_?  If, in the fullness of time and experience, we discover the
extra round trip is a serious impediment, we are free to design and
implement new mechanisms.

File under: another confusing example of hybi efforts eschewing HTTP
mechanisms and HTTP compliance.  If someone could elucidate that, I
would be grateful.

b

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Fri, 3 Sep 2010 22:57:36 -0700

As a general point, we (Google) are very concerned with initial latency. The
addition of 50ms before an app is usable is nontrivial. I say that not to
argue for or against the current handshake, but rather to push back against
the notion that 50ms at startup doesn't matter. Time at startup is among the
most important, we can often hide delays at other points.

On Sep 3, 2010 10:08 PM, "Benjamin Black" <[email-masked]> wrote:
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: Benjamin Black <[email-masked]>
Date: Fri, 3 Sep 2010 23:12:45 -0700

I actually removed a sentence saying approximately "I don't see how
this matters to anyone but Google", but thought it too snarky.  Next
time I'll know!

My suggestion?  Use existing HTTP auth, since that is easier for
everyone else.  Implement alternative schemes in Chrome and for your
apps (the client side will know to use the Google auth mechanism, and
its use will tell the server what is going on).  I see no reason the 2
need be in conflict.  If the non-HTTP mechanisms prove to be a major
win, and there is general demand for them, contribute them to the WG.
The additional experience in implementation and operations will make
your arguments in their favor irresistible.

It is in the best interests of this work to start with a minimal set
of features, making as much use as possible of existing infrastructure
(in this case, mostly HTTP).

b

---

From: John Tamplin <[email-masked]>
Date: Sat, 4 Sep 2010 08:31:32 -0400

> this matters to anyone but Google", but thought it too snarky.  Next

Perhaps it should matter to more people -- experience has shown that usage
and user happiness goes up when latency goes down.  Many tools exist solely
to help developers make their websites faster (Google only provides a few of
these), and much of the suggestions center around reducing startup latency.
 As Ian mentions, there are lots of ways to hide latency in other places,
but you really can't hide startup latency.

So perhaps what you mean is "I don't see how this matters to anyone but
those wanting more usage and happier users".

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Benjamin Black <[email-masked]>
Date: Sat, 4 Sep 2010 11:05:50 -0700

> these), and much of the suggestions center around reducing startup latency.

That experience, and those tools, are based on page load times:
short-lived connections and request reply.  If you can direct me to
published data from Google (or any other major operator) regarding the
influence on user behavior of connection setup latency for long-lived
connections, I should very much like to see it (and I expect it would
be of interest to many others).

All that being said, I apologize for entering the debate on latency as
it is not relevant in this context.  The root of the problem is the WG
charter, and I will put that in another email.

b

---

From: Scott Ferguson <[email-masked]>
Date: Sat, 04 Sep 2010 11:08:03 -0700

>   2) the credentials can't be passed to the Websocket system to use in

It's for non-browser applications, which have different latency and 
security requirements than browser-based applications. The 
authenticating "user" is a remote program. Thinking of cookies as 
authentication credentials is meaningless in this context.

Consider a messaging application which primarily sends single messages, 
but can either batch in short bursts or has a related event notification 
system for reading messages. Or think of the requirements of something 
like memcache or a query-based service like a database. A majority of 
the calls might be short request/response, and those might be the 
critical ones from a performance perspective. You might only have the 
WebSocket open for a short burst (1 sec) since connections are not 
always poolable for a long time in non-browser applications.  So you 
can't always just amortize extra handshake cost away.

If the WebSockets handshake overhead is sufficiently low, it can be used 
for the entire application. If it was identical to HTTP performance, it 
would always be a win. But if it's too high for the RPC, it may not be 
usable, and if the WebSockets performance is significantly worse than 
HTTP/RPC, it won't be a viable upgrade.

Suggesting a mix of HTTP and WebSockets a single application isn't 
really viable. You want the performance to be reasonable across a wide 
range of connection times.  It's not as simple as saying HTTP should be 
used for request/response and WebSockets used for long lived connections 
because both requirements may exist in the same application, or the 
burst rate may blur the distinction between the two..

If we follow your suggestion, non-browser applications would likely just 
use BASIC auth to avoid the handshake penalty. It wouldn't be a crisis 
since that's what many HTTP/webservice applications do today.  But it 
seems a shame to discourage the stronger challenge/response 
authentication and settle for sending passwords in the clear when we can 
enable challenge/response with zero extra overhead.

-- Scott

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 6 Sep 2010 23:33:55 +1000

> this matters to anyone but Google", but thought it too snarky.  Next

I've been implementing comet solutions for applications with several
orders of magnitude less users than google.

Initial start up time definitely does matter.

For example, if the websocket transport is left on, then the RTT taken
to try, fail and then fall back to normal comet is very noticeable.
Specially if it combines with RTTs for cross domain preflight
requests.

> its use will tell the server what is going on).

My suggestion is that this WG should not be trying to pick winners in
the game of Authentication. We should support all commonly deployed
authentication mechanisms and anticipate future support of all
reasonably conceived possible authentication mechanisms.

cheers