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

Greg Wilkins <gregw@webtide.com> Mon, 02 November 2009 02:21 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 C420B3A67E3 for <hybi@core3.amsl.com>; Sun, 1 Nov 2009 18:21:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, SARE_MILLIONSOF=0.315]
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 FcJHU1cQAVYt for <hybi@core3.amsl.com>; Sun, 1 Nov 2009 18:21:12 -0800 (PST)
Received: from mail-gx0-f212.google.com (mail-gx0-f212.google.com [209.85.217.212]) by core3.amsl.com (Postfix) with ESMTP id F1F173A63EC for <hybi@ietf.org>; Sun, 1 Nov 2009 18:21:11 -0800 (PST)
Received: by gxk4 with SMTP id 4so3859434gxk.8 for <hybi@ietf.org>; Sun, 01 Nov 2009 18:21:28 -0800 (PST)
Received: by 10.150.71.1 with SMTP id t1mr7374621yba.203.1257128488714; Sun, 01 Nov 2009 18:21:28 -0800 (PST)
Received: from ?10.10.1.9? (60-242-119-126.tpgi.com.au [60.242.119.126]) by mx.google.com with ESMTPS id 14sm937469gxk.14.2009.11.01.18.21.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 01 Nov 2009 18:21:27 -0800 (PST)
Message-ID: <4AEE421B.7030808@webtide.com>
Date: Mon, 02 Nov 2009 13:21:15 +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> <6.2.5.6.2.20091031080527.040fe028@resistor.net> <Pine.LNX.4.62.0911012010470.27039@hixie.dreamhostps.com>
In-Reply-To: <Pine.LNX.4.62.0911012010470.27039@hixie.dreamhostps.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
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: Mon, 02 Nov 2009 02:21:12 -0000

Ian Hickson wrote:

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

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