Subject: Re: [hybi] Proposed Charter for HyBi WG (rev.3)

From: Ian Hickson <[email-masked]>
Date: Sun, 1 Nov 2009 20:35:46 +0000 (UTC)

On Sat, 31 Oct 2009, Greg Wilkins wrote:
> Ian Hickson wrote:
> > The protocol stack I'm proposing looks something like this:
> > 
> >    |\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
> >    | Application-level protocol | user application features
> >    +----------------------------+
> >    | WebSocket protocol         | browser security model, event wrapper
> >    +----------------------------+
> >    | TCP                        | reliability, connection wrapper
> >    +----------------------------+
> >    | IP                         | packet abstraction, routing
> >    +----------------------------+
> >    | Ethernet                   | link-level routing
> >    |/\/\/\/\/\/\/\/\/\/\/\/\/\/\|
> 
> Currently you are insisting that there are no layers between websocket 
> and TCP or between the application and websocket.

The "Application-level protocol" can be any number of further layered 
protocols. For example, you could have:

    |\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
    | Application-level protocol | user application features
    +----------------------------+
    | ACME MIME encoding layer   | library-supported protocol
    +----------------------------+
    | ACME Message Acknowledger  | library-supported protocol
    +----------------------------+
    | ACME Multiplexing Support  | library-supported protocol
    +----------------------------+
    | WebSocket protocol         | browser security model, event wrapper
    +----------------------------+
    | TCP                        | reliability, connection wrapper
    +----------------------------+
    | IP                         | packet abstraction, routing
    +----------------------------+
    | Ethernet                   | link-level routing
    |/\/\/\/\/\/\/\/\/\/\/\/\/\/\|

Anything above the Websocket protocol layer is what I would call the 
"Application-level protocol". A framework could define a very thorough 
WebSocket support protocol for people to build their own protocols on top 
of, much like TCP has BEEP or XMPP as protocols on which features have 
been layered.

> > What is the protocol stack you are imagining?
> 
> What I'd like to see is:
> 
>    |\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
>    | Application-level protocol | user application features
>    +----------------------------+
>    | BWT browser binding        | browser security model
>    +----------------------------+
>    | Optional transport features| Multiplexing, compression, etc.
>    +----------------------------+
>    | Bidirectional Web Transport| Two way communications through firewalls etc.
>    +----------------------------+
>    | TCP                        | reliability, connection wrapper
>    +----------------------------+
>    | IP                         | packet abstraction, routing
>    +----------------------------+
>    | Ethernet                   | link-level routing
>    |/\/\/\/\/\/\/\/\/\/\/\/\/\/\|

That seems reasonable.

> What I'm currently trying to compromise on is:
> 
> 
>    |\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
>    | Application-level protocol | user application features
>    +----------------------------+
>    | Optional transport features| Multiplexing, compression, etc.
>    +----------------------------+
>    | Websocket protocol         | Two way comms, browser security model
>    +----------------------------+
>    | TCP                        | reliability, connection wrapper
>    +----------------------------+
>    | IP                         | packet abstraction, routing
>    +----------------------------+
>    | Ethernet                   | link-level routing
>    |/\/\/\/\/\/\/\/\/\/\/\/\/\/\|

That's what I'm advocating. I guess our disagreement is that I think the 
optional transport features should be in a separate spec layered on top of 
WebSocket, just like BEEP and XMPP aren't in the raw TCP spec.

> > and reducing latency from 150ms (TCP round trip to set up the 
> > connection plus a packet for the message) to 50ms (just the packet for 
> > the message) is far more than marginal.
> 
> We just benchmarked a comet installation using HTTP long polling that 
> handled 8000 clients with an average 60ms latency.
> 
> Latency is not a big problem for me - but I acknowledge others might 
> want to do better (specially for max latency).

Ping to google.com from where I am here (on the Stanford campus) is 80ms, 
so the TCP handshake itself is going to be 120ms or so. If you're seeing 
60ms latencies, I'd love to hear how.

> Ideally if we had shared multiplexed with fragmentation that were 
> capable of carrying HTTP as well as bidirectional datagrams, then we 
> would be able to truly have 1 connection per client.

