Re: [hybi] Technical feedback. was: Process!

Maciej Stachowiak <mjs@apple.com> Sun, 31 January 2010 00:35 UTC

Return-Path: <mjs@apple.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 14B823A67A8 for <hybi@core3.amsl.com>; Sat, 30 Jan 2010 16:35:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.534
X-Spam-Level:
X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 5UY7PKOwwJwO for <hybi@core3.amsl.com>; Sat, 30 Jan 2010 16:35:45 -0800 (PST)
Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 1246E3A683F for <hybi@ietf.org>; Sat, 30 Jan 2010 16:35:45 -0800 (PST)
Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 62E1B82D12B6 for <hybi@ietf.org>; Sat, 30 Jan 2010 16:36:13 -0800 (PST)
X-AuditID: 11807130-b7b0aae00000102c-ab-4b64d07dcd88
Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay11.apple.com (Apple SCV relay) with SMTP id B2.44.04140.D70D46B4; Sat, 30 Jan 2010 16:36:13 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from [10.0.1.5] (c-69-181-42-237.hsd1.ca.comcast.net [69.181.42.237]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KX300FDT5OCKP30@elliott.apple.com> for hybi@ietf.org; Sat, 30 Jan 2010 16:36:12 -0800 (PST)
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <4B64B93E.3010703@webtide.com>
Date: Sat, 30 Jan 2010 16:36:11 -0800
Message-id: <6E7A870D-4641-4F34-8DA9-112A367920F1@apple.com>
References: <de17d48e1001280012i2657b587i83cda30f50013e6b@mail.gmail.com> <4B620B8F.6030706@gmx.de> <Pine.LNX.4.64.1001282217320.22053@ps20323.dreamhostps.com> <bbeaa26f1001281449q1a6e1813q3f537fe15a5a9d60@mail.gmail.com> <4B625733.2020907@webtide.com> <6.2.5.6.2.20100128225542.06fa8d68@resistor.net> <Pine.LNX.4.64.1001290817520.22020@ps20323.dreamhostps.com> <4B62C5FE.8090904@it.aoyama.ac.jp> <Pine.LNX.4.64.1001291134350.22020@ps20323.dreamhostps.com> <4B62E516.2010003@webtide.com> <5c902b9e1001290756r3f585204h32cacd6e64fbebaa@mail.gmail.com> <4B636757.3040307@webtide.com> <BBF3CE06-3276-4A7C-8961-7B3DDEE406D0@apple.com> <4B63DC2D.4090702@webtide.com> <4678E38C-EBD3-4867-B3A6-53A60F7F26C0@apple.com> <4B64B93E.3010703@webtide.com>
To: Greg Wilkins <gregw@webtide.com>
X-Mailer: Apple Mail (2.1077)
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] Technical feedback. was: Process!
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, 31 Jan 2010 00:35:46 -0000

On Jan 30, 2010, at 2:57 PM, Greg Wilkins wrote:

> 
> 
> It is very hard for a server to determine what is abuse.
> 
> If the server sets a low limit of connections per browser, then multiple
> tabs/frames in the same browser can quickly hit that limit in non abusing
> uses.

The handshake sends the Origin, so it could be per-browser per-origin, then your only problem is multiple tabs from the same site. (Different frames of the same page can cooperate to share a connection.)

> 
> If the server sets a moderate limit of connections to allow for the occasional
> user of multiple tabs/windows, then a single frame can abuse that limit
> and open maximal connections.
> 
> The point is that the connection usage policy should be something that
> is handled between the user-agent and the server.   The application
> developer should not be required to (or able to) participate in
> the connection management.
> 
> 
>>> I've previously explained in detail how a widget vendor might find some better performance by opening multiple websockets, so that they get a greater share of the bandwidth
>>> available from a server.   But that only works if your the only one doing it.  Soon everybody will be opening 4, 8, 16 connections etc.
>> 
>> So, this seems to have an assumption that the client-side code is developed by an independent entity from the server-side code. I can see how that might be true if your
>> WebSocket service is intended for cross-site use. However, it seems like that often won't be the case. For example, a vendor providing the chat service is likely to author both
>> the client-side JavaScript and the server-side code to manage it. Presumably they would not make this mistake. We do need to make sure that it's practical for clients to
>> minimize the number of connections they choose to use of course.
> 
> Firstly it is problematic to make assumptions about future usage.   But there are already plenty
> of examples of where third parties contribute code to a webpage either statically or dynamically.
> Go to any home page on any portal site and you will see plenty of third party widgets offering
> services... many of which would benefit from websocket type connectivity.

If you are embedding untrusted third party code on your site without doing anything to restrict what it can do, then you have much bigger problems than excessive WebSocket connections.

> 
> It is also not safe to assume that client libraries provided by a server will always be used.
> If the connection limit is imposed by the client library and their is an advantage to be
> obtained by exceeding the connection limit, then app developers will work around the libraries
> (or in js they will probably just modify the code).
> 
> Voluntary resource restriction just does not work.

I think the main limiting factor on use of excess connections is simply that many of the likely use cases would not actually benefit from using more connections (as described in other parts of my previous email).

> 
> 
> 
>> I do think the ability to do multiplexing as an optional feature may be useful. I see it as something that could be a 2.0 (or 1.1) protocol feature, and that could be totally
>> transparent in the client API. But if there are pitfalls that make it impossible to roll out later, it would be good to know now.
> 
> I agree that multiplexing would be advantageous and I've proposed several ways in which
> it could be done.    However I also do recognize that it is a difficult thing to achieve in 1.0.
> 
> The suggestion that I have made (and that was rejected) was that at least the 1.0 spec change it's
> language so that the websocket user is not promised a connection, but rather a conduit or channel.
> This would allow multiplexing to be added at a later date with less disruption etc.

I think that from the API perspective, whether you got a fresh connection or a channel over a multiplexed version of the protocol is not observable. Thus, such a change in the protocol to allow multiplexing would not require any API changes - it could be totally transparent to JS-level clients. What kind of disruption are you worried about, and can you help me understand more about your suggested change? Is it the protocol spec or the API spec that should be mentioning the possibility of channels that are not separate TCP connections? And how would this reduce future disruption. 

> 
> 
>>> working with load balancers and other intermediaries that need out-of-band communication with the server is another.
>> 
>> What's needed for the sake of these kinds of intermediaries? I think the principle we should apply here is that the protocol should be able to work with no changes to
>> intermediaries in general, but if we have a way to make it work better with optional cooperation from intermediaries, we should consider it. Can you mention some concrete
>> problems that come up here? Do you have solutions in mind?
> 
> 
> The number and type of intermediaries is too numerous and varied to generalize.
> But the ability to insert meta data into a stream that will not affect the application data is
> something that is easy to do and would enable a large variety of extensions (including multiplexing).
> 
> EG. a meta data frame could be injected to indicate the channel, encoding, encryption, origin, etc.
> of a following frame (or frames).

Can we talk about some specific problems for intermediaries? You don't have to cover everything, but a few example use cases would help me understand how your proposed mechanism would help.

Regards,
Maciej