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. `._.-(,_..'--(,_..'`-.;.'
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.