If you can get implementations interested in supporting something like 
this, that would be great. Personally I can't find a way to do this that 
would be simple enough to implement without relying on a dedicated 
framework, and I think the ability to implement the protocol simply is a 
key requirement.

On Sat, 31 Oct 2009, SM wrote:
> 
> Joint responsibility increases the chances of failure as two working 
> groups do not work the same way.

How do you define "success"? I think the more people are involved the more 
likely we are to get interoperable implementations.

> > It should be noted that the WHATWG's work is based on technical merit 
> > and not on consensus. If even just one person raises a valid technical 
> > issue in the WHATWG, they cannot be overridden by the rest of the 
> > group having complete agreement that they should just ignore the 
> > technical issue. There is also a firm philosophy that the specs match 
> > interoperable deployed implementations, and that the specs not leave 
> > things undefined.
> 
> The IETF process is based on consensus.  An IETF Working Group cannot 
> change that. The philosophical questions can be addressed in the charter 
> if the group reaches a consensus about that.
> 
> My comments are as an individual.  The proposed WG will be part of the 
> IETF. It is not the IETF.  The entire IETF community will be asked to 
> comment on the proposal submitted for publication.  The IETF does not 
> constrain the solution. It is up to the IETF participants to determine 
> what problem will be solved and how it will be solved.  There's the BoF 
> and this mailing to discuss about all that and come up with a proposed 
> charter.  People from the W3C WebApps and WHATWG are not excluded.  Ask 
> them to join this mailing list and participate.

Sure. And people from the IETF are not excluded from the WHATWG, and are 
welcome to join the mailing list and participate there also.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 02 Nov 2009 13:21:15 +1100

> 60ms latencies, I'd love to hear how.

60ms was for average message delivery not handshake.
So with 80ms ping time, how exactly does websocket achieve 50ms handshakes?

Let me put my point another way.    I have delivered infrastructure to
clients with comet solutions that are currently deployed for 10's
of millions of subscribers.   I'm  working with others that
are now going live to many 10s of millions more.

With that work, none of my clients have ever asked:

  Can you reduce latency from 150ms to 50ms
  Can you reduce the verbosity of the HTTP headers you send
  Can you reduce the verbosity of the bayeux protocol (it is verbose, but
  it can be compressed).

These have just not been significant issues.

What they have asked for is:

  Can this work through our existing network infrastructure, load balancers etc.
  Can we layer our special version of OAUTH on top.
  Can we encrypt/sign messages without SSL
  How can we increase the number of users connected per node.
  Our carrier is charging us per connection - can we reduce connection usage.
  How do we know this message was delivered.
  Why are connections being closed by the "network"

So don't tell me what my issues are.   Don't tell me that it's
stupid that some 3G carriers have connection limits.  Don't tell
me that reimplementing SSL inside the connection is a bad idea.
These are my issues that I'm hoping hybi can help with.

I understand why google want's header compression and/or less bytes
per message.  Yet while that's not my problem,  I'm not going to tell
you that it's also not googles problem .

I'm happy for a protocol that solves googles problems - but I'd
like it to help with mine.

regards

---

From: Martin Tyler <[email-masked]>
Date: Mon, 2 Nov 2009 09:01:52 +0000

aa

>  Can you reduce the verbosity of the bayeux protocol (it is verbose, but

Some of our customers ask the first question. They also ask about message
size, but not specifically about HTTP headers or anything.

To Ian:
The kilobytes of headers I have not seen and I very much doubt any
implementation would be sending the same amount of headers on each
WebSocket/BWTP message that they do for an individual HTTP request. It's
likely to be a mime type, and optional at that, so no overhead at all if all
your messages are the same mime type

>  Why are connections being closed by the "network"
Yes, these are all valid questions which we have to deal with too. Network
infrastructure can be a biggie, and anything we can do to make it work with
existing infrastructure would be great, rather than saying 'disconnect'

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 02 Nov 2009 12:48:01 +0200

> welcome to join the mailing list and participate there also.
My comment as individual.
I am in the WHATWG ml, but I have to say that I haven't seen any 
discussion, at least lately, on the WebSocket spec.
at least in the specification mailing list.
Actually I'd like also see more people from WHATWG community become 
involved the technical discussion that at the moment
is happening in the HyBi mailing list.

cheers
Sal