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

Greg Wilkins <gregw@webtide.com> Sat, 31 October 2009 05:22 UTC

Return-Path: <gregw@webtide.com>
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 0E0493A6922 for <hybi@core3.amsl.com>; Fri, 30 Oct 2009 22:22:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.41
X-Spam-Level:
X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.189, 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 g619tDC4ZAgN for <hybi@core3.amsl.com>; Fri, 30 Oct 2009 22:22:27 -0700 (PDT)
Received: from mail-gx0-f212.google.com (mail-gx0-f212.google.com [209.85.217.212]) by core3.amsl.com (Postfix) with ESMTP id 61EBE3A6405 for <hybi@ietf.org>; Fri, 30 Oct 2009 22:22:27 -0700 (PDT)
Received: by gxk4 with SMTP id 4so2605506gxk.8 for <hybi@ietf.org>; Fri, 30 Oct 2009 22:22:41 -0700 (PDT)
Received: by 10.150.1.18 with SMTP id 18mr4473449yba.156.1256966561419; Fri, 30 Oct 2009 22:22:41 -0700 (PDT)
Received: from ?10.10.1.9? (60-242-119-126.tpgi.com.au [60.242.119.126]) by mx.google.com with ESMTPS id 14sm111497gxk.6.2009.10.30.22.22.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 30 Oct 2009 22:22:40 -0700 (PDT)
Message-ID: <4AEBC997.1030409@webtide.com>
Date: Sat, 31 Oct 2009 16:22:31 +1100
From: Greg Wilkins <gregw@webtide.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Ian Hickson <ian@hixie.ch>
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>
In-Reply-To: <Pine.LNX.4.62.0910310335580.25616@hixie.dreamhostps.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: "hybi@ietf.org" <hybi@ietf.org>
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: Sat, 31 Oct 2009 05:22:29 -0000

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.
That is hardly and endorsement of a layered
approach.


> 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
   |/\/\/\/\/\/\/\/\/\/\/\/\/\/\|



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
   |/\/\/\/\/\/\/\/\/\/\/\/\/\/\|



> What are the features that
> TCP lacks that you think need to be added between the "IP" and
> "Application-level protocol" layers of the stack above?

I want a transport that will provide bidirectional communications
through the web - where my definition of the web is the internet as
deployed with firewalls, NAT routers, aggregation, load balancers,
SSL offload, etc.

HTTP is a reasonable web transport, but it is not bidirectional


> Where do you think features like the browser-level origin model should fit?

Above the transport layer.
Below the application layer.


Where do you think features like multiplexing should fit?
I think you are advocating in the application layer - which is
just wrong!


> The origin security model makes no sense for a standalone app,
> since it controls what it sends down the wire. Such a model only makes
> sense when the handshake is done by a different party than the application
> -- indeed, it only makes sense when the application is assumed to be
> hostile. Most environments assume the application is benign.


And because the origin model implementation uses a standard
meta data channel (HTTP headers), applications that don't care about
it can simply ignore it and still work!!!!   Websocket is using
this technique in it's own handshake, but denying the same
technique to anything built on top of websocket.





Ian Hickson wrote:
> I must admit to being more interested in technical soundness than 
> consensus. 

Do you realize how arrogant that reads and how
non-constructive that is towards creating a civil
conversation?

We've not question your technical credentials to
participate in this forum, so please do not imply that
those that disagree with you cannot propose technically
sound solutions.


> I thought that's what I was doing: responding to proposals with counter 
> proposals, 

I'm still waiting for a single counter proposal other than
to say the application layer can do it all.



> Reducing kilobytes of data to 2 bytes is more than "a little more byte 
> efficient", 

HTTP headers used for most comet interactions are not kilobytes.

Even if there were, there are proposals that can be made to
browser/server developers to greatly reduce the overheads of
headers.

Data rate is not a big problem for me - but I acknowledge
others might want to do better.


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


> It halves the number of connections relative to current solutions. 
> I would  hardly characterise one connection per user as bloat --


It does not decrease the connections.  At the very least it
will add one connection because it can't be used for normal
HTTP - so those connections will still be used for normal
ajax stuff (or just held idle)

It is not one connection per user.    It is one connection
per end point that the application creates per frame, per tab
per window per user.

The number of connections IS a problem for me and others -
but I acknowledge that others don't give a damn.


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.


>> It's going to break all the load balancers I work with and the SSL 
>> offloaders and most other network infrastructure.
> 
> Could you elaborate on what requirements your load balancers and SSL 
> offloaders have which, if addressed, would lead to WebSocket working with 
> them to your satisfaction?

It's not "my satisfaction".    I'm just telling you that there is a
big industry in developing intermediaries that do all sorts of funky
stuff with HTTP - mostly based on the ability to pass meta data.

I don't know what they all do... I don't even think all the ones I
know about are good ideas.

But yet they still exist.  Like it or not, they will continue to
exit.    Trying to ignore them is just not going to be helpful.

I've already given you plenty of examples