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
- [hybi] Proposed Charter for HyBi WG (rev.3) Salvatore Loreto
- Re: [hybi] Proposed Charter for HyBi WG (rev.3) Ian Hickson
- Re: [hybi] Proposed Charter for HyBi WG (rev.3) Greg Wilkins
- Re: [hybi] Proposed Charter for HyBi WG (rev.3) Salvatore Loreto
- Re: [hybi] Proposed Charter for HyBi WG (rev.3) SM
- Re: [hybi] Proposed Charter for HyBi WG (rev.3) Ian Hickson
- Re: [hybi] Proposed Charter for HyBi WG (rev.3) Greg Wilkins
- Re: [hybi] Proposed Charter for HyBi WG (rev.3) SM
- Re: [hybi] Proposed Charter for HyBi WG (rev.3) Ian Hickson
- Re: [hybi] Proposed Charter for HyBi WG (rev.3) Greg Wilkins
- Re: [hybi] Proposed Charter for HyBi WG (rev.3) Martin Tyler
- Re: [hybi] Proposed Charter for HyBi WG (rev.3) Salvatore Loreto