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

Ian Hickson <ian@hixie.ch> Sun, 01 November 2009 20:35 UTC

Return-Path: <ian@hixie.ch>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94E2A3A67D1 for <hybi@core3.amsl.com>; Sun, 1 Nov 2009 12:35:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.535
X-Spam-Level:
X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTXxFP9VtUXL for <hybi@core3.amsl.com>; Sun, 1 Nov 2009 12:35:24 -0800 (PST)
Received: from looneymail-a1.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 5C6FB3A6897 for <hybi@ietf.org>; Sun, 1 Nov 2009 12:35:24 -0800 (PST)
Received: from hixie.dreamhostps.com (hixie.dreamhost.com [208.113.210.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a1.g.dreamhost.com (Postfix) with ESMTP id 3B20915D572 for <hybi@ietf.org>; Sun, 1 Nov 2009 12:35:42 -0800 (PST)
Date: Sun, 01 Nov 2009 20:35:46 +0000
From: Ian Hickson <ian@hixie.ch>
To: "hybi@ietf.org" <hybi@ietf.org>
In-Reply-To: <6.2.5.6.2.20091031080527.040fe028@resistor.net>
Message-ID: <Pine.LNX.4.62.0911012010470.27039@hixie.dreamhostps.com>
References: <4AE966CA.9090907@ericsson.com> <Pine.LNX.4.62.0910300047310.25608@hixie.dreamhostps.com> <4AEABDBF.80705@ericsson.com> <6.2.5.6.2.20091030120030.043cff78@resistor.net> <Pine.LNX.4.62.0910310335580.25616@hixie.dreamhostps.com> <6.2.5.6.2.20091031080527.040fe028@resistor.net>
Content-Language: en-GB-hixie
Content-Style-Type: text/css
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Subject: Re: [hybi] Proposed Charter for HyBi WG (rev.3)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Nov 2009 20:35:25 -0000

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.   `._.-(,_..'--(,_..'`-.;.'