From tobias.oberstein@tavendo.de Sat Jun 1 02:56:06 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951E921F8749 for ; Sat, 1 Jun 2013 02:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEI+l9DsVefP for ; Sat, 1 Jun 2013 02:55:55 -0700 (PDT) Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id BC67921F86F4 for ; Sat, 1 Jun 2013 02:55:54 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.90]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Sat, 1 Jun 2013 02:55:53 -0700 From: Tobias Oberstein To: Simone Bordet , Takeshi Yoshino Date: Sat, 1 Jun 2013 02:55:54 -0700 Thread-Topic: [hybi] Call for interest: multiplexing dedicated for WebSocket Thread-Index: Ac5attqzWx6pbG2eQ4i04OK+Y1TkLwD76sSA Message-ID: <634914A010D0B943A035D226786325D4422DC20DAA@EXVMBX020-12.exch020.serverdata.net> References: <007501ce56f0$67f74080$37e5c180$@noemax.com> <519CD6A1.7080708@ericsson.com> <519CE075.4000106@tavendo.de> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 09:56:06 -0000 > On Mon, May 27, 2013 at 10:25 AM, Takeshi Yoshino > wrote: > > Isn't it in-app priority? Can't script and server address that > > problem? If only the client knows current priority, the client can > > tell the priority to the peer servlet using a WebSocket message. If > > the server know priority for each position, it can just control transmi= ssion > speed. > > > > Even if we need help by the server, the servlet would call some > > special function to tell the server about priority. > > > > Different from HTTP/2.0's case, we don't need to provide a special > > field in mux protocol to pass priority, I think. If intermediaries are no preserve a per-channel priority based scheduling, = then they might need to know the channel priority. >=20 > Sure, but then you force every application to reinvent this mechanism on = top of > WebSocket mux. > At that point, one could argue that application messages could have their= own > "channel_id" in their messages, and applications can do mux themselves, i= f > they need it. Yep, agree. Scheduling integrated with MUX has another advantage: e.g. when doing per-channel priority based scheduling the scheduling could = not only consider channel priority, but also the quota. A high priority channel with data outstanding to be sent but not quota to s= end would otherwise block a lower priority channel with data _and_ quota. Another issue: implementing s.th. like priority based scheduling at app lev= el would might require to reinvent some kind of fragmentation at the app le= vel to be able to schedule according to priority (otherwise once a very lar= ge message on a low prio channel is started to be sent, it'll block everyth= ing else). One way to look at this is: WS fragmentation < WS multiplexing < WS scheduling | APP where "<" means "builds on", and everything up to "|" is provided by an WS = implementation, hence does not need to be reinvented at app level, and WS a= ware infrastructure can optimize / do their thing. =3D=3D=3D It seems that HTTP/2 likely will have "request priorization" (I don't know = about "response priorization"). If we (in a pure WS land) don't have priorization, that's a potential disad= vantage and source of discussion. =3D=3D=3D A per-channel scheduling could work according to different policies: 1. Round-Robin scheduling 2. Priority scheduling 3. Fair Bandwidth scheduling 4. First-Come, First-Serve scheduling The policy mechnism could be selected for the whole physical WS (and commun= icated for intermediaries), e.g. Sec-WebSocket-Extensions: mux; scheduler=3D"round-robin" Only with 2. there is a need to select and communicate a per-channel info (= during channel creation), e.g. Sec-WebSocket-Extensions: mux; scheduler=3D"priority" and then AddChannelRequest with the 3 RSV bits (currently unassigned) containing a p= riority 0-7 for the channel.=20 [This does not yet answer how to re-prioritize an existing channel] Hence I'd like to propose to 1) add an (optional) extension parameter "scheduler" as above 2) use the 3 currently unassigned RSV bits in AddChannelRequest for channel= prio (when scheduler=3D"priority") 3) define appropriate MUST semantics (scheduling should not follow advisory= semantics .. apps should be able to rely on it) 4) probably add a new PriorityControl message to change prio of existing ch= annels =3D=3D=3D Above is a kind of per-channel scheduling. One might argue that it lacks in= at least 2 respects: - an app is not able to control e.g. prio on a per-message basis - there are no ordering guarantees between messages on different channels Example: An app creates an empty file on some cloud service. Subsequently the app wa= nts to append to that file. The first could be a high-prio message, the latter messages low-prio. The app does not care whether those messages travel over 1 physical, or mul= tiple different logical WS channels. However, the app does care that the first "create file" message arrives bef= ore any subsequent "append to file" messages. So a different design involving per-message prios on a single WS channel (p= hysical or logical) might allow higher-prio messages to overtake lower prio= -messages, but not otherwise round.=20 /Tobias From scott@adligo.com Sat Jun 1 10:55:40 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8479021F9DE5 for ; Sat, 1 Jun 2013 10:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+zJIEWnNfNs for ; Sat, 1 Jun 2013 10:55:39 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 90D0721F9D24 for ; Sat, 1 Jun 2013 10:55:39 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x14so6637345ief.26 for ; Sat, 01 Jun 2013 10:55:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=0ZODoEFEaaYFGH9lOrbXbmo1N1r773YBMJRK24KmJwk=; b=Mk5wE/5etn51yMhDt8CUuxkaDdtB6/YFqg9DFT4khaHhLidNaIsGh9MST72pcvNBsU Yh1+BRCz6yq2R+W3+aHYAhofhTnAn9Blvc/ydDBkXpeRdiy31n4AMCONp2rBTAg80dWD 95IuApsvKP50ZM+EZM60Z7DDl8MXuyJuLcAwbesF90HKfrTA9BQ9FsHq7XZLxFQYrczc QSGw4uX4tMpVVMvVeWMZD12uTOFzmNC8y3DamGoSU9nX1wfdEnxDHiUK1/sq7W9BmQx3 l22uoDBSK2eJBdTrQVDKLJe2o9RvCo52uwlxoGvdGzeBPL2vmRPLDaGfAHlqyxIma3kN b58A== MIME-Version: 1.0 X-Received: by 10.43.90.137 with SMTP id bi9mr7140353icc.51.1370109338691; Sat, 01 Jun 2013 10:55:38 -0700 (PDT) Received: by 10.64.148.71 with HTTP; Sat, 1 Jun 2013 10:55:38 -0700 (PDT) In-Reply-To: References: Date: Sat, 1 Jun 2013 12:55:38 -0500 Message-ID: From: Scott Morgan To: hybi@ietf.org Content-Type: multipart/alternative; boundary=bcaec51867786fc0cc04de1b70ed X-Gm-Message-State: ALoCoQnaVJD0pdEkVc4sM4mcld0Q/xviReCmkqXKjO8Mz0VVspEyr5qPNpaNvIoUqVnPzh+0u92o Subject: Re: [hybi] hybi Digest, Vol 51, Issue 14 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 17:55:40 -0000 --bcaec51867786fc0cc04de1b70ed Content-Type: text/plain; charset=ISO-8859-1 Hi Takeshi, Your link to the rfc answered most of my questions, sorry I am new to the commenting process. I am trying to use the ip address header of multiple connections to provide a bit more validation of the ip address header, since mux may always use the same physical connection it would always have the same ip address header. I realize this is probably the wrong place to ask the following question but; Is anyone aware of another or better way to validate the source ip address of a TCP/IP connection? Thanks, Scott PS see below for other comments if your interested. On Tue, May 28, 2013 at 10:36 PM, Takeshi Yoshino wrote: > On Wed, May 29, 2013 at 4:44 AM, Scott Morgan wrote: > >> Also what will happen if multiple to the multiplexed ws if one of >> two browser tabs calls close on the ws connection? >> Does the other tab force keep the ws connection open? >> Does the other tab have to auto recover and reopen the connection? >> > > close() call on a WebSocket instance that is multiplexed in network stack > should result in close of the logical channel used by the WebSocket > instance. Not close on the physical WebSocket connection. Once the last > logical connection is closed, the network stack may start closing the > physical connection. It can be also delayed. > http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-10#section-15 is > the section discussing that. > > >> Sorry if I missed this somewhere in the drafts. >> Just my 2cents. >> >> It's important for a attempt to block browser ip address spoofing on >> the first ws connection in a the following use case; >> >> > Could you elaborate? > Yes and actually I am going to change the way I do this after reading the rfc. I am going to use regular http(s) for the authentication part so this would change to the following. 1 Browser sends authentication to the server over https 2 Server notes the ip address of the request and responds with a ws url to the client if successful ie. wss://example.com/valid?session=123 3 Browser connects to url wss://example.com/valid?session=123 4 Server checks the ip address of the original https request with the wss connection to make sure they are the same, and takes appropriate action (closes the wss connection if they are NOT, or some other appropriate action) > > >> 1 Browser connects to a wss server >> 2 User does some authentication (ie user id, password) >> 3 wss server does authentication using user id, password and ip address >> (for either some privileges or as a additional authentication parameter >> for a success fail style authentication) >> > > That is that only access from some IP address X will have some high > privilege? > Yes the ip address of the user may allow the user to gain additional privileges, ie something like; John logs in to the Bank from a public computer he can't do much, but see the accounts. John logs in from his office (and the office ips addresses are marked as secure locations) he gets to transfer money Note my application is not a bank application, this is just a example. > > >> 4 after successful auth message at the browser an the wss connection is >> closed >> and a different wss is opened on the same port with a different path in >> the url >> 5 The wss server only allows the different wss connection to open if >> there is a http session from the original wss connection from the same ip >> address of the first connection. >> > > Does the server get a session parameter over the new connection and also > check the source IP address? Or the server here just checks if there was > successful authentication on some prior connection with the same IP address > as the new one? > My main goal was to attempt to validate the IP address of the sender by comparing the ip address of multiple connections, (originally both wss, now https and wss). > > >> >> Not that this is a fool proof solution to ip address spoofing, but it >> would at least provide some level of ip address spoofing support (as the >> spoofer would need to know that it had to spoof twice). If the connection >> stayed open, the original spoof would remain in effect and this sort of >> attempt to block ip address spoofing would be rendered completely >> in-effective. >> > > --bcaec51867786fc0cc04de1b70ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Takeshi,

=A0=A0 Your link to the= rfc answered most of my questions, sorry I am new to the commenting proces= s.=A0=A0=A0 I am trying to use the ip address header of multiple connection= s to provide a bit more validation of the ip address header, since mux may = always use the same physical connection it would always have the same ip ad= dress header.
=A0=A0=A0 I realize this is probably the wrong place to ask the follo= wing question but;
Is anyone aware of another or better way to validate= the source ip address of a TCP/IP connection?

Thanks,
= Scott

=A0 PS see below for oth= er comments if your interested.


On Tu= e, May 28, 2013 at 10:36 PM, Takeshi Yoshino <tyoshino@google.com&g= t; wrote:
On Wed, May 29, 2013 at 4:44 AM, Scott Morgan &= lt;scott@adligo.com> wrote:
=A0= =A0 Also what will happen if multiple to the=A0multiplexed ws if one of two browser tabs = calls close on the ws connection?
=A0 =A0Doe= s the other tab force keep the ws connection open?
=A0 =A0Does the other = tab have to auto recover and reopen the connection?

=A0
Sorry if I= missed this somewhere in the drafts.
Just my 2cents.=

=A0 =A0It's important for a attempt to block browser ip addre= ss spoofing on the first ws connection in a the following use case;<= /div>


Could you elaborat= e?
Yes and actually I am goi= ng to change the way I do this after reading the rfc.=A0=A0 I am going to u= se regular http(s) for the authentication part so this would change to the = following.

1 Browser sends authentication to the server over https
<= /div>
2 Server notes the ip address of the request and responds with a = ws url to the client if successful ie.=A0 wss://example.com/valid?session=3D123
3 Browser connects to url wss://example.com/valid?session=3D123
4 Serv= er checks the ip address of the original https request with the wss connect= ion
=A0=A0=A0 to make sure they are the same, and takes appropriate = action (closes the wss connection if they are NOT, or some other appropriat= e action)


=A0
=A0
1 Browser connects to a wss server
2 User does some authentic= ation (ie user id, password)
3 wss serv= er does authentication using user id, password and ip address
<= div>(for either= some privileges or as a additional authentication parameter for a success = fail style authentication)

That is that only access from = some IP address X will have some high privilege?
Yes the ip address of the user may allow the user to gain ad= ditional privileges, ie something like;
John logs in to the Bank from a public computer he can't do much, but s= ee the accounts.
John logs in from his office (and the office ips addres= ses are marked as secure locations)
=A0 he gets to transfer m= oney

Note my application is not a bank application, this is just = a example.
=A0
4 after su= ccessful auth message at the browser an the=A0wss connection is closed
=A0and a different wss is opened on the same port with a differe= nt path in the url
5 The wss server only allows the diff= erent wss connection to open if there is a http session from the original w= ss connection from the same ip address of the first connection.

Does the server get a session = parameter over the new connection and also check the source IP address? Or = the server here just checks if there was successful authentication on some = prior connection with the same IP address as the new one?
My main goal was to attempt to validate= the IP address of the sender by comparing the ip address of multiple conne= ctions, (originally both wss, now https and wss).
=A0
=A0

Not that this is a fool proof solution to ip address spoo= fing, but it would at least provide some level of ip address spoofing suppo= rt (as the spoofer would need to know that it had to spoof twice). =A0If th= e connection stayed open, the original spoof would remain in effect and thi= s sort of attempt to block ip address spoofing would be rendered completely= in-effective.
=A0

--bcaec51867786fc0cc04de1b70ed-- From tobias.oberstein@tavendo.de Sat Jun 1 15:29:56 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E3D21F9DDC for ; Sat, 1 Jun 2013 15:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xee9EBEUCgLX for ; Sat, 1 Jun 2013 15:29:51 -0700 (PDT) Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id 123AC21F9DD1 for ; Sat, 1 Jun 2013 15:29:50 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.90]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Sat, 1 Jun 2013 15:29:49 -0700 From: Tobias Oberstein To: Takeshi Yoshino , "hybi@ietf.org" Date: Sat, 1 Jun 2013 15:29:52 -0700 Thread-Topic: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-09.txt Thread-Index: Ac5bc75BydJsDfCVSP+lKrMvspJ0PgDoUx7Q Message-ID: <634914A010D0B943A035D226786325D4422DC20DC7@EXVMBX020-12.exch020.serverdata.net> References: <20130425140626.10027.9016.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-09.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 22:29:56 -0000 > Please post your opinions and experience (implemented, faced any difficul= ties, found issues, etc.). """ A client MAY attach the "c2s_max_window_bits" extension parameter if the client can adjust LZ77 sliding window size based on the "c2s_max_window_bits" sent by the server. This parameter has no value. """ Any reason there is no "c2s_no_context_takeover" parameter that allows the = client to _announce_ it supports the feature? Proposal (new text): """ A client MAY attach the "c2s_no_context_takeover" extension parameter if the client can disable the takeover of context based on the "c2s_no_context_takeover" sent by the server. This parameter has no value. """ A client that fully supports all features and requests none from the server= would then offer "permessage-deflate; c2s_max_window_bits; c2s_no_context_takeover" and the server would accept the offer requesting no features by responding = with "permessage-deflate" From fenix@google.com Mon Jun 3 11:15:07 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F26C21F85E0 for ; Mon, 3 Jun 2013 11:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBBW25Y+o3sm for ; Mon, 3 Jun 2013 11:14:53 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id DA52321E805E for ; Mon, 3 Jun 2013 11:12:51 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id v10so4141717lbd.34 for ; Mon, 03 Jun 2013 11:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1u25UEkk4bDmOY+mH3dt1HH2mXCpyx4x+zHaGbYQkJ8=; b=Vs5oW/AlOP+mvbmEzO+UoW+3LTCegYWFkWgndkyNlntWmsv71qzHkfnUFRJxMvL2WN dsx2oHI8/A701ByDOyjLK2YW7vmmhgubQpysaiMl31G2yC4HVkG3Cj5Gwdlm3A/rNUlC q+G9Q55fsRrFwe5rEKls3O1sq+zKPBYU0HJFDUJbIWmQwAqpav1onDLL8085lDI7UgvY LVHaUaAfxtTFMoh4duFtYwcdtvQVCPRPF7yT7YdflO1eb24NtmJ3gzpdFJK3jgx+iUi2 xzhkYCkiwjqLmT9+8rMGsSzE6WgLUSfZtrcgfJLzBOwLMEUk0TuN2IQqLXYOA5lXzjPI P6Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=1u25UEkk4bDmOY+mH3dt1HH2mXCpyx4x+zHaGbYQkJ8=; b=nDGvYnS/lSmEB6HkOM42SHgBZUNKnCzBNptYCxghOet9CYqfp4uhNg/pd2x9wRAsBe cHzL4SPW9JJOKd3XEBkznaTXV9DdO5zTIig3MQCeJpjh0z/rgYQbJ45wC53+jh2ten8E AXiuaE5XoiH6nfrFWsHnzQ/FGO4J64HryTK5btScohWW8aId3aYMlyszPWTSEoDJ9BHQ 7A7qiFmrHjKOWJbR1Q6B0d1WnH7l8QRv5rhlanwnl8COkuIW78795JFLQ8iLF4zg15oU YlK3ztKqFfsl9r4PsEDLJp0D63eG4rkhy+ptlrzMBFbkDQ6SHafxhvaWngQe9HmPXZri 5rSw== MIME-Version: 1.0 X-Received: by 10.112.148.104 with SMTP id tr8mr11478831lbb.56.1370283170726; Mon, 03 Jun 2013 11:12:50 -0700 (PDT) Received: by 10.112.76.231 with HTTP; Mon, 3 Jun 2013 11:12:50 -0700 (PDT) In-Reply-To: <51A85EF9.3010907@tavendo.de> References: <634914A010D0B943A035D226786325D4422C319646@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D4422C3DA774@EXVMBX020-12.exch020.serverdata.net> <51A70DF9.5010601@tavendo.de> <51A85EF9.3010907@tavendo.de> Date: Mon, 3 Jun 2013 11:12:50 -0700 Message-ID: From: Roberto Peon To: Tobias Oberstein Content-Type: multipart/alternative; boundary=047d7b3a8300a21ffe04de43e96f X-Gm-Message-State: ALoCoQk0ZVJkqaiiw/LWAJuvhIBya1ey9aYvGDotPBikHOc9rkpDoIrZI3KULRVPHgwhQXXiVssugitDZgi6j6PGV6Hcve1ovW/bGKORFqw3M+fQ/jD0qforYox+i0OoHP7gpPeryQT55WU7BSTFVf8MhJoyLkp0Ii/Im3eM2awpjLQKE4O74aM+UhurD2WsK0689h39gRri Cc: "hybi@ietf.org" Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 18:15:07 -0000 --047d7b3a8300a21ffe04de43e96f Content-Type: text/plain; charset=ISO-8859-1 Well, more precisely, the compression context must be shared between material sourced by the attacker and also for the purpose of using the site, and the context must be probe-able in some reasonable amount of time. A gzip context which was reused between messages would be a no-no, for instance. Another compression context (which makes probing difficult) might be acceptable. -=R On Fri, May 31, 2013 at 1:27 AM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > The way CRIME works is to have a 3rd party include links to the >> site-to-attack. Thus it doesn't matter if the schemes are http, https, >> ws, wss, whatever. >> > > Does above refer to the general requirement for CRIME: the attacker must > be able to inject data into the source material before it is compressed and > then encrypted? > > If so, how would that be possible with WebSocket and the proposed > WebSocket per-message compression? > > > random thoughts: > > a) > permessage-deflate only compresses WS data messages, not control frames. > > So the attacker would need to inject data into the app-level payload. > > The only way to send app-level payload in browsers if via the JavaScript > WebSocket API (socket.send()). > > So the attacker would need to somehow modify this JS code. However, the > origin of the JS running is (at least with browsers) sent during the WS > opening handshake as a HTTP header, and a WS server can check and decline > an incoming connection. > > b) > With WS HTTP headers are only sent _once_: during the initial WS opening > handshake, and by the client to the server. > > CRIME requires repeated injection of attacker data. > > More so: permessage-deflate does not touch the opening handshake, which > remains uncompressed. > > Side Q: Do browsers reuse an established TLS/TCP connection for multiple > WS connections? > > /Tobias > > --047d7b3a8300a21ffe04de43e96f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Well, more precisely, the compression context must be shar= ed between material sourced by the attacker and also for the purpose of usi= ng the site, and the context must be probe-able in some reasonable amount o= f time.
A gzip context which was reused between messages would be a no-no, for inst= ance. Another compression context (which makes probing difficult) might be = acceptable.

-=3DR


On Fri, May 31, 2013 at 1:27 AM, Tobias = Oberstein <tobias.oberstein@tavendo.de> wrote:
=
The way CRIME works is to have a 3rd party include links to the
site-to-attack. Thus it doesn't matter if the schemes are http, https,<= br> ws, wss, whatever.

Does above refer to the general requirement for CRIME: the attacker must be= able to inject data into the source material before it is compressed and t= hen encrypted?

If so, how would that be possible with WebSocket and the proposed WebSocket= per-message compression?


random thoughts:

a)
permessage-deflate only compresses WS data messages, not control frames.
So the attacker would need to inject data into the app-level payload.

The only way to send app-level payload in browsers if via the JavaScript We= bSocket API (socket.send()).

So the attacker would need to somehow modify this JS code. However, the ori= gin of the JS running is (at least with browsers) sent during the WS openin= g handshake as a HTTP header, and a WS server can check and decline an inco= ming connection.

b)
With WS HTTP headers are only sent _once_: during the initial WS opening ha= ndshake, and by the client to the server.

CRIME requires repeated injection of attacker data.

More so: permessage-deflate does not touch the opening handshake, which rem= ains uncompressed.

Side Q: Do browsers reuse an established TLS/TCP connection for multiple WS= connections?

/Tobias


--047d7b3a8300a21ffe04de43e96f-- From fenix@google.com Mon Jun 3 11:18:25 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E643C21F85B4 for ; Mon, 3 Jun 2013 11:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOulzLvk+yYT for ; Mon, 3 Jun 2013 11:18:14 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 69FFC21F8746 for ; Mon, 3 Jun 2013 11:15:39 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id gw10so1316945lab.2 for ; Mon, 03 Jun 2013 11:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D7+QPr7Dvd5GsrlbLP7b9pfI1qB/AkR6WDSWILE+nEQ=; b=ok3F8YHbHdStLecllqioD8mIfmiES17eIVf9+rfaY+pv+zRFxO/g6hERt4FmJZWuM7 k5K2lmxV22/juP1dnoshccSJFb2Mtrt+xflx2EVJ256ZnkHg0v+USea0QXp2KnPg5W8f k23iMEQJ5lbFA0XbmZ24BhcmOihN6AXLuOW08WGIqqHD90co6EMhlf5wu8LjcuQfWkJn gUNJ4cL42ROyRIFjAgTWxRxr5H21SeQnQ3j8lXlPNkvQ7cvROqW5Ql6ISTgos8w1zHop yRWLzrF/Y46ezu3PyLRatZGtbU286CCc/c552VISVs38V/tocLLotNjAaQGIpHp6a+YF x/HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=D7+QPr7Dvd5GsrlbLP7b9pfI1qB/AkR6WDSWILE+nEQ=; b=Tlt4rVEkTeCNeqZ2NNaq7NT+61oc2o81JaYaaZBqaWEpK6ao9noFVPCNX5tRGOya+z tPTUTAtHS4BigyDM1xCPl/sMsFPkjUK0cAsX5AJFGKU5iwxwxdydyRf/IrY+jMtOAOp4 HCl7ODtXVxFWW4wS0vSekNiGLD6eqXtHLHTIV+q9GQSNE8wbdvXZFlC1W9sjO3ea5KPt OvbI3yOKbPdkYBT26ZVj+3hOvVAw1cqs305qsJbM9nNMyPsnhKSHOI5FZcWxonvpviQY jUKM+Cbj4yXdKigLflz82Kq2Wh0bL9OrK7jAYlhI+f4tsxEFtTq6jViNFSFAVzDRhK94 nVBg== MIME-Version: 1.0 X-Received: by 10.112.134.34 with SMTP id ph2mr11430790lbb.112.1370283338330; Mon, 03 Jun 2013 11:15:38 -0700 (PDT) Received: by 10.112.76.231 with HTTP; Mon, 3 Jun 2013 11:15:38 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D4422DC20DAA@EXVMBX020-12.exch020.serverdata.net> References: <007501ce56f0$67f74080$37e5c180$@noemax.com> <519CD6A1.7080708@ericsson.com> <519CE075.4000106@tavendo.de> <634914A010D0B943A035D226786325D4422DC20DAA@EXVMBX020-12.exch020.serverdata.net> Date: Mon, 3 Jun 2013 11:15:38 -0700 Message-ID: From: Roberto Peon To: Tobias Oberstein Content-Type: multipart/alternative; boundary=047d7b3a8c0c9f8a7a04de43f325 X-Gm-Message-State: ALoCoQlZTZwWbskrzdVF8I3Nu1XOVoW3xQAD/gM+22OaCw3N51Ww+4fCrmOfkgjdYaIdoGDSWUrBCyIE2hyKml+CNX+fcYZRoc94I04dpCkzrifiX3CIEDshoDvCZqebnAw5vVJprg6MoCGs/7CMKo4Tr4unvFNa9NVx8ZBw3g7Jc1j08jNxl0Vk2gj8U4yKkVsE6TtJtGcR Cc: Simone Bordet , "hybi@ietf.org" Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 18:18:26 -0000 --047d7b3a8c0c9f8a7a04de43f325 Content-Type: text/plain; charset=ISO-8859-1 imho, we're reinventing SPDY/HTTP/2, and I'd rather implement the complexity of muxing, security, prioritization, flow-control, liveness-checking, stream initiation, and compression, only once. -=R On Sat, Jun 1, 2013 at 2:55 AM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > > On Mon, May 27, 2013 at 10:25 AM, Takeshi Yoshino > > wrote: > > > Isn't it in-app priority? Can't script and server address that > > > problem? If only the client knows current priority, the client can > > > tell the priority to the peer servlet using a WebSocket message. If > > > the server know priority for each position, it can just control > transmission > > speed. > > > > > > Even if we need help by the server, the servlet would call some > > > special function to tell the server about priority. > > > > > > Different from HTTP/2.0's case, we don't need to provide a special > > > field in mux protocol to pass priority, I think. > > If intermediaries are no preserve a per-channel priority based scheduling, > then they might need to know the channel priority. > > > > > Sure, but then you force every application to reinvent this mechanism on > top of > > WebSocket mux. > > At that point, one could argue that application messages could have > their own > > "channel_id" in their messages, and applications can do mux themselves, > if > > they need it. > > Yep, agree. > > Scheduling integrated with MUX has another advantage: > > e.g. when doing per-channel priority based scheduling the scheduling could > not only consider channel priority, but also the quota. > > A high priority channel with data outstanding to be sent but not quota to > send would otherwise block a lower priority channel with data _and_ quota. > > Another issue: implementing s.th. like priority based scheduling at app > level would might require to reinvent some kind of fragmentation at the app > level to be able to schedule according to priority (otherwise once a very > large message on a low prio channel is started to be sent, it'll block > everything else). > > One way to look at this is: > > WS fragmentation < WS multiplexing < WS scheduling | APP > > where "<" means "builds on", and everything up to "|" is provided by an WS > implementation, hence does not need to be reinvented at app level, and WS > aware infrastructure can optimize / do their thing. > > === > > It seems that HTTP/2 likely will have "request priorization" (I don't know > about "response priorization"). > > If we (in a pure WS land) don't have priorization, that's a potential > disadvantage and source of discussion. > > === > > A per-channel scheduling could work according to different policies: > > 1. Round-Robin scheduling > 2. Priority scheduling > 3. Fair Bandwidth scheduling > 4. First-Come, First-Serve scheduling > > The policy mechnism could be selected for the whole physical WS (and > communicated for intermediaries), e.g. > > Sec-WebSocket-Extensions: mux; scheduler="round-robin" > > Only with 2. there is a need to select and communicate a per-channel info > (during channel creation), e.g. > > Sec-WebSocket-Extensions: mux; scheduler="priority" > > and then > > AddChannelRequest with the 3 RSV bits (currently unassigned) containing a > priority 0-7 for the channel. > > [This does not yet answer how to re-prioritize an existing channel] > > Hence I'd like to propose to > > 1) add an (optional) extension parameter "scheduler" as above > 2) use the 3 currently unassigned RSV bits in AddChannelRequest for > channel prio (when scheduler="priority") > 3) define appropriate MUST semantics (scheduling should not follow > advisory semantics .. apps should be able to rely on it) > 4) probably add a new PriorityControl message to change prio of existing > channels > > === > > Above is a kind of per-channel scheduling. One might argue that it lacks > in at least 2 respects: > > - an app is not able to control e.g. prio on a per-message basis > - there are no ordering guarantees between messages on different channels > > Example: > An app creates an empty file on some cloud service. Subsequently the app > wants to append to that file. > > The first could be a high-prio message, the latter messages low-prio. > > The app does not care whether those messages travel over 1 physical, or > multiple different logical WS channels. > > However, the app does care that the first "create file" message arrives > before any subsequent "append to file" messages. > > So a different design involving per-message prios on a single WS channel > (physical or logical) might allow higher-prio messages to overtake lower > prio-messages, but not otherwise round. > > /Tobias > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --047d7b3a8c0c9f8a7a04de43f325 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
imho, we're reinventing SPDY/HTTP/2, and I'd rathe= r implement the complexity of muxing, security, prioritization, flow-contro= l, liveness-checking, stream initiation, and=A0compression,=A0only=A0once.<= div>
-=3DR


On Sat, Jun 1, 2013 at 2:55 AM, Tobias Oberstein <tobi= as.oberstein@tavendo.de> wrote:
> On Mon, May 27, 2013 = at 10:25 AM, Takeshi Yoshino <tyo= shino@google.com>
> wrote:
> > Isn't it in-app priority? Can't script and server address= that
> > problem? If only the client knows current priority, the client ca= n
> > tell the priority to the peer servlet using a WebSocket message. = If
> > the server know priority for each position, it can just control t= ransmission
> speed.
> >
> > Even if we need help by the server, the servlet would call some > > special function to tell the server about priority.
> >
> > Different from HTTP/2.0's case, we don't need to provide = a special
> > field in mux protocol to pass priority, I think.

If intermediaries are no preserve a per-channel priority based schedu= ling, then they might need to know the channel priority.

>
> Sure, but then you force every application to reinvent this mechanism = on top of
> WebSocket mux.
> At that point, one could argue that application messages could have th= eir own
> "channel_id" in their messages, and applications can do mux = themselves, if
> they need it.

Yep, agree.

Scheduling integrated with MUX has another advantage:

e.g. when doing per-channel priority based scheduling the scheduling could = not only consider channel priority, but also the quota.

A high priority channel with data outstanding to be sent but not quota to s= end would otherwise block a lower priority channel with data _and_ quota.
Another issue: implementing s.th<= /a>. like priority based scheduling at app level would might require to rei= nvent some kind of fragmentation at the app level to be able to schedule ac= cording to priority (otherwise once a very large message on a low prio chan= nel is started to be sent, it'll block everything else).

One way to look at this is:

WS fragmentation < WS multiplexing < WS scheduling | APP

where "<" means "builds on", and everything up to &q= uot;|" is provided by an WS implementation, hence does not need to be = reinvented at app level, and WS aware infrastructure can optimize / do thei= r thing.

=3D=3D=3D

It seems that HTTP/2 likely will have "request priorization" (I d= on't know about "response priorization").

If we (in a pure WS land) don't have priorization, that's a potenti= al disadvantage and source of discussion.

=3D=3D=3D

A per-channel scheduling could work according to different policies:

1. Round-Robin scheduling
2. Priority scheduling
3. Fair Bandwidth scheduling
4. First-Come, First-Serve scheduling

The policy mechnism could be selected for the whole physical WS (and commun= icated for intermediaries), e.g.

Sec-WebSocket-Extensions: mux; scheduler=3D"round-robin"

Only with 2. there is a need to select and communicate a per-channel info (= during channel creation), e.g.

Sec-WebSocket-Extensions: mux; scheduler=3D"priority"

and then

AddChannelRequest with the 3 RSV bits (currently unassigned) containing a p= riority 0-7 for the channel.

[This does not yet answer how to re-prioritize an existing channel]

Hence I'd like to propose to

1) add an (optional) extension parameter "scheduler" as above
2) use the 3 currently unassigned RSV bits in AddChannelRequest for channel= prio (when scheduler=3D"priority")
3) define appropriate MUST semantics (scheduling should not follow advisory= semantics .. apps should be able to rely on it)
4) probably add a new PriorityControl message to change prio of existing ch= annels

=3D=3D=3D

Above is a kind of per-channel scheduling. One might argue that it lacks in= at least 2 respects:

- an app is not able to control e.g. prio on a per-message basis
- there are no ordering guarantees between messages on different channels
Example:
An app creates an empty file on some cloud service. Subsequently the app wa= nts to append to that file.

The first could be a high-prio message, the latter messages low-prio.

The app does not care whether those messages travel over 1 physical, or mul= tiple different logical WS channels.

However, the app does care that the first "create file" message a= rrives before any subsequent "append to file" messages.

So a different design involving per-message prios on a single WS channel (p= hysical or logical) might allow higher-prio messages to overtake lower prio= -messages, but not otherwise round.

/Tobias
_____________________= __________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--047d7b3a8c0c9f8a7a04de43f325-- From tobias.oberstein@tavendo.de Mon Jun 3 14:38:01 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16F111E8117 for ; Mon, 3 Jun 2013 14:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CW2KoowM8Vg3 for ; Mon, 3 Jun 2013 14:37:47 -0700 (PDT) Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id 92C4B21F94DC for ; Mon, 3 Jun 2013 14:33:34 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.90]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Mon, 3 Jun 2013 14:33:33 -0700 From: Tobias Oberstein To: Roberto Peon Date: Mon, 3 Jun 2013 14:33:27 -0700 Thread-Topic: [hybi] Call for interest: multiplexing dedicated for WebSocket Thread-Index: Ac5ghlykxG8qMgFlR2S684o2ridP0gAF4bBw Message-ID: <634914A010D0B943A035D226786325D4422DC2133A@EXVMBX020-12.exch020.serverdata.net> References: <007501ce56f0$67f74080$37e5c180$@noemax.com> <519CD6A1.7080708@ericsson.com> <519CE075.4000106@tavendo.de> <634914A010D0B943A035D226786325D4422DC20DAA@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simone Bordet , "hybi@ietf.org" Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 21:38:02 -0000 >imho, we're reinventing SPDY/HTTP/2, and I'd rather implement the complexi= ty of muxing, security, prioritization, flow-control, liveness-checking, st= ream initiation, and=A0compression,=A0only=A0once. >-=3DR First, lets admit: we are both biased;) What about HTTP/2 over WS? http://tools.ietf.org/html/draft-montenegro-httpbis-speed-mobility-02 I prefer native WS. I do single-page web apps with app manifests. The attractiveness of SPDY(TM) (be it native or over WS) in this situation = is limited. Any static resources are retrieved only once anyway, and any co= mmunication after that can be done via WS. - native WS is widely implemented today - native WS has lower per-message overhead than "WS over SPDY(TM)" - WS (now) has _payload_ compression - liveness checking =3D> WS pings/pongs - security =3D> WS masking, WS origin So I'd say a WS-MUX with flow-control (draft there) plus priorization/sched= uling (not there) is "the last missing piece". Lets finish it. /Tobias On Sat, Jun 1, 2013 at 2:55 AM, Tobias Oberstein wrote: > On Mon, May 27, 2013 at 10:25 AM, Takeshi Yoshino > wrote: > > Isn't it in-app priority? Can't script and server address that > > problem? If only the client knows current priority, the client can > > tell the priority to the peer servlet using a WebSocket message. If > > the server know priority for each position, it can just control transmi= ssion > speed. > > > > Even if we need help by the server, the servlet would call some > > special function to tell the server about priority. > > > > Different from HTTP/2.0's case, we don't need to provide a special > > field in mux protocol to pass priority, I think. If intermediaries are no preserve a per-channel priority based scheduling, = then they might need to know the channel priority. > > Sure, but then you force every application to reinvent this mechanism on = top of > WebSocket mux. > At that point, one could argue that application messages could have their= own > "channel_id" in their messages, and applications can do mux themselves, i= f > they need it. Yep, agree. Scheduling integrated with MUX has another advantage: e.g. when doing per-channel priority based scheduling the scheduling could = not only consider channel priority, but also the quota. A high priority channel with data outstanding to be sent but not quota to s= end would otherwise block a lower priority channel with data _and_ quota. Another issue: implementing s.th. like priority based scheduling at app lev= el would might require to reinvent some kind of fragmentation at the app le= vel to be able to schedule according to priority (otherwise once a very lar= ge message on a low prio channel is started to be sent, it'll block everyth= ing else). One way to look at this is: WS fragmentation < WS multiplexing < WS scheduling | APP where "<" means "builds on", and everything up to "|" is provided by an WS = implementation, hence does not need to be reinvented at app level, and WS a= ware infrastructure can optimize / do their thing. =3D=3D=3D It seems that HTTP/2 likely will have "request priorization" (I don't know = about "response priorization"). If we (in a pure WS land) don't have priorization, that's a potential disad= vantage and source of discussion. =3D=3D=3D A per-channel scheduling could work according to different policies: 1. Round-Robin scheduling 2. Priority scheduling 3. Fair Bandwidth scheduling 4. First-Come, First-Serve scheduling The policy mechnism could be selected for the whole physical WS (and commun= icated for intermediaries), e.g. Sec-WebSocket-Extensions: mux; scheduler=3D"round-robin" Only with 2. there is a need to select and communicate a per-channel info (= during channel creation), e.g. Sec-WebSocket-Extensions: mux; scheduler=3D"priority" and then AddChannelRequest with the 3 RSV bits (currently unassigned) containing a p= riority 0-7 for the channel. [This does not yet answer how to re-prioritize an existing channel] Hence I'd like to propose to 1) add an (optional) extension parameter "scheduler" as above 2) use the 3 currently unassigned RSV bits in AddChannelRequest for channel= prio (when scheduler=3D"priority") 3) define appropriate MUST semantics (scheduling should not follow advisory= semantics .. apps should be able to rely on it) 4) probably add a new PriorityControl message to change prio of existing ch= annels =3D=3D=3D Above is a kind of per-channel scheduling. One might argue that it lacks in= at least 2 respects: - an app is not able to control e.g. prio on a per-message basis - there are no ordering guarantees between messages on different channels Example: An app creates an empty file on some cloud service. Subsequently the app wa= nts to append to that file. The first could be a high-prio message, the latter messages low-prio. The app does not care whether those messages travel over 1 physical, or mul= tiple different logical WS channels. However, the app does care that the first "create file" message arrives bef= ore any subsequent "append to file" messages. So a different design involving per-message prios on a single WS channel (p= hysical or logical) might allow higher-prio messages to overtake lower prio= -messages, but not otherwise round. /Tobias _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi From fenix@google.com Mon Jun 3 15:14:11 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE97411E8106 for ; Mon, 3 Jun 2013 15:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUNx7Dr+LIrX for ; Mon, 3 Jun 2013 15:14:00 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3551F11E80F9 for ; Mon, 3 Jun 2013 15:07:54 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id eg20so633555lab.33 for ; Mon, 03 Jun 2013 15:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tW9tW5EaXJMb/bg5utYbjiBQ/GFL3t2AiSM1iu6uRBM=; b=kV92sZDUgixwKW1z5vr0eLocQY+7GoYfT5BR2TVf9iAKhAns5BUhmJDCKxRJz+2cdN NaZZIv6uYZjjOysEQ0GexN5CJUi/xVIQB3q4+w2Rhoqb87I3C3+Ez9MRYaxc+D6JqbGH ZebXkCsb6LnFzyK/iKv09NXdJAJM2bwwvMRXNF3v9MTx5QU1ky7zd2b2HPkrHeBwLB86 r1atAGoAq4mdnKtK2zEmyBgkIZ9XAMCMnYQq5BTCrR3WZfjlVNIcg04DMR6JufeXYd7P 8QHfGXYEbpyX7o3tFQbK6+YWsoY49KU7EjK10JBgOoutUomfzShwub/y98ySyrjGnAnL Px2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=tW9tW5EaXJMb/bg5utYbjiBQ/GFL3t2AiSM1iu6uRBM=; b=P75q9/gxG0HqUpp0zAAwIVcxmPnifulOzYCh0QEfQuXbdy3dF5kLBTV0Um6LCEH1tB IffiGsoxotw9oQmrXBLH/6Zx60Z5WYUw13D669jaS63iR826sxNmTzMjfSvtYFCHQjv0 lQPm7zTPNOd+dKqD7SJsDs+VQt5x6g1o+SMPtgKENigiAKEPXDrM2WcHTBks+u+yTgkb c618hy0OSAJx2eJTkk1nLxi75a8fg++2uWng/a7eHEjXsq8DuPMAuJMPUOlTKXgFIGLU 1HXFARL/SH/nWswd9FKBKXouzlA3dsqrBj7Hx/ORashNvi372yxwIY2w2Fh0BTe0RBoL 9whg== MIME-Version: 1.0 X-Received: by 10.152.27.170 with SMTP id u10mr11828716lag.45.1370297273767; Mon, 03 Jun 2013 15:07:53 -0700 (PDT) Received: by 10.112.76.231 with HTTP; Mon, 3 Jun 2013 15:07:53 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D4422DC2133A@EXVMBX020-12.exch020.serverdata.net> References: <007501ce56f0$67f74080$37e5c180$@noemax.com> <519CD6A1.7080708@ericsson.com> <519CE075.4000106@tavendo.de> <634914A010D0B943A035D226786325D4422DC20DAA@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D4422DC2133A@EXVMBX020-12.exch020.serverdata.net> Date: Mon, 3 Jun 2013 15:07:53 -0700 Message-ID: From: Roberto Peon To: Tobias Oberstein Content-Type: multipart/alternative; boundary=089e0160a3b83d7a6304de4732fc X-Gm-Message-State: ALoCoQnYDbsQNeTuD+7WgZAP6BF6m21vTl1RBuAFyRwDr0pqorJJcDLjegLiCepksTEeV2tY4IVPBOrSyVSzaI3pdanidY8BK4YQ+vsCXeuvGpy9chSwn+r2l15uWLpdvDkRyu3fxs3TI2YwKGqV6wpstB3ZwhlyQudgFiZR4Y/tR1bHr1hQKFfF8/iFQum7QPoWjS/H5BPn Cc: Simone Bordet , "hybi@ietf.org" Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 22:14:11 -0000 --089e0160a3b83d7a6304de4732fc Content-Type: text/plain; charset=ISO-8859-1 Noone is unbiased, but I'm a lot less biased than you'd think given my name is within the WS doc too and I was pretty active in attempting (and sadly failing) to get mux into the base WS functionality. :) Out of curiosity, and on a different topic, how large have the messages been in your applications? -=R On Mon, Jun 3, 2013 at 2:33 PM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > >imho, we're reinventing SPDY/HTTP/2, and I'd rather implement the > complexity of muxing, security, prioritization, flow-control, > liveness-checking, stream initiation, and compression, only once. > >-=R > > First, lets admit: we are both biased;) > > What about HTTP/2 over WS? > > http://tools.ietf.org/html/draft-montenegro-httpbis-speed-mobility-02 > > I prefer native WS. I do single-page web apps with app manifests. > > The attractiveness of SPDY(TM) (be it native or over WS) in this situation > is limited. Any static resources are retrieved only once anyway, and any > communication after that can be done via WS. > > - native WS is widely implemented today > - native WS has lower per-message overhead than "WS over SPDY(TM)" > - WS (now) has _payload_ compression > - liveness checking => WS pings/pongs > - security => WS masking, WS origin > > So I'd say a WS-MUX with flow-control (draft there) plus > priorization/scheduling (not there) is "the last missing piece". Lets > finish it. > > /Tobias > > > On Sat, Jun 1, 2013 at 2:55 AM, Tobias Oberstein < > tobias.oberstein@tavendo.de> wrote: > > On Mon, May 27, 2013 at 10:25 AM, Takeshi Yoshino > > wrote: > > > Isn't it in-app priority? Can't script and server address that > > > problem? If only the client knows current priority, the client can > > > tell the priority to the peer servlet using a WebSocket message. If > > > the server know priority for each position, it can just control > transmission > > speed. > > > > > > Even if we need help by the server, the servlet would call some > > > special function to tell the server about priority. > > > > > > Different from HTTP/2.0's case, we don't need to provide a special > > > field in mux protocol to pass priority, I think. > If intermediaries are no preserve a per-channel priority based scheduling, > then they might need to know the channel priority. > > > > > Sure, but then you force every application to reinvent this mechanism on > top of > > WebSocket mux. > > At that point, one could argue that application messages could have > their own > > "channel_id" in their messages, and applications can do mux themselves, > if > > they need it. > Yep, agree. > > Scheduling integrated with MUX has another advantage: > > e.g. when doing per-channel priority based scheduling the scheduling could > not only consider channel priority, but also the quota. > > A high priority channel with data outstanding to be sent but not quota to > send would otherwise block a lower priority channel with data _and_ quota. > > Another issue: implementing s.th. like priority based scheduling at app > level would might require to reinvent some kind of fragmentation at the app > level to be able to schedule according to priority (otherwise once a very > large message on a low prio channel is started to be sent, it'll block > everything else). > > One way to look at this is: > > WS fragmentation < WS multiplexing < WS scheduling | APP > > where "<" means "builds on", and everything up to "|" is provided by an WS > implementation, hence does not need to be reinvented at app level, and WS > aware infrastructure can optimize / do their thing. > > === > > It seems that HTTP/2 likely will have "request priorization" (I don't know > about "response priorization"). > > If we (in a pure WS land) don't have priorization, that's a potential > disadvantage and source of discussion. > > === > > A per-channel scheduling could work according to different policies: > > 1. Round-Robin scheduling > 2. Priority scheduling > 3. Fair Bandwidth scheduling > 4. First-Come, First-Serve scheduling > > The policy mechnism could be selected for the whole physical WS (and > communicated for intermediaries), e.g. > > Sec-WebSocket-Extensions: mux; scheduler="round-robin" > > Only with 2. there is a need to select and communicate a per-channel info > (during channel creation), e.g. > > Sec-WebSocket-Extensions: mux; scheduler="priority" > > and then > > AddChannelRequest with the 3 RSV bits (currently unassigned) containing a > priority 0-7 for the channel. > > [This does not yet answer how to re-prioritize an existing channel] > > Hence I'd like to propose to > > 1) add an (optional) extension parameter "scheduler" as above > 2) use the 3 currently unassigned RSV bits in AddChannelRequest for > channel prio (when scheduler="priority") > 3) define appropriate MUST semantics (scheduling should not follow > advisory semantics .. apps should be able to rely on it) > 4) probably add a new PriorityControl message to change prio of existing > channels > > === > > Above is a kind of per-channel scheduling. One might argue that it lacks > in at least 2 respects: > > - an app is not able to control e.g. prio on a per-message basis > - there are no ordering guarantees between messages on different channels > > Example: > An app creates an empty file on some cloud service. Subsequently the app > wants to append to that file. > > The first could be a high-prio message, the latter messages low-prio. > > The app does not care whether those messages travel over 1 physical, or > multiple different logical WS channels. > > However, the app does care that the first "create file" message arrives > before any subsequent "append to file" messages. > > So a different design involving per-message prios on a single WS channel > (physical or logical) might allow higher-prio messages to overtake lower > prio-messages, but not otherwise round. > > /Tobias > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --089e0160a3b83d7a6304de4732fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Noone is unbiased, but I'm a lot less biased than= you'd think given my name is within the WS doc too and I was pretty ac= tive in attempting (and sadly failing) to get mux into the base WS function= ality. :)

Out of curiosity, and on a different topic, = how large have the messages been in your applications?
-=3D= R


On Mon, Jun 3, 2013 at 2:33 PM, Tobias Oberstein <tobias.oberste= in@tavendo.de> wrote:
>imho, we're reinventing SPDY/HTTP/2, and I'd = rather implement the complexity of muxing, security, prioritization, flow-c= ontrol, liveness-checking, stream initiation, and=A0compression,=A0only=A0o= nce.
>-=3DR

First, lets admit: we are both biased;)

What about HTTP/2 over WS?

http://tools.ietf.org/html/draft-montenegro-httpbi= s-speed-mobility-02

I prefer native WS. I do single-page web apps with app manifests.

The attractiveness of SPDY(TM) (be it native or over WS) in this situation = is limited. Any static resources are retrieved only once anyway, and any co= mmunication after that can be done via WS.

- native WS is widely implemented today
- native WS has lower per-message overhead than "WS over SPDY(TM)"= ;
- WS (now) has _payload_ compression
- liveness checking =3D> WS pings/pongs
- security =3D> WS masking, WS origin

So I'd say a WS-MUX with flow-control (draft there) plus priorization/s= cheduling (not there) is "the last missing piece". Lets finish it= .

/Tobias


On Sat, Jun 1, 2013 at 2:55 AM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:
> On Mon, May 27, 2013 at 10:25 AM, Takeshi Yoshino <tyoshino@google.com>
> wrote:
> > Isn't it in-app priority? Can't script and server address= that
> > problem? If only the client knows current priority, the client ca= n
> > tell the priority to the peer servlet using a WebSocket message. = If
> > the server know priority for each position, it can just control t= ransmission
> speed.
> >
> > Even if we need help by the server, the servlet would call some > > special function to tell the server about priority.
> >
> > Different from HTTP/2.0's case, we don't need to provide = a special
> > field in mux protocol to pass priority, I think.
If intermediaries are no preserve a per-channel priority based scheduling, = then they might need to know the channel priority.

>
> Sure, but then you force every application to reinvent this mechanism = on top of
> WebSocket mux.
> At that point, one could argue that application messages could have th= eir own
> "channel_id" in their messages, and applications can do mux = themselves, if
> they need it.
Yep, agree.

Scheduling integrated with MUX has another advantage:

e.g. when doing per-channel priority based scheduling the scheduling could = not only consider channel priority, but also the quota.

A high priority channel with data outstanding to be sent but not quota to s= end would otherwise block a lower priority channel with data _and_ quota.
Another issue: implementing s.th<= /a>. like priority based scheduling at app level would might require to rei= nvent some kind of fragmentation at the app level to be able to schedule ac= cording to priority (otherwise once a very large message on a low prio chan= nel is started to be sent, it'll block everything else).

One way to look at this is:

WS fragmentation < WS multiplexing < WS scheduling | APP

where "<" means "builds on", and everything up to &q= uot;|" is provided by an WS implementation, hence does not need to be = reinvented at app level, and WS aware infrastructure can optimize / do thei= r thing.

=3D=3D=3D

It seems that HTTP/2 likely will have "request priorization" (I d= on't know about "response priorization").

If we (in a pure WS land) don't have priorization, that's a potenti= al disadvantage and source of discussion.

=3D=3D=3D

A per-channel scheduling could work according to different policies:

1. Round-Robin scheduling
2. Priority scheduling
3. Fair Bandwidth scheduling
4. First-Come, First-Serve scheduling

The policy mechnism could be selected for the whole physical WS (and commun= icated for intermediaries), e.g.

Sec-WebSocket-Extensions: mux; scheduler=3D"round-robin"

Only with 2. there is a need to select and communicate a per-channel info (= during channel creation), e.g.

Sec-WebSocket-Extensions: mux; scheduler=3D"priority"

and then

AddChannelRequest with the 3 RSV bits (currently unassigned) containing a p= riority 0-7 for the channel.

[This does not yet answer how to re-prioritize an existing channel]

Hence I'd like to propose to

1) add an (optional) extension parameter "scheduler" as above
2) use the 3 currently unassigned RSV bits in AddChannelRequest for channel= prio (when scheduler=3D"priority")
3) define appropriate MUST semantics (scheduling should not follow advisory= semantics .. apps should be able to rely on it)
4) probably add a new PriorityControl message to change prio of existing ch= annels

=3D=3D=3D

Above is a kind of per-channel scheduling. One might argue that it lacks in= at least 2 respects:

- an app is not able to control e.g. prio on a per-message basis
- there are no ordering guarantees between messages on different channels
Example:
An app creates an empty file on some cloud service. Subsequently the app wa= nts to append to that file.

The first could be a high-prio message, the latter messages low-prio.

The app does not care whether those messages travel over 1 physical, or mul= tiple different logical WS channels.

However, the app does care that the first "create file" message a= rrives before any subsequent "append to file" messages.

So a different design involving per-message prios on a single WS channel (p= hysical or logical) might allow higher-prio messages to overtake lower prio= -messages, but not otherwise round.

/Tobias
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi


--089e0160a3b83d7a6304de4732fc-- From tobias.oberstein@tavendo.de Mon Jun 3 22:29:43 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1714111E8104 for ; Mon, 3 Jun 2013 22:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ll23TRga7dGn for ; Mon, 3 Jun 2013 22:29:28 -0700 (PDT) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id 14B9121E8056 for ; Mon, 3 Jun 2013 21:41:13 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.90]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Mon, 3 Jun 2013 21:41:12 -0700 From: Tobias Oberstein To: Roberto Peon Date: Mon, 3 Jun 2013 21:41:08 -0700 Thread-Topic: [hybi] Call for interest: multiplexing dedicated for WebSocket Thread-Index: Ac5gps9A4RTK9OsfRVSmJA9gpDTNtAANCJ7Q Message-ID: <634914A010D0B943A035D226786325D4422DC213B1@EXVMBX020-12.exch020.serverdata.net> References: <007501ce56f0$67f74080$37e5c180$@noemax.com> <519CD6A1.7080708@ericsson.com> <519CE075.4000106@tavendo.de> <634914A010D0B943A035D226786325D4422DC20DAA@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D4422DC2133A@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simone Bordet , "hybi@ietf.org" Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 05:29:43 -0000 > Noone is unbiased, but I'm a lot less biased than you'd think given my na= me is within the WS doc too and I was pretty active in attempting (and sadl= y failing) to get mux into the base WS functionality. :) I think the extensibility built into WS (extensions and subprotocols) is a = strength, and having a relatively simple base functionality is good. I don'= t want to implement MUX on an embedded device like Arduino, and I likely do= n't need it there anyway. Also: having implemented an automated WS protocol= test suite I can say that getting good coverage of the "relatively simple = base functionality" already requires a lot. Even the >300 test cases we hav= e today don't cover 100%. I guess writing automated tests for WS-MUX / flow= -control / scheduling might be a challenge;) >Out of curiosity, and on a different topic, how large have the messages be= en in your applications? I haven't don't systematic measurements / stats, but - today - probably bet= ween 20 - 20k of JSON payload with a fair amount of URIs sprinkled in. Now that we've implemented "permessage-deflate", I'll take the chance and a= dd some traffic stats tracking .. /Tobias From tyoshino@google.com Tue Jun 4 03:07:32 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DD221F9BEE for ; Tue, 4 Jun 2013 03:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5QpdvOyCs5O for ; Tue, 4 Jun 2013 03:07:20 -0700 (PDT) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id A549421F9B79 for ; Tue, 4 Jun 2013 02:04:40 -0700 (PDT) Received: by mail-ea0-f177.google.com with SMTP id j14so2071080eak.8 for ; Tue, 04 Jun 2013 02:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=F/jfU/mAIw15lP+VhA9idn40OVVbhn3ZFPxNeYROKAo=; b=LNFsetyQ+WjDlS7xcF5vtjcqfFEktwnqJqXcLzy+dcEQqXwBr5kmIJhVuvPp6S7tQ/ f7BflrxKZjC/Q9tV/GIfN1fL/EY/vrQ6LLjP2XKN3oOt8fxq3EXrihSSycnHZl0Rn02n HexExzlQUgWSEAuoplXs9u5zzUGY5SkgnXBUSxpusKRiXv370mxwoGTIMChewlq5A45L 2BeGojf0pNcugzsviUlew+9UALPWkvnquEEVFXKiMAYw4yWNUXbZKkKWtEbps3GM1gkO f7rJtVoawnobJ7v4Z3kwby7Fve4gV0GauFOLVPvxSKGtAzWmjOLh2pzN7DVgI2V7tQqu +MNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=F/jfU/mAIw15lP+VhA9idn40OVVbhn3ZFPxNeYROKAo=; b=mw+6KWiSnfBpPnsbZdgHJss5Jg9EExUNNHpPV/xdEobROHyOhXBKH2kbybkSL6Df1R y9Cn6djm/JRGgWwPruAQYzqyf6mkG50REUrEGVB81OPTAnNVXrH+qneW993xzn+yQ0dK UgstSA3YQT5dFhGLXG7jS/0cPkvq7tRluoi7rjq2nMYejit8btRXsdcxd5GMq55S2RNh gCfEtz/cReyqPl0ft/lQq9pHwgcvFo7k20wAudP67y7Ttm91yN1k9M35yj20fK6JqG5H Su5wiog5UU34G9A3tupZ+i1bIFp9OUlT6n0lfEvO/QH6PPRNHvU5ekTI1CA1pbTdfR8w Hp0g== X-Received: by 10.14.225.66 with SMTP id y42mr40910eep.129.1370336674824; Tue, 04 Jun 2013 02:04:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.86.67 with HTTP; Tue, 4 Jun 2013 02:04:13 -0700 (PDT) In-Reply-To: <51A737E6.2090707@tavendo.de> References: <007501ce56f0$67f74080$37e5c180$@noemax.com> <519CD6A1.7080708@ericsson.com> <519CE075.4000106@tavendo.de> <519D02E7.6040009@tavendo.de> <519D2E2D.4080809@tavendo.de> <634914A010D0B943A035D226786325D4422C3DA775@EXVMBX020-12.exch020.serverdata.net> <51A737E6.2090707@tavendo.de> From: Takeshi Yoshino Date: Tue, 4 Jun 2013 18:04:13 +0900 Message-ID: To: Tobias Oberstein Content-Type: multipart/alternative; boundary=047d7b670997ba0e0204de505ed5 X-Gm-Message-State: ALoCoQkiTkJT5qu4UcjDxqLMo2kQZ4RxRHTGoagKva5dtzs1bw8HcbvLVlzcDQr8HW/fVV4kG3mUV8H9jgYKfpSKZosihsfP2ojeZlZcBXK08CLLnY7L2uihqP42teQJ+223iE0xgJk+6YWrqkcuLm1FT7yHoGMsMFN7W1wSoRxIJAqYz4jYh51wysqvV81J8T8i7KlEwxoG Cc: "hybi@ietf.org" Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 10:07:32 -0000 --047d7b670997ba0e0204de505ed5 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 30, 2013 at 8:28 PM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > b) the endpoints need to cut mass data into smaller chunks to reserve >> > slots for inserting chatty traffic. e.g. if acceptable delay for chatty >> traffic is x ms, set the maximum send unit of mass traffic to (current >> through put) * x. >> >> To allow one to control the peer's message scheduling, both per-socket >> buffer size and ws-mux flow control are insufficient, I think. Needs to >> exchange ToS info. >> > > I now can see that flow control and priorization are somewhat orthogonal > issues. > > Priorization and ToS is not goal of WS-MUX at all? > > It's again, as I said in reply to Simone's comment above, it depends on frequency and usage if we should have WebSocket protocol level ToS or should just do it in JS. ... >> Traffic for various services would be multiplexed into one TCP. We wanna >> demultiplex it and forward to designated backends. This means that >> there're again lots of TCP connections between LB-backends, but we can >> make any optimization there as we want. >> > > I see. So the load-balancer needs to be a layer-7 one, and not only be > WS-MUX enabled, but also app/service aware? Something like this: > > E.g. user has 2 tabs open which (logically) connect to > > wss://google.com/gmail > wss://google.com/gplus > > Both would be transported over 1 physical WS (via WS-MUX). > > The LB would demux traffic for logical channel > > wss://google.com/gmail > > to backend nodes of cluster "GMAIL", while it would demux traffic for > > wss://google.com/gplus > > to backend nodes of cluster "GPLUS"? > > Yes. > > >> >Basically multiplexing should be done as close to network as >> possible. If it's done in application layer, for example when >> compression is used, such a load balancer need to decode the >> compression to see the >multiplexing information. That doesn't make >> them happy. >> >> This seems to assume that >> >> - either the LB is done above layer 4 and/or >> - the logical WS connections contained in the physical WS would need >> to be balanced to _different_ backend nodes. >> >> >> Yes. Sorry that we haven't told the story in our mind in detail. >> > > I think it might be helpful to add text to the MUX draft that describe the > use cases WS-MUX addresses and how it improves thing over alternatives. > Motivation is always good and helps by providing context and examples. OK. --047d7b670997ba0e0204de505ed5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 30, 2013 at 8:28 PM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:
b) the endpoints need to cut mass data into smaller chunks to reserve
slots for inserting chatty traffic. e.g. if acceptable delay for chatty
traffic is x ms, set the maximum send unit of mass traffic to (current
through put) * x.

To allow one to control the peer's message scheduling, both per-socket<= br> buffer size and ws-mux flow control are insufficient, I think. Needs to
exchange ToS info.

I now can see that flow control and priorization are somewhat orthogonal is= sues.

Priorization and ToS is not goal of WS-MUX at all?


It's again, as I said in repl= y to Simone's comment above, it depends on frequency and usage if we sh= ould have WebSocket protocol level ToS or should just do it in JS.

...


Traffic for various services would be multiplexed into one TCP. We wanna demultiplex it and forward to designated backends. This means that
there're again lots of TCP connections between LB-backends, but we can<= br> make any optimization there as we want.

I see. So the load-balancer needs to be a layer-7 one, and not only be WS-M= UX enabled, but also app/service aware? Something like this:

E.g. user has 2 tabs open which (logically) connect to

wss://google.com/gmai= l
wss://google.com/gplu= s

Both would be transported over 1 physical WS (via WS-MUX).

The LB would demux traffic for logical channel

wss://google.com/gmai= l

to backend nodes of cluster "GMAIL", while it would demux traffic= for

wss://google.com/gplu= s

to backend nodes of cluster "GPLUS"?

<= /blockquote>

Yes.
=A0


=A0 =A0 =A0>Basically multiplexing should be done as close to network as=
=A0 =A0 possible. If it's done in application layer, for example when =A0 =A0 compression is used, such a load balancer need to decode the
=A0 =A0 compression to see the >multiplexing information. That doesn'= ;t make
=A0 =A0 them happy.

=A0 =A0 This seems to assume that

=A0 =A0 - either the LB is done above layer 4 and/or
=A0 =A0 - the logical WS connections contained in the physical WS would nee= d
=A0 =A0 to be balanced to _different_ backend nodes.


Yes. Sorry that we haven't told the story in our mind in detail.

I think it might be helpful to add text to the MUX draft that describe the = use cases WS-MUX addresses and how it improves thing over alternatives. Mot= ivation is always good and helps by providing context and examples.

OK.
=A0
--047d7b670997ba0e0204de505ed5-- From tyoshino@google.com Tue Jun 4 03:12:48 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C88321F9BFE for ; Tue, 4 Jun 2013 03:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhQshP8JdACc for ; Tue, 4 Jun 2013 03:12:38 -0700 (PDT) Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1357C21F9C09 for ; Tue, 4 Jun 2013 02:08:38 -0700 (PDT) Received: by mail-ea0-f179.google.com with SMTP id z16so4347788ead.10 for ; Tue, 04 Jun 2013 02:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dNMSajBbl5lPrRAnO06YKbSTwqsBCwaZgAlH9Eu2Dl4=; b=KAFQxaVTn1aLpuZxZ17it8MFQFceq7RtM4hojo8v0Kf/fa+0H6hXnyXimgSWLDWpxA lDOFC84zrhwkb6jjS7uh6u+I6z/oOJaWD54yKmv9WT2jlP4bh2NhdQGI7Cc2bGveOxKb DduJaPHApsypDvBtAUNEivETIvLgiiMWSuwz+Y8Mo85R31IDm5G7N8LkxImUyqH0M7Cq mrrcqVuRvISuBNlK9nuOzfGvtg6Xr4Hrw0jhbeqcmVtkU6d8Oa0PHgS5VQSKZkHtxnrM n0RpSuKicLIRil9WGmlvdn8+VqAsZh0JFdZa+Pr0g9917/K4b19vqupF9w6UCRRRe1Sg 1mbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=dNMSajBbl5lPrRAnO06YKbSTwqsBCwaZgAlH9Eu2Dl4=; b=VxJXXuakxGREmVlAz6d0IsZGqG5RtAAb2lJqnlfpUarqsAkQMqmfvx2p3hv68lbmQb +XN7PX0tnDQkfSMxsYOnUhscgYIs9z1NW7BcfU9SJdetVwYX1U/uxGJuKozzid8eU1tB 7S7nLM4i1GaRr52TUEDGAI6Vrm3V9KQb1coC4Q6M3Fmu51F0wIMZTicXdS4A92z4cz2v 0dGElTG6QfNQwJvJgxA+9zZY8zDqs78qFCH3IgaHO60vt4rap9ziRZyA5R+qStMsA3kM gV2tYkPCRwsEZZdstvmW5oykEU/h62R94ilZN1JN1Gbf1nIvQZ/sOFmQJ9mNyyrEA3Hp el4g== X-Received: by 10.14.225.66 with SMTP id y42mr60435eep.129.1370336917996; Tue, 04 Jun 2013 02:08:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.86.67 with HTTP; Tue, 4 Jun 2013 02:08:16 -0700 (PDT) In-Reply-To: References: <634914A010D0B943A035D226786325D4422C319646@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D4422C3DA774@EXVMBX020-12.exch020.serverdata.net> <51A70DF9.5010601@tavendo.de> <51A85EF9.3010907@tavendo.de> From: Takeshi Yoshino Date: Tue, 4 Jun 2013 18:08:16 +0900 Message-ID: To: Roberto Peon Content-Type: multipart/alternative; boundary=047d7b67099738798b04de506ddb X-Gm-Message-State: ALoCoQmw7GpirS0f9kDzAvKbFI/lO0YLY0sD+4fnwVDfsoe30R5fWYNsGXbbic0vAmrNP6SFEGxagTPl8FiL90cZnF65Cov097k+cidBZwwIFHZNaDpeLwiH4Hc2CdygiXLXyXoIuL5EQpV7/kFU8MODwFJ9sz3RXk9qko52KHiDPzApCYDyBRom/IUCE28UJT1mCGqs/vay Cc: "hybi@ietf.org" Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 10:12:48 -0000 --047d7b67099738798b04de506ddb Content-Type: text/plain; charset=ISO-8859-1 Considering CRIME attack, we have a note in the current multiplexing spec saying that history based compression should not be used over chunks containing handshake and ones containing script generated data keeping compression context. E.g. Sec-WebSocket-Extensions: permessage-deflate, mux is allowed but Sec-WebSocket-Extensions: mux, permessage-deflate is prohibited. I listed CRIME just as an example of security consideration around multiplexing. For now, it's already addressed in the mux spec. On Tue, Jun 4, 2013 at 3:12 AM, Roberto Peon wrote: > Well, more precisely, the compression context must be shared between > material sourced by the attacker and also for the purpose of using the > site, and the context must be probe-able in some reasonable amount of time. > A gzip context which was reused between messages would be a no-no, for > instance. Another compression context (which makes probing difficult) might > be acceptable. > > -=R > > > On Fri, May 31, 2013 at 1:27 AM, Tobias Oberstein < > tobias.oberstein@tavendo.de> wrote: > >> The way CRIME works is to have a 3rd party include links to the >>> site-to-attack. Thus it doesn't matter if the schemes are http, https, >>> ws, wss, whatever. >>> >> >> Does above refer to the general requirement for CRIME: the attacker must >> be able to inject data into the source material before it is compressed and >> then encrypted? >> >> If so, how would that be possible with WebSocket and the proposed >> WebSocket per-message compression? >> >> >> random thoughts: >> >> a) >> permessage-deflate only compresses WS data messages, not control frames. >> >> So the attacker would need to inject data into the app-level payload. >> >> The only way to send app-level payload in browsers if via the JavaScript >> WebSocket API (socket.send()). >> >> So the attacker would need to somehow modify this JS code. However, the >> origin of the JS running is (at least with browsers) sent during the WS >> opening handshake as a HTTP header, and a WS server can check and decline >> an incoming connection. >> >> b) >> With WS HTTP headers are only sent _once_: during the initial WS opening >> handshake, and by the client to the server. >> >> CRIME requires repeated injection of attacker data. >> >> More so: permessage-deflate does not touch the opening handshake, which >> remains uncompressed. >> >> Side Q: Do browsers reuse an established TLS/TCP connection for multiple >> WS connections? >> >> /Tobias >> >> > --047d7b67099738798b04de506ddb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Considering CRIME attack, we have a note in the current mu= ltiplexing spec saying that history based compression should not be used ov= er chunks containing handshake and ones containing script generated data ke= eping compression context.

E.g.
Sec-WebSocket-Extensions: permess= age-deflate, mux
is allowed but
Sec-WebSock= et-Extensions: mux, permessage-deflate
is prohibited.

I listed CRIME just as an example of securi= ty consideration around multiplexing. For now, it's already addressed i= n the mux spec.


On Tue, Jun 4, 2013 at 3:12 AM, Roberto Peon <fenix@google.com> wrote:
Well, more precisely, the compression context must be shar= ed between material sourced by the attacker and also for the purpose of usi= ng the site, and the context must be probe-able in some reasonable amount o= f time.
A gzip context which was reused between messages would be a no-no, for inst= ance. Another compression context (which makes probing difficult) might be = acceptable.

-=3DR


On Fri, May 31, 2013 at 1:27 AM, Tobias = Oberstein <tobias.oberstein@tavendo.de> wrote:
=
The way CRIME works is to have a 3rd party include links to the
site-to-attack. Thus it doesn't matter if the schemes are http, https,<= br> ws, wss, whatever.

Does above refer to the general requirement for CRIME: the attacker must be= able to inject data into the source material before it is compressed and t= hen encrypted?

If so, how would that be possible with WebSocket and the proposed WebSocket= per-message compression?


random thoughts:

a)
permessage-deflate only compresses WS data messages, not control frames.
So the attacker would need to inject data into the app-level payload.

The only way to send app-level payload in browsers if via the JavaScript We= bSocket API (socket.send()).

So the attacker would need to somehow modify this JS code. However, the ori= gin of the JS running is (at least with browsers) sent during the WS openin= g handshake as a HTTP header, and a WS server can check and decline an inco= ming connection.

b)
With WS HTTP headers are only sent _once_: during the initial WS opening ha= ndshake, and by the client to the server.

CRIME requires repeated injection of attacker data.

More so: permessage-deflate does not touch the opening handshake, which rem= ains uncompressed.

Side Q: Do browsers reuse an established TLS/TCP connection for multiple WS= connections?

/Tobias



--047d7b67099738798b04de506ddb-- From simone.bordet@gmail.com Tue Jun 4 03:27:34 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62BB21F9B2B for ; Tue, 4 Jun 2013 03:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovtB4R4aKWBn for ; Tue, 4 Jun 2013 03:27:19 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3216821F84B5 for ; Tue, 4 Jun 2013 02:21:29 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id v10so1932867pde.18 for ; Tue, 04 Jun 2013 02:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tyuNnyPx2DVhp/AcyZsLWhACuH6KFwZixw0ENU++TMc=; b=d9vRfMCC6PFHHkuHrVNjttuSTkJ0m7QnSAjR7Wzz09SVCK04fShBGVhaUY+2inwSDk Tl03Tng4us/ZiQbWFaW6CLWWbMCu5em+9VVjkYT21NqjkjlAErXP66KPOPEcVlSsjBJM 8/XYbqFPNsbq5B/jHKhc9U/IjBBhySToGvkn9N/CZIY7Aj/gDEzmvo5HCVf4qn100cDn TiX33Bkf75B1s64ICvPRUQ2fXlw0HW09+qvMbgxpPiaflo2iCGOWw8H46RTvoQhyTIhF NaeTyVhblSrAvwRnkCpH+DumngmyHReyK2whPM9dFqizDSmU4KNbdRJDnAin5gkQBhRq UUBA== MIME-Version: 1.0 X-Received: by 10.68.219.70 with SMTP id pm6mr27458398pbc.154.1370337675452; Tue, 04 Jun 2013 02:21:15 -0700 (PDT) Sender: simone.bordet@gmail.com Received: by 10.68.209.131 with HTTP; Tue, 4 Jun 2013 02:21:15 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D4422DC2133A@EXVMBX020-12.exch020.serverdata.net> References: <007501ce56f0$67f74080$37e5c180$@noemax.com> <519CD6A1.7080708@ericsson.com> <519CE075.4000106@tavendo.de> <634914A010D0B943A035D226786325D4422DC20DAA@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D4422DC2133A@EXVMBX020-12.exch020.serverdata.net> Date: Tue, 4 Jun 2013 11:21:15 +0200 X-Google-Sender-Auth: cbbnKBlrufhZ5Z0vP4l52B79n9k Message-ID: From: Simone Bordet To: Tobias Oberstein Content-Type: text/plain; charset=UTF-8 Cc: "hybi@ietf.org" Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 10:27:34 -0000 Hi, On Mon, Jun 3, 2013 at 11:33 PM, Tobias Oberstein wrote: >>imho, we're reinventing SPDY/HTTP/2, and I'd rather implement the complexity of muxing, security, prioritization, flow-control, liveness-checking, stream initiation, and compression, only once. FWIW, I am with Roberto here. > First, lets admit: we are both biased;) > > What about HTTP/2 over WS? > > http://tools.ietf.org/html/draft-montenegro-httpbis-speed-mobility-02 > > I prefer native WS. I do single-page web apps with app manifests. > > The attractiveness of SPDY(TM) (be it native or over WS) in this situation is limited. Any static resources are retrieved only once anyway, and any communication after that can be done via WS. > > - native WS is widely implemented today > - native WS has lower per-message overhead than "WS over SPDY(TM)" > - WS (now) has _payload_ compression > - liveness checking => WS pings/pongs > - security => WS masking, WS origin Sure. But I fail to see why you need MUX for your use case. One duplex connection seems enough to me. > So I'd say a WS-MUX with flow-control (draft there) plus priorization/scheduling (not there) is "the last missing piece". Lets finish it. The problem I see is that the 2 features you mention here are quite complicated to specify and implement correctly, i.e. we duplicate the larger effort undertaken by HTTP/2. -- Simone Bordet ---- http://cometd.org http://webtide.com http://intalio.com Developer advice, training, services and support from the Jetty & CometD experts. Intalio, the modern way to build business applications. From tyoshino@google.com Tue Jun 4 03:36:05 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC6D21F9678 for ; Tue, 4 Jun 2013 03:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.527 X-Spam-Level: X-Spam-Status: No, score=-1.527 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CChcLUW1nn7S for ; Tue, 4 Jun 2013 03:35:50 -0700 (PDT) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id F148121F9A77 for ; Tue, 4 Jun 2013 02:31:36 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id q10so402622eaj.31 for ; Tue, 04 Jun 2013 02:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PCsMa/y7zWV0r7isz2e0tWW6f3yiW/XCkCgr9zyQsEk=; b=EvjOb8owd3Opg3WOU4/f3He24XPKwYFrZfMC+chYFdmMtZVVcB8PsmDkdcLadU5N/B HbBpVFeydmZK9XCFb+6lkY7lAMk66/OfTxZZ0nxvD1ieJABAsq76GJgYjs5yrCCj7VUC fRpPHHz7TyiFLMjjj2rEzmssIFRKd2nZBBYAN686LR9AqOknuIHN5Q8NM8EpB44x/ZKW mi3In4oiOJFAUYJOzfVHWpZzlxMp8CRRLajgJ1iYZKi7u2WnbB6upj7c0cR/6gqlD/Td 6G95ydLdM/70Y9Wh39zjJWVHv0EHUe3cu13HCWiyn914dVSVA/XQVwJR/LthxZS073Df 5KyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=PCsMa/y7zWV0r7isz2e0tWW6f3yiW/XCkCgr9zyQsEk=; b=C+BCDL0+8Fl3s+tqfj0BljThJqZtZ3ljZwUlgrIT299LU8G6HCWp27zNgO6AkxYwHP XLyucEMCn4X45SZZ4avFXOb5Xtdh6jSRVMWjmq/ZrX8diPDjbvDc2jGr19vL8cjSwuQk 18dVwyUAV4Z66CHQwIp8D3R8U9Nmf00SPQcXhOjXWRLrif836QHZQnf/jsl3VLDof0BQ F5/9RUAiuPSS/+hJfbe2Y/6JdwshqmBFKZp94xLSi+SyDPEenEWm3cgnrZURI0Kzm7Xn BYJy20bRcaY8WsEYtgD5foeu4nBM4vj6vdzDF4zw3vNVQZ1ZejF6byiXuApov76YCe6c zA+A== X-Received: by 10.15.32.142 with SMTP id a14mr25453427eev.152.1370338295737; Tue, 04 Jun 2013 02:31:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.86.67 with HTTP; Tue, 4 Jun 2013 02:31:15 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D4422DC20DAA@EXVMBX020-12.exch020.serverdata.net> References: <007501ce56f0$67f74080$37e5c180$@noemax.com> <519CD6A1.7080708@ericsson.com> <519CE075.4000106@tavendo.de> <634914A010D0B943A035D226786325D4422DC20DAA@EXVMBX020-12.exch020.serverdata.net> From: Takeshi Yoshino Date: Tue, 4 Jun 2013 18:31:15 +0900 Message-ID: To: Tobias Oberstein Content-Type: multipart/alternative; boundary=089e0163521058917804de50bf9b X-Gm-Message-State: ALoCoQlUcB1L/VSwdXg2jKe9GWQm+8QEyNh3TMzlu6DrLPof0RudTjAXA/+IRi8kjfbs9GKer55TWD05ruA6A9x/qd4qIB2RrhXuYIz1q9IrcDfIMDccsP3P5fTEs4CkQNM2E3Rv6iBC+T5pFzMtf/8m60Lk+XosCb7RHKHTI3flZY7teTyijL1VKLOWWvm+ZRcSXke96swa Cc: Simone Bordet , "hybi@ietf.org" Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 10:36:05 -0000 --089e0163521058917804de50bf9b Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 1, 2013 at 6:55 PM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > If intermediaries are no preserve a per-channel priority based scheduling, > then they might need to know the channel priority. > Good point. > > Sure, but then you force every application to reinvent this mechanism on > top of > > WebSocket mux. > > At that point, one could argue that application messages could have > their own > > "channel_id" in their messages, and applications can do mux themselves, > if > > they need it. > > Yep, agree. > > Scheduling integrated with MUX has another advantage: > > e.g. when doing per-channel priority based scheduling the scheduling could > not only consider channel priority, but also the quota. > > A high priority channel with data outstanding to be sent but not quota to > send would otherwise block a lower priority channel with data _and_ quota. > Yes, if the algorithm is designed to do so. > Another issue: implementing s.th. like priority based scheduling at app > level would might require to reinvent some kind of fragmentation at the app > level to be able to schedule according to priority (otherwise once a very > large message on a low prio channel is started to be sent, it'll block > everything else). > > Yes. The app must be able to send a fragment. But it's a matter of WebSocket API. A server can do that, but if a client want to, it can't for now due to limitation of the API. Hence, it needs application level fragmentation. > It seems that HTTP/2 likely will have "request priorization" (I don't know > about "response priorization"). > > If we (in a pure WS land) don't have priorization, that's a potential > disadvantage and source of discussion. > > Yes > === > > A per-channel scheduling could work according to different policies: > > 1. Round-Robin scheduling > 2. Priority scheduling > 3. Fair Bandwidth scheduling > 4. First-Come, First-Serve scheduling > > The policy mechnism could be selected for the whole physical WS (and > communicated for intermediaries), e.g. > > Sec-WebSocket-Extensions: mux; scheduler="round-robin" > > Only with 2. there is a need to select and communicate a per-channel info > (during channel creation), e.g. > > Sec-WebSocket-Extensions: mux; scheduler="priority" > > and then > > AddChannelRequest with the 3 RSV bits (currently unassigned) containing a > priority 0-7 for the channel. > > [This does not yet answer how to re-prioritize an existing channel] > > Hence I'd like to propose to > > 1) add an (optional) extension parameter "scheduler" as above > 2) use the 3 currently unassigned RSV bits in AddChannelRequest for > channel prio (when scheduler="priority") > 3) define appropriate MUST semantics (scheduling should not follow > advisory semantics .. apps should be able to rely on it) > 4) probably add a new PriorityControl message to change prio of existing > channels > > === > WebSocket API is not ready for such a sophisticated ToS mechanism. > Above is a kind of per-channel scheduling. One might argue that it lacks > in at least 2 respects: > > - an app is not able to control e.g. prio on a per-message basis > - there are no ordering guarantees between messages on different channels > I think it's ok. > > Example: > An app creates an empty file on some cloud service. Subsequently the app > wants to append to that file. > > The first could be a high-prio message, the latter messages low-prio. > > The app does not care whether those messages travel over 1 physical, or > multiple different logical WS channels. > > However, the app does care that the first "create file" message arrives > before any subsequent "append to file" messages. > > So a different design involving per-message prios on a single WS channel > (physical or logical) might allow higher-prio messages to overtake lower > prio-messages, but not otherwise round. > I see. --089e0163521058917804de50bf9b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 1, 2013 at 6:55 PM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:
If intermediaries are no preserve a per-channel priority based sc= heduling, then they might need to know the channel priority.

Good point.
=A0
> Sure, but then you force every application to reinvent this mecha= nism on top of
> WebSocket mux.
> At that point, one could argue that application messages could have th= eir own
> "channel_id" in their messages, and applications can do mux = themselves, if
> they need it.

Yep, agree.

Scheduling integrated with MUX has another advantage:

e.g. when doing per-channel priority based scheduling the scheduling could = not only consider channel priority, but also the quota.

A high priority channel with data outstanding to be sent but not quota to s= end would otherwise block a lower priority channel with data _and_ quota.

Yes, if the algorithm is designed to do = so.
=A0
Another issue: implementing s.th. like priority based scheduling at app l= evel would might require to reinvent some kind of fragmentation at the app = level to be able to schedule according to priority (otherwise once a very l= arge message on a low prio channel is started to be sent, it'll block e= verything else).


Yes. The app must be able to send a fr= agment.

But it's a matter of WebSocket A= PI. A server can do that, but if a client want to, it can't for now due= to limitation of the API. Hence, it needs application level fragmentation.=
=A0
It seems that HTTP/2 likely will have "request priori= zation" (I don't know about "response priorization").
If we (in a pure WS land) don't have priorization, that's a potenti= al disadvantage and source of discussion.


Yes
=A0
=3D=3D=3D

A per-channel scheduling could work according to different policies:

1. Round-Robin scheduling
2. Priority scheduling
3. Fair Bandwidth scheduling
4. First-Come, First-Serve scheduling

The policy mechnism could be selected for the whole physical WS (and commun= icated for intermediaries), e.g.

Sec-WebSocket-Extensions: mux; scheduler=3D"round-robin"

Only with 2. there is a need to select and communicate a per-channel info (= during channel creation), e.g.

Sec-WebSocket-Extensions: mux; scheduler=3D"priority"

and then

AddChannelRequest with the 3 RSV bits (currently unassigned) containing a p= riority 0-7 for the channel.

[This does not yet answer how to re-prioritize an existing channel]

Hence I'd like to propose to

1) add an (optional) extension parameter "scheduler" as above
2) use the 3 currently unassigned RSV bits in AddChannelRequest for channel= prio (when scheduler=3D"priority")
3) define appropriate MUST semantics (scheduling should not follow advisory= semantics .. apps should be able to rely on it)
4) probably add a new PriorityControl message to change prio of existing ch= annels

=3D=3D=3D

WebSocket API is not re= ady for such a sophisticated ToS mechanism.
=A0
Above is a kind of per-channel scheduling. One might argue that it lacks in= at least 2 respects:

- an app is not able to control e.g. prio on a per-message basis
- there are no ordering guarantees between messages on different channels
=A0
I think it's ok.
=A0

Example:
An app creates an empty file on some cloud service. Subsequently the app wa= nts to append to that file.

The first could be a high-prio message, the latter messages low-prio.

The app does not care whether those messages travel over 1 physical, or mul= tiple different logical WS channels.

However, the app does care that the first "create file" message a= rrives before any subsequent "append to file" messages.

So a different design involving per-message prios on a single WS channel (p= hysical or logical) might allow higher-prio messages to overtake lower prio= -messages, but not otherwise round.

I see.
=A0
--089e0163521058917804de50bf9b-- From tobias.oberstein@tavendo.de Tue Jun 4 03:38:31 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2795E21F9BC3 for ; Tue, 4 Jun 2013 03:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2iAo6OGk1iq for ; Tue, 4 Jun 2013 03:38:17 -0700 (PDT) Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7794721F9C5F for ; Tue, 4 Jun 2013 02:33:45 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.90]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Tue, 4 Jun 2013 02:33:44 -0700 From: Tobias Oberstein To: Simone Bordet Date: Tue, 4 Jun 2013 02:33:42 -0700 Thread-Topic: [hybi] Call for interest: multiplexing dedicated for WebSocket Thread-Index: Ac5hBN4xQ9d7jZxERJSJyt6o7srJ0AAAEZWA Message-ID: <634914A010D0B943A035D226786325D4422DC213B8@EXVMBX020-12.exch020.serverdata.net> References: <007501ce56f0$67f74080$37e5c180$@noemax.com> <519CD6A1.7080708@ericsson.com> <519CE075.4000106@tavendo.de> <634914A010D0B943A035D226786325D4422DC20DAA@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D4422DC2133A@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 10:38:31 -0000 PiBTdXJlLiBCdXQgSSBmYWlsIHRvIHNlZSB3aHkgeW91IG5lZWQgTVVYIGZvciB5b3VyIHVzZSBj YXNlLiBPbmUgZHVwbGV4DQo+IGNvbm5lY3Rpb24gc2VlbXMgZW5vdWdoIHRvIG1lLg0KDQpFeGFt cGxlOiBTYXkgSSB3YW50IHRvIHdyaXRlIGEgc2luZ2xlLXBhZ2UgYnJvd3NlciBhcHAgdGhhdCBo YXMgYm90aCBsb3ctbGF0ZW5jeSBjaGF0dHkgdHJhZmZpYyBhbmQgbWFzcy1kYXRhIHRyYWZmaWMg KGUuZy4gY2hhdCArIGZpbGUgdHJhbnNmZXIpLg0KDQpJIHdhbnQgdGhlIGNoYXR0eSB0cmFmZmlj IG1haW50YWluIGl0J3MgbG93LWxhdGVuY3ksIHdoaWxlIG1hc3MtZGF0YSB0cmFuc2ZlcnMgYXJl IGNvbmN1cnJlbnRseSBoYXBwZW5pbmcuDQoNClRoaXMgY291bGQgYmUgZG9uZSBieSBtdXhpbmcg MiBsb2dpY2FsIFdTIG92ZXIgYSBwaHlzaWNhbCBXUyB3aXRoIHRoZSBmaXJzdCBXUyBoYXZpbmcg aGlnaC1wcmlvIHZzIHRoZSAybmQgV1MuDQoNClNvIGEgc21hbGwgYXV0by1mcmFnbWVudCBzaXpl IHBsdXMgZmxvdy1jb250cm9sIGFuZCBzY2hlZHVsaW5nIHdvdWxkIGJlIGhlbHBmdWwuDQoNCkRv aW5nIHRoaXMgaW4gSlMgc2VlbXMgc3Vib3B0aW1hbCB0aGUgbGVhc3QgLi4NCg0KPiANCj4gPiBT byBJJ2Qgc2F5IGEgV1MtTVVYIHdpdGggZmxvdy1jb250cm9sIChkcmFmdCB0aGVyZSkgcGx1cw0K PiBwcmlvcml6YXRpb24vc2NoZWR1bGluZyAobm90IHRoZXJlKSBpcyAidGhlIGxhc3QgbWlzc2lu ZyBwaWVjZSIuIExldHMgZmluaXNoIGl0Lg0KPiANCj4gVGhlIHByb2JsZW0gSSBzZWUgaXMgdGhh dCB0aGUgMiBmZWF0dXJlcyB5b3UgbWVudGlvbiBoZXJlIGFyZSBxdWl0ZQ0KPiBjb21wbGljYXRl ZCB0byBzcGVjaWZ5IGFuZCBpbXBsZW1lbnQgY29ycmVjdGx5LCBpLmUuIHdlIGR1cGxpY2F0ZSB0 aGUgbGFyZ2VyDQoNCkkgYWdyZWUgLi4gdGhvc2UgYXJlIHRyaWNreS4gRldJVyBJIGFtIHdpbGxp bmcgdG8gaW52ZXN0IHRpbWUgYW5kIGVmZm9ydCB0byBleHRlbmQgQXV0b2JhaG4gdGVzdHN1aXRl IGZvciBXUyBleHRlbnNpb25zLiBXZSBhcmUgd29ya2luZyBub3cgb24gcGVybWVzc2FnZS1kZWZs YXRlLg0KDQo+IGVmZm9ydCB1bmRlcnRha2VuIGJ5IEhUVFAvMi4NCg0KSXQgYWxsIGRlcGVuZHMg b24gcGVyc3BlY3RpdmUsIGdvYWxzIGFuZCB1c2UgY2FzZXMgLi4gYnV0IEkgY2FuIGZvbGxvdyB5 b3VyIHZpZXcgLi4gZ3Vlc3MgSmV0dHkgd2FudHMgdG8gaGF2ZSBib3RoIFdTIGFuZCBTUERZLg0K DQovVG9iaWFzDQoNCg== From tobias.oberstein@tavendo.de Tue Jun 4 04:12:39 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA6321F9B42 for ; Tue, 4 Jun 2013 04:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+By8xlTNVjz for ; Tue, 4 Jun 2013 04:12:23 -0700 (PDT) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id 4E06021F9B7E for ; Tue, 4 Jun 2013 03:04:34 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.90]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Tue, 4 Jun 2013 03:04:33 -0700 From: Tobias Oberstein To: Takeshi Yoshino Date: Tue, 4 Jun 2013 03:04:31 -0700 Thread-Topic: [hybi] Call for interest: multiplexing dedicated for WebSocket Thread-Index: Ac5hBlATZ073JABoSNOC4CQ+WWItZQAAWhlw Message-ID: <634914A010D0B943A035D226786325D4422DC213B9@EXVMBX020-12.exch020.serverdata.net> References: <007501ce56f0$67f74080$37e5c180$@noemax.com> <519CD6A1.7080708@ericsson.com> <519CE075.4000106@tavendo.de> <634914A010D0B943A035D226786325D4422DC20DAA@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simone Bordet , "hybi@ietf.org" Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 11:12:39 -0000 > Another issue: implementing s.th . like priority based > scheduling at app level would might require to reinvent some kind of > fragmentation at the app level to be able to schedule according to > priority (otherwise once a very large message on a low prio channel > is started to be sent, it'll block everything else). >=20 >=20 > Yes. The app must be able to send a fragment. >=20 > But it's a matter of WebSocket API. A server can do that, but if a=20 > client want to, it can't for now due to limitation of the API. Hence, it= =20 > needs application level fragmentation. The WS client implementation could do auto-fragmentation. The fragment size could be chosen by upstream bandwidth and latency target. A WS server could= do the same. Auto-fragment based on downstream bandwidth and latency target. The app isn't bothered with fragmentation then. > Hence I'd like to propose to >=20 > 1) add an (optional) extension parameter "scheduler" as above > 2) use the 3 currently unassigned RSV bits in AddChannelRequest for > channel prio (when scheduler=3D"priority") > 3) define appropriate MUST semantics (scheduling should not follow > advisory semantics .. apps should be able to rely on it) > 4) probably add a new PriorityControl message to change prio of > existing channels >=20 > =3D=3D=3D >=20 >=20 > WebSocket API is not ready for such a sophisticated ToS mechanism. Yes. Apart from extending the JS WS browser API (which currently only has WS URL and protocol for open) with ToS: var sock =3D new WebSocket("ws://example.com ", [], {scheduler: "priority",= priority: 7}); This would assume that logical WS channels eligible to be shared over 1 phy= sical WS not only share same host:port, but also scheduler. [this API does not provide for 4) - dynamically changing channel prio] Another option would be to let the server choose based on URL requested URL 1 : ws://example.com/chat URL 2 : ws://example.com/file If the client connects and speaks MUX, the server can answer (in opening ha= ndshake) mux; scheduler=3Dpriority; priority=3D7 for URL 1 e.g.. For the first connection, that would happen on the physical= WS. For subsequent connections, it would happen on logical WS (scheduler needs to be the same)= : MUX is not nested, but only the "priority" parameter used by the client WS implementation. Yet another option would be to "use" URL parameters to hint URL 1 : ws://example.com?scheduler=3Dpriority&priority=3D1 URL 2 : ws://example.com?scheduler=3Dpriority&priority=3D7 and let the server make final decision. > Example: > An app creates an empty file on some cloud service. Subsequently the > app wants to append to that file. >=20 > The first could be a high-prio message, the latter messages low-prio. >=20 > The app does not care whether those messages travel over 1 physical, > or multiple different logical WS channels. >=20 > However, the app does care that the first "create file" message > arrives before any subsequent "append to file" messages. >=20 > So a different design involving per-message prios on a single WS > channel (physical or logical) might allow higher-prio messages to > overtake lower prio-messages, but not otherwise round. >=20 >=20 > I see. This would definitely require API change sock.send("foobar", 7); // send message with priority 7 It would provide even richer semantics to an app though .. From tyoshino@google.com Tue Jun 4 05:24:52 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A9E21F9B2C for ; Tue, 4 Jun 2013 05:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+7WIgvGFsgk for ; Tue, 4 Jun 2013 05:24:42 -0700 (PDT) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6913521F9CB4 for ; Tue, 4 Jun 2013 04:00:51 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id c41so19335eek.40 for ; Tue, 04 Jun 2013 04:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CrM9DduBoPYYehGK0zO6UIbtMWEj2WOtHEJYnpYqHiw=; b=eX9J1srEVXqPkQrcaiR7Xx8eV1YB+HjpcDQgDSreSEFVz+RNZ7St+ovbUvkArb/Ife HjheU265BXDYrzHmrg/DGxf1syq5xCjM+6UTBZXdrT1Xu1oofmGTAieW5O/B8IIJWmfp 5+7w9ut96KsmTQdGnRUzUOJoFV1A2mT1CFfOOGrlDueyZvj8Qas/trn1xEIhZEzUJ+PE rI/nliVUpXZcBwadVp15ykXuHu0Ru+pUzMxrGOKBW1V0oBzlh/XgBoPChgbmMFkAtCeP S2uZvz0aTxY6vuCGeoX2FQXsAeJbxunu33vqJ3u1BfmQUy4Twn8ZTem8/l2P+ELKQH3V oTPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=CrM9DduBoPYYehGK0zO6UIbtMWEj2WOtHEJYnpYqHiw=; b=Edxo3PCNJF/K0PIV7rct5YZGe5D+4+w2MI2xDT4nVDq288kCIdDTt/VCjhzre0rUDZ TFaPlf7S5O6pQUjrAAwLsQijBJlT5iNbcbJamVKs+xA+PhDc73U8NMUU5W4yWsRXWRfM uf1JvkKHRcVlxkkFHYkRKoa/dauUZIvoV0Z2mC36FuZAQ3tZ1LFZ9Axz+Z5oRVJbiNFi 5yDJEupMH4D4UQUkMG3EF6bfTwgMSqA9MNEyu2HBZ0QzD2T4aLp+0B+y94BK68L/ZGAZ VpdKDSVLoJUSdR0aEMtOnkpj5hd7v6L0DWblGZ64bUD8swcc1m1pghrA3ZzjCId1AQfp ZCbQ== X-Received: by 10.15.32.142 with SMTP id a14mr25690574eev.152.1370343649742; Tue, 04 Jun 2013 04:00:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.86.67 with HTTP; Tue, 4 Jun 2013 04:00:28 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D4422DA06FA0@EXVMBX020-12.exch020.serverdata.net> References: <20130425140626.10027.9016.idtracker@ietfa.amsl.com> <634914A010D0B943A035D226786325D4422DA06FA0@EXVMBX020-12.exch020.serverdata.net> From: Takeshi Yoshino Date: Tue, 4 Jun 2013 20:00:28 +0900 Message-ID: To: Tobias Oberstein Content-Type: multipart/alternative; boundary=089e0163521076cf8e04de51fe5c X-Gm-Message-State: ALoCoQkn3DUTFYgWap8ydXeR+Xz0MT+qiaSiFrdUbrYU/JjYJUptjayocPJTR7zjzhSWlO61tJXTupCxcAjCQNnpfZfMB1CWxQBfoNZouwalzYK4Bhi4If/dBokY3DUahdNTOyJu8/yfejMw4DhxJOWmadQQjMm95dijjd4rKTjeUx537SmoAfLXjm9ycl+4pn1plGmvgiiq Cc: "hybi@ietf.org" Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-09.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 12:24:52 -0000 --089e0163521076cf8e04de51fe5c Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 31, 2013 at 7:51 PM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > > Please post your opinions and experience (implemented, faced any > difficulties, found issues, etc.). > > Hi Takeshi, > > We are implementing the extension now in Autobahn - testing against latest > Chrome Canary which provides the extension. > > Does Chrome have any (user accessible) switch/options to > > 1. force automatic message fragmentation > We don't have it yet. Unless it's required to be implemented, e.g. for mux or partial send API in the future, we won't. > 2. set compress window sizes > Not planned. Chrome always accept data compressed w/ 32k window. > 3. context takeover > No. > > ? > > Rgd 1.: I am asking since Autobahn provides APIs for message, frame and > streaming processing and we want to make sure permessage-deflate works for > those also. > We could help you by extending pywebsocket's echo_client.py. Sorry that Chrome won't. --089e0163521076cf8e04de51fe5c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 31, 2013 at 7:51 PM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:
> Please post your opinions and experience (implemented, faced any diff= iculties, found issues, etc.).

Hi Takeshi,

We are implementing the extension now in Autobahn - testing against latest = Chrome Canary which provides the extension.

Does Chrome have any (user accessible) switch/options to

1. force automatic message fragmentation

We don't have it yet. Unless it's required to be implemente= d, e.g. for mux or partial send API in the future, we won't.
=A0
2. set compress window sizes

Not = planned. Chrome always accept data compressed w/ 32k window.
=A0<= /div>
3. context takeover

No.
=A0

?

Rgd 1.: I am asking since Autobahn provides APIs for message, frame and str= eaming processing and we want to make sure permessage-deflate works for tho= se also.

We could help you by ext= ending pywebsocket's echo_client.py.

Sorry that Chrome won't.
=A0<= /div>
--089e0163521076cf8e04de51fe5c-- From tyoshino@google.com Tue Jun 4 05:44:45 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB05621F9A12 for ; Tue, 4 Jun 2013 05:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaj5yyUqdUGY for ; Tue, 4 Jun 2013 05:44:32 -0700 (PDT) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B421421F9BF7 for ; Tue, 4 Jun 2013 04:17:58 -0700 (PDT) Received: by mail-ea0-f171.google.com with SMTP id m14so70119eaj.30 for ; Tue, 04 Jun 2013 04:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5nXab+P1bL2jHRpYkN7atZiaYAJWBJwczZdMTnUiRdM=; b=Xa9PmRiZOG/BKStCsZBsZ0DzBU92aV0qDA0zs5KmfZT2S7PohAjiZ2a1xQgc68OtG+ c8Vu9ajefTnpF6wSZB/PFxYW87EjKIx+Mw8STO3vIXaExkSxCpeLuWW5FIqybtY/kaaw jdFX1ceXEHKfuwWWLoG2CRD3yVcQLpciVoTUTMKnuseAOLUXUHJWkLYVQ0iXZaTBM5ik Gy+dvWzxmKiSGakAjB7s9KVw6sTa0fGwCz8whzkoe7wqriXPriT5ygbjpsMkMsgIwBdL qKM8JTZ4yker+b0Gywwt1u9KxMoAEqGBiZNXHFHFzArdqRZ6sVwMmLc5+fFHBsDv1lrb ZL7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=5nXab+P1bL2jHRpYkN7atZiaYAJWBJwczZdMTnUiRdM=; b=H2QljZA+TBRlmBj49/Quf/Bx3rckJoBZzJ4cmVutjxuBEPDzYVRf+6VE4NNS4UDMxo B40ryl+vdraf9vH48ukqHCKfzAD+ZZM62tAuQaydXTCT45evE+K3P+s1F8jeq+S/ApNl aahEnLdMwlOqbfxClgkoAI2v5Uy2hrkdAgtz37CZpP0MhjnQMM9LYmLhGUlinuOJwBqX fHGgmsVvofWcsdgl0r1R5M5RehNeIQGDn0abeAIGmOIVrFUAPK9+2A7cnx23lsblnoei +9ZiG8Q7Fl4D3SUyTsR8p6TG+2wTv4iHlLpHwbFMrFgKpTNHlaeq+4i6y3ZI5i5aA5dC Dngg== X-Received: by 10.14.2.7 with SMTP id 7mr9279930eee.99.1370344677699; Tue, 04 Jun 2013 04:17:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.86.67 with HTTP; Tue, 4 Jun 2013 04:17:36 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D4422DC20D62@EXVMBX020-12.exch020.serverdata.net> References: <20130425140626.10027.9016.idtracker@ietfa.amsl.com> <634914A010D0B943A035D226786325D4422DC20D62@EXVMBX020-12.exch020.serverdata.net> From: Takeshi Yoshino Date: Tue, 4 Jun 2013 20:17:36 +0900 Message-ID: To: Tobias Oberstein Content-Type: multipart/alternative; boundary=047d7b66f6cbbc345304de523b85 X-Gm-Message-State: ALoCoQl3fRG0dzw/8KxDU+jl8zHnwdDqlzq1J8irNdTNQ+l3CaSQZ2Vn7FZmqa9pMf+iRy6quT7jhyJgok9/FC4nbdKSl54e1clki5bN6FXIaGfNGdyLCs5rYslg4hNsUkKBGHOWc6S0mdWA3P/4JxZi2J9NHDCXx6HSLvOPXIv5wgPm7j0rqyQrc1Z8ksbVVylnUjw2WJ0r Cc: "hybi@ietf.org" Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-09.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 12:44:45 -0000 --047d7b66f6cbbc345304de523b85 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 1, 2013 at 5:54 AM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > > Please post your opinions and experience (implemented, faced any > difficulties, found issues, etc.). > > 1) Some first testing .. > > http://code.google.com/p/chromium/issues/detail?id=245732 > http://code.google.com/p/chromium/issues/detail?id=245719 > > Thanks so much. > 2) > If client offers multiple PMCE choices to the server by including multiple > elements in the "Sec-WebSocket-Extensions" header and the server supports > more than one of the PMCEs offered, is there any preference which PMCE the > server SHOULD choose? E.g. the first PMCE in the header that is supported > by the server? > > The description of the examples in "5.1. Negotiation Examples" seem to > suggest that the _ordering_ of alternative PMCE offered designates > _preference_. > > Yes. Order means preference. The server may choose any even if it supports all of them. Do you think we need any text to make it clear? > 3) > """ > A server MUST decline a "permessage-deflate" offer if any of the > following conditions is met: > > o The offer has any extension parameter not defined for use in an > offer. > > o The offer has any extension parameter with an invalid value. > > o The offer has multiple extension parameters with the same name. > > o The server doesn't support the offered configuration. > """ > > So if multiple permessage-deflate PMCEs are offered by the client, the > server silently skips any invalid until the first valid or none if there is > no single valid one? > > The server does NOT fail the WS connection upon encountering the first > invalid PMCE in the list of offers? > Yes. As far as there's no WebSocket-core-protocol-level grammar error (extension-param ABNF in RFC 6455), the server doesn't have to fail the connection. > > 4) > """ > A client MUST _Fail the WebSocket Connection_ if the server accepted > a "permessage-deflate" offer with a response meeting any of the > following condition: > > o The response has any extension parameter not defined for use in a > response. > > o The response has any extension parameter with an invalid value. > > o The response has multiple extension parameters with the same name. > > o The client doesn't support the configuration the response > represents. > """ > > This list does not include: "The response corresponds to a PMCE > configuration not offered by the client originally". > Is this on purpose? > (A client may support a configuration which it did not offer .. for > whatever reasons) > > Yes. To allow multiple offers but make it unnecessary to identify accepted request (e.g. we need to attach request ID or something to each extension entry to do that), I made permessage-deflate responses self-contained (both client side parameters and server side parameters are listed in a response). Each extension has sole discretion to consider what response to be invalid/unsupported. --047d7b66f6cbbc345304de523b85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 1, 2013 at 5:54 AM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:
> Please p= ost your opinions and experience (implemented, faced any difficulties, foun= d issues, etc.).

1) Some first testing ..

http://code.google.com/p/chromium/issues/detail?id=3D245732<= /a>
http://code.google.com/p/chromium/issues/detail?id=3D245719<= /a>


=A0
2)
If client offers multiple PMCE choices to the server by including multiple = elements in the "Sec-WebSocket-Extensions" header and the server = supports more than one of the PMCEs offered, is there any preference which = PMCE the server SHOULD choose? E.g. the first PMCE in the header that is su= pported by the server?

The description of the examples in "5.1. Negotiation Examples" se= em to suggest that the _ordering_ of alternative PMCE offered designates _p= reference_.


Yes. Order means preference. The= server may choose any even if it supports all of them.
Do you think we need any text to make it clear?
=A0
3)
"""
=A0 =A0A server MUST decline a "permessage-deflate" offer if any = of the
=A0 =A0following conditions is met:

=A0 =A0o =A0The offer has any extension parameter not defined for use in an=
=A0 =A0 =A0 offer.

=A0 =A0o =A0The offer has any extension parameter with an invalid value.
=A0 =A0o =A0The offer has multiple extension parameters with the same name.=

=A0 =A0o =A0The server doesn't support the offered configuration.
"""

So if multiple permessage-deflate PMCEs are offered by the client, the serv= er silently skips any invalid until the first valid or none if there is no = single valid one?

The server does NOT fail the WS connection upon encountering the first inva= lid PMCE in the list of offers?

Y= es. As far as there's no WebSocket-core-protocol-level grammar error (e= xtension-param ABNF in RFC 6455), the server doesn't have to fail the c= onnection.
=A0

4)
"""
=A0 A client MUST _Fail the WebSocket Connection_ if the server accepted =A0 =A0a "permessage-deflate" offer with a response meeting any o= f the
=A0 =A0following condition:

=A0 =A0o =A0The response has any extension parameter not defined for use in= a
=A0 =A0 =A0 response.

=A0 =A0o =A0The response has any extension parameter with an invalid value.=

=A0 =A0o =A0The response has multiple extension parameters with the same na= me.

=A0 =A0o =A0The client doesn't support the configuration the response =A0 =A0 =A0 represents.
"""

This list does not include: "The response corresponds to a PMCE config= uration not offered by the client originally".
Is this on purpose?
(A client may support a configuration which it did not offer .. for whateve= r reasons)


Yes. To allow= multiple offers but make it unnecessary to identify accepted request (e.g.= we need to attach request ID or something to each extension entry to do th= at), I made permessage-deflate responses self-contained (both client side p= arameters and server side parameters are listed in a response).

Each extension has sole discretion to consider what response to be invalid= /unsupported.
=A0
--047d7b66f6cbbc345304de523b85-- From tyoshino@google.com Tue Jun 4 06:01:23 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E154D21F8FAF for ; Tue, 4 Jun 2013 06:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.857 X-Spam-Level: X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iq5sOySrSHi1 for ; Tue, 4 Jun 2013 06:01:05 -0700 (PDT) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C47C421F9BD9 for ; Tue, 4 Jun 2013 04:35:41 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id c13so31104eek.3 for ; Tue, 04 Jun 2013 04:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=DqE3JYDBEj78cSOj9VNGgjah1zkprDChgkDlP4FXIIY=; b=MK/Vc1YD8NYAHTWcXEQPUcrrndZ19li7Y51bAuIiQUXHjj0gs4FayBVdKNqFeL6Ygr XkZ8lSwrL5Ip0AG68oLISpNqyWSk3GDVAAYiM85KweToGCqKu8Tnfzm06wl8YVfALa6I vlwGYIrA+dr47/nGwqJ61kt6XeanZos2MrsqfD0C3i6NADZAbUOFSyl2A+rwgEKsCx2U FepTRBRnEk/LiEdjFrwlxn+O9SWNmldFdBFHplVi0aAISnXVCHyboqt7jI9Xjmk1hT+W 0HZeTEd5dSRRJLda/u6eo+38WFHl71pm9kvBiZkg3CgDnlmHFh+d0QxgjzkaJ1fGFOfM si4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=DqE3JYDBEj78cSOj9VNGgjah1zkprDChgkDlP4FXIIY=; b=AWT3xt8bzKQBH/M5+pS6WxQbKtEPVVcZK58QPIRhiVyfBvw8HrdBduYj8ne9nBDDIT u0PVVFNQHLRqaGwK8yEzLbQD6oHeNuzcpwstM6doZ6XJ1i3MDi/myB0Oc67HFSXEnBa1 WbjoztjdZ5nA9Sp89rvFV8zFD7/8yiP2EptelQD+oJYPVVA71k3nKDpKYxCTstXjH0is mjAw4PwsLrvMNTrL7sj6eP6ktLu3d+4zcAroa06E2k/bhhV6d7Cah0ps8nooYs/G+jGm xdkd8wTjccNBhfLO/1e4vuW4quPBAA1c0cGWK9ZPgvh9A+KdpfxE2zA3kNQ2NPOYNw0S R7OA== X-Received: by 10.14.110.194 with SMTP id u42mr26294116eeg.117.1370345740852; Tue, 04 Jun 2013 04:35:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.86.67 with HTTP; Tue, 4 Jun 2013 04:35:20 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D4422DC20DC7@EXVMBX020-12.exch020.serverdata.net> References: <20130425140626.10027.9016.idtracker@ietfa.amsl.com> <634914A010D0B943A035D226786325D4422DC20DC7@EXVMBX020-12.exch020.serverdata.net> From: Takeshi Yoshino Date: Tue, 4 Jun 2013 20:35:20 +0900 Message-ID: To: Tobias Oberstein Content-Type: multipart/alternative; boundary=089e015384ac1aa32e04de527b1e X-Gm-Message-State: ALoCoQmFS7paYFVLd3BbFkJkqqQkiRfohzbNpyEJ3KwzutmIa4FIrpZ6bhNjTNneReKbbnbjoEjcZStlEgx4N0fEUxjFYmovO94WNVWfAlgHckoHfiScACUngr8bWHueS4mgV+mg2q00kWqDaQc1OBu/1w4prgiYtOzORD4wHbieIVlKoKh5MDbXRsEEbKpOI3YMhJYA9Yd5 Cc: "hybi@ietf.org" Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-09.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 13:01:23 -0000 --089e015384ac1aa32e04de527b1e Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jun 2, 2013 at 7:29 AM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > > Please post your opinions and experience (implemented, faced any > difficulties, found issues, etc.). > > """ > A client MAY attach the "c2s_max_window_bits" extension parameter if > the client can adjust LZ77 sliding window size based on the > "c2s_max_window_bits" sent by the server. This parameter has no > value. > """ > > Any reason there is no "c2s_no_context_takeover" parameter that allows the > client to _announce_ it supports the feature? > I assumed that there's no platform/language where it's difficult to implement c2s_no_context_takeover. It means that DEFLATE context is singleton and can never be reset (or reset operation is very heavy). Unless there's any existing difficulty, c2s_no_context_takeover should be supported widely, I think. Your suggestion allows a client to force a server which is reluctant to but can enable c2s_context_takeover to enable it. Do you think it's important functionality? --089e015384ac1aa32e04de527b1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jun 2, 2013 at 7:29 AM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:
> Please post your opinions and experience (implemented, faced any diff= iculties, found issues, etc.).

"""
=A0 =A0A client MAY attach the "c2s_max_window_bits" extens= ion parameter if
=A0 =A0the client can adjust LZ77 sliding window size based on the
=A0 =A0"c2s_max_window_bits" sent by the server. =A0This paramete= r has no
=A0 =A0value.
"""

Any reason there is no "c2s_no_context_takeover" parameter that a= llows the client to _announce_ it supports the feature?

I assumed that there's no platform/language wher= e it's difficult to implement c2s_no_context_takeover. It means that DE= FLATE context is singleton and can never be reset (or reset operation is ve= ry heavy).

Unless there's any existing difficulty,= c2s_no_context_takeover should be supported widely, I think.

Your suggestion allows a client to force a server w= hich is reluctant to but can enable c2s_context_takeover to enable it. Do y= ou think it's important functionality?
=A0
--089e015384ac1aa32e04de527b1e-- From tobias.oberstein@tavendo.de Tue Jun 4 06:31:05 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BC521F9B06 for ; Tue, 4 Jun 2013 06:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3q+Wzh2S6rRr for ; Tue, 4 Jun 2013 06:30:50 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1E821F9ABF for ; Tue, 4 Jun 2013 04:57:47 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.90]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Tue, 4 Jun 2013 04:57:46 -0700 From: Tobias Oberstein To: Takeshi Yoshino Date: Tue, 4 Jun 2013 04:57:43 -0700 Thread-Topic: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-09.txt Thread-Index: Ac5hEsiIHawiR3MTSTqN0BpM6Vit4gABydVw Message-ID: <634914A010D0B943A035D226786325D4422DC213CB@EXVMBX020-12.exch020.serverdata.net> References: <20130425140626.10027.9016.idtracker@ietfa.amsl.com> <634914A010D0B943A035D226786325D4422DA06FA0@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-09.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 13:31:05 -0000 >>Rgd 1.: I am asking since Autobahn provides APIs for message, frame and s= treaming processing and we want to make sure permessage-deflate works for t= hose also. >We could help you by extending pywebsocket's echo_client.py. >Sorry that Chrome won't. No problem. Thanks! Autobahn now implements both server and client, and has all features contro= llable. *** To everyone: I am looking for other implementations of permessage-deflate (client and/or= server) .. including ones that allow to control features .. to test intero= perability. *** Note: We are also working on extending Autobahn testsuite to test permessag= e-deflate .. but that will take a litte time .. /Tobias From tobias.oberstein@tavendo.de Tue Jun 4 06:53:28 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114DD21F9997 for ; Tue, 4 Jun 2013 06:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZV-Zrch5t7p for ; Tue, 4 Jun 2013 06:53:13 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id 9338D21F9AA2 for ; Tue, 4 Jun 2013 05:20:56 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.90]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Tue, 4 Jun 2013 05:20:54 -0700 From: Tobias Oberstein To: Takeshi Yoshino Date: Tue, 4 Jun 2013 05:20:48 -0700 Thread-Topic: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-09.txt Thread-Index: Ac5hFS2qc5FLRswvRW6q9R2YxqaBlQABaBbg Message-ID: <634914A010D0B943A035D226786325D4422DC213DF@EXVMBX020-12.exch020.serverdata.net> References: <20130425140626.10027.9016.idtracker@ietfa.amsl.com> <634914A010D0B943A035D226786325D4422DC20D62@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-09.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 13:53:28 -0000 > http://code.google.com/p/chromium/issues/detail?id=3D245732 > http://code.google.com/p/chromium/issues/detail?id=3D245719 >=20 >=20 > Thanks so much. Thanks for awesome speed with fixing the first! >=20 > 2) > If client offers multiple PMCE choices to the server by including > multiple elements in the "Sec-WebSocket-Extensions" header and the > server supports more than one of the PMCEs offered, is there any > preference which PMCE the server SHOULD choose? E.g. the first PMCE > in the header that is supported by the server? >=20 > The description of the examples in "5.1. Negotiation Examples" seem > to suggest that the _ordering_ of alternative PMCE offered > designates _preference_. >=20 >=20 > Yes. Order means preference. The server may choose any even if it=20 > supports all of them. >=20 > Do you think we need any text to make it clear? I think it would clarify things by adding text like """ A server MAY choose any PMCE offered by the client and supported by the ser= ver. The order of PMCE offered by the client designates preference by the client= and a server SHOULD accept the first offer in the list (by order) that it = supports. """ This IMHO makes sense and brings the abstract description in line with the = text in "5.1. Negotiation Examples". >=20 > 3) > """ > A server MUST decline a "permessage-deflate" offer if any of the > following conditions is met: >=20 > o The offer has any extension parameter not defined for use in a= n > offer. >=20 > o The offer has any extension parameter with an invalid value. >=20 > o The offer has multiple extension parameters with the same name= . >=20 > o The server doesn't support the offered configuration. > """ >=20 > So if multiple permessage-deflate PMCEs are offered by the client, > the server silently skips any invalid until the first valid or none > if there is no single valid one? >=20 > The server does NOT fail the WS connection upon encountering the > first invalid PMCE in the list of offers? >=20 >=20 > Yes. As far as there's no WebSocket-core-protocol-level grammar error=20 > (extension-param ABNF in RFC 6455), the server doesn't have to fail the=20 > connection. "doesn't have to fail" .. So a server MAY fail the handshake instead of just skipping bad offers? Con= fused. At least for me I have troubles with the word "decline" in "A server MUST d= ecline .." a) decline =3D silently skip OR b) decline =3D fail handshake ? I'd prefer b) - why be too liberal here - , but am ok with a) also .. but p= lease consider defining "decline" in the text. Sorry: maybe it's just me, but I was really spending time with above questi= on .. >=20 >=20 > 4) > """ > A client MUST _Fail the WebSocket Connection_ if the server accept= ed > a "permessage-deflate" offer with a response meeting any of the > following condition: >=20 > o The response has any extension parameter not defined for use i= n a > response. >=20 > o The response has any extension parameter with an invalid value= . >=20 > o The response has multiple extension parameters with the same > name. >=20 > o The client doesn't support the configuration the response > represents. > """ >=20 > This list does not include: "The response corresponds to a PMCE > configuration not offered by the client originally". > Is this on purpose? > (A client may support a configuration which it did not offer .. for > whatever reasons) >=20 >=20 > Yes. To allow multiple offers but make it unnecessary to identify=20 > accepted request (e.g. we need to attach request ID or something to each= =20 > extension entry to do that), I made permessage-deflate responses=20 > self-contained (both client side parameters and server side parameters=20 > are listed in a response). >=20 > Each extension has sole discretion to consider what response to be=20 > invalid/unsupported. Lets say a client supports all features, but offers permessage-deflate; s2c_max_window_bits=3D10 (hence, no fallback) and the server responds: permessage-deflate. Autobahn client will FAIL that, since the PMCE response from the server doe= s not match any offer, despite the reponse PMCE is supported. If it would accept that, why would there be a need to offer explicit fallba= cks like permessage-deflate; s2c_max_window_bits=3D10, permessage-deflate ? From tobias.oberstein@tavendo.de Tue Jun 4 07:06:03 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43EF121F961F for ; Tue, 4 Jun 2013 07:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfWB0hhC6twS for ; Tue, 4 Jun 2013 07:05:48 -0700 (PDT) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id 759A521F9C6E for ; Tue, 4 Jun 2013 05:31:52 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.90]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Tue, 4 Jun 2013 05:31:51 -0700 From: Tobias Oberstein To: Takeshi Yoshino Date: Tue, 4 Jun 2013 05:31:49 -0700 Thread-Topic: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-09.txt Thread-Index: Ac5hF6blmCA+p89sQ7K2RhA5nU8RKgABlemg Message-ID: <634914A010D0B943A035D226786325D4422DC213FA@EXVMBX020-12.exch020.serverdata.net> References: <20130425140626.10027.9016.idtracker@ietfa.amsl.com> <634914A010D0B943A035D226786325D4422DC20DC7@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-09.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 14:06:03 -0000 Am 04.06.2013 13:35, schrieb Takeshi Yoshino:> On Sun, Jun 2, 2013 at 7:29 = AM, Tobias Oberstein=20 > > wrote: >=20 > > Please post your opinions and experience (implemented, faced any > difficulties, found issues, etc.). >=20 > """ > A client MAY attach the "c2s_max_window_bits" extension parameter= if > the client can adjust LZ77 sliding window size based on the > "c2s_max_window_bits" sent by the server. This parameter has no > value. > """ >=20 > Any reason there is no "c2s_no_context_takeover" parameter that > allows the client to _announce_ it supports the feature? >=20 >=20 > I assumed that there's no platform/language where it's difficult to=20 > implement c2s_no_context_takeover. It means that DEFLATE context is=20 > singleton and can never be reset (or reset operation is very heavy). >=20 > Unless there's any existing difficulty, c2s_no_context_takeover should=20 > be supported widely, I think. The current draft reads: " It is RECOMMENDED that clients implement the "c2s_no_context_takeover" parameter." It's not "MUST implement" .. so there might be client which won't, and then= a server has no chance to adapt it's response to the client and maximize l= ikelihood of connection success given it ideally wants to activate "c2s_no_= context_takeover". >=20 > Your suggestion allows a client to force a server which is reluctant to=20 > but can enable c2s_context_takeover to enable it. Do you think it's=20 > important functionality? Why is that? The presence of "c2s_no_context_takeover" in the client's offer would just = signal to the server that the client supports the feature and the server MA= Y enable it. Why signal feature presence for "c2s_max_window_bits", but not "c2s_no_cont= ext_takeover"? Maybe it's just me, but the asymmetry was a source of confusion to me. I think it would make the spec more consequent, and the change is minimal, = e.g. it's a 1 liner for Chrome: String CompressionMessageExtensionProcessor::handshakeString() { return ASCIILiteral("permessage-deflate; c2s_max_window_bits"); } =3D> String CompressionMessageExtensionProcessor::handshakeString() { return ASCIILiteral("permessage-deflate; c2s_max_window_bits; c2s_no_co= ntext_takeover;"); } /Tobias From tyoshino@google.com Wed Jun 5 21:18:54 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F7911E80D3 for ; Wed, 5 Jun 2013 21:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dF6Zs+pNIWDt for ; Wed, 5 Jun 2013 21:18:53 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 36F8E11E80E4 for ; Wed, 5 Jun 2013 21:18:52 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id r16so2154038ead.41 for ; Wed, 05 Jun 2013 21:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=y3yk2HRFmEetD5BZhaYuvp9IahpjortEgd4pvI8hN0o=; b=C6TXGIJZPz3PSLRrQl4nmyMoUFY6UbaYsZU/VdEk5Edckl0YoxEHjGAIxk8niNOhJW XzuVxj2nhXxVvMdw2N8YM76ptPyxscE041Qc38w8RGnAlVwPSN3fPodMOONBego6+Xg+ 36VhKiccYIaoESfgTN7j8odAkbrG9odjbuvRhUWuQ/QpHsEB4nPfVTD61ZX1ogks54Wu uVFeu/yHqtkDxN38crPg9NOcMyEjXCK1x9cVxe4ETN8d4BSnZBaLIggzSr2EXgJkWmhg UjTWXYFzCczfvm+ZfA2byFOhBfoq80FnUrtIQuY5gm2SI0t9g7MWAyh5Px8jlhoMR2I8 3PvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=y3yk2HRFmEetD5BZhaYuvp9IahpjortEgd4pvI8hN0o=; b=o71+YTodGGlbVBop+TRDbStkv53Uu1Qh+hbvJC0MUxMK7m7gw5k9Y+QuCkIL590VRz eVzkei55zNZJkumpPDgXgqXQiAe6AoQwj8owu/IK7OWEgzX+b9ZiZ9X5smAS02D/qzmK XZ1+c6w5Y1YnffNGHej7nqB4SoTgd3FUvlof7pZx+OYZaiHVUYmSiOVLMFkWD1Cylngc M3ynfBgzmZWvCxM7vWESIK0Cfu04RSQCoG5ZVrfmEQZQ3Erdf086Qhm02/T17cC56GLB jzxXn9KdSfLZ3CCd+B9gELjykWVJrEWZEjxyf0ZvHcVNvam4+p5HTPmOXVhrOxY2UylE Ohfw== X-Received: by 10.15.32.142 with SMTP id a14mr31768900eev.152.1370492332117; Wed, 05 Jun 2013 21:18:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.86.67 with HTTP; Wed, 5 Jun 2013 21:18:31 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Thu, 6 Jun 2013 13:18:31 +0900 Message-ID: To: Scott Morgan Content-Type: multipart/alternative; boundary=089e016352109fc63904de749ca5 X-Gm-Message-State: ALoCoQmvGu2mZc67A1iseYR9PWXyjGSquZzMjnTJFIld2j6mV2tpbEER1L8BTUMHNfbBiUlCSS9FjFAsntsIrkKxkWd2eLzmfQL3pvDEnhiTcTFD8b2nDBkUlmgHrN0C0EInUhH8okiGhUAvaljaJdnrd4Fu+XyuuAQZsUV1wKSIEkWowglAxDil4yH0Ml0hvA/HeSL2qhXK Cc: "hybi@ietf.org" Subject: Re: [hybi] hybi Digest, Vol 51, Issue 14 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 04:18:54 -0000 --089e016352109fc63904de749ca5 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jun 2, 2013 at 2:55 AM, Scott Morgan wrote: > On Tue, May 28, 2013 at 10:36 PM, Takeshi Yoshino wrote: > ... > Could you elaborate? >> > Yes and actually I am going to change the way I do this after reading the > rfc. I am going to use regular http(s) for the authentication part so > this would change to the following. > > 1 Browser sends authentication to the server over https > 2 Server notes the ip address of the request and responds with a ws url to > the client if successful ie. wss://example.com/valid?session=123 > 3 Browser connects to url wss://example.com/valid?session=123 > 4 Server checks the ip address of the original https request with the wss > connection > to make sure they are the same, and takes appropriate action (closes > the wss connection if they are NOT, or some other appropriate action) > I see. > 1 Browser connects to a wss server >>> 2 User does some authentication (ie user id, password) >>> 3 wss server does authentication using user id, password and ip address >>> (for either some privileges or as a additional authentication parameter >>> for a success fail style authentication) >>> >> >> That is that only access from some IP address X will have some high >> privilege? >> > Yes the ip address of the user may allow the user to gain additional > privileges, ie something like; > John logs in to the Bank from a public computer he can't do much, but see > the accounts. > John logs in from his office (and the office ips addresses are marked as > secure locations) > he gets to transfer money > > Sounds fine. > Note my application is not a bank application, this is just a example. > >> >> >>> 4 after successful auth message at the browser an the wss connection >>> is closed >>> and a different wss is opened on the same port with a different path in >>> the url >>> 5 The wss server only allows the different wss connection to open if >>> there is a http session from the original wss connection from the same ip >>> address of the first connection. >>> >> >> Does the server get a session parameter over the new connection and also >> check the source IP address? Or the server here just checks if there was >> successful authentication on some prior connection with the same IP address >> as the new one? >> > My main goal was to attempt to validate the IP address of the sender by > comparing the ip address of multiple connections, (originally both wss, now > https and wss). > Even without multiplexing, it's possible that both auth and application traffic come over the same TCP connection. RFC 6455 doesn't prohibit using the same TCP connection for HTTPS and WSS. It's not about multiplexing but keep-alive. IIRC, it's still under discussion but technically you can do an HTTPS for auth and then send WS handshake on the same connection. --089e016352109fc63904de749ca5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jun 2, 2013 at 2:55 AM, Scott Morgan <scott@adligo= .com> wrote:
On Tue, May 28, 2013 at 10:36 PM, Takeshi Yoshino <tyoshino@google.com> wrote:
...=A0
Could you elaborate?
=
Yes and actually I am going to change the way I do this after re= ading the rfc.=A0=A0 I am going to use regular http(s) for the authenticati= on part so this would change to the following.

1 Browser sends authentication to the server over https
<= /div>
2 Server notes the ip address of the request and responds with a = ws url to the client if successful ie.=A0 wss://example.com/valid?session=3D123
4 Server checks the ip address of the original https request wi= th the wss connection
=A0=A0=A0 to make sure they are the same, and takes appropriate = action (closes the wss connection if they are NOT, or some other appropriat= e action)

I see.
=A0
<= div class=3D"im">
1 Browser connects to a wss server
2 User does some authentication= (ie user id, password)
3 wss serv= er does authentication using user id, password and ip address
<= div>(for either= some privileges or as a additional authentication parameter for a success = fail style authentication)

That is that only access from = some IP address X will have some high privilege?
Yes the ip address of the user may allow the user to g= ain additional privileges, ie something like;
John logs in to the Bank from a public computer he can't do much, but s= ee the accounts.
John logs in from his office (and the office ips addres= ses are marked as secure locations)
=A0 he gets to transfer m= oney


Sounds fine.
=A0
<= div class=3D"gmail_quote">
Note my application is not a bank= application, this is just a example.
=A0
4 after su= ccessful auth message at the browser an the=A0wss connection is closed
=A0and a different wss is opened on the same port with a differe= nt path in the url
5 The wss server only allows the diff= erent wss connection to open if there is a http session from the original w= ss connection from the same ip address of the first connection.

Does the server get a session = parameter over the new connection and also check the source IP address? Or = the server here just checks if there was successful authentication on some = prior connection with the same IP address as the new one?
My main goal was to attempt to va= lidate the IP address of the sender by comparing the ip address of multiple= connections, (originally both wss, now https and wss).=A0

= Even without multiplexing, it's possible that both auth and application= traffic come over the same TCP connection. RFC 6455 doesn't prohibit u= sing the same TCP connection for HTTPS and WSS. It's not about multiple= xing but keep-alive. IIRC, it's still under discussion but technically = you can do an HTTPS for auth and then send WS handshake on the same connect= ion.
=A0
--089e016352109fc63904de749ca5-- From tobias.oberstein@tavendo.de Sat Jun 8 05:50:31 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1496221F9A33 for ; Sat, 8 Jun 2013 05:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYSpXWafTT5u for ; Sat, 8 Jun 2013 05:50:26 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id C9F9D21F9A1F for ; Sat, 8 Jun 2013 05:50:26 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.90]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Sat, 8 Jun 2013 05:50:25 -0700 From: Tobias Oberstein To: "hybi@ietf.org" Date: Sat, 8 Jun 2013 05:50:25 -0700 Thread-Topic: permessage-bzip2, -lz4 and -snappy Thread-Index: Ac5kRibdx1skfPOtS8S2+IGDmAvUPg== Message-ID: <634914A010D0B943A035D226786325D4422DD31B98@EXVMBX020-12.exch020.serverdata.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [hybi] permessage-bzip2, -lz4 and -snappy X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 12:50:31 -0000 Hi, we are experimenting with adding new compression methods to the PMCE framew= ork provided by Takeshi's "permessage-compression" draft http://tools.ietf.= org/html/draft-ietf-hybi-permessage-compression-09 Motivation: While "permessage-deflate" balances CPU, memory and compression ratio and "= zlib" is widely available, other compression methods either provide higher = compression ratios (consuming more CPU and/or memory) or lower CPU and/or m= emory load. We are thinking of - permessage-bzip2 - permessage-lz4 - permessage-snappy We have already implemented "permessage-bzip2" in AutobahnPython (both clie= nt and server). The others will follow. Here is an example opening handshake: GET /runCase?case=3D6&agent=3DAutobahnPython/0.6.0 HTTP/1.1 User-Agent: AutobahnPython/0.6.0 Host: 127.0.0.1:9001 Upgrade: WebSocket Connection: Upgrade Pragma: no-cache Cache-Control: no-cache Sec-WebSocket-Key: 900jKLXzMJ6OrZ3v9HgyOA=3D=3D Sec-WebSocket-Extensions: permessage-bzip2; c2s_compress_level, permessage-= deflate; c2s_no_context_takeover; c2s_max_window_bits Sec-WebSocket-Version: 13 HTTP/1.1 101 Switching Protocols Server: AutobahnTestSuite/0.5.4-0.6.0 Upgrade: WebSocket Connection: Upgrade Sec-WebSocket-Accept: 0sry1e2yduhqN51p9afaWmkcFnU=3D Sec-WebSocket-Extensions: permessage-bzip2 When connecting from a client only supporting "permessage-deflate" (e.g. cu= rrent Chrome Canary), server will fallback to that of course. =3D=3D I'd like to ask on the list: a) any interest by other implementors? b) - how should the new PMCEs be specified? within Takeshi's current draft or = outside? - how to register the extension names and parameters? - does above even make sense, given that (as far as I know), none of bzip2,= lz4 or snappy has an RFC? /Tobias From ricea@google.com Mon Jun 10 00:12:10 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1037A21F8B35 for ; Mon, 10 Jun 2013 00:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_44=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOXBcaaBP4IJ for ; Mon, 10 Jun 2013 00:12:09 -0700 (PDT) Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id AD3D221F86CA for ; Mon, 10 Jun 2013 00:12:08 -0700 (PDT) Received: by mail-bk0-f48.google.com with SMTP id jf17so3142476bkc.35 for ; Mon, 10 Jun 2013 00:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rtZS0di3GFc7B2mKHiwtKBOBPFQhJ0AS9LAADy5YOic=; b=kBv4yk+ZDtGETFGEJHjHN6xYRtVSbwTHvIGW/WCGTJv5QoLQLcSYJzqfYFjrQtCAYu KgvD0FDxmPxcYBwRMWsUY3m1RosrcVBAev75flxZhw27mHP0LVPBuT7bX6Kl/v9MN0Wp pIqxgulAE36gtkayHmausrv+AQz7Y0Bag1LpckhLQLTmODFRrmGccjvIE+Rszyn64/Us P30mi8ZUcez5+0vghxlQczJ/fr3k71r0BMsCz2pyUkelJeExECH9wb8+7FRXTPlWuQUI guxEYLfKgr7vInL9Ws9tJDFac2+tGe6x5no+KYTuelSZ9zPFGvg+kO2nW2r9kRG53By7 dnYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=rtZS0di3GFc7B2mKHiwtKBOBPFQhJ0AS9LAADy5YOic=; b=luKFuDeialUqLSBcpw3dmew9vV/v6/Y986DjbiUdifeEFW6r2P2Mmu5TiDIQrLfd1i oklVqJAjdLr4NdDwjWs2ZVPw7BRex0YTOEvMMDT8mrP2IDSdDI+kg3q9HVmfDJYQWYv9 GFPbfbIFJuBeXkI2+cqsTktjSvg3oeDVmxU28qn+QVARcfhMJxqdZt/IlP6Be/Jp9gwX IuZ0hHcYn/P8jptB5mKuZjhx6KNsTKchtze0PD0Z9le9jiKzgpiHRZ4GxeUVfkfpo40O 8pGS7bxrqwpqx1rNEOQC/+F0nAwHloDf3iBT/b71x9hBMD3UUnFCOTCobxnM1aNTGsih A3Vg== MIME-Version: 1.0 X-Received: by 10.204.184.69 with SMTP id cj5mr1264357bkb.60.1370848327349; Mon, 10 Jun 2013 00:12:07 -0700 (PDT) Received: by 10.204.35.195 with HTTP; Mon, 10 Jun 2013 00:12:07 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D4422DC213B9@EXVMBX020-12.exch020.serverdata.net> References: <007501ce56f0$67f74080$37e5c180$@noemax.com> <519CD6A1.7080708@ericsson.com> <519CE075.4000106@tavendo.de> <634914A010D0B943A035D226786325D4422DC20DAA@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D4422DC213B9@EXVMBX020-12.exch020.serverdata.net> Date: Mon, 10 Jun 2013 16:12:07 +0900 Message-ID: From: Adam Rice To: Tobias Oberstein Content-Type: multipart/alternative; boundary=20cf302ad01898356d04dec77f6c X-Gm-Message-State: ALoCoQkUD+iwq5599dWqXgQvaRzuI2DrbrbvBH4kOeZyk7heagQ7QkBgRELjqXCp8mD7hZpPwvO25uMkW8ufTfLbnRszHjb+esd6p5+avmAsDnUcEH+s7X05O4kjH7ubPKcVEOzEOioldePlb9Di8JiMgHSy0WV+FrboJp1O2V8xuMpnow6GmvSCTZm6B6frvrQrhMGFvyVY Cc: Simone Bordet , "hybi@ietf.org" Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 07:12:10 -0000 --20cf302ad01898356d04dec77f6c Content-Type: text/plain; charset=ISO-8859-1 I believe our priority is to finalise a multiplexing specification quickly. So we should focus on what is essential for multiplexing to be useful. I think we have general consensus that flow control is essential. I have not been convinced that prioritisation is essential. In the event that a single application has both low-latency and high-throughput channels, the lack of prioritisation in the protocol can be worked around by using different endpoints (hence different physical channels) for different traffic types. To make this easier to deploy, I am leaning towards the idea that wss://a.example.com/ and wss://b.example.com/ should be considered distinct endpoints, even if the IP address is the same. This is not ideal, and the low-latency and high-throughput channels will still fight for bandwidth at the network level, but it is still a win to have one each of latency-sensitive and throughput-sensitive TCP/IP connections rather than a dozen of each. I am not saying that prioritisation is not desirable, just that I don't think the complexity versus benefit tradeoff makes sense right now. On 4 June 2013 19:04, Tobias Oberstein wrote: > > Another issue: implementing s.th . like priority based > > scheduling at app level would might require to reinvent some kind of > > fragmentation at the app level to be able to schedule according to > > priority (otherwise once a very large message on a low prio channel > > is started to be sent, it'll block everything else). > > > > > > Yes. The app must be able to send a fragment. > > > > But it's a matter of WebSocket API. A server can do that, but if a > > client want to, it can't for now due to limitation of the API. Hence, it > > needs application level fragmentation. > > The WS client implementation could do auto-fragmentation. The fragment size > could be chosen by upstream bandwidth and latency target. A WS server > could do > the same. Auto-fragment based on downstream bandwidth and latency target. > > The app isn't bothered with fragmentation then. > > > Hence I'd like to propose to > > > > 1) add an (optional) extension parameter "scheduler" as above > > 2) use the 3 currently unassigned RSV bits in AddChannelRequest for > > channel prio (when scheduler="priority") > > 3) define appropriate MUST semantics (scheduling should not follow > > advisory semantics .. apps should be able to rely on it) > > 4) probably add a new PriorityControl message to change prio of > > existing channels > > > > === > > > > > > WebSocket API is not ready for such a sophisticated ToS mechanism. > > Yes. > > Apart from extending the JS WS browser API (which currently only has > WS URL and protocol for open) with ToS: > > var sock = new WebSocket("ws://example.com ", [], {scheduler: "priority", > priority: 7}); > > This would assume that logical WS channels eligible to be shared over 1 > physical WS > not only share same host:port, but also scheduler. > > [this API does not provide for 4) - dynamically changing channel prio] > > Another option would be to let the server choose based on URL requested > > URL 1 : ws://example.com/chat > URL 2 : ws://example.com/file > > If the client connects and speaks MUX, the server can answer (in opening > handshake) > > mux; scheduler=priority; priority=7 > > for URL 1 e.g.. For the first connection, that would happen on the > physical WS. For subsequent > connections, it would happen on logical WS (scheduler needs to be the > same): MUX is not nested, > but only the "priority" parameter used by the client WS implementation. > > Yet another option would be to "use" URL parameters to hint > > URL 1 : ws://example.com?scheduler=priority&priority=1 > URL 2 : ws://example.com?scheduler=priority&priority=7 > > and let the server make final decision. > > > Example: > > An app creates an empty file on some cloud service. Subsequently the > > app wants to append to that file. > > > > The first could be a high-prio message, the latter messages low-prio. > > > > The app does not care whether those messages travel over 1 physical, > > or multiple different logical WS channels. > > > > However, the app does care that the first "create file" message > > arrives before any subsequent "append to file" messages. > > > > So a different design involving per-message prios on a single WS > > channel (physical or logical) might allow higher-prio messages to > > overtake lower prio-messages, but not otherwise round. > > > > > > I see. > > This would definitely require API change > > sock.send("foobar", 7); // send message with priority 7 > > It would provide even richer semantics to an app though .. > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --20cf302ad01898356d04dec77f6c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I believe our priority is to finalise a multiplexing speci= fication quickly. So we should focus on what is essential for multiplexing = to be useful.

I think we have general consensus that flo= w control is essential.

I have not been convinced that prioritisation is essent= ial. In the event that a single application has both low-latency and high-t= hroughput channels, the lack of prioritisation in the protocol can be worke= d around by using different endpoints (hence different physical channels) f= or different traffic types. To make this easier to deploy, I am leaning tow= ards the idea that wss://a.example.com/ and wss://b.example.com/ should be= considered distinct endpoints, even if the IP address is the same.

This is not ideal, and the low-latency and high-through= put channels will still fight for bandwidth at the network level, but it is= still a win to have one each of latency-sensitive and throughput-sensitive= TCP/IP connections rather than a dozen of each.

I am not saying that prioritisation is not desirable, j= ust that I don't think the complexity versus benefit tradeoff makes sen= se right now.


On 4 June 2013 19:04, Tobias Oberstein <tobias.oberstein@tavendo= .de> wrote:
> =A0 =A0 Another issue: implementing s.th <http://s.th<= /a>>. like priority based
> =A0 =A0 scheduling at app level would might require = to reinvent some kind of
> =A0 =A0 fragmentation at the app level to be able to schedule accordin= g to
> =A0 =A0 priority (otherwise once a very large message on a low prio ch= annel
> =A0 =A0 is started to be sent, it'll block everything else).
>
>
> Yes. The app must be able to send a fragment.
>
> But it's a matter of WebSocket API. A server can do that, but if a=
> client want to, it can't for now due to limitation of the API. Hen= ce, it
> needs application level fragmentation.

The WS client implementation could do auto-fragmentation. The fragmen= t size
could be chosen by upstream bandwidth and latency target. A WS server could= do
the same. Auto-fragment based on downstream bandwidth and latency target.
The app isn't bothered with fragmentation then.

> =A0 =A0 Hence I'd like to propose to
>
> =A0 =A0 1) add an (optional) extension parameter "scheduler"= as above
> =A0 =A0 2) use the 3 currently unassigned RSV bits in AddChannelReques= t for
> =A0 =A0 channel prio (when scheduler=3D"priority")
> =A0 =A0 3) define appropriate MUST semantics (scheduling should not fo= llow
> =A0 =A0 advisory semantics .. apps should be able to rely on it)
> =A0 =A0 4) probably add a new PriorityControl message to change prio o= f
> =A0 =A0 existing channels
>
> =A0 =A0 =3D=3D=3D
>
>
> WebSocket API is not ready for such a sophisticated ToS mechanism.

Yes.

Apart from extending the JS WS browser API (which currently only has
WS URL and protocol for open) with ToS:

var sock =3D new WebSocket("ws://example.com ", [], {scheduler: "priority", p= riority: 7});

This would assume that logical WS channels eligible to be shared over 1 phy= sical WS
not only share same host:port, but also scheduler.

[this API does not provide for 4) - dynamically changing channel prio]

Another option would be to let the server choose based on URL requested

URL 1 : ws://example.= com/chat
URL 2 : ws://example.= com/file

If the client connects and speaks MUX, the server can answer (in opening ha= ndshake)

mux; scheduler=3Dpriority; priority=3D7

for URL 1 e.g.. For the first connection, that would happen on the physical= WS. For subsequent
connections, it would happen on logical WS (scheduler needs to be the same)= : MUX is not nested,
but only the "priority" parameter used by the client WS implement= ation.

Yet another option would be to "use" URL parameters to hint

URL 1 : ws://example.com?scheduler=3Dpriority&priority=3D1<= /a>
URL 2 : ws://example.com?scheduler=3Dpriority&priority=3D7<= /a>

and let the server make final decision.

> =A0 =A0 Example:
> =A0 =A0 An app creates an empty file on some cloud service. Subsequent= ly the
> =A0 =A0 app wants to append to that file.
>
> =A0 =A0 The first could be a high-prio message, the latter messages lo= w-prio.
>
> =A0 =A0 The app does not care whether those messages travel over 1 phy= sical,
> =A0 =A0 or multiple different logical WS channels.
>
> =A0 =A0 However, the app does care that the first "create file&qu= ot; message
> =A0 =A0 arrives before any subsequent "append to file" messa= ges.
>
> =A0 =A0 So a different design involving per-message prios on a single = WS
> =A0 =A0 channel (physical or logical) might allow higher-prio messages= to
> =A0 =A0 overtake lower prio-messages, but not otherwise round.
>
>
> I see.

This would definitely require API change

sock.send("foobar", 7); // send message with priority 7

It would provide even richer semantics to an app though ..

_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--20cf302ad01898356d04dec77f6c-- From ricea@google.com Mon Jun 10 00:37:38 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4BF21F885A for ; Mon, 10 Jun 2013 00:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZ4gQlSLpzK2 for ; Mon, 10 Jun 2013 00:37:37 -0700 (PDT) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 447BC21F84E7 for ; Mon, 10 Jun 2013 00:37:36 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id r7so3136716bkg.3 for ; Mon, 10 Jun 2013 00:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7bSlpLOcLMxqPybUtU2ye1romvyrEdLx4M0+4Z2FHrc=; b=ENB9Ha8GXzD0g1WsuAONCJeq8NvfMg3qdwIfqLCSCIFIm7qDiPRg9YQMSUanM1kSy2 QZOQ6dK7URwHOPI7ATKZJerKg2JlVi/wS3HvZq2oyjnHpBsELEh7SShA0hDb/oT+MOCU E5ewPX5SMMery68UOYw0FQE5OEphyNTURiEQiUO/R1ABivomQDqiTzNrbRugzv3Jd/s1 TIsR6Y58BEC0YbSoo+WTbYeQQBOCvEERFN6aK3rloaUSFMpgD4V18sdgnppA5zKCEMGI AkHC8cRXypBDgfEtVMJvQ9fy2aOMoPXMBqRVIzzGesXql5zSESO2I5fUV7FTPZZjoHoQ 15ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=7bSlpLOcLMxqPybUtU2ye1romvyrEdLx4M0+4Z2FHrc=; b=XMRY6g7E/mUD3Ry3VUaje3A+5tJqGQb4KBkGDY5jpCjRy3/xpfQzMUdjZmTRZkMuuh /xDMR/RhQWWCA+IBtEAqmkEG1M4rrlSiRohsW57XJVOrwcoPDXOupG94vV9h6jpXKcmV Fq4/sH2+B2hI/HdqCtiHqoxVrUHWeIoac7jLRvpohLFS3uR8ejc/0HyB2yDbGIgtxmXJ fY2Kny9uN4dL2lxDbbdGyHbJs8p0PtZCJJWqvr2SRf1rC2JB+q0HquCmv3VCPuB38xM5 Rc1XfImeFN09DGRPS6ly0Uqw4nJcBagSPRWUZdH2s/DQiSXE5cLvsSY7nMQpTMEhhfgA Vipg== MIME-Version: 1.0 X-Received: by 10.204.225.73 with SMTP id ir9mr1304707bkb.45.1370849856084; Mon, 10 Jun 2013 00:37:36 -0700 (PDT) Received: by 10.204.35.195 with HTTP; Mon, 10 Jun 2013 00:37:35 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Jun 2013 16:37:35 +0900 Message-ID: From: Adam Rice To: Scott Morgan Content-Type: multipart/alternative; boundary=485b3970d098b6e7cc04dec7daf1 X-Gm-Message-State: ALoCoQkynu4jJVi0QBK0QQs8ioRA5JIsI4WGReWL4ciLbPm8g1QErzOVnA/8dJNVWu29l342JueM5Yx3xBozTXcjygcL11uIPFfznskLprxcWAn1IC+YFwcQwVx4tYz6DV1G1u2P2L0a9JEYyZueU7nH9Le5Qk6V1rOzPrSaSWbqx4i5CfRYoh2fbmdQZOhu/X9TIHsttqZx Cc: "hybi@ietf.org" Subject: Re: [hybi] hybi Digest, Vol 51, Issue 14 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 07:37:38 -0000 --485b3970d098b6e7cc04dec7daf1 Content-Type: text/plain; charset=ISO-8859-1 On 2 June 2013 02:55, Scott Morgan wrote: > Yes and actually I am going to change the way I do this after reading the > rfc. I am going to use regular http(s) for the authentication part so > this would change to the following. > > 1 Browser sends authentication to the server over https > 2 Server notes the ip address of the request and responds with a ws url to > the client if successful ie. wss://example.com/valid?session=123 > 3 Browser connects to url wss://example.com/valid?session=123 > 4 Server checks the ip address of the original https request with the wss > connection > to make sure they are the same, and takes appropriate action (closes > the wss connection if they are NOT, or some other appropriate action) > > It seems to me that storing the session ID in a cookie would make this easier. If you want to put the session ID in a URL, I would recommend making it single-use, although that means you need some mechanism to get a new session ID if the WebSocket connection fails. RFC6455 allows WebSocket connections to use a different proxy than HTTPS connections. Although I'm not aware of any client that actually implements this, you should not assume that all requests from the same sender will come from the same IP. --485b3970d098b6e7cc04dec7daf1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 2 June 2013 02:55, Scott Morgan <<= a href=3D"mailto:scott@adligo.com" target=3D"_blank" class=3D"cremed">scott= @adligo.com> wrote:
Yes and actua= lly I am going to change the way I do this after reading the rfc.=A0=A0 I a= m going to use regular http(s) for the authentication part so this would ch= ange to the following.

1 Browser sends authentication to the server over https
<= /div>
2 Server notes the ip address of the request and responds with a = ws url to the client if successful ie.=A0 wss://example.com/vali= d?session=3D123
3 Browser connects to url wss://example.com/valid?ses= sion=3D123
4 Server checks the ip address of the original= https request with the wss connection
=A0=A0=A0 to make sure they are the same, and takes appropriate = action (closes the wss connection if they are NOT, or some other appropriat= e action)


It seems to me that storing the session ID= in a cookie would make this easier.

If you want t= o put the session ID in a URL, I would recommend making it single-use, alth= ough that means you need some mechanism to get a new session ID if the WebS= ocket connection fails.

RFC6455 allows WebSocket connections to use a different= proxy than HTTPS connections. Although I'm not aware of any client tha= t actually implements this, you should not assume that all requests from th= e same sender will come from the same IP.
--485b3970d098b6e7cc04dec7daf1-- From tobias.oberstein@tavendo.de Tue Jun 11 02:08:58 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4188121F8618 for ; Tue, 11 Jun 2013 02:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvctEtTag2Eq for ; Tue, 11 Jun 2013 02:08:53 -0700 (PDT) Received: from EXHUB020-2.exch020.serverdata.net (exhub020-2.exch020.serverdata.net [206.225.164.29]) by ietfa.amsl.com (Postfix) with ESMTP id C254F21F8476 for ; Tue, 11 Jun 2013 02:08:52 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.90]) by EXHUB020-2.exch020.serverdata.net ([206.225.164.29]) with mapi; Tue, 11 Jun 2013 02:08:34 -0700 From: Tobias Oberstein To: Adam Rice Date: Tue, 11 Jun 2013 02:08:30 -0700 Thread-Topic: [hybi] Call for interest: multiplexing dedicated for WebSocket Thread-Index: Ac5lqdMzGEOxHqpIRDmKKb1rUan8QQAx4Jbw Message-ID: <634914A010D0B943A035D226786325D4422DDFCBCA@EXVMBX020-12.exch020.serverdata.net> References: <007501ce56f0$67f74080$37e5c180$@noemax.com> <519CD6A1.7080708@ericsson.com> <519CE075.4000106@tavendo.de> <634914A010D0B943A035D226786325D4422DC20DAA@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D4422DC213B9@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simone Bordet , "hybi@ietf.org" Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 09:08:58 -0000 Am 10.06.2013 09:12, schrieb Adam Rice:> I believe our priority is to final= ise a multiplexing specification=20 > quickly. So we should focus on what is essential for multiplexing to be=20 > useful. I agree. I'd like to note however that "useful" from my POV depends on use-case.=20 Reducing the number of physical TCPs in scenarios like 1. multiple web apps of a single vendor open in multiple browser tabs 2. web widget from a vendor embedded into pages of many sites might already be well addressed with MUX+flow-control and don't necessarily= need priorization. Scenarios like e.g. 3. single app with multiple communication requirements with different TOS = (low-latency/mass..) might need MUX+flow-control+priorization. > I think we have general consensus that flow control is essential. Yep, seems nobody stepped up for multiplexing _without_ flow control. > I have not been convinced that prioritisation is essential. In the event= =20 It's not essential for use case 1. + 2. above, I agree. But it is for use c= ase 3. > for different traffic types. To make this easier to deploy, I am leaning= =20 > towards the idea that wss://a.example.com/ and=20 > wss://b.example.com/ should be considered=20 > distinct endpoints, even if the IP address is the same. +1 for making those "different" (cannot be mux'ed over same physical WS). > I am not saying that prioritisation is not desirable, just that I don't=20 > think the complexity versus benefit tradeoff makes sense right now. Ok. I agree that specifying different scheduling schemes etc in detail now would delay the draft. However, even the current draft contains text """ 13. Fairness Sender side o The sender MUST use a fair mechanism for selecting which logical channel's data to send in the next WebSocket message. Simple implementations may choose a round-robin scheduler, while more advanced implementations may adjust priority based on the amount or frequency of data sent by each logical channel. """ Here is an idea: could we just include minimal additions which would allow describing specific scheduling algorithms later or in separate documents? Like e.g. the "permessage-compression" draft does: it provides a _framework= _ for compression schemes, and only specs 1 algo: deflate. Here is a proposal that only adds to the opening handshake on physical and = logical WS: ************************ 1) Handshake on physical WS Example 1.1 client-to-server: "mux; scheduler=3Droundrobin" =3D> client announces MUX, and states that it implements only "roundrobin" = scheduler. server-to-client: "mux; scheduler=3Droundrobin" =3D> server agrees to speak MUX and round-robin scheduling Only "roundrobin" would be described in the current draft. Example 1.2 client-to-server: "mux; scheduler=3Dpriority, mux; scheduler=3Droundrobin" =3D> client annouces MUX, preferring "priority" based scheduler, but may fa= llback to roundrobin server-to-client: "mux; scheduler=3Dpriority" =3D> server agrees to speak MUX and select priority-based scheduling Detailing "priority" scheduling would be postponed. 2) Handshake on logical WS For a future priority scheduler, a client should be able to _hint_ which pr= iority a new (logical) WS connections should have. The only way to do that without changing the WS (browser) API would be to include the "hint" within the WS URL opened by the client: Example 2.1 URL 1 : ws://example.com/chat URL 2 : ws://example.com/file Example 2.2 URL 1 : ws://example.com?priority=3D7 URL 2 : ws://example.com?priority=3D1 A server receiving such a new logical WS connection may then respect the hi= nt, and send back header in logical handshake: Sec-WebSocket-Extensions: mux; scheduler=3Dpriority; priority=3D7 if the scheduler is "priority" on the physical WS. Otherwise it ignores the= hint. The client then applies the parameters sent by the server in the logical ha= ndshake to the scheduler for the physical WS. ************************ In effect, the scheduling scheme in use is negotiated during the opening ha= ndshake on=20 the physical WS, while the per-channel scheduler parameters can be hinted b= y the client, but are always (finally) decided by server (for both client and server side= ) and determined during the opening handshake on the logical WS for the channel. Pros: + only uses WS extensions headers of physical and logical WS + no additional MUX control frame opcodes + no use of MUX control frame RSV bits + no browser API change Cons: - scheduler parameters for logical WS cannot be changed dynamically - TOS parameters cannot be chosen "per WS message" I think with a little more work we could prepare for more advanced scheduli= ng schemes in the future and allow implementations to experiment today without breaking interoperability. /Tobias From jat@jaet.org Tue Jun 11 08:07:10 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C8421F93F8 for ; Tue, 11 Jun 2013 08:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDhBA56lBy-f for ; Tue, 11 Jun 2013 08:07:05 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E2C5421F86FB for ; Tue, 11 Jun 2013 08:07:01 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id 9so4632976iec.33 for ; Tue, 11 Jun 2013 08:07:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=9yT4tJq0/9VpCml1byL6v4uDyDcguJLREZQgTzL17v0=; b=SPuJGWulQzA2+DT0GcwqezvvIH3N4lZDENwr7E6DtSp37RpeHQRqbn65SoAPTAMMLz uG4IEAZpDLTAAfRMg145SgiGEDjcFzlaF4NEA+AELs2kQ11hIYYH/HZMIySKZ2FlV3cK 5qw9VqHvlG8rmQmzdTkdA6u4CAHk1UxlbN0Ydje7dK0tV5WRGJioWRF0F9LR25r/BEw8 Bzug378VjqkTHEOh+7UMu3M4d362Xzb6EgLm0IhAQJezYNmjPFOI4e5LkNPWwVdN0CHo vxbEbPwjHYkEMFyHpEI3ghbfS4DvHFvWNsiDc7gLkX4xnPMTT9SZTOz5G+csyUGuBumh eD0A== X-Received: by 10.50.73.37 with SMTP id i5mr1132457igv.88.1370963221273; Tue, 11 Jun 2013 08:07:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.152.40 with HTTP; Tue, 11 Jun 2013 08:06:40 -0700 (PDT) X-Originating-IP: [198.49.103.3] In-Reply-To: <634914A010D0B943A035D226786325D4422DDFCBCA@EXVMBX020-12.exch020.serverdata.net> References: <007501ce56f0$67f74080$37e5c180$@noemax.com> <519CD6A1.7080708@ericsson.com> <519CE075.4000106@tavendo.de> <634914A010D0B943A035D226786325D4422DC20DAA@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D4422DC213B9@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D4422DDFCBCA@EXVMBX020-12.exch020.serverdata.net> From: "John A. Tamplin" Date: Tue, 11 Jun 2013 11:06:40 -0400 Message-ID: To: Tobias Oberstein Content-Type: multipart/alternative; boundary=089e013a0e08cdf4af04dee23f7d X-Gm-Message-State: ALoCoQkeiQ1dKPxqt0IjD2W6pORSV60FJhzPkaJhpUt7DhjW7qMo8PQ/4UxV2Dl37mdoTlgM+gIf Cc: Simone Bordet , "hybi@ietf.org" Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 15:07:10 -0000 --089e013a0e08cdf4af04dee23f7d Content-Type: text/plain; charset=UTF-8 On Tue, Jun 11, 2013 at 5:08 AM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > 3. single app with multiple communication requirements with different TOS > (low-latency/mass..) > > might need MUX+flow-control+priorization. In the case of a single app, it can always do its own prioritization, so I do not think it essential for this case. > I think with a little more work we could prepare for more advanced > scheduling > schemes in the future and allow implementations to experiment today without > breaking interoperability. > I don't see much value in providing the extension mechanism in this draft without actually requiring an implementation, and requiring a priority implementation means adding a lot of extra work. The only way I would support this would be if the text were basically "the application can provide an indication of priority, and the server is free to use or ignore this information as it sees fit". In that case, would anyone bother to use it? -- John A. Tamplin --089e013a0e08cdf4af04dee23f7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 11, 2013 at 5:08 AM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:
<= div class=3D"gmail_extra">
3. single app wit= h multiple communication requirements with different =C2=A0TOS (low-latency= /mass..)

might need MUX+flow-control+priorization.

In the case of a single app, it can always do its own prioritization, = so I do not think it essential for this case.
=C2=A0
I think with a little= more work we could prepare for more advanced scheduling
schemes in the future and allow implementations to experiment today without=
breaking interoperability.

I don't see much value in providing the extension mechanism = in this draft without actually requiring an implementation, and requiring a= priority implementation means adding a lot of extra work. =C2=A0The only w= ay I would support this would be if the text were basically "the appli= cation can provide an indication of priority, and the server is free to use= or ignore this information as it sees fit". =C2=A0In that case, would= anyone bother to use it?

--
John A. Tamplin
--089e013a0e08cdf4af04dee23f7d-- From tobias.oberstein@tavendo.de Tue Jun 11 08:36:03 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A2B21F9A00 for ; Tue, 11 Jun 2013 08:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9Xx2L0q6NYi for ; Tue, 11 Jun 2013 08:35:58 -0700 (PDT) Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id A3DEC21F9A39 for ; Tue, 11 Jun 2013 08:35:57 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.90]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Tue, 11 Jun 2013 08:35:56 -0700 From: Tobias Oberstein To: "John A. Tamplin" Date: Tue, 11 Jun 2013 08:35:53 -0700 Thread-Topic: [hybi] Call for interest: multiplexing dedicated for WebSocket Thread-Index: Ac5mtVXlYwcFav5eRhS96qdjfnyzIwAAMXpw Message-ID: <634914A010D0B943A035D226786325D4422DDFCDEC@EXVMBX020-12.exch020.serverdata.net> References: <007501ce56f0$67f74080$37e5c180$@noemax.com> <519CD6A1.7080708@ericsson.com> <519CE075.4000106@tavendo.de> <634914A010D0B943A035D226786325D4422DC20DAA@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D4422DC213B9@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D4422DDFCBCA@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Simone Bordet , "hybi@ietf.org" Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 15:36:04 -0000 PiAgICAgMy4gc2luZ2xlIGFwcCB3aXRoIG11bHRpcGxlIGNvbW11bmljYXRpb24gcmVxdWlyZW1l bnRzIHdpdGgNCj4gICAgIGRpZmZlcmVudCAgVE9TIChsb3ctbGF0ZW5jeS9tYXNzLi4pDQo+IA0K PiAgICAgbWlnaHQgbmVlZCBNVVgrZmxvdy1jb250cm9sK3ByaW9yaXphdGlvbi4NCj4gDQo+IElu IHRoZSBjYXNlIG9mIGEgc2luZ2xlIGFwcCwgaXQgY2FuIGFsd2F5cyBkbyBpdHMgb3duIHByaW9y aXRpemF0aW9uLCBzbyANCg0KVGhlIGFwcCB0aGVuIG5lZWRzIHRvIGltcGxlbWVudCBhcHAtbGV2 ZWwgZnJhZ21lbnRhdGlvbiwgd2hlcmUgdGhlDQpkcmFmdCBhbHJlYWR5IHJlcXVpcmVzIGZyYWdt ZW50YXRpb24gZm9yIG11eC4NCg0KPiBJIGRvIG5vdCB0aGluayBpdCBlc3NlbnRpYWwgZm9yIHRo aXMgY2FzZS4NCg0KRm9yIGEgc2luZ2xlIGluc3RhbmNlICh0YWIpIG9mIHRoZSBhcHAsIHRoZSBj YW4gcmVpbnZlbnQgZnJhZ21lbnRhdGlvbg0KYW5kIGltcGxlbWVudCBpdCdzIG93biBwcmlvcml0 eSBzY2hlZHVsaW5nLg0KDQpUaGlzIHNlZW1zIHRvIGJlIGhpZ2hseSBpbmVmZmljaWVudC4NCg0K Rm9yIG11bHRpcGxlIGluc3RhbmNlcyAodGFicykgb2YgdGhlIGFwcCwgaXQncyBlc3NlbnRpYWws IHNpbmNlIHRoZSBhcHAgY2Fubm90DQppbXBsZW1lbnQgaXRzZWxmLg0KDQo+IA0KPiAgICAgSSB0 aGluayB3aXRoIGEgbGl0dGxlIG1vcmUgd29yayB3ZSBjb3VsZCBwcmVwYXJlIGZvciBtb3JlIGFk dmFuY2VkDQo+ICAgICBzY2hlZHVsaW5nDQo+ICAgICBzY2hlbWVzIGluIHRoZSBmdXR1cmUgYW5k IGFsbG93IGltcGxlbWVudGF0aW9ucyB0byBleHBlcmltZW50IHRvZGF5DQo+ICAgICB3aXRob3V0 DQo+ICAgICBicmVha2luZyBpbnRlcm9wZXJhYmlsaXR5Lg0KPiANCj4gDQo+IEkgZG9uJ3Qgc2Vl IG11Y2ggdmFsdWUgaW4gcHJvdmlkaW5nIHRoZSBleHRlbnNpb24gbWVjaGFuaXNtIGluIHRoaXMg DQo+IGRyYWZ0IHdpdGhvdXQgYWN0dWFsbHkgcmVxdWlyaW5nIGFuIGltcGxlbWVudGF0aW9uLCBh bmQgcmVxdWlyaW5nIGEgDQoNClRoZSBkcmFmdCBhbHJlYWR5IHJlcXVpcmVzIHRoZSBpbXBsZW1l bnRhdGlvbiB0byB1c2UgYSAiZmFpciBzY2hlZHVsZXIiLCBidXQNCmxlYXZlcyB0aGUgZXhhY3Qg bWVjaG5pc20gb3Blbi4NCg0KPiBwcmlvcml0eSBpbXBsZW1lbnRhdGlvbiBtZWFucyBhZGRpbmcg YSBsb3Qgb2YgZXh0cmEgd29yay4gIFRoZSBvbmx5IHdheSANCj4gSSB3b3VsZCBzdXBwb3J0IHRo aXMgd291bGQgYmUgaWYgdGhlIHRleHQgd2VyZSBiYXNpY2FsbHkgInRoZSANCj4gYXBwbGljYXRp b24gY2FuIHByb3ZpZGUgYW4gaW5kaWNhdGlvbiBvZiBwcmlvcml0eSwgYW5kIHRoZSBzZXJ2ZXIg aXMgDQo+IGZyZWUgdG8gdXNlIG9yIGlnbm9yZSB0aGlzIGluZm9ybWF0aW9uIGFzIGl0IHNlZXMg Zml0Ii4gIEluIHRoYXQgY2FzZSwgDQo+IHdvdWxkIGFueW9uZSBib3RoZXIgdG8gdXNlIGl0Pw0K DQpBIGNsaWVudCBjYW4gb25seSBoaW50LCBidXQgX2lmXyB0aGUgc2VydmVyIHNldHMgcHJpb3Jp dHkgb24gYSBjaGFubmVsLCB0aGUNCmNsaWVudCBfbXVzdF8gc2NoZWR1bGUgYWNjb3JkaW5nbHku DQoNCkZvciBhIGltcGxlbWVudGF0aW9ucyBub3Qgc3VwcG9ydGluZyBwcmlvcml0eSBzY2hlZHVs aW5nLCB0aGUgcHJvcG9zYWwNCmVzc2VudGlhbGx5IG9ubHkgcmVsYXhlcyB0aGUgYWxsb3dlZCBw YXJhbWV0ZXJzIGluIFNlYy1XZWJTb2NrZXQtRXh0ZW5zaW9ucw0KaGVhZGVyIGZvciBjbGllbnQt dG8tc2VydmVyOg0KDQpwcmlvcml0eS1lbmFibGVkIGNsaWVudCA9PiBub24tc3VwcG9ydGluZyBz ZXJ2ZXI6DQoNCmMyczogbXV4OyBwcmlvcml0eT1zY2hlZHVsZXI7IG11eA0KczJjOiBtdXgNCg0K Q2hhbmdlOiBza2lwIG11eCBjb25maWd1cmF0aW9ucyBub3Qgc3VwcG9ydGVkIGluc3RlYWQgb2Yg ZmFpbGluZyB0aGUgaGFuZHNoYWtlLg0KDQpub24tc3VwcG9ydGluZyBjbGllbnQgPT4gcHJpb3Jp dHktZW5hYmxlZCBzZXJ2ZXI6DQoNCmMyczogbXV4DQpzMmM6IG11eA0KDQpObyBjaGFuZ2UgYXQg YWxsLg0K From scott@adligo.com Tue Jun 11 11:22:07 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8043221F9638 for ; Tue, 11 Jun 2013 11:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vW+R6RWEHMe for ; Tue, 11 Jun 2013 11:22:06 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id EAEE421F98C3 for ; Tue, 11 Jun 2013 11:22:03 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id a13so7762286iee.34 for ; Tue, 11 Jun 2013 11:22:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=P5YgJKpSrK9jKD/05NgDjDfHKjwrRzvTpqut97n0bfA=; b=G5g6gEtHEIIZLFPxZwN3nZ3TpkcbDyiO7YfcRYPK/kBIRsfzzx7FXiZOFXV2G+9g15 U5xJQ/hMaCz570sx6NS/eg6W7jUyOrn9n9uQwoGOdqfLNUIbYuGZ85OZy4RkSM05Artf dSIa1GgyEs2aEoi3KeCnT62HWbZKdTTvRwOv8UZXri2CzvP69LTwnt3FP9lKxA6XG8uy TkxCy5Z6ZOStYj50Ak2ocU6yrTCMB/pND40ndwNMtEKJqBKNUKJtKXdvE4YDKwK4S5QJ TSREGaz30FSoaJJLnMAyPezgwxf37/odLpXaqGsLpeLFpnSuCtGegiFV9ZUXrghKulnd bPJg== MIME-Version: 1.0 X-Received: by 10.50.29.79 with SMTP id i15mr1556493igh.106.1370974923343; Tue, 11 Jun 2013 11:22:03 -0700 (PDT) Received: by 10.64.148.71 with HTTP; Tue, 11 Jun 2013 11:22:03 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Jun 2013 13:22:03 -0500 Message-ID: From: Scott Morgan To: Adam Rice , hybi@ietf.org Content-Type: multipart/alternative; boundary=047d7bd755144d5ad104dee4f957 X-Gm-Message-State: ALoCoQmVBf8YO6LG5Gc2HXhj3BLJasa4ZHN6OB0mdnyz7y0Ua1FonSqK52yX19FeA23gg+dKE/dQ Subject: Re: [hybi] hybi Digest, Vol 51, Issue 14 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 18:22:07 -0000 --047d7bd755144d5ad104dee4f957 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 10, 2013 at 2:37 AM, Adam Rice wrote: > On 2 June 2013 02:55, Scott Morgan wrote: > >> Yes and actually I am going to change the way I do this after reading the >> rfc. I am going to use regular http(s) for the authentication part so >> this would change to the following. >> >> 1 Browser sends authentication to the server over https >> 2 Server notes the ip address of the request and responds with a ws url >> to the client if successful ie. wss://example.com/valid?session=123 >> 3 Browser connects to url wss://example.com/valid?session=123 >> 4 Server checks the ip address of the original https request with the wss >> connection >> to make sure they are the same, and takes appropriate action (closes >> the wss connection if they are NOT, or some other appropriate action) >> >> > It seems to me that storing the session ID in a cookie would make this > easier. > Yes it would be easier to implement with a cookie, however it drives me nuts that cookies are usually used for additional location based authentication. For instance, I use a few computers with 3+ user agents (ie browsers) each to connect to my bank , and each browser on each computer needs to have it's cookie verified at a additional level, which creates extra work for users. > If you want to put the session ID in a URL, I would recommend making it > single-use, although that means you need some mechanism to get a new > session ID if the WebSocket connection fails. > > RFC6455 allows WebSocket connections to use a different proxy than HTTPS > connections. Although I'm not aware of any client that actually implements > this, you should not assume that all requests from the same sender will > come from the same IP. > Could you be a little more specific as to where in RFC6455 it says this? Also I understand you to mean something like; Johns FF Browser -> Proxy A https request -> Https/WS Server Proxy A dies, and Johns internet connection fails over to proxy B Johns FF Browser ->Proxy B ws request -> WS Server Is this what you meant? Cheers, Scott --047d7bd755144d5ad104dee4f957 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 10, 2013 at 2:37 AM, Adam Rice <ricea@google.com>= ; wrote:
On 2 June 2013 02:55, Scott Morgan <scott@adligo.com> wrote:
Yes and actually I am going to change the way I do this after reading the r= fc.=A0=A0 I am going to use regular http(s) for the authentication part so = this would change to the following.

1 Browser sends authentication to the server over https
<= /div>
2 Server notes the ip address of the request and responds with a = ws url to the client if successful ie.=A0 wss://example.com/valid?session=3D123
4 Server checks the ip address of the original https request wi= th the wss connection
=A0=A0=A0 to make sure they are the same, and takes appropriate = action (closes the wss connection if they are NOT, or some other appropriat= e action)


It seems to me that storing the sess= ion ID in a cookie would make this easier.
Yes it would be easier to implement with a cookie, however it driv= es me nuts that cookies are usually used for additional location based auth= entication.=A0=A0 For instance, I use a few computers with 3+ user agents (= ie browsers)=A0 each to connect to my bank , and each browser on each compu= ter needs to have it's cookie verified at a additional level, which cre= ates extra work for users.
=A0
If you want to put the session ID in a URL, I would recommend making= it single-use, although that means you need some mechanism to get a new se= ssion ID if the WebSocket connection fails.

RFC6455 allows WebSocket connections to use a different= proxy than HTTPS connections. Although I'm not aware of any client tha= t actually implements this, you should not assume that all requests from th= e same sender will come from the same IP.
Could you be a little more specific as = to where in RFC6455 it says this?

Also I understand you t= o mean something like;
Johns FF Browser -> Proxy A https r= equest -> Https/WS Server
Proxy A dies, and Johns internet connection fails over to proxy = B
Johns FF Browser ->Proxy B ws request -> WS Server
Is this what you meant?

Cheers,
Scott
--047d7bd755144d5ad104dee4f957-- From ricea@google.com Tue Jun 11 19:26:07 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E1121F9BAC for ; Tue, 11 Jun 2013 19:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hH70-iytTIxX for ; Tue, 11 Jun 2013 19:26:06 -0700 (PDT) Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 72AD821F9BA6 for ; Tue, 11 Jun 2013 19:26:04 -0700 (PDT) Received: by mail-bk0-f43.google.com with SMTP id jm2so3037282bkc.2 for ; Tue, 11 Jun 2013 19:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IIbXbyn950VpY1uy+DkWq/iGF7//mLvjhOGwJfNs+qA=; b=HgXnbOUluc4JvV34D/EKvceoqfBWUSS1P+7C6b7Q3jPDOREy/e3Nf2kSxXW7GG5YWN CTFJNg+rM2H2SjoEr1qAB7C/YiW5NE1YHkx/PYnmzXgz6Ua/E6ONlvwFk8ENdtU9VBkq svnM74b/q/jRMtU2Y4vIf9AGjEmB+TCTXkqOCQT7BpQWtNJpauiqXFmBFPWk8ot85Ctw DXdzCVdIJNwnNpeST5gk7HZ7WPLOduYOnry1FvwXAU0LYbmcRJyfw6DC5mLL3/2r/0M7 7svDkL8oeJFs1dLPxZ39OM4sSfXuw8vOUaxxIwA1lGGMT+poLoxBtx02DiGy9nnD0/mW RBIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=IIbXbyn950VpY1uy+DkWq/iGF7//mLvjhOGwJfNs+qA=; b=c0DzbVTWyTJGy4Jb6DnXcjagkeUz6p12IWbeAj1iulOnwUU+wLfRl26o63rEZwSwf8 CDc/wsMuwWoQVeCvhIfr6jbGNXBkLkPw3KN/1JS2aNZm3obRk0v9IrQfiP8fgWiWtdSv zl3kAAdUXVMgLbVUUlzARhJ0tXkZBD5ob7GpxExcPOwq0Hlv6kehQwFcbPJJjXeaVLjw 4TRUSlpIDRPeBE3Wm4ZwyRS+GtIZoKyjEWhzXvusk3ANjGze6cPQkh9WKXLZKDVBMoyc nLMs+kTkTJ7q17TstpR6wvZ2f5dkkDZ9aWrDXhqeUBPnPwRJVmWi8w0VKSj+LrgSVln7 2sJg== MIME-Version: 1.0 X-Received: by 10.204.183.16 with SMTP id ce16mr2688331bkb.91.1371003963929; Tue, 11 Jun 2013 19:26:03 -0700 (PDT) Received: by 10.204.35.195 with HTTP; Tue, 11 Jun 2013 19:26:03 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 Jun 2013 11:26:03 +0900 Message-ID: From: Adam Rice To: Scott Morgan Content-Type: multipart/alternative; boundary=20cf301ee34142212e04deebbcb3 X-Gm-Message-State: ALoCoQl56DDp5DX94qnuB+ddCaN4Czp11bdnkrVhvV0sYY5z36ioGCHbrtPOWMdTYHdwaOAat4paE3XtdxYl1+ufdCVabifK91KfVt0YgykWU3sWMS2q3IFDTai/CNkzo/yhD6BTQwgoejKiRlqKWXJ6HXS7jRjuKknOTBL9VejTFj52UZdzK8+7wTac/ijEY9aIzH45Q+Lz Cc: "hybi@ietf.org" Subject: Re: [hybi] hybi Digest, Vol 51, Issue 14 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 02:26:07 -0000 --20cf301ee34142212e04deebbcb3 Content-Type: text/plain; charset=ISO-8859-1 On 12 June 2013 03:22, Scott Morgan wrote: > Yes it would be easier to implement with a cookie, however it drives me > nuts that cookies are usually used for additional location based > authentication. For instance, I use a few computers with 3+ user agents > (ie browsers) each to connect to my bank , and each browser on each > computer needs to have it's cookie verified at a additional level, which > creates extra work for users. > Personally I usually find the short session timeouts used by banks to be more aggravating. I'm not sure what you mean by "location based authentication". I don't want someone to have access to my account just because they are standing behind me. If you want to put the session ID in a URL, I would recommend making it >> single-use, although that means you need some mechanism to get a new >> session ID if the WebSocket connection fails. >> >> RFC6455 allows WebSocket connections to use a different proxy than HTTPS >> connections. Although I'm not aware of any client that actually implements >> this, you should not assume that all requests from the same sender will >> come from the same IP. >> > Could you be a little more specific as to where in RFC6455 it says this? > 4.1.3: NOTE: Implementations that do not expose explicit UI for selecting a proxy for WebSocket connections separate from other proxies are encouraged to use a SOCKS5 [RFC1928 ] proxy for WebSocket connections, if available, or failing that, to prefer the proxy configured for HTTPS connections over the proxy configured for HTTP connections. > Also I understand you to mean something like; > Johns FF Browser -> Proxy A https request -> Https/WS Server > Proxy A dies, and Johns internet connection fails over to proxy B > Johns FF Browser ->Proxy B ws request -> WS Server > Is this what you meant? > No, I mean Johns FF Browser -> Proxy A https request from 1.1.1.1 to HTTPS/WS Server Johns FF Browser -> Proxy B ws request from 255.255.255.1 to HTTP/WS Server The proxy is selected based on the protocol, so there is no need to Proxy A to be dead for Proxy B to be used. Of course, there are other circumstances where Johns FF Browser might change IP address, for example when switching between mobile networks. Thanks, Adam --20cf301ee34142212e04deebbcb3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 12 June 2013 03:22, Scott Morgan <= scot= t@adligo.com> wrote:
Yes it would be easier to implement with a cookie, however it drives m= e nuts that cookies are usually used for additional location based authenti= cation.=A0=A0 For instance, I use a few computers with 3+ user agents (ie b= rowsers)=A0 each to connect to my bank , and each browser on each computer = needs to have it's cookie verified at a additional level, which creates= extra work for users.

Personally I usual= ly find the short session timeouts used by banks to be more aggravating.

I'm not sure what you mean by "location bas= ed authentication". I don't want someone to have access to my acco= unt just because they are standing behind me.=A0

If you want to put the session ID in a URL, I would recomme= nd making it single-use, although that means you need some mechanism to get= a new session ID if the WebSocket connection fails.

RFC6455 allows WebSocket connections to use a different= proxy than HTTPS connections. Although I'm not aware of any client tha= t actually implements this, you should not assume that all requests from th= e same sender will come from the same IP.
Could you be a little more specif= ic as to where in RFC6455 it says this?

4.1.3:

       NOTE: Implementations that do not expose explicit UI for
       selecting a proxy for WebSocket connections separate from other
       proxies are encouraged to use a SOCKS5 [RFC1928] proxy for
       WebSocket connections, if available, or failing that, to prefer
       the proxy configured for HTTPS connections over the proxy
       configured for HTTP connections.
=A0
Also I understand you to mean something like;
Johns FF Brows= er -> Proxy A https request -> Https/WS Server
Proxy A dies, and Johns internet connection fails over to proxy = B
Johns FF Browser ->Proxy B ws request -> WS Server
Is this what you meant?

No, I mean

Johns FF Browser -> Proxy= A https request from 1.1.1.1 to HTTPS/WS Server
Johns FF Browser= -> Proxy B ws request from 255.255.255.1 to HTTP/WS Server

The proxy is selected based on the protocol, so there is no = need to Proxy A to be dead for Proxy B to be used.

Of course, there are other circumstances where Johns FF Browser might chan= ge IP address, for example when switching between mobile networks.

Thanks,
Adam
--20cf301ee34142212e04deebbcb3-- From tobias.oberstein@tavendo.de Wed Jun 12 10:20:39 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AB821F9AD3 for ; Wed, 12 Jun 2013 10:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8sipMLjahtV for ; Wed, 12 Jun 2013 10:20:34 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id 583E521F9A72 for ; Wed, 12 Jun 2013 10:20:32 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.90]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Wed, 12 Jun 2013 10:20:31 -0700 From: Tobias Oberstein To: "hybi@ietf.org" Date: Wed, 12 Jun 2013 10:20:30 -0700 Thread-Topic: permessage-deflate parameter negotiation Thread-Index: Ac5njnHLF5b8/7S6QyiFAzrIo7JCrw== Message-ID: <634914A010D0B943A035D226786325D4422DDFD452@EXVMBX020-12.exch020.serverdata.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [hybi] permessage-deflate parameter negotiation X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:20:39 -0000 After implementing permessage-deflate client/server and with all features, = I think the initial parameter negotiation is by far the most complex part of the extension. I still have some questions. To keep it simple, here are a couple of exampl= es: 1) client offers: permessage-deflate; c2s_max_window_bits server response: permessage-deflate; s2c_no_context_takeover 2) client offers: permessage-deflate; c2s_max_window_bits server response: permessage-deflate; s2c_max_window_bits=3D10 3) client offers: permessage-deflate; c2s_max_window_bits ; s2c_max_window_bits=3D10 server response: permessage-deflate; s2c_max_window_bits=3D8 4) client offers: permessage-deflate; c2s_max_window_bits; s2c_max_window_bits=3D10 server response: permessage-deflate; s2c_max_window_bits=3D12 =3D=3D=3D Chrome Canary fails 1 + 2 (bails out "Received an unexpected permessage-def= late extension parameter"). Chrome offers a fixed "permessage-deflate; c2s_max_window_bits", so I could= not test 3 and 4. The current draft (in my reading) allows 1 + 2, but not 3, and not 4. I think 1-3 should be successful, and 4 failed by client. As in my other mail, I also think a client should explicitly announce suppo= rt for "c2s_no_context_takeover": permessage-deflate; c2s_max_window_bits; c2s_no_context_takeover /Tobias From tyoshino@google.com Thu Jun 13 08:31:24 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E4B21F8AE8 for ; Thu, 13 Jun 2013 08:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khVB+qqpznZS for ; Thu, 13 Jun 2013 08:31:24 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9C83521F86D5 for ; Thu, 13 Jun 2013 08:31:23 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so1056463wiw.4 for ; Thu, 13 Jun 2013 08:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rFtz4A2JiQc9Zqd0RG5d1POBuUhaLME3bjMl2icwfg0=; b=hyVqToM4nDvNjzCbF+I6eOcz8jXVR/O66aeR7qpZTq3vzADJpIccFP3YPTNks8OpGR 9VMYIziQ1Mln2d9Xj82+8vKjVO8qA/vlTI/UX6DNKUnULB7dXbEdaFtvOeYgVAHtp2sl /ZhH3oQeYQtiITra1hp0msffGkXiHOWDriF2jI5ytvzyS6wvvXrAuy1fJkn1bw5wj+20 nlxpjF1/TO2LoQ1DYvqls0Oaw8W1eDdZED0EEadPJD7tzP8ZGlNClaWrF7cf0ja9Rt0I msbfYwNzFXbSvfe6sbytXbe7knOsgZ0LPDMjTrmPeQKr1gdMwnBeMQy1RJQRJIR84XpV YUWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=rFtz4A2JiQc9Zqd0RG5d1POBuUhaLME3bjMl2icwfg0=; b=eicnVQ0k1BR1TX05gOxHtSkeuTqBidl7ioNRVnsO2PQidT0NciewsLkri976MpXaBd qBTL1g0hplxuelfEzLU08KdSXGg/RVjp9jX5EtBa22VUOYYOx1bCni76Up4xNme1+hDg nHewXdeOyqpVCWhCfB1H8G2zsX82YmtXP5pffJAPhkzo5M/DZaW+YbANSd/vQD8bKPBh ZS7he0RQwb1iFkmz9In3qUYvHhRZMh+9NHP34zVTy4iXkFI72Ff7pe1hgWEPYxZF3jen nrsXOUms2gGPWNOWKoW3FQGrExjXudGcixtNA/XE9GO3b+bsE8nYaVbEFMfkDKByUjaM Fn3A== X-Received: by 10.180.36.12 with SMTP id m12mr926090wij.10.1371137481939; Thu, 13 Jun 2013 08:31:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.25.230 with HTTP; Thu, 13 Jun 2013 08:31:01 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D4422DDFD452@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D4422DDFD452@EXVMBX020-12.exch020.serverdata.net> From: Takeshi Yoshino Date: Fri, 14 Jun 2013 00:31:01 +0900 Message-ID: To: Tobias Oberstein Content-Type: multipart/alternative; boundary=e89a8f5030ac8cb7a304df0ad2e8 X-Gm-Message-State: ALoCoQkVAKFMczwW202H4VQQXcTY07EMmibMY47VHpGX+LGXBpFkrd4esb+zFtANDDMpU6CJlX3HBePcF8EjiwHW/HBLxHbvAVJDraV6cDG/24Wo0g3qYrxFPzfTlB7jJQlVtuHV5S9gLpCop6ZSsw+iTwNzDEtcROxg9UBpyPA4E3hVfIHl8E2ZbKHl6B3zA8QGuIB4sugn Cc: "hybi@ietf.org" Subject: Re: [hybi] permessage-deflate parameter negotiation X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 15:31:24 -0000 --e89a8f5030ac8cb7a304df0ad2e8 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 13, 2013 at 2:20 AM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > After implementing permessage-deflate client/server and with all features, > I think the initial > parameter negotiation is by far the most complex part of the extension. > > I still have some questions. To keep it simple, here are a couple of > examples: > > 1) > client offers: > permessage-deflate; c2s_max_window_bits > > server response: > permessage-deflate; s2c_no_context_takeover > This is fine. The client may reset context if it wants. Sorry about Chrome's bug. It rejects this now. > > 2) > client offers: > permessage-deflate; c2s_max_window_bits > > server response: > permessage-deflate; s2c_max_window_bits=10 > Fine. The client should be able to accept data compressed using any wbits value. > > 3) > client offers: > permessage-deflate; c2s_max_window_bits ; s2c_max_window_bits=10 > > server response: > permessage-deflate; s2c_max_window_bits=8 > > Fine, too. > 4) > client offers: > permessage-deflate; c2s_max_window_bits; s2c_max_window_bits=10 > > server response: > permessage-deflate; s2c_max_window_bits=12 > > Bad. Maximum wbits the client can afford is 10. > === > > Chrome Canary fails 1 + 2 (bails out "Received an unexpected > permessage-deflate extension parameter"). > > Chrome offers a fixed "permessage-deflate; c2s_max_window_bits", so I > could not test 3 and 4. > > The current draft (in my reading) allows 1 + 2, but not 3, and not 4. > > I'll fix it to allow 3. > I think 1-3 should be successful, and 4 failed by client. > > As in my other mail, I also think a client should explicitly announce > support for "c2s_no_context_takeover": > > permessage-deflate; c2s_max_window_bits; c2s_no_context_takeover > > /Tobias > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --e89a8f5030ac8cb7a304df0ad2e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 13, 2013 at 2:20 AM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:
After implementin= g permessage-deflate client/server and with all features, I think the initi= al
parameter negotiation is by far the most complex part of the extension.

I still have some questions. To keep it simple, here are a couple of exampl= es:

1)
client offers:
permessage-deflate; c2s_max_window_bits

server response:
permessage-deflate; s2c_no_context_takeover

=
This is fine. The client may reset context if it wants.

Sorry about Chrome's bug. It rejects this = now.
=A0

2)
client offers:
permessage-deflate; c2s_max_window_bits

server response:
permessage-deflate; s2c_max_window_bits=3D10

Fine. The client should be able to accept data compressed using= any wbits value.
=A0

3)
client offers:
permessage-deflate; c2s_max_window_bits ; s2c_max_window_bits=3D10

server response:
permessage-deflate; s2c_max_window_bits=3D8


Fine, too.
=A0
4)
client offers:
permessage-deflate; c2s_max_window_bits; s2c_max_window_bits=3D10

server response:
permessage-deflate; s2c_max_window_bits=3D12


Bad. Maximum wbits the client ca= n afford is 10.
=A0
=3D=3D=3D

Chrome Canary fails 1 + 2 (bails out "Received an unexpected permessag= e-deflate extension parameter").

Chrome offers a fixed "permessage-deflate; c2s_max_window_bits", = so I could not test 3 and 4.

The current draft (in my reading) allows 1 + 2, but not 3, and not 4.


I'll fix it to allow 3.
=A0
I think 1-3 should be successful, and 4 failed by client.

As in my other mail, I also think a client should explicitly announce suppo= rt for "c2s_no_context_takeover":

permessage-deflate; c2s_max_window_bits; c2s_no_context_takeover

/Tobias
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--e89a8f5030ac8cb7a304df0ad2e8-- From tyoshino@google.com Thu Jun 13 08:47:13 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C79621F96D9 for ; Thu, 13 Jun 2013 08:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRGRxP5aVyH1 for ; Thu, 13 Jun 2013 08:47:12 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id F0F9621F98AD for ; Thu, 13 Jun 2013 08:47:10 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so8127745wes.17 for ; Thu, 13 Jun 2013 08:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nnMpffG+pLD7GT4Lshn0RuZgskUaHGB+VVxyst88J5Q=; b=GlLQkWZmi7rH8AJsEH8+Xj5ZVfbfCJHEIV351+aObMj3hDjO1icWDbXDIRKRUA8/Or OAvhaWdimniFDbYe90BpPUpIqBxITSQV0IPU85V/vdfHGGbhtTh/Kj2OW7vMvjzCjKax Q0+J2lMti5OB1UkuiqPODrUmwxk69SX5QaOOJm3YjK+jF4pZAfmBf87lmPZq8TZmQMYr KuxZ5U9h8H8hLCcba4vg14tszOdmwivdvNQft63fxOW2POAQihbNrWDZJ1vBcQJTCAqH 52DklL2nZ4NBuSBSaf2cNKdS3iOI3zr9TPrcbmVzOTlBLUVpLoB2xYxewwoRmxYxFDoA WGtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=nnMpffG+pLD7GT4Lshn0RuZgskUaHGB+VVxyst88J5Q=; b=NLkbh5ldb2ZQlGSwSMRbOFR8zVd0DVBCkS5uK1tXY6zSDXrN9+LXJxUgp1z1U8O+C+ XArJbznVujAakpV42EydPS7LyyhP7zL2SyHZ3PoG6UPdk0r6dW+U7FB9vZQlrlao5Gtm OqhGWftPGq4zR0gQUW6VxzuvycazzcG+AcTt//TeLXzqChwpnJv+P076lFNeOhuy5F2C FT4Yh/pSgaUPb2ifCW+7HhhFPtTUzCImUE0eSSocFXlgR2nekbAAz1OkO5iOlYiK2yHD ILwl+k5xv3Ou49hLE3hePZ7QZB0jWgaj3fbcSdw4NI4VaxCK2m4KHCqnEDO/kYHKkdtq DAQg== X-Received: by 10.194.21.231 with SMTP id y7mr889427wje.94.1371138430083; Thu, 13 Jun 2013 08:47:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.25.230 with HTTP; Thu, 13 Jun 2013 08:46:49 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D4422DD31B98@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D4422DD31B98@EXVMBX020-12.exch020.serverdata.net> From: Takeshi Yoshino Date: Fri, 14 Jun 2013 00:46:49 +0900 Message-ID: To: Tobias Oberstein Content-Type: multipart/alternative; boundary=047d7b5d27fc103ccd04df0b0b37 X-Gm-Message-State: ALoCoQnEg8tRIM3hbz9ncjMJp/80jgKkcRfhvftXlTp7pfzdiAJrHN0/cmH9R15+BC7Jo9jC3zS7iKOFt30EDoimuRW3ILlhy1k/eOZENBIFigqvxVBX5nRR38DwMej/LA69nKvEU9bkxKxwexyphFhgl6/uXH+4zCYWENt78nu27zvcRuBhMzu6uKjZhTDjBzQZg+yUCStU Cc: "hybi@ietf.org" Subject: Re: [hybi] permessage-bzip2, -lz4 and -snappy X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 15:47:13 -0000 --047d7b5d27fc103ccd04df0b0b37 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 8, 2013 at 9:50 PM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > b) > - how should the new PMCEs be specified? within Takeshi's current draft or > outside? > As we experienced for permessage-deflate, for each algorithm it should take long time for investigation on characteristics, performance metrics, and survey on implementation feasibility. I think they should be specified in a separate RFC. > - how to register the extension names and parameters? > We don't have any registry to control extension parameters. Each spec should define their parameters individually, and only register their extension name to the extension name registry. > - does above even make sense, given that (as far as I know), none of > bzip2, lz4 or snappy has an RFC? > RFC 2616 doesn't have formal reference to compress. We have RFC for DEFLATE but it's informative. We should at least have some normative doc even outside of IETF if possible. I have no idea about IPR of those algorithms. --047d7b5d27fc103ccd04df0b0b37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 8, 2013 at 9:50 PM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:
b)
- how should the new PMCEs be specified? within Takeshi's current draft= or outside?

As we experienced for perm= essage-deflate, for each algorithm it should take long time for investigati= on on characteristics, performance metrics, and survey on implementation fe= asibility. I think they should be specified in a separate RFC.
=A0
- how to register the extension names and parameters?
=
We don't have any registry to control extension paramete= rs. Each spec should define their parameters individually, and only registe= r their extension name to the extension name registry.
=A0
- does above even make sense, given that (as far as I know), none of bzip2,= lz4 or snappy has an RFC?

RFC 2616 doe= sn't have formal reference to compress. We have RFC for DEFLATE but it&= #39;s informative.

We should at least have some normative doc even o= utside of IETF if possible. I have no idea about IPR of those algorithms.
=A0
--047d7b5d27fc103ccd04df0b0b37-- From tyoshino@google.com Thu Jun 13 09:22:58 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A86521F9944 for ; Thu, 13 Jun 2013 09:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atSJGIkIrH8Y for ; Thu, 13 Jun 2013 09:22:57 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id D2E7F21F9695 for ; Thu, 13 Jun 2013 09:22:55 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f11so294742wgh.15 for ; Thu, 13 Jun 2013 09:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SmS4dxizKtUA164kz1Iz/hkbEYOBaBjMZ0jvKUKjG/c=; b=L6bynUP0dIE2rvs4tFnN8C3ckOjbUdGeXR+/b9IHO2hbzOByMMYjgm9ecxhoE/pSEd wMwxnmBbWYflPNio0puCNOMPwqamOETWyrWXR5B8Oeq4LWErpwRGiNUiJ2Imy2m6gaCf OWfn53iMuVNDZKaNdo8EbGuD+4coIctzT0Xy4Iwe5uAf3JYc+SEmi1TE6HXYIs4TxrBb abqI4pD0kPK/gq6rB8FmhgdYWyainLGPXDWydBamkSnCvLlR13ewpGVuN2lvTCMcMN+x 4gtwwK1UfmCZxCMe8SvUVR68Sy0T19yi9+UVyfiFZmE0AcSjBMq4EOqNTGDY0a/04qYI Diow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=SmS4dxizKtUA164kz1Iz/hkbEYOBaBjMZ0jvKUKjG/c=; b=oyYO1rnEyQK1hU3/7dZ/ZzhEQcNODxpjoIJzuSNnCb7Sm8Y4nSClmAEAjhIDdhyq6b kcCTKYudBAD6dyopTHdSuaIUwgVtUTWtKYR42ZeWlJ7ou9dH4ERX4ntgkgrkfQAI/5e6 9YBta1OguW5yw4rOAnTCYJotsD389kuhdpQ05yTQo0k5TiD4KDnc7g6htorRfCH+tEf0 AWpZ+a2dqfpy2A4EL3ZfA788zLGLOBY8qA5XaiNePbWd976uXs5+//lMh8c39t0nCWn9 Vkeq1WGyjM2AtEDm7QszlfdRxxG9qp2EzjeKRHjARTAru0KnWfPWG60nKmCTPMg2kCG9 jTwA== X-Received: by 10.180.36.12 with SMTP id m12mr1063070wij.10.1371140574754; Thu, 13 Jun 2013 09:22:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.25.230 with HTTP; Thu, 13 Jun 2013 09:22:33 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D4422DC213DF@EXVMBX020-12.exch020.serverdata.net> References: <20130425140626.10027.9016.idtracker@ietfa.amsl.com> <634914A010D0B943A035D226786325D4422DC20D62@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D4422DC213DF@EXVMBX020-12.exch020.serverdata.net> From: Takeshi Yoshino Date: Fri, 14 Jun 2013 01:22:33 +0900 Message-ID: To: Tobias Oberstein Content-Type: multipart/alternative; boundary=e89a8f5030ace5588804df0b8aa4 X-Gm-Message-State: ALoCoQm0e1ezKobzGUMKPOpMfrn/jNfhIb07jPadtSEThjXCi7SjriNM0IIkHmn5bhjEx6ciSQz3whwicPA5bb0iZJaSTskBiZCiJ7EKXiR3vXX6QF+DGpgJ/3Jyt84Ai/xr8YNCGADdnyg42DjGXqWVOPRc/kD9+o4HTAPIeaOgl8k1ubstLoRA0LR4g02aVbPhqmbx09F2 Cc: "hybi@ietf.org" Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-09.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 16:22:58 -0000 --e89a8f5030ace5588804df0b8aa4 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 4, 2013 at 9:20 PM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > "doesn't have to fail" .. > > So a server MAY fail the handshake instead of just skipping bad offers? > Confused. > > At least for me I have troubles with the word "decline" in "A server MUST > decline .." > > a) decline = silently skip > > OR > > b) decline = fail handshake > > ? > > I meant a). As far as the Sec-WebSocket-Extensions header value conforms to the grammar for it and the server doesn't include a reply for it, there should be no problem. But I'm also fine with b). > I'd prefer b) - why be too liberal here - , but am ok with a) also .. but > please consider defining "decline" in the text. > > Sorry: maybe it's just me, but I was really spending time with above > question .. > > Sorry about that. > > > > Yes. To allow multiple offers but make it unnecessary to identify > > accepted request (e.g. we need to attach request ID or something to each > > extension entry to do that), I made permessage-deflate responses > > self-contained (both client side parameters and server side parameters > > are listed in a response). > > > > Each extension has sole discretion to consider what response to be > > invalid/unsupported. > Sorry. Let me correct this: s/Each extension/The client/. > > Lets say a client supports all features, but offers > > permessage-deflate; s2c_max_window_bits=10 > > (hence, no fallback) > > and the server responds: > > permessage-deflate. > This is bad response. Servers MUST not generate such a response. But if the client can and wants to accept the response, we don't have to stop it. I remember the rationale based on which we made RFC 6455 to enforce servers to reject frames w/o masking. Enforcing receiver to ban bad-mannered data can work as some pressure to server implementors to conform to the server requirements. >From this point of view, I agree with you. > > Autobahn client will FAIL that, since the PMCE response from the server > does not match any offer, despite the reponse PMCE is supported. > > If it would accept that, why would there be a need to offer explicit > fallbacks like > > permessage-deflate; s2c_max_window_bits=10, permessage-deflate > > ? > > A server conforms to the spec (requirements for servers) responds with "permessage-deflate" to this request, but doesn't for "permessage-deflate; s2c_max_window_bits=10". So, the client needs to send this. Sorry that my last response was unclear and misleading. --e89a8f5030ace5588804df0b8aa4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 4, 2013 at 9:20 PM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:
"doesn't have to fail" ..

So a server MAY fail the handshake instead of just skipping bad offers? Con= fused.

At least for me I have troubles with the word "decline" in "= A server MUST decline .."

a) decline =3D silently skip

OR

b) decline =3D fail handshake

?


I meant a). As far as the Sec-WebSocke= t-Extensions header value conforms to the grammar for it and the server doe= sn't include a reply for it, there should be no problem.

But I'm also fine with b).
=A0
I'd prefer b) - why be too liberal here - , but am ok with a) also .. b= ut please consider defining "decline" in the text.

Sorry: maybe it's just me, but I was really spending time with above qu= estion ..


Sorry about that.
=A0
>
> Yes. To allow multiple offers but make it unnecessary to identify
> accepted request (e.g. we need to attach request ID or something to ea= ch
> extension entry to do that), I made permessage-deflate responses
> self-contained (both client side parameters and server side parameters=
> are listed in a response).
>
> Each extension has sole discretion to consider what response to be
> invalid/unsupported.

Sorry. = Let me correct this:
s/Each extension/The client/.
=A0<= /div>

Lets say a client supports all features, but offers

permessage-deflate; s2c_max_window_bits=3D10

(hence, no fallback)

and the server responds:

permessage-deflate.

This is bad respons= e. Servers MUST not generate such a response.

But = if the client can and wants to accept the response, we don't have to st= op it.

I remember the rationale based on which we made RFC 645= 5 to enforce servers to reject frames w/o masking. Enforcing receiver to ba= n=A0bad-mannered data can work as some pressure to server implementors to c= onform to the server requirements.

From this point of view, I agree with you.
= =A0

Autobahn client will FAIL that, since the PMCE response from the server doe= s not match any offer, despite the reponse PMCE is supported.

If it would accept that, why would there be a need to offer explicit fallba= cks like

permessage-deflate; s2c_max_window_bits=3D10, permessage-deflate

?


A server conforms to the spec (require= ments for servers) responds with "permessage-deflate" to this req= uest, but doesn't for "permessage-deflate; s2c_max_window_bits=3D1= 0".

So, the client needs to send this.

=
Sorry that my last response was unclear and misleading.
=A0
--e89a8f5030ace5588804df0b8aa4-- From scott@adligo.com Thu Jun 13 10:18:19 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0AED21F99EF for ; Thu, 13 Jun 2013 10:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5JjbTtQW-OJ for ; Thu, 13 Jun 2013 10:18:19 -0700 (PDT) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4672421F99EC for ; Thu, 13 Jun 2013 10:18:18 -0700 (PDT) Received: by mail-vb0-f46.google.com with SMTP id 10so7063029vbe.19 for ; Thu, 13 Jun 2013 10:18:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=sfIrpJjiJFQYt2rxGZAOPujAlWVO+YTLyyXat4EKoQY=; b=NcmctsfGr7WtPhbC0JOlJplP5r+IAh01Y33HyNKkbx79BGqd0esy7JNUxKb/0ljM83 UOowaEx+qPeZ1wUCz86VCZBA3VT7XOOvL2REOQH6lD/K2tfRrdBcV3xEJmmJncEr9TNI otVVIDby6TB7dWM81mTkjmaFi3Z2fwSjpG7Py399cA2fHmSrYvz8Jfj3fd+7YusWJipB WVMBxmrL3Tk4gPEn6cHf0nx39cssDiFVDXrDQgp76nhmEeCYqYtXI5BJfGWWfggy4Wln yCtfQ+YUwtEogDGZ4/vLGM9Yy5E/SKLZpol4pPB/xlGDcSgbvoqBpNPyjbt97gOULL6g 4rpw== MIME-Version: 1.0 X-Received: by 10.221.21.74 with SMTP id qr10mr728256vcb.25.1371143894449; Thu, 13 Jun 2013 10:18:14 -0700 (PDT) Received: by 10.58.203.40 with HTTP; Thu, 13 Jun 2013 10:18:14 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 Jun 2013 12:18:14 -0500 Message-ID: From: Scott Morgan To: Adam Rice , hybi@ietf.org Content-Type: multipart/alternative; boundary=001a1133a182c3cd5004df0c504a X-Gm-Message-State: ALoCoQn999s11DwbYbkFodQToqiIIs1O9bPzwIKXy8zEOeOGW/8oe84HQIKelIauSHqKnfZM7gMr Subject: Re: [hybi] hybi Digest, Vol 51, Issue 14 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 17:18:19 -0000 --001a1133a182c3cd5004df0c504a Content-Type: text/plain; charset=ISO-8859-1 HI Adam, Thanks for your reply it really helped! To clarify what I meant by "location based authentication"? I mean three potential things and any combination of them; A) The user could be authenticated base on their location (where they are) using session cookies or their ip address for implementation. This one could be useful for blocking requests from locations outside of your building/neighborhood/state/country exc B) The location (again either by session cookies or ip address) of the user in addition to other credentials (ie user id, password) is used to authenticate the user. This is the one that most banks use to make them more secure than just a user id/password? C) The location (again either by session cookies or ip address) of the user is used to grant additional roles/privileges to the authenticate user (however they authenticated). Cheers and thanks again, Scott --001a1133a182c3cd5004df0c504a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
HI Adam,

= =A0=A0 Thanks for your reply it really helped!

To clarify what= I meant by "location based authentication"?
I mean thre= e potential things and any combination of them;
A)=A0 The user could be authenticated base on their location (where t= hey are) using session cookies or their ip address for implementation.
<= br>
This one could be useful for blocking requests from locations= outside of your building/neighborhood/state/country exc

B) The location (again either by session cookies or ip= address) of the user in addition to other credentials (ie user id, passwor= d) is used to authenticate the user.

This is the one that= most banks use to make them more secure than just a user id/password?

C) The location (again either by session cookies or i= p address) of the user is used to grant additional roles/privileges to the = authenticate user (however they authenticated).

Cheers and tha= nks again,
Scott
--001a1133a182c3cd5004df0c504a-- From tyoshino@google.com Thu Jun 13 10:24:08 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D3F21F9A1C for ; Thu, 13 Jun 2013 10:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id da8AmNhLAOF6 for ; Thu, 13 Jun 2013 10:24:08 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id D331A21F99EE for ; Thu, 13 Jun 2013 10:24:07 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id w56so8335129wes.11 for ; Thu, 13 Jun 2013 10:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tbJwBASQlXQAyzgnlj/7mTirJ6ZjDWUV3Tep6CiWZ5g=; b=VGt0e1e9hlF+MoCHtQ0K9jOwkWGQyVZYWk4yZblngpbHbO0F6vo05HyUK3ENHC0w9g OEBCuHqE99pgYYAeJ3rQ38Gxw8FN5uRRwKWvBf7Qi9dpO1PzCpiuSAKGvVYKsc9qsGaz jVoCknPPe4l5TENJ9JpRm+Rvtyy/DlXR41I4xDdjxcNwf1rFxbZ0432vkKk51u7DOXDr OhPPJac+15alVcJEPrO/FcR8WEkyeyGJU9ZrvN2F3h0YILJHBsGnD2j6MZVzsNmKWM37 Yh/sNwskCY3XtDfpPPkm2fG2WNqitqoO7N63Ulsq1uONFKeB738fCHT1deOtpd7QSXTv unBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=tbJwBASQlXQAyzgnlj/7mTirJ6ZjDWUV3Tep6CiWZ5g=; b=Q4y2/mXnJGixDgpyYUv733b4TI+eV+3yjVXpPgcZ2pWJTPOo3ZE5P0NFB/ukDUHaHm 29u5UMqNN3knTcYliXVJ27l4+GRWcHXRbGkMOoQQBxFvvFw/SJ0d1mixlby9IhHZpfa8 3vS6sj2Pqg8hzAMqaxCSnJ7VD6IQs8b7Av4pVOyiSpOpwd1tEI5EuabYTjItqRwyX/Zi nvsBfmU5EX0kXgUIbLawifNYGeG328ccNdif+4JkgjPmwAoyaCVgvpfZiwBhS+0iKH9G ynJc24j0SLdP+K+aHMVLiC2ImaIgfKA/FoxbVVpWe7qQ8bkIUHGsJDTt+NqQlaJyKp65 TOZg== X-Received: by 10.194.21.231 with SMTP id y7mr1141870wje.94.1371144246808; Thu, 13 Jun 2013 10:24:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.25.230 with HTTP; Thu, 13 Jun 2013 10:23:46 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D4422DC213FA@EXVMBX020-12.exch020.serverdata.net> References: <20130425140626.10027.9016.idtracker@ietfa.amsl.com> <634914A010D0B943A035D226786325D4422DC20DC7@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D4422DC213FA@EXVMBX020-12.exch020.serverdata.net> From: Takeshi Yoshino Date: Fri, 14 Jun 2013 02:23:46 +0900 Message-ID: To: Tobias Oberstein Content-Type: multipart/alternative; boundary=047d7b5d27fcc46b7e04df0c651b X-Gm-Message-State: ALoCoQm8jIEAb4ADRp6J6iT/lcSV1jqgSFE6heoJ9RrHr+Tn593oJzcXeFq59fwP9CundLs+HV1Op9UiSJHFtpkW3HRtUkaE7WOVAU3JhUb6W6wJbtACMWtyaMNjD62RWSvZ2HjlUb2z5Z5wnV+24jl01tBvJMGaw1fCitA5of54eaz/+AOEXOLL+MzTYCOXgpOZ/VTr0o4x Cc: "hybi@ietf.org" Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-09.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 17:24:08 -0000 --047d7b5d27fcc46b7e04df0c651b Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 4, 2013 at 9:31 PM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > > Unless there's any existing difficulty, c2s_no_context_takeover should > > be supported widely, I think. > > The current draft reads: > > " It is RECOMMENDED that clients implement the > "c2s_no_context_takeover" parameter." > > It's not "MUST implement" .. so there might be client which won't, and > then a server has no chance to adapt it's response to the client and > maximize likelihood of connection success given it ideally wants to > activate "c2s_no_context_takeover". > Oh, this is a bug. This should be MUST. > > > > > Your suggestion allows a client to force a server which is reluctant to > > but can enable c2s_context_takeover to enable it. Do you think it's > > important functionality? > > Why is that? > > The presence of "c2s_no_context_takeover" in the client's offer would just > signal to the server that the client supports the feature and the server > MAY enable it. > > Why signal feature presence for "c2s_max_window_bits", but not > "c2s_no_context_takeover"? > > Maybe it's just me, but the asymmetry was a source of confusion to me. > This makes sense. But as I said above I wanted to mean c2s_no_context_takeover implementation is mandatory for clients. Once the fix is made on the spec, it would be rather confusing that we have announcement about mandatory feature. > > I think it would make the spec more consequent, and the change is minimal, > e.g. it's a 1 liner for Chrome: > Yes --047d7b5d27fcc46b7e04df0c651b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 4, 2013 at 9:31 PM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:
> Unless there's any existing difficulty, c2s_no_context_takeover s= hould
> be supported widely, I think.

The current draft reads:

" It is RECOMMENDED that clients implement the
=A0 =A0"c2s_no_context_takeover" parameter."

It's not "MUST implement" .. so there might be client which w= on't, and then a server has no chance to adapt it's response to the= client and maximize likelihood of connection success given it ideally want= s to activate "c2s_no_context_takeover".

Oh, this is a bug. This should be MU= ST.
=A0

>
> Your suggestion allows a client to force a server which is reluctant t= o
> but can enable c2s_context_takeover to enable it. Do you think it'= s
> important functionality?

Why is that?

The presence of "c2s_no_context_takeover" in the client's off= er would just signal to the server that the client supports the feature and= the server MAY enable it.

Why signal feature presence for "c2s_max_window_bits", but not &q= uot;c2s_no_context_takeover"?

Maybe it's just me, but the asymmetry was a source of confusion to me.<= br>

This makes sense. But as I said a= bove I wanted to mean c2s_no_context_takeover implementation is mandatory f= or clients. Once the fix is made on the spec, it would be rather confusing = that we have announcement about mandatory feature.
=A0

I think it would make the spec more consequent, and the change is minimal, = e.g. it's a 1 liner for Chrome:

Yes
=A0
--047d7b5d27fcc46b7e04df0c651b-- From webmaster@zaphoyd.com Thu Jun 13 14:33:50 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBDE21F9AE3 for ; Thu, 13 Jun 2013 14:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iatu9qQgnm7c for ; Thu, 13 Jun 2013 14:33:44 -0700 (PDT) Received: from sh78.surpasshosting.com (sh78.surpasshosting.com [72.29.64.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA3721F9A71 for ; Thu, 13 Jun 2013 14:33:44 -0700 (PDT) Received: from ranna.uchicago.edu ([128.135.45.206]:52897) by sh78.surpasshosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UnF9I-0003Mp-PT; Thu, 13 Jun 2013 17:33:42 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_AA84DDFA-C394-427C-819F-22CB2678E9BD" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Peter Thorson In-Reply-To: Date: Thu, 13 Jun 2013 16:33:39 -0500 Message-Id: <8DC56394-50A0-47F5-8E8D-87F160A46EBD@zaphoyd.com> References: <20130425140626.10027.9016.idtracker@ietfa.amsl.com> <634914A010D0B943A035D226786325D4422DC20DC7@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D4422DC213FA@EXVMBX020-12.exch020.serverdata.net> To: Takeshi Yoshino X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sh78.surpasshosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zaphoyd.com X-Get-Message-Sender-Via: sh78.surpasshosting.com: authenticated_id: webmaster@zaphoyd.com X-Source: X-Source-Args: X-Source-Dir: Cc: "hybi@ietf.org" Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-09.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 21:33:50 -0000 --Apple-Mail=_AA84DDFA-C394-427C-819F-22CB2678E9BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jun 13, 2013, at 12:23 , Takeshi Yoshino wrote: > The current draft reads: >=20 > " It is RECOMMENDED that clients implement the > "c2s_no_context_takeover" parameter." >=20 > It's not "MUST implement" .. so there might be client which won't, and = then a server has no chance to adapt it's response to the client and = maximize likelihood of connection success given it ideally wants to = activate "c2s_no_context_takeover". >=20 > Oh, this is a bug. This should be MUST. +1 >> Yes. Order means preference. The server may choose any even if it=20 >> supports all of them. >>=20 >> Do you think we need any text to make it clear? >=20 > I think it would clarify things by adding text like >=20 > """ > A server MAY choose any PMCE offered by the client and supported by = the server. > The order of PMCE offered by the client designates preference by the = client and a server SHOULD accept the first offer in the list (by order) = that it supports. > """ >=20 > This IMHO makes sense and brings the abstract description in line with = the text in "5.1. Negotiation Examples". Technically RFC6455 explicitly states that extensions are offered in = order of preference, but I agree that there should be some text here = (beyond the hints in the examples) that either references that or just = reminds implementers that this is the case.=20 Just to confirm, am I correct in assuming the following operations = shouldn't cause problems: 1. Either endpoint may unilaterally send messages compressed with a = smaller window size than the (implicit or explicit) negotiated maximum = window size. 2. Either endpoint may unilaterally reset its own context for outgoing = messages without informing the peer that it is doing so.= --Apple-Mail=_AA84DDFA-C394-427C-819F-22CB2678E9BD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 tyoshino@google.com> = wrote:

The current draft reads:

" It is RECOMMENDED that clients implement the
   "c2s_no_context_takeover" parameter."

It's not "MUST implement" .. so there might be client which won't, and = then a server has no chance to adapt it's response to the client and = maximize likelihood of connection success given it ideally wants to = activate "c2s_no_context_takeover".

Oh, this is a bug. This = should be = MUST.

+1

Yes. Order means preference. The = server may choose any even if it 
supports all of = them.

Do you think we need any text to make it = clear?

I think it would clarify things by adding = text like

"""
A server MAY choose any PMCE offered by the = client and supported by the server.
The order of PMCE offered by the = client designates preference by the client and a server SHOULD accept = the first offer in the list (by order) that it = supports.
"""

This IMHO makes sense and brings the abstract = description in line with the text in "5.1. Negotiation = Examples".

Technically RFC6455 = explicitly states that extensions are offered in order of preference, = but I agree that there should be some text here (beyond the hints = in the examples) that either references that or just reminds = implementers that this is the = case. 


Just to confirm, am = I correct in assuming the following operations shouldn't cause = problems:
1. Either endpoint may unilaterally send messages = compressed with a smaller window size than the (implicit or = explicit) negotiated maximum window size.
2. Either = endpoint may unilaterally reset its own context for outgoing messages = without informing the peer that it is doing = so.
= --Apple-Mail=_AA84DDFA-C394-427C-819F-22CB2678E9BD-- From tyoshino@google.com Fri Jun 14 03:25:49 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8CC21F9BF3 for ; Fri, 14 Jun 2013 03:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfcihehSBT3c for ; Fri, 14 Jun 2013 03:25:49 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id BB2D221F9BEB for ; Fri, 14 Jun 2013 03:25:48 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id p60so336695wes.27 for ; Fri, 14 Jun 2013 03:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OCv/6uBxHMjqiz8XK+Q9dccXpwf+rKCi0lZwWAuoUB4=; b=K93FHx1DA1bf+rheIXSfSTcj6r19HPrG6PeUIaApcWbGo01F6dioE72VWzWKBnpdd5 nLYenkkJEqpzE7t0I/zSiFp9SjusOhjWN2QOtiU0tI3CTsQQrKa16NW+lQb0mpqXRzVn +FPMBbPEpvf2qbialbF1S67aQRmJ2OOAaVoGSIzBGm8rhWnGVV+toGRY2g+bDCrsS+2I 1AQTDmCDfWeTxv54RLmCSrhaUuNenT6DqPzasBq8pNLXBtKQkoN/NMrpZR+w0OIezsOc aHPWfaRk4xY5xFRWh3dNN7xdQprnebm4bUd6GmqSxDc7XA1kvGN7Ht15rKv+G/qGouob 3CyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=OCv/6uBxHMjqiz8XK+Q9dccXpwf+rKCi0lZwWAuoUB4=; b=FyJWo2cgBkaCi9XTJOqNjAOD8M13/HLN0aS1hU/Ar8Qz5JneYRO07ZHFu6WLug/JRW KQBLdbnpE0iufs2aBhosgGRgYmt/YPUJjE7mDtZidpiZBCjYf3PecMVRw+8nvuM3Vifw bCiJaEst0xw5JzeBL/OL6zAxXudt/QZhoXUUO1X8EiaXD8FLwa9RJavwcc5hMabX7os1 E7moeW43bcvCL1SxkTS7xP3DM1Df226ujgO4ONRSTPk30Xg/7fy7zS0w7A3x469mcCZl t2wST4zWCmE1ACZHr453k6Rc5p3fpP/elBBqQtxAgNl9H3207XfqHOa9BrviIpXXm5NU OERA== X-Received: by 10.180.87.162 with SMTP id az2mr912266wib.10.1371205547352; Fri, 14 Jun 2013 03:25:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.25.230 with HTTP; Fri, 14 Jun 2013 03:25:27 -0700 (PDT) In-Reply-To: References: <634914A010D0B943A035D226786325D4422DDFD452@EXVMBX020-12.exch020.serverdata.net> From: Takeshi Yoshino Date: Fri, 14 Jun 2013 19:25:27 +0900 Message-ID: To: Tobias Oberstein Content-Type: multipart/alternative; boundary=f46d0444ecaf907c3b04df1aab5a X-Gm-Message-State: ALoCoQk2RxHUTQO1lMpgdVmiSfVVrEPPv+fZqJg3SEGnhsnvKK3MA14WHeRJ2CZ80uzlL1UdHSBIEOm/PCAnBYyMl9S9UChgkTB1542AD+Czb1ON4fGTd2zgp3tQ51d7JcNiKlrHmbCwzHPxELbyDmTGzz+IhcIg9ZaNMroqaZ22fJAvtxOAAWZVaZAVlrMLjjSyabwjFDtv Cc: "hybi@ietf.org" Subject: Re: [hybi] permessage-deflate parameter negotiation X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 10:25:49 -0000 --f46d0444ecaf907c3b04df1aab5a Content-Type: text/plain; charset=ISO-8859-1 As we're going to allow unsolicited s2c_no_context_takeover and s2c_max_window_size, maybe we should also allow client to send c2s_no_context_takeover and c2s_max_window_size if it wants. Existing client->server c2s_max_window_size without value can be kept. I.e.: - Empty client->server c2s_max_window_size means that the client can accept c2s_max_window_size. - client->server c2s_max_window_size with value X means that the client can accept c2s_max_window_size and even if the server won't send any server->client c2s_max_window_size, the client won't use window size larger than X. --f46d0444ecaf907c3b04df1aab5a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As we're going to allow unsolicited s2c_no_context_tak= eover and s2c_max_window_size, maybe we should also allow client to send c2= s_no_context_takeover and c2s_max_window_size if it wants.

Existing client->server c2s_max_window_size without value can be kept. I= .e.:
- Empty client->server c2s_max_window_size means th= at the client can accept c2s_max_window_size.
- client->= server c2s_max_window_size with value X means that the client can accept c2= s_max_window_size and even if the server won't send any server->clie= nt c2s_max_window_size, the client won't use window size larger than X.=

--f46d0444ecaf907c3b04df1aab5a-- From ricea@google.com Fri Jun 14 06:47:16 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C87C21F9C92 for ; Fri, 14 Jun 2013 06:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4-FxD4X0XX5 for ; Fri, 14 Jun 2013 06:47:15 -0700 (PDT) Received: from mail-vb0-x22a.google.com (mail-vb0-x22a.google.com [IPv6:2607:f8b0:400c:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9E39C21F9C90 for ; Fri, 14 Jun 2013 06:47:15 -0700 (PDT) Received: by mail-vb0-f42.google.com with SMTP id i3so447519vbh.1 for ; Fri, 14 Jun 2013 06:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VzCxM/PAWcqBp995OgVerrDYtbFD38NgYss5PKoYlG8=; b=MsM20si9wbBiwzVhFbqU248FpwYmV8un682wZ9C6sCP1xnB8QM5J13iZJ3unZbE1ZO yZTHhd47cY6MLUhNkFLS16q5zE3NPf3FbarVAnMluajbras3NbN4yR/N7ik8Bxn5TJFm GxEEkS9JwuvztGVywpG/MSh6Z9fFLhkS+HvLKMiJriRUgzc/JIwxHGrmj8K3gcOr54CS 9XJ9fYqwlqXlSRu6d0dYQvMWWD855EemJxZ5pAaPsnHhfoxRD25SGW88tK2SqKmmg7TG 4Qt1Y5ZKKs/9V/Tc8S/Ps4e2HiBF8IPL9kWLtewqGaDSjCU9s6YXHKgj2qyNAgi6qjQp L72w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=VzCxM/PAWcqBp995OgVerrDYtbFD38NgYss5PKoYlG8=; b=jtjMVfk6HjMXe9eIH3RR8KlpZLcl0dF5x0dHWz1LFGR5PJO8L1rxl3oCVminwE/nT3 Y59tG8DKlUOFvIBYlkOO2v3B714n/CmDzfxuJVeonu6hz6HxzWaAOfioWJLHEl3gJ60p wiED5AmwWZZJxV1eObO61a9TFdMfmOu3Ux5r3db3I/1t/hrwGGJV/n/e1Vg7rQDPyxmr 8YTWs89mfaMTp3v3TYrPyFhiTSeHqe8K6Po6N/E5sxWk6jQeZBSP4iKYXwqRR9THZAuM QqWrsBamRZ3f1bw0gJdTa1ecJV6KS2Z6P5euZRIDmS4zdd7y8knYP+iv9D/nhZkPuxtZ cgNg== MIME-Version: 1.0 X-Received: by 10.58.224.102 with SMTP id rb6mr974738vec.43.1371217634993; Fri, 14 Jun 2013 06:47:14 -0700 (PDT) Received: by 10.58.223.168 with HTTP; Fri, 14 Jun 2013 06:47:14 -0700 (PDT) In-Reply-To: References: <634914A010D0B943A035D226786325D4422DDFD452@EXVMBX020-12.exch020.serverdata.net> Date: Fri, 14 Jun 2013 22:47:14 +0900 Message-ID: From: Adam Rice To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=089e011763cd0b4d2104df1d7cfe X-Gm-Message-State: ALoCoQljUnqBCW8myiYRFxVih85/qgDTqTAon0thBPc/4vMCE4YP1g7o6rTEtNy2fE8rgfoV0/TidWEeW+MgXhRgCmLkG9Ci9VWBPQx1cVf9r8FzMJ2iHzqMcAllYD7LogIVWZ59ti1WqppeTXO0SRUcVohCgy3v/z6Ag0T/hdOn0g07FmKeT7TOqk8Ug/V3vWOjOtP76zv/ Cc: "hybi@ietf.org" Subject: Re: [hybi] permessage-deflate parameter negotiation X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 13:47:16 -0000 --089e011763cd0b4d2104df1d7cfe Content-Type: text/plain; charset=ISO-8859-1 Yes. For options where 1. The receiver could still correctly decode the frames if it ignored the option, but 2. The receiver could take advantage of the option to save resources I think it makes sense to encourage the sender to specify those options, even if unsolicited. The sender will be compliant even if it locally applies those options without telling the receiver about it, but the receiver can benefit from knowing about it. On 14 June 2013 19:25, Takeshi Yoshino wrote: > As we're going to allow unsolicited s2c_no_context_takeover and > s2c_max_window_size, maybe we should also allow client to send > c2s_no_context_takeover and c2s_max_window_size if it wants. > > Existing client->server c2s_max_window_size without value can be kept. > I.e.: > - Empty client->server c2s_max_window_size means that the client can > accept c2s_max_window_size. > - client->server c2s_max_window_size with value X means that the client > can accept c2s_max_window_size and even if the server won't send any > server->client c2s_max_window_size, the client won't use window size larger > than X. > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --089e011763cd0b4d2104df1d7cfe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes. For options where

1. The receiver = could still correctly decode the frames if it ignored the option, but
=
2. The receiver could take advantage of the option to save resources

I think it makes sense to encourage the sender to speci= fy those options, even if unsolicited. The sender will be compliant even if= it locally applies those options without telling the receiver about it, bu= t the receiver can benefit from knowing about it.


On 14 J= une 2013 19:25, Takeshi Yoshino <tyoshino@google.com> wrot= e:
As we're going to allow= unsolicited s2c_no_context_takeover and s2c_max_window_size, maybe we shou= ld also allow client to send c2s_no_context_takeover and c2s_max_window_siz= e if it wants.

Existing client->server c2s_max_window_size without value can be kept. I= .e.:
- Empty client->server c2s_max_window_size means that the= client can accept c2s_max_window_size.
- client->server c2s_m= ax_window_size with value X means that the client can accept c2s_max_window= _size and even if the server won't send any server->client c2s_max_w= indow_size, the client won't use window size larger than X.


_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi


--089e011763cd0b4d2104df1d7cfe-- From internet-drafts@ietf.org Wed Jun 19 01:31:12 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE8C21F9AFF; Wed, 19 Jun 2013 01:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEMSdo-ug3KO; Wed, 19 Jun 2013 01:31:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC9A21F9B35; Wed, 19 Jun 2013 01:31:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130619083111.29854.78694.idtracker@ietfa.amsl.com> Date: Wed, 19 Jun 2013 01:31:11 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-10.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 08:31:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the BiDirectional or Server-Initiated HTTP Wo= rking Group of the IETF. Title : Compression Extensions for WebSocket Author(s) : Takeshi Yoshino Filename : draft-ietf-hybi-permessage-compression-10.txt Pages : 27 Date : 2013-06-19 Abstract: This document specifies a framework for creating WebSocket extensions that add compression functionality to the WebSocket Protocol. An extension based on this framework compresses the payload data portion of non-control WebSocket messages on a per-message basis using parameters negotiated during the opening handshake. This framework provides a general method to apply a compression algorithm to the contents of WebSocket messages. For each compression algorithm, an extension is defined by specifying parameter negotiation and compression algorithm in detail. This document also specifies one specific compression extension using the DEFLATE algorithm. Please send feedback to the hybi@ietf.org mailing list. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hybi-permessage-compression There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hybi-permessage-compression-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tyoshino@google.com Wed Jun 19 01:38:29 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1B721F9F8A for ; Wed, 19 Jun 2013 01:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5d6-ASllVG7 for ; Wed, 19 Jun 2013 01:38:29 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id A91A221F9F84 for ; Wed, 19 Jun 2013 01:38:28 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m19so4187709wev.36 for ; Wed, 19 Jun 2013 01:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=ZkUpbCCXViqMrBnY4X/iCrgt/bBj9hrstvgJP0NB/N8=; b=U5BQRCXgXV9sHxKHtNl4ELOmnmUOkliYy6kf2hH+v+7Pj3q/pWBZC3w3JXMChhGIgy w/TZRkYjX2xnbX4Clkw/r7EQEIoy9sCbgVV5xxVGndefXeow0C0Y3VtfOItnJ4vrtYaM 6BgJ/2K4HFHpd0CIJjrO6bq5ocYE/4C2lL3IziNHaiiEciX7a8Y/xW8US93sjahZWKkc wgQPz1sJFb7YoynU7yMogB28pKgnb0+WxcBnEU22SLSJRd4HSGiGMN6zD3gznMHIfMmP eCcc/sfdZf4zYROE4Eqy3c3LVFimCtDA3UhlDLnCAKmfEyY1KEEq10LHuEV5heMp7udw BAJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=ZkUpbCCXViqMrBnY4X/iCrgt/bBj9hrstvgJP0NB/N8=; b=iEkW2FcpXSi74N6mqMoM9Qq6HNSlJmKxm++6zryzIUEOPllACvgW0+QOHTCgaGB5Vt UFnqrmuSAHDxzCTmw3olQSYZqdQDlzBN8SU0gBLW21/idFux9NmMGQG+7+S7zLjkWvBJ sqnNOKSwh80RW63XTKkQXGTADLG9BvzghoZJ+z5Y1fv8z1BJ5bOqQb3aKIaoD9jD6Ptt x0MZJVB4ridhO5ubAmekwqK7dUD1iqqi1wXGmdIaCyxXmJrOJBflnRSel3k/MOrj5T6o LtGP3yJzKNThM42xSLdcwvotGL0DWsF7jRhTk7euMJEufRMUHcKzi1q2UJWv8M0G1f1I qGVg== X-Received: by 10.180.87.162 with SMTP id az2mr10236654wib.10.1371631107626; Wed, 19 Jun 2013 01:38:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.175.161 with HTTP; Wed, 19 Jun 2013 01:38:07 -0700 (PDT) In-Reply-To: <20130619083111.29854.78694.idtracker@ietfa.amsl.com> References: <20130619083111.29854.78694.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Wed, 19 Jun 2013 17:38:07 +0900 Message-ID: To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary=f46d0444ecafeef76c04df7dc0bf X-Gm-Message-State: ALoCoQk5lBf4I93m8+swKRXMy5QMUZZX1+pcU7+FTxQ/MCm4R7CAwO3gtWztl/H+pP4k+K9MJOMRKhUVtesZYGxT5dQs/nnt+o4o8oYYusFGj/LtmyZPGyKoVl5bYQ9cFCokCqWnVACAtExXqZMXuSn1FeiodSl0kL1iRLA6et6FDH4EjHEA1gfTtYmcIWk91EcjXOotR73M Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-10.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 08:38:29 -0000 --f46d0444ecafeef76c04df7dc0bf Content-Type: text/plain; charset=ISO-8859-1 Changes - defined "accept" and "decline" - note about the relation between order of elements and PMCE preference - unsolicited server-to-client s2c_no_context_takeover and s2c_max_window_bits. - unsolicited client-to-server c2s_no_context_takeover and c2s_max_window_bits with value. They server as hints. - made server-to-client s2c_no_context_takeover mandatory for clients Takeshi On Wed, Jun 19, 2013 at 5:31 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the BiDirectional or Server-Initiated HTTP > Working Group of the IETF. > > Title : Compression Extensions for WebSocket > Author(s) : Takeshi Yoshino > Filename : draft-ietf-hybi-permessage-compression-10.txt > Pages : 27 > Date : 2013-06-19 > > Abstract: > This document specifies a framework for creating WebSocket extensions > that add compression functionality to the WebSocket Protocol. An > extension based on this framework compresses the payload data portion > of non-control WebSocket messages on a per-message basis using > parameters negotiated during the opening handshake. This framework > provides a general method to apply a compression algorithm to the > contents of WebSocket messages. For each compression algorithm, an > extension is defined by specifying parameter negotiation and > compression algorithm in detail. This document also specifies one > specific compression extension using the DEFLATE algorithm. > > Please send feedback to the hybi@ietf.org mailing list. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-hybi-permessage-compression > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-10 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-hybi-permessage-compression-10 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --f46d0444ecafeef76c04df7dc0bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Changes
- defined "accept" and &= quot;decline"
- note about the relation between order of ele= ments and PMCE preference
- unsolicited server-to-client s2= c_no_context_takeover and s2c_max_window_bits.
- unsolicited client-to-server c2s_no_context_takeover and c2s_m= ax_window_bits with value. They server as hints.
- made ser= ver-to-client s2c_no_context_takeover mandatory for clients

Takeshi


On Wed, Jun 19, 2013 at 5:31 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the BiDirectional or Server-Initiated HTTP = Working Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Compression Extensions for WebS= ocket
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Takeshi Yoshino
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-hybi-permessage-compre= ssion-10.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 27
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-06-19

Abstract:
=A0 =A0This document specifies a framework for creating WebSocket extension= s
=A0 =A0that add compression functionality to the WebSocket Protocol. =A0An<= br> =A0 =A0extension based on this framework compresses the payload data portio= n
=A0 =A0of non-control WebSocket messages on a per-message basis using
=A0 =A0parameters negotiated during the opening handshake. =A0This framewor= k
=A0 =A0provides a general method to apply a compression algorithm to the =A0 =A0contents of WebSocket messages. =A0For each compression algorithm, a= n
=A0 =A0extension is defined by specifying parameter negotiation and
=A0 =A0compression algorithm in detail. =A0This document also specifies one=
=A0 =A0specific compression extension using the DEFLATE algorithm.

=A0 =A0Please send feedback to the hybi@ie= tf.org mailing list.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-hybi= -permessage-compression

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-hybi-permessa= ge-compression-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-hybi-permessage-compression-10


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--f46d0444ecafeef76c04df7dc0bf-- From tyoshino@google.com Wed Jun 19 01:44:40 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B47421F9FB3 for ; Wed, 19 Jun 2013 01:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vh6ZWzLBPDtr for ; Wed, 19 Jun 2013 01:44:39 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id AFD7821F9FB9 for ; Wed, 19 Jun 2013 01:44:35 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so4292960wes.3 for ; Wed, 19 Jun 2013 01:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pFKELdCEO23SeDjQLjgyc7z8jNX9AKIvJtTwPxWk+Ek=; b=CF0jph0VyrR8sXp6oZBH0RsK3rE1ecO/hTYQyk4asheFVFBPjfjJyaY5eVqMHZRrFO kF9N+krwiVxnMV+bk6HPpzOFhXUtfICeD2YCX3r1f6NLQSrIcR5D9n6Rc0bQ627joV7Z gqiSf9K33r4xREY9TsADGzN6G+FnRC+P7DL1eFGTTNXXFlXDETo+p/sto8/fQ14UrY7G XxCDhQg2YJwJXH+HDHB11FSGqXjJX7ypllK8pAz1vVXuWmQWRDp5sugZ3SM4zked4Nbt 8V1QyGi6Im4ClhghX6BfVDaUqBag422SZVCvw+nQxw5sYKA2NeIMv/pHO+TsG1QbhS7B YIoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=pFKELdCEO23SeDjQLjgyc7z8jNX9AKIvJtTwPxWk+Ek=; b=HUxxeEZ6jNv8dmkdxBZ76eegcNU59fHtvAnv9+E6Lfx0dIJ+L+BriWVapobvb1VdVm GXVnawdbbwq3SnQH6/YSxjl9E/Js7gk2reWbR+prww3GpfyTLSVt5F7v5Gp3e3ogyv4J EKHjfF976Zo7qf1l2pqlIgTPrwBGvLTdWWAp12iZpVcNrGapWjp+CIJhBL+4GXDIsksl xyPDXld3eFg0iIEeqxFsbO/y3cKWoZft/L3A5tAZxMcmTpKyBwwb8GquNlHRIa/QfHA6 1xn9SYWEmeRujolKyaAEVlzeuUJRiIiSg0OFV3zTeBQCDpkk7X/SKe7lnxEmiwhOl9tY gk4A== X-Received: by 10.194.108.73 with SMTP id hi9mr1290074wjb.85.1371631472576; Wed, 19 Jun 2013 01:44:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.175.161 with HTTP; Wed, 19 Jun 2013 01:44:12 -0700 (PDT) In-Reply-To: References: <634914A010D0B943A035D226786325D4422DDFD452@EXVMBX020-12.exch020.serverdata.net> From: Takeshi Yoshino Date: Wed, 19 Jun 2013 17:44:12 +0900 Message-ID: To: Adam Rice Content-Type: multipart/alternative; boundary=047d7bf10b28afac9c04df7dd676 X-Gm-Message-State: ALoCoQkY5KAVIqUjpeyxdo9NS4GJE+8R9OY90rdnD1wgrdtwfawaw37/cFgKFIwHamwzp4Zwku3litF1TG/it+CBw2VBWutSs5kUHnw9NF/sv5ZUmGkMwS6ib8aDRvHNZGizeiqcIbaJxTwbEApzvc0NC+5y1DvLvUNw0sgWIzwirGf/EOE/47LfUmj2I1Odht/LMto2lqlI Cc: "hybi@ietf.org" Subject: Re: [hybi] permessage-deflate parameter negotiation X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 08:44:40 -0000 --047d7bf10b28afac9c04df7dd676 Content-Type: text/plain; charset=ISO-8859-1 Thanks Adam, Tobias. I've incorporated proposal in this thread into -10 draft.. --047d7bf10b28afac9c04df7dd676 Content-Type: text/html; charset=ISO-8859-1
Thanks Adam, Tobias. I've incorporated proposal in this thread into -10 draft..

--047d7bf10b28afac9c04df7dd676-- From tyoshino@google.com Wed Jun 19 01:48:59 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C76D21F9F5F for ; Wed, 19 Jun 2013 01:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62VXD+CQ-OXH for ; Wed, 19 Jun 2013 01:48:59 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id AB96E21F9EBC for ; Wed, 19 Jun 2013 01:48:58 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x54so4279647wes.32 for ; Wed, 19 Jun 2013 01:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fV7rUWRJ2T1bfpGpHSKh1F3mbHGyusMhNXczdgk2bkE=; b=clcQ4VeHgI0n1BBnxVgDqQxEj2E/HgxNyNmJArj/iKkspNscI/kmdyg/Plcff30aeS dp17gk2q6OXwBEV95S6Mp8YCK7nldEhSsMDZFjn+Q1ssQQSgHwBVoIE94U3z+bYtkQNr A+AEwvLNiS5CFgTaQDbUrnRnWYL+3qIV/xzR2YWat7dIe8zLAzrAW4N3vUlvqViT8ZWY wXmd9Pz5bpQcE5vDggrCVrnC9tI2V0sucmvOS12iSg17MPwHiqwCYVwunyvoWmivBw7y khlYldPsCuymCynDme/Rt6uL68UEkLS/grkhtCJ63ZL2Mw5NUGTSffaXwi1Xk9+DYoYV 4nqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=fV7rUWRJ2T1bfpGpHSKh1F3mbHGyusMhNXczdgk2bkE=; b=YUgozr5UNXs1Pk6bW9/zVc+QAf77ucNYnIt8T1gNCMjnLCvLCnrn+7PZL3dB4tfciV BsoEz0/COmZX04+27JPRHrR1LMNSLe00HU7YpYNWF2ojdcaIwOIxB9ETE1CqJtrWr3rM MnWXCZALewMBl06adkkPPs7yW6rvcXfI7dPvkJ56VexGkoPSOZnUu09rn5lCYu3fMeAM ErAQVsRbyGImiw4aCnYPDg3psk4NgB+MhpwVd27mUEm6OIsLkO7KYbPE5c8k0hrihwRX MOqsx2gR42sHFrL75yc9Psjgk7Ur6gd4SIadLz0lx4WxGMrSVkPFHUU3ZUpPsi77C9hQ wawg== X-Received: by 10.194.21.231 with SMTP id y7mr1276363wje.94.1371631737604; Wed, 19 Jun 2013 01:48:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.175.161 with HTTP; Wed, 19 Jun 2013 01:48:37 -0700 (PDT) In-Reply-To: <8DC56394-50A0-47F5-8E8D-87F160A46EBD@zaphoyd.com> References: <20130425140626.10027.9016.idtracker@ietfa.amsl.com> <634914A010D0B943A035D226786325D4422DC20DC7@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D4422DC213FA@EXVMBX020-12.exch020.serverdata.net> <8DC56394-50A0-47F5-8E8D-87F160A46EBD@zaphoyd.com> From: Takeshi Yoshino Date: Wed, 19 Jun 2013 17:48:37 +0900 Message-ID: To: Peter Thorson Content-Type: multipart/alternative; boundary=047d7b5d27fc7ba38b04df7de6d5 X-Gm-Message-State: ALoCoQkIQe9Uj+SRTyjqCpifLzUH3t36p+uATfQRVaIu7j4QzL7ua2/ZLsWfPtdH3+LGOyUDzmXnNdnfHei67yOIGQqk7M7MRswER8aNsAzdIUIktSW2uwecd4UlPmBHDkYivVT/63RljMWAAlQdiHVEdXjaZszF+A7FnZYbVjmivjv5UcB/hsYDuE+Qs4f2ZuBnC/lCh9Wt Cc: "hybi@ietf.org" Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-09.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 08:48:59 -0000 --047d7b5d27fc7ba38b04df7de6d5 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 14, 2013 at 6:33 AM, Peter Thorson wrote: > Just to confirm, am I correct in assuming the following operations > shouldn't cause problems: > 1. Either endpoint may unilaterally send messages compressed with a > smaller window size than the (implicit or explicit) negotiated maximum > window size. > Y. Decompressor with larger window works for data compressed with smaller window. > 2. Either endpoint may unilaterally reset its own context for outgoing > messages without informing the peer that it is doing so. > Y. Just data after reset doesn't have back reference to the old context. Decompressor still holds old history which new frames never refer, but works for them. --047d7b5d27fc7ba38b04df7de6d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 14, 2013 at 6:33 AM, Peter Thorson <web= master@zaphoyd.com> wrote:
Just to = confirm, am I correct in assuming the following operations shouldn't ca= use problems:
1. Either endpoint may unilaterally send messages compressed with= a smaller window size than the (implicit or explicit)=A0negotiated maximum= window size.

Y. De= compressor with larger window works for data compressed with smaller window= .
=A0
2. Either endpoint may unilaterally reset its own context f= or outgoing messages without informing the peer that it is doing so.

Y= . Just data after reset doesn't have back reference to the old context.= Decompressor still holds old history which new frames never refer, but wor= ks for them.

--047d7b5d27fc7ba38b04df7de6d5-- From tyoshino@google.com Wed Jun 19 01:54:17 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FDE21F9F46 for ; Wed, 19 Jun 2013 01:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmv-5ZfSaF14 for ; Wed, 19 Jun 2013 01:54:17 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id EF6E421F9EBC for ; Wed, 19 Jun 2013 01:54:16 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id k10so392322wiv.11 for ; Wed, 19 Jun 2013 01:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jf55uQDu2/NEzxHVpQZ1Rw2r8WmkZeg9YABpuZ5SkvQ=; b=oHgerJ3MFRnjuvW2VRGaAYD81M7h3glHTzSB91Q8UA7NiQhlTnyucKEbjj8iwClN4G 0XWLGhNpwrCTdft23Nesa8KQGSqRCZAq0CaSfrGEg9GrZL7F1CeYudewXVyErDGqyZcI oT/bDHSl7nOXM09tkZ+KgYphCN0iTLeWed8iwdbOkvfRLmgxETqpgNTf8DAy4O/KRql6 Je8G5MOOm4CXpuzJAkPreI0hMq8FsKKVg5+Amp0+7vGzaL7qezmxW5u4YDyjS23gVfom CsA2Hv4FD4vCfPnczLpYAhacdwTaLAdlMSKgsDt+nbtcB1donXjvzCe0+6poxrXWnWzS Y2IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=jf55uQDu2/NEzxHVpQZ1Rw2r8WmkZeg9YABpuZ5SkvQ=; b=UOpDEFiwXYaI9QMPbBX5MMHmX5y3UqpaVsAYfKPPCG1UOKvE5hCPSzlITvAwe9InY+ lYotg/NGnwCZj993thwZyBPJDEDZzkgFd0Ffq+nOCEz+AS+3qJnFSCq9h+kOFw7ujMGb peklSTeBQKxcEdMn6/oe1QoUiz30RpjS1IIdnRiVnaw+WIJ59vupEz0++BPK5COFVoLp guD89/U2desBv0NxeShtE+catdImj+WX+uFvxMstm4h3OA86h29nUsZ2HFUNNVvC6CVm xJzO4jXjDmgTKfE45Gf8VNeKtOTN9YNK68Q50O1AzQN1207oFn6ye4IijwcGM9WaFNLn u5bg== X-Received: by 10.194.47.167 with SMTP id e7mr889497wjn.57.1371632056036; Wed, 19 Jun 2013 01:54:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.175.161 with HTTP; Wed, 19 Jun 2013 01:53:55 -0700 (PDT) In-Reply-To: References: <20130425140626.10027.9016.idtracker@ietfa.amsl.com> <634914A010D0B943A035D226786325D4422DC20DC7@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D4422DC213FA@EXVMBX020-12.exch020.serverdata.net> <8DC56394-50A0-47F5-8E8D-87F160A46EBD@zaphoyd.com> From: Takeshi Yoshino Date: Wed, 19 Jun 2013 17:53:55 +0900 Message-ID: To: Peter Thorson Content-Type: multipart/alternative; boundary=047d7b86e5f076880e04df7df916 X-Gm-Message-State: ALoCoQlZKILclpw1wPMMmVbA759yY1OBFDf9+NTeYLLGBM8REUM5U4uiHFV9E3aVWmNof+HskxsC2zI1TDWCzTTdMIfZ4xiFABNqob8AXUDBdYCqjfQG64StdFEHUpv9cv3e142mZ+kLDs/klf7oLzn7sJ3ENFsiO6dxEWBFdsYEymIkQ+4i3fyc2bOkcUzp4RADk3/x1ge9 Cc: "hybi@ietf.org" Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-09.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 08:54:17 -0000 --047d7b86e5f076880e04df7df916 Content-Type: text/plain; charset=ISO-8859-1 I've fixed bugs reported in this thread in -10 draft. It's still ignoring bad offers. It does not fail. Anyone else has opinion on this? --047d7b86e5f076880e04df7df916 Content-Type: text/html; charset=ISO-8859-1
I've fixed bugs reported in this thread in -10 draft.

It's still ignoring bad offers. It does not fail.
Anyone else has opinion on this?
--047d7b86e5f076880e04df7df916-- From tyoshino@google.com Wed Jun 19 02:09:49 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69C421F9FB8 for ; Wed, 19 Jun 2013 02:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxfDdO7f6Koz for ; Wed, 19 Jun 2013 02:09:49 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id AEAD221F9F9F for ; Wed, 19 Jun 2013 02:09:48 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id t56so4225821wes.35 for ; Wed, 19 Jun 2013 02:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=qovP5AqaFD3QUIIkoF4Tn0GyVH91k7NBvfQvsw0G65Q=; b=OmO4RHMT7cLPWV+6sLX6vQ9BpbKqCKV2roa9AsePsiCLpDQjkWHADI0/sFhps6qcGR cbRmJMbyWZq2IxDJkzfvEyU2rAUOANoRZRnYS4mFkDpCAiqjd9BE7+wuRdFnYkJ6pEIH W6ICsLQ5Q5LNbvgpmjF2FydA8SMUW2ttssWVjF0c0+a+itqRZ3iZwg0C08ZJZC++jFjb xMZQaXye440xW9AVnWbMAcV51JzCx9AtFlddNceoXnPPyUor4E2NtYFw33+PiCP/ISjK PqgS7Tyl+kBnZH2bIYKwGLIANjJi6rRkwHGI4Cd7UEJIV7g1hK/nPRxpGc1cXrF48z81 tHrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=qovP5AqaFD3QUIIkoF4Tn0GyVH91k7NBvfQvsw0G65Q=; b=m+daxg7YgaCabnQSiwagZu/EB73sDvSW98lk72EJPv91zWjobMXZttd9R9Vy+omCsF gg+De8Me7vYR4/YdRDLMhl2sGxQRJZUiEUHZnC+hUHDtrDn4QY1GzA33eoES+0coq+m/ LrvOkZgVpxV9Rz8xT2kY4OfwIQUumyZ6v33errDn4uZXsd00uN1+wk4p7+nGOBKl3O/c j7E+k/tLUYUIQTrPGChIrRQdGWmVs37vU4lTN9ivUI47to3bVCsYeI1Vc4I45LzyQRme 2sJSChI1DOevxuHN12Mrr6bR5j5cX2HqwB/JQ9uA3PCqpIBQAwWOj7R55L6/btgrkt5J EPow== X-Received: by 10.180.36.12 with SMTP id m12mr1374463wij.10.1371632987373; Wed, 19 Jun 2013 02:09:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.175.161 with HTTP; Wed, 19 Jun 2013 02:09:27 -0700 (PDT) In-Reply-To: References: <20130619083111.29854.78694.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Wed, 19 Jun 2013 18:09:27 +0900 Message-ID: To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f5030acf9af5404df7e3010 X-Gm-Message-State: ALoCoQlmwnHQqZ1ERefM6RhchZDMFNQvQKbU7Dr820Uaez/JXlTeqpJkiNMmUevnhoYGCZ9ygP4MGcI3H9Ez5C6jbdebJN2GIu2h57z/k4k9MJIEU/mZ/Hr5iZ5H96bDl9TDRJK+FzajQYBok0tiASTG5rQqm+6xHq4Q30mKS6uVTgGXsQvAURTz2EDoakfKSI8ih4qc8Qg+ Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-10.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 09:09:50 -0000 --e89a8f5030acf9af5404df7e3010 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 19, 2013 at 5:38 PM, Takeshi Yoshino wrote: > Changes > - defined "accept" and "decline" > - note about the relation between order of elements and PMCE preference > - unsolicited server-to-client s2c_no_context_takeover and > s2c_max_window_bits. > - unsolicited client-to-server c2s_no_context_takeover and > c2s_max_window_bits with value. They server as hints. > s/server/serve/ Now, In an extension offer: - s2c_no_context_takeover: constraint request - s2c_max_window_bits: constraint request - c2s_no_context_takeover: hint - c2s_max_window_bits: capability announcement and (optionally) hint In a reponse: - s2c_no_context_takeover: acknowledgement or unsolicited configuration announcement - s2c_max_window_bits: (possibly tighter) acknowledgement or unsolicited configuration announcement - c2s_no_context_takeover: constraint request - c2s_max_window_bits: constraint request Even after this change, my answer to Joakim's question [1] still works. hints and configuration announcements can be simply ignored if the endpoint don't want to utilize them. [1] https://www.ietf.org/mail-archive/web/hybi/current/msg10023.html --e89a8f5030acf9af5404df7e3010 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 19, 2013 at 5:38 PM= , Takeshi Yoshino <tyoshino@google.com> wrote:
Changes
- defined "accept&= quot; and "decline"
- note about the relation between order of elements and PMCE preference
- unsolicited server-to-client s2c_no_context_takeover and s2c_max_w= indow_bits.
- unsolicited client-to-server c2s_no_context_takeover and c2s_max_win= dow_bits with value. They server as hints.
s/server/serve/

Now,

In an extension offer:
- s2c_no_con= text_takeover: constraint request
- s2c_max_window_bits: constrai= nt request
- c2s_no_context_takeover: hint
- c2s_max_window_bits: capability announcement and (optionally) hint

In a reponse:
- s2c_no_context_takeover: = acknowledgement or unsolicited configuration announcement
- s2c_max_window_bits: (possibly tighter) acknowledgement or unsolicit= ed configuration announcement
- c2s_no_context_takeover: constrai= nt request
- c2s_max_window_bits: constraint request

Even after this change, my answer to Joakim's quest= ion [1] still works. hints and configuration announcements can be simply ig= nored if the endpoint don't want to utilize them.

=A0
--e89a8f5030acf9af5404df7e3010-- From wb@wbudd.com Wed Jun 19 18:23:07 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0326A21F9F11 for ; Wed, 19 Jun 2013 18:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTPhWqAPAGN2 for ; Wed, 19 Jun 2013 18:23:06 -0700 (PDT) Received: from mail.wbudd.com (li327-245.members.linode.com [66.228.46.245]) by ietfa.amsl.com (Postfix) with ESMTP id AA26D21F9F04 for ; Wed, 19 Jun 2013 18:23:06 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.wbudd.com (Postfix) with ESMTPSA id 899531044A for ; Thu, 20 Jun 2013 10:23:05 +0900 (JST) Received: by mail-qc0-f176.google.com with SMTP id z10so3380564qcx.21 for ; Wed, 19 Jun 2013 18:23:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=h4X6bLDNfJif3qaQHwE2ZfHvHg9Q5rYuOoQC5u3bHng=; b=EzFkh4kPwXTKPVQYoy/nnG6+29+xd2MIED9tzKSoxUvv01IfA6Pvozy1mpMy33MlK2 j5ERpA54CSYEZlSIT04Jk0Lk6p8MK32yzxMFbvdqAJ62e0ne7tAGLw5FTQUrNEA3HU19 /zRrUEBX6075deSN2jaatctBUi+Ces0z/dXLM9NZdMAoq/zwdfYZnUbTNMsVD5whcoZB RAAiftSTXljWFCOD9dQkEjLTYjPmTs3DXFRcMEjbH4osvQ8EDLO3IO1wItfX/O+xEhlI 7BbrNkT/WzDKzv8u4YInyFHXe9LTZrMLFONs2QC3tqkzbdk9X9yasMTekFSx60o6rtaw 5VDw== MIME-Version: 1.0 X-Received: by 10.229.78.213 with SMTP id m21mr2074336qck.55.1371691385214; Wed, 19 Jun 2013 18:23:05 -0700 (PDT) Received: by 10.49.58.174 with HTTP; Wed, 19 Jun 2013 18:23:05 -0700 (PDT) Date: Thu, 20 Jun 2013 10:23:05 +0900 Message-ID: From: William Budd To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 01:29:55 -0000 Hello everyone, While I find RFC 6455 very reasonable all around, there is one consequence of the spec with regard to fragmentation that seems quite unfortunate to me. First off, the following reasoning is given in favor of fragmentation: "The primary purpose of fragmentation is to allow sending a message that is of unknown size when the message is started without having to buffer that message. If messages couldn't be fragmented, then an endpoint would have to buffer the entire message so its length could be counted before the first byte is sent. With fragmentation, a server or intermediary may choose a reasonable size buffer and, when the buffer is full, write a fragment to the network. A secondary use-case for fragmentation is for multiplexing, where it is not desirable for a large message on one logical channel to monopolize the output channel, so the multiplexing needs to be free to split the message into smaller fragments to better share the output channel. (Note that the multiplexing extension is not described in this document.)" And I completely agree with that. Large messages need to be fragmented in order to be processed efficiently by websocket endpoints and intermediates. However, I think the spec should also make provisions against over-fragmentation. Unless I overlooked something, RFC allows any message to be split into an infinite amount of fragments with payloads of 0 bytes (or if I'm wrong about that, it still allows a message to be fragmented in a nutty number of fragments with 1 byte); and endpoints need to handle that in order to comply with RFC 6455. This is particularly annoying when a websocket server wants to guard against denial of service attacks, because in the case of deliberately over-fragmented messages the server needs to process an excessive (or infinite?) amount of framing data before it has enough payload data to determine whether the message is valid with regard to any API built on top of the websocket layer. This issue could be easily prevented if websocket frames that do not have the FIN bit set need to specify a payload of at least X bytes (where I would vote for X to be 125, but could conceivably be as small as 8 or so bytes). Any non-FIN frames smaller than X could then simply be declined with a 1002 protocol error. A nice side effect of this measure would be that special purpose websocket servers that serve an API which never expects payloads of more than (X - 1) bytes, wouldn't need to handle fragmentation at all (because the maximum expected valid payload size would be reached before any continuation frame arrives or is parsed). Of course, all of this depends on the presence/absence of valid use cases for non-final frames with tiny payloads. I can't think of any (which is why I'm writing this email), so please inform of such cases if they do exist. If so, would they smaller than 125 bytes? How small do they need to be, and why? Hoping to get some constructive feedback, if only to inform myself better. Also, sorry if this has been brought up before (but a few cursory Google search made me none the wiser). Regards, Will From tyoshino@google.com Thu Jun 20 00:28:12 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6665011E810C for ; Thu, 20 Jun 2013 00:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrLnzRMA4XLn for ; Thu, 20 Jun 2013 00:28:11 -0700 (PDT) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4350B11E810B for ; Thu, 20 Jun 2013 00:28:10 -0700 (PDT) Received: by mail-ea0-f170.google.com with SMTP id h10so3807622eaj.1 for ; Thu, 20 Jun 2013 00:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MrXHIHt2ZUjy1Ij761ot4Yzm7YNpFNxowq/M6KIf2pU=; b=hBVYiIDJzsCJFDvxh8B4WCcYTO5AddV6S60KZ2TdoguW9J8IsqjfCP5uajgs9L9v1d 0MjnLqETY9JAA8zjvkWxojaorsHRigDp6dLXMP4qTTnkNqkJevJ3bFZKbHETueqsLnmm t1VB27UOZ67AqIz8Lj4Al2mcuZBf38lARtSUwCU1CskluD+9aTcY1YrJgCa9uUGLBQei pPtvEzk6PLOH5mftNTpEOUX1r8fBiqXs0Nausa8SRk77qs8Es3PGhNdw6Y2UVBsl1TNe 1JPWqjP5um+QGBj9GnHTJgrnpa2ioI5JplbpEBSmYmO/JoZ3GTiEH0yz3/PrkZvdWbbf 7tpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=MrXHIHt2ZUjy1Ij761ot4Yzm7YNpFNxowq/M6KIf2pU=; b=YcmJRVzwxwowmKi0MfZSmz+DLoEL1foroCLHVe4BcGlK0cwVeenH0zeLgAqVmSXT8F lUTKo2Xk1PVdostJYC8tiogg+n/bO0qLrqG4QjMjM66szahUCQXi9NQ485+I4RQoBr7y OBlccs3yoeEqI81bnZriENdWuqYPD4MqN51bQ3lbSquttH/dEcd3FKcU87kqxwS+WJgL Wx28sbwTRFsj6stryTKZs6U0QtmwoRUeHxuDAy7arzfw1lw2NWr3KlJS3TSNKt0vxoRX 54RMLL/PsLcJQ3H/fepTGV8Wl8I5xzSGL7LigL7TzS2xCbTxva5L03lg43ce1Od/F/KH R9Sw== X-Received: by 10.15.63.204 with SMTP id m52mr6190169eex.59.1371713289999; Thu, 20 Jun 2013 00:28:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.86.67 with HTTP; Thu, 20 Jun 2013 00:27:48 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Thu, 20 Jun 2013 16:27:48 +0900 Message-ID: To: William Budd Content-Type: multipart/alternative; boundary=001a1132f848629e0004df90e346 X-Gm-Message-State: ALoCoQlkKf84sTXqlwUOe5OV4B96KdCAqmBVYy4vz9+WRlY35hvxMv34OFPxb7oY3NAbt+LoOUaBiQy+U07KGlo3qjHOE5MENCkxEDd8NkXEL2GqEY3ngitKQ9NFfhMLQqmA2+Vv9OBOKcrEWMWfAD4/0MHdz2DQ53onS3JtXeQJWlsn0fDOGLMy8n+o5KPskvu2NDSyxRXh Cc: "hybi@ietf.org" Subject: Re: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 07:28:12 -0000 --001a1132f848629e0004df90e346 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 20, 2013 at 10:23 AM, William Budd wrote: > This is particularly annoying when a websocket server wants to guard > against denial of service attacks, because in the case of deliberately > over-fragmented messages the server needs to process an excessive (or > Guard against this kind of attack could be done by frame/sec limit, fragments/message limit, idle (no new payload octet coming) timeout, etc. > infinite?) amount of framing data before it has enough payload data to > determine whether the message is valid with regard to any API built on > top of the websocket layer. > With this change, we can delegate DoS detection to code after defragment. I agree that it's useful. For keep-alive we already have ping/pong, so nobody should miss empty (non-first && non-last) frames. > This issue could be easily prevented if websocket frames that do not > have the FIN bit set need to specify a payload of at least X bytes > I'd relax it to "!FIN && !first". > (where I would vote for X to be 125, but could conceivably be as small > as 8 or so bytes). Any non-FIN frames smaller than X could then simply > If we were still standardizing per-frame mux, I'd say "this could be source of head of line blocking when used for multiplexing. Though 125 sounds small enough not to clog multiplexed connection, I don't want X to be greater than 1". But now in the latest mux spec, we're encapsulating fragments into messages. So, it's fine wrt current mux spec. > (which is why I'm writing this email), so please inform of such cases > if they do exist. If so, would they smaller than 125 bytes? How small > do they need to be, and why? > Personally, I think fragmentation should be completely transparent to semantics of messages. And, nowadays, there shouldn't be any device that cannot afford 125B/connection buffer while paying extra network overhead for small fragments. So, I don't come up with any real/concrete concern for now. > Hoping to get some constructive feedback, if only to inform myself > better. Also, sorry if this has been brought up before (but a few > cursory Google search made me none the wiser). > IIRC, no. I don't want to get bothered by minimum transmission unit when flushing data, but in practice, we're always asked to consolidate small chunks if possible to reduce overhead, and we do so. Sorry for rambling response. Thanks --001a1132f848629e0004df90e346 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 20, 2013 at 10:23 AM, William Budd <wb@wbudd.com= > wrote:
This is particularly annoying when a websocket server wants to guard
against denial of service attacks, because in the case of deliberately
over-fragmented messages the server needs to process an excessive (or

Guard against this kind of attack could be d= one by frame/sec limit, fragments/message limit, idle (no new payload octet= coming) timeout, etc.
=A0
infinite?) amount of framing data before it has enough payload data to
determine whether the message is valid with regard to any API built on
top of the websocket layer.

With = this change, we can delegate DoS detection to code after defragment. I agre= e that it's useful. For keep-alive we already have ping/pong, so nobody= should miss empty (non-first && non-last) frames.
=A0
This issue could be easily prevent= ed if websocket frames that do not
have the FIN bit set need to specify a payload of at least X bytes

I'd relax it to "!FIN &&= !first".
=A0
(where I would vote for X to be 125, but could conceivably be as small
as 8 or so bytes). Any non-FIN frames smaller than X could then simply
<= /blockquote>

If we were still standardizing per-fr= ame mux, I'd say "this could be source of head of line blocking wh= en used for multiplexing. Though 125 sounds small enough not to clog multip= lexed connection, I don't want X to be greater than 1".

But now in the latest mux spec, we're e= ncapsulating fragments into messages. So, it's fine wrt current mux spe= c.
=A0
(which is why I'm writing this email), so please inform of such cases
if they do exist. If so, would they smaller than 125 bytes? How small
do they need to be, and why?

Pers= onally, I think fragmentation should be completely transparent to semantics= of messages. And, nowadays, there shouldn't be any device that cannot = afford 125B/connection buffer while paying extra network overhead for small= fragments. So, I don't come up with any real/concrete concern for now.=
=A0
Hoping to get some constructive feedback, if only to inform myself
better. Also, sorry if this has been brought up before (but a few
cursory Google search made me none the wiser).

IIRC, no.

I don't want to get bo= thered by minimum transmission unit when flushing data, but in practice, we= 're always asked to consolidate small chunks if possible to reduce over= head, and we do so.

Sorry for rambling response.
Than= ks
=A0
--001a1132f848629e0004df90e346-- From wb@wbudd.com Thu Jun 20 04:12:55 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDEF21F9A4A for ; Thu, 20 Jun 2013 04:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyvoeBrvUGVd for ; Thu, 20 Jun 2013 04:12:50 -0700 (PDT) Received: from mail.wbudd.com (li327-245.members.linode.com [66.228.46.245]) by ietfa.amsl.com (Postfix) with ESMTP id D5B8E21F9A40 for ; Thu, 20 Jun 2013 04:12:49 -0700 (PDT) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.wbudd.com (Postfix) with ESMTPSA id 1B993FD0F for ; Thu, 20 Jun 2013 20:12:49 +0900 (JST) Received: by mail-qe0-f49.google.com with SMTP id cz11so3873598qeb.36 for ; Thu, 20 Jun 2013 04:12:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6NUzeqoLNfiQ4SWRHlDZXEfJm/TWdKZZortDCbxXq7Y=; b=Niomtw6nsQhfle5fGenUEVAOhfZpsEeRkqaCQXy1mGru3oiHCuexwoFP7JTwWOhtbl ZUPRHZTw/cYtvtuoosBBzT8aadB3vf84ap2iY63BB1fo3KH7BaYAqiItczCgqa9NpUGN dPfd9HfbOvsgXh6uFVpw8rCpM+9k/c38twoh9zV0yx9tD1F4toVZib9i02fhEMVMiTi4 bvsYwC7/tF5hSRoisc2UirUMCbdGGnArS6rD8RrV3l4AnI4DUtfaPpBGDVL6Qw4ROImb 6w2q+fuWcd7F6si32xf7wIEV9ysjQOEsNFtiuSOJwXUAsBfwvKACLfBXcM+wim/rYZHt rikw== MIME-Version: 1.0 X-Received: by 10.229.24.198 with SMTP id w6mr2720986qcb.37.1371726768847; Thu, 20 Jun 2013 04:12:48 -0700 (PDT) Received: by 10.49.58.174 with HTTP; Thu, 20 Jun 2013 04:12:48 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Jun 2013 20:12:48 +0900 Message-ID: From: William Budd To: "hybi@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [hybi] Fwd: Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 11:12:55 -0000 >> This is particularly annoying when a websocket server wants to guard >> against denial of service attacks, because in the case of deliberately >> over-fragmented messages the server needs to process an excessive (or > > Guard against this kind of attack could be done by frame/sec limit, > fragments/message limit, idle (no new payload octet coming) timeout, etc. Yes, careful timing can certainly catch a lot of unreasonable traffic (albeit at the cost of a significant processing overhead in some cases). I'm not sure what you mean by a fragments/message limit though. If a server decides to drop fragments beyond a certain fragment count, isn't that a violation of RFC 6455 (as the reason for declining would be based on the framing rather than on the contents of the payload)? >> infinite?) amount of framing data before it has enough payload data to >> determine whether the message is valid with regard to any API built on >> top of the websocket layer. > > With this change, we can delegate DoS detection to code after defragment. I > agree that it's useful. For keep-alive we already have ping/pong, so nobody > should miss empty (non-first && non-last) frames. Glad to hear that! >> This issue could be easily prevented if websocket frames that do not >> have the FIN bit set need to specify a payload of at least X bytes > > I'd relax it to "!FIN && !first". Alright, but could you give an example of when it would be desirable to make the first frame of a fragmented message (very) small? >> (where I would vote for X to be 125, but could conceivably be as small >> as 8 or so bytes). Any non-FIN frames smaller than X could then simply > > If we were still standardizing per-frame mux, I'd say "this could be source > of head of line blocking when used for multiplexing. Though 125 sounds small > enough not to clog multiplexed connection, I don't want X to be greater than > 1". > > But now in the latest mux spec, we're encapsulating fragments into messages. > So, it's fine wrt current mux spec. A fortunate coincidence. :) > I don't want to get bothered by minimum transmission unit when flushing > data, but in practice, we're always asked to consolidate small chunks if > possible to reduce overhead, and we do so. Agreed. Thank you for your thoughtful input! It would be good if other people chimed in with their opinions too, but if it turns out there are no significant drawbacks I hope said minimum size can be ratified in the next version of the websocket protocol. Best, Will From tobias.oberstein@tavendo.de Thu Jun 20 07:11:37 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C2421F944C for ; Thu, 20 Jun 2013 07:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrY+kmdAFgrx for ; Thu, 20 Jun 2013 07:11:32 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id 6831B21F9B2F for ; Thu, 20 Jun 2013 07:11:31 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.90]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Thu, 20 Jun 2013 07:11:31 -0700 From: Tobias Oberstein To: William Budd , "hybi@ietf.org" Date: Thu, 20 Jun 2013 07:11:27 -0700 Thread-Topic: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes Thread-Index: Ac5tVa+dLj4V+3cETAatWRLcCivs4wAaI3YQ Message-ID: <634914A010D0B943A035D226786325D4422DF4C171@EXVMBX020-12.exch020.serverdata.net> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 14:11:37 -0000 > However, I think the spec should also make provisions against over- > fragmentation. Unless I overlooked something, RFC allows any message to b= e > split into an infinite amount of fragments with payloads of 0 bytes (or i= f I'm > wrong about that, it still allows a message to be fragmented in a nutty n= umber > of fragments with 1 byte); and endpoints need to handle that in order to = comply > with RFC 6455. Not only endpoints, but also any intermediary.. > This is particularly annoying when a websocket server wants to guard agai= nst > denial of service attacks, because in the case of deliberately over-fragm= ented > messages the server needs to process an excessive (or If you want to protect against DoS, there a multiple scenarios not explicit= ly discussed or specified in the RFC. E.g. opening handshake timeouts, maximum frame size or excessive numbers of= ping requests. I think the decision what's acceptable depends on the concrete situation an= d application, and can be left open to implementations providing knobs for = users to adjust. So you can have a knob "minimal frame size for non-final frames" and fail t= he connection with a custom close code upon exceeding the limit. Having fixed (non-negotiated) and implicit (non-modifyable) limits for spec= ific parameters seems less desirable from my perspective. /Tobias From webmaster@zaphoyd.com Thu Jun 20 08:16:03 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A2221F9298 for ; Thu, 20 Jun 2013 08:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b82FJv3k1RO8 for ; Thu, 20 Jun 2013 08:15:48 -0700 (PDT) Received: from sh78.surpasshosting.com (sh78.surpasshosting.com [72.29.64.142]) by ietfa.amsl.com (Postfix) with ESMTP id 8A44521F9CE8 for ; Thu, 20 Jun 2013 08:15:41 -0700 (PDT) Received: from c-68-51-76-178.hsd1.il.comcast.net ([68.51.76.178]:45664 helo=[10.0.1.88]) by sh78.surpasshosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UpgaJ-00011R-BS; Thu, 20 Jun 2013 11:15:39 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Peter Thorson In-Reply-To: <634914A010D0B943A035D226786325D4422DF4C171@EXVMBX020-12.exch020.serverdata.net> Date: Thu, 20 Jun 2013 10:15:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <59AC62CE-9FFE-4DAE-A522-1D8083DE09F0@zaphoyd.com> References: <634914A010D0B943A035D226786325D4422DF4C171@EXVMBX020-12.exch020.serverdata.net> To: Tobias Oberstein X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sh78.surpasshosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zaphoyd.com X-Get-Message-Sender-Via: sh78.surpasshosting.com: authenticated_id: webmaster@zaphoyd.com X-Source: X-Source-Args: X-Source-Dir: Cc: "hybi@ietf.org" Subject: Re: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 15:16:03 -0000 On Jun 20, 2013, at 9:11 , Tobias Oberstein = wrote: >> However, I think the spec should also make provisions against over- >> fragmentation. Unless I overlooked something, RFC allows any message = to be >> split into an infinite amount of fragments with payloads of 0 bytes = (or if I'm >> wrong about that, it still allows a message to be fragmented in a = nutty number >> of fragments with 1 byte); and endpoints need to handle that in order = to comply >> with RFC 6455. >=20 > Not only endpoints, but also any intermediary.. >=20 >> This is particularly annoying when a websocket server wants to guard = against >> denial of service attacks, because in the case of deliberately = over-fragmented >> messages the server needs to process an excessive (or >=20 > If you want to protect against DoS, there a multiple scenarios not = explicitly discussed or specified in the RFC. >=20 > E.g. opening handshake timeouts, maximum frame size or excessive = numbers of ping requests. >=20 > I think the decision what's acceptable depends on the concrete = situation and application, and can be left open to implementations = providing knobs for users to adjust. >=20 > So you can have a knob "minimal frame size for non-final frames" and = fail the connection with a custom close code upon exceeding the limit. >=20 > Having fixed (non-negotiated) and implicit (non-modifyable) limits for = specific parameters seems less desirable from my perspective. >=20 > /Tobias I would argue that a WebSocket server that dropped connections = attempting to send excessive numbers of fragments (for some application = defined value of excessive) or fragments that were too small (for some = application defined value of small) with a private code or code = 1008/Policy Violation would be compliant with RFC6455 without any = modifications. With respect to protections against excessive resource usage in general = I agree that it doesn't make sense to explicitly specify every limit in = an RFC. There are too many potential limits and the appropriate values = depend too much on what the application's needs are and will change over = time. Application specific tuning parameters seem like a good way to = address this. Perhaps the security section of any errata or future RFCs = can include a list of parameters that other applications have found = useful to tune from a security and interoperability standpoint?= From tobias.oberstein@tavendo.de Thu Jun 20 08:27:05 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3390721F9A97 for ; Thu, 20 Jun 2013 08:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwZo9YbXiBRu for ; Thu, 20 Jun 2013 08:26:58 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id 9D33A21F9C07 for ; Thu, 20 Jun 2013 08:26:33 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.90]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Thu, 20 Jun 2013 08:26:32 -0700 From: Tobias Oberstein To: Peter Thorson Date: Thu, 20 Jun 2013 08:26:29 -0700 Thread-Topic: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes Thread-Index: Ac5tyQljyZoaVCvPS++nj8YfaiFDNAAAQRmw Message-ID: <634914A010D0B943A035D226786325D4422DF4C20D@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D4422DF4C171@EXVMBX020-12.exch020.serverdata.net> <59AC62CE-9FFE-4DAE-A522-1D8083DE09F0@zaphoyd.com> In-Reply-To: <59AC62CE-9FFE-4DAE-A522-1D8083DE09F0@zaphoyd.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 15:27:05 -0000 > I would argue that a WebSocket server that dropped connections attempting= to > send excessive numbers of fragments (for some application defined value o= f > excessive) or fragments that were too small (for some application defined > value of small) with a private code or code 1008/Policy Violation would b= e > compliant with RFC6455 without any modifications. Ah, right. Forgot about 1008. I agree: no real need for inventing an app sp= ecific code. > With respect to protections against excessive resource usage in general I= agree > that it doesn't make sense to explicitly specify every limit in an RFC. T= here are > too many potential limits and the appropriate values depend too much on w= hat > the application's needs are and will change over time. Application specif= ic > tuning parameters seem like a good way to address this. Perhaps the secur= ity > section of any errata or future RFCs can include a list of parameters tha= t other > applications have found useful to tune from a security and interoperabili= ty > standpoint? That would be quite useful! E.g. me I forgot about "attack vector" tiny fragment sizes (or max. frame c= ount or something) as William has brought up. A systematic list of potential "DoS protection knobs" in the security secti= on: +1 /Tobias From zhong.j.yu@gmail.com Thu Jun 20 08:28:21 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE2821F9D7B for ; Thu, 20 Jun 2013 08:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AufeaJPODty for ; Thu, 20 Jun 2013 08:28:20 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 25B5C21F9D88 for ; Thu, 20 Jun 2013 08:28:16 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id g12so8228285oah.11 for ; Thu, 20 Jun 2013 08:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3oJkl/ET0kqo8ENfgxWyGzAKCcwO3JdEBdGV10/S0qI=; b=nVr1zM41IY+k2eLp2HOM17FeU3WMLze4YVEOObaG8ho5xTRp2rEvEtZ+FeUTXbO+qW T8AGgDrcOJoLCE8RF6/iR7fGez3717nk7+jeC0Q6DC9IYrlX/m+F5w85h64NtTTeLv9K soEP/gbHDqZ24ds4WTXBGqGQchyjnaRqzhSggz1hneLosd365RCBwZ8WtF5iMSpIP9Zu GN5tTX1fS4iPKpJV+KJhK4x4qn/WFC9L/MJtD7wC/rt0g4HFzs9NjI0ooaSKZhJ8Uy/F 6qOarWSEo6ShZGbPflh/yBiZmtXXJbe7ebsWVnm+vx05yo8D2NuNlno7vNeqb2WfEViZ bh9w== MIME-Version: 1.0 X-Received: by 10.60.37.168 with SMTP id z8mr4743783oej.66.1371742095664; Thu, 20 Jun 2013 08:28:15 -0700 (PDT) Received: by 10.76.79.8 with HTTP; Thu, 20 Jun 2013 08:28:15 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Jun 2013 10:28:15 -0500 Message-ID: From: Zhong Yu To: William Budd Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Fwd: Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 15:28:21 -0000 Not all websocket applications treat messages as atoms. If client/server are doing streaming (within a message), we need to support tiny frames. The requirement of min payload length will restrict how the protocol can be used. Empty frames are odd, and a sender should never depend on empty frames to carry any semantics. But why would empty frames cause any trouble for the receiver? Can't the receiver simply discard them? Zhong Yu On Thu, Jun 20, 2013 at 6:12 AM, William Budd wrote: >>> This is particularly annoying when a websocket server wants to guard >>> against denial of service attacks, because in the case of deliberately >>> over-fragmented messages the server needs to process an excessive (or >> >> Guard against this kind of attack could be done by frame/sec limit, >> fragments/message limit, idle (no new payload octet coming) timeout, etc. > > Yes, careful timing can certainly catch a lot of unreasonable traffic > (albeit at the cost of a significant processing overhead in some > cases). I'm not sure what you mean by a fragments/message limit > though. If a server decides to drop fragments beyond a certain > fragment count, isn't that a violation of RFC 6455 (as the reason for > declining would be based on the framing rather than on the contents of > the payload)? > >>> infinite?) amount of framing data before it has enough payload data to >>> determine whether the message is valid with regard to any API built on >>> top of the websocket layer. >> >> With this change, we can delegate DoS detection to code after defragment. I >> agree that it's useful. For keep-alive we already have ping/pong, so nobody >> should miss empty (non-first && non-last) frames. > > Glad to hear that! > >>> This issue could be easily prevented if websocket frames that do not >>> have the FIN bit set need to specify a payload of at least X bytes >> >> I'd relax it to "!FIN && !first". > > Alright, but could you give an example of when it would be desirable > to make the first frame of a fragmented message (very) small? > >>> (where I would vote for X to be 125, but could conceivably be as small >>> as 8 or so bytes). Any non-FIN frames smaller than X could then simply >> >> If we were still standardizing per-frame mux, I'd say "this could be source >> of head of line blocking when used for multiplexing. Though 125 sounds small >> enough not to clog multiplexed connection, I don't want X to be greater than >> 1". >> >> But now in the latest mux spec, we're encapsulating fragments into messages. >> So, it's fine wrt current mux spec. > > A fortunate coincidence. :) > >> I don't want to get bothered by minimum transmission unit when flushing >> data, but in practice, we're always asked to consolidate small chunks if >> possible to reduce overhead, and we do so. > > Agreed. Thank you for your thoughtful input! > > It would be good if other people chimed in with their opinions too, > but if it turns out there are no significant drawbacks I hope said > minimum size can be ratified in the next version of the websocket > protocol. > > Best, > Will > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From joakim@intalio.com Thu Jun 20 09:06:43 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDB821F9330 for ; Thu, 20 Jun 2013 09:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9HL804qcLeE for ; Thu, 20 Jun 2013 09:06:42 -0700 (PDT) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id CE5F121F99F8 for ; Thu, 20 Jun 2013 09:06:35 -0700 (PDT) Received: by mail-ea0-f171.google.com with SMTP id m14so4081697eaj.30 for ; Thu, 20 Jun 2013 09:06:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=gi4uo9j91vEPhpQZbrANbuAsPPeHBwLK979gvxISVng=; b=ga1kj2oX3dcXYv3as67nLP6Y3BWlCsVyE9MvEcJ1w6tT5/rseP0AGS3lQgxo+rGFdJ QA+ffvTxSDl6SZuMOZwPoR+mqc3vmVyCxG9qGkSB9l2ic0XkZpbDRKpTia7zg+Qa85UY kDz+ANIm7C2BCCAuplnivnqyG+AeA53FKyCvlVlNO8PkXf/aGcBi6nJIeIBIYIr5HaAq rXSnY/N8UFkWlwbCxtryTb1Q1MDQzCvZ+TisogfMh2tfRtkmjJw8krUTvTcm73apja9t BV8Vk9d7fWk0o3tFkixcYTjoLGdFlR05S3kBNEhrBWJb3V8pSq8cQJ6uxbDwt5pKd3O1 5t7A== MIME-Version: 1.0 X-Received: by 10.14.180.4 with SMTP id i4mr8141411eem.148.1371744394837; Thu, 20 Jun 2013 09:06:34 -0700 (PDT) Received: by 10.15.32.8 with HTTP; Thu, 20 Jun 2013 09:06:34 -0700 (PDT) In-Reply-To: <59AC62CE-9FFE-4DAE-A522-1D8083DE09F0@zaphoyd.com> References: <634914A010D0B943A035D226786325D4422DF4C171@EXVMBX020-12.exch020.serverdata.net> <59AC62CE-9FFE-4DAE-A522-1D8083DE09F0@zaphoyd.com> Date: Thu, 20 Jun 2013 09:06:34 -0700 Message-ID: From: Joakim Erdfelt To: Peter Thorson Content-Type: multipart/alternative; boundary=047d7b62214a60b0f804df982177 X-Gm-Message-State: ALoCoQmYzFWO9T+tnMYQ/bM10O8/dI3rMV6rz2EtGtorUipnFOHw8RfWqFr5OZqQb8/V/mj7NnrS Cc: "hybi@ietf.org" Subject: Re: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:06:43 -0000 --047d7b62214a60b0f804df982177 Content-Type: text/plain; charset=ISO-8859-1 What about a new fragment extension that can communicate these limits? Something like this... On client handshake it can say fragment; min=125; max=65535 which would tell the server that messages should be fragmented, within these limits. alternative behavior would be for the Client to state that it supports fragment rules by simply saying fragment and the server responding with the rules it expects fragment; min=0; max=1234567 thoughts? -- Joakim Erdfelt webtide.com Developer advice, services and support from the Jetty & CometD experts eclipse.org/jetty - cometd.org On Thu, Jun 20, 2013 at 8:15 AM, Peter Thorson wrote: > > On Jun 20, 2013, at 9:11 , Tobias Oberstein > wrote: > > >> However, I think the spec should also make provisions against over- > >> fragmentation. Unless I overlooked something, RFC allows any message to > be > >> split into an infinite amount of fragments with payloads of 0 bytes (or > if I'm > >> wrong about that, it still allows a message to be fragmented in a nutty > number > >> of fragments with 1 byte); and endpoints need to handle that in order > to comply > >> with RFC 6455. > > > > Not only endpoints, but also any intermediary.. > > > >> This is particularly annoying when a websocket server wants to guard > against > >> denial of service attacks, because in the case of deliberately > over-fragmented > >> messages the server needs to process an excessive (or > > > > If you want to protect against DoS, there a multiple scenarios not > explicitly discussed or specified in the RFC. > > > > E.g. opening handshake timeouts, maximum frame size or excessive numbers > of ping requests. > > > > I think the decision what's acceptable depends on the concrete situation > and application, and can be left open to implementations providing knobs > for users to adjust. > > > > So you can have a knob "minimal frame size for non-final frames" and > fail the connection with a custom close code upon exceeding the limit. > > > > Having fixed (non-negotiated) and implicit (non-modifyable) limits for > specific parameters seems less desirable from my perspective. > > > > /Tobias > > > I would argue that a WebSocket server that dropped connections attempting > to send excessive numbers of fragments (for some application defined value > of excessive) or fragments that were too small (for some application > defined value of small) with a private code or code 1008/Policy Violation > would be compliant with RFC6455 without any modifications. > > With respect to protections against excessive resource usage in general I > agree that it doesn't make sense to explicitly specify every limit in an > RFC. There are too many potential limits and the appropriate values depend > too much on what the application's needs are and will change over time. > Application specific tuning parameters seem like a good way to address > this. Perhaps the security section of any errata or future RFCs can include > a list of parameters that other applications have found useful to tune from > a security and interoperability standpoint? > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --047d7b62214a60b0f804df982177 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
What about a new fragment extension that can communicate t= hese limits?

Something like this...

On client handshake it can say=A0
= =A0 fragment; min=3D125; max=3D65535
which would tell the server that messages should be fragmented, = within these limits.

alternative behav= ior would be for the Client to state that it supports fragment rules by sim= ply saying
=A0 fragment
and the server responding with the = rules it expects
=A0 fragment; min=3D0; max=3D1234567
=

thoughts?

<= div class=3D"gmail_extra">
--
Joakim Erdfelt <joakim@intalio.com>
webtide.com
Developer advice, services and support
from the Jetty= & CometD experts


On Thu, Jun 20, 2013 at 8:15 AM, Peter T= horson <webmaster@zaphoyd.com> wrote:

On Jun 20, 2013, at 9:11 , Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:

>> However, I think the spec should also make provisions against over= -
>> fragmentation. Unless I overlooked something, RFC allows any messa= ge to be
>> split into an infinite amount of fragments with payloads of 0 byte= s (or if I'm
>> wrong about that, it still allows a message to be fragmented in a = nutty number
>> of fragments with 1 byte); and endpoints need to handle that in or= der to comply
>> with RFC 6455.
>
> Not only endpoints, but also any intermediary..
>
>> This is particularly annoying when a websocket server wants to gua= rd against
>> denial of service attacks, because in the case of deliberately ove= r-fragmented
>> messages the server needs to process an excessive (or
>
> If you want to protect against DoS, there a multiple scenarios not exp= licitly discussed or specified in the RFC.
>
> E.g. opening handshake timeouts, maximum frame size or excessive numbe= rs of ping requests.
>
> I think the decision what's acceptable depends on the concrete sit= uation and application, and can be left open to implementations providing k= nobs for users to adjust.
>
> So you can have a knob "minimal frame size for non-final frames&q= uot; and fail the connection with a custom close code upon exceeding the li= mit.
>
> Having fixed (non-negotiated) and implicit (non-modifyable) limits for= specific parameters seems less desirable from my perspective.
>
> /Tobias


I would argue that a WebSocket server that dropped connections = attempting to send excessive numbers of fragments (for some application def= ined value of excessive) or fragments that were too small (for some applica= tion defined value of small) with a private code or code 1008/Policy Violat= ion would be compliant with RFC6455 without any modifications.

With respect to protections against excessive resource usage in general I a= gree that it doesn't make sense to explicitly specify every limit in an= RFC. There are too many potential limits and the appropriate values depend= too much on what the application's needs are and will change over time= . Application specific tuning parameters seem like a good way to address th= is. Perhaps the security section of any errata or future RFCs can include a= list of parameters that other applications have found useful to tune from = a security and interoperability standpoint?
___________________________________= ____________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--047d7b62214a60b0f804df982177-- From joakim@intalio.com Thu Jun 20 09:10:16 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD7221F9DB9 for ; Thu, 20 Jun 2013 09:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CT28RZ5-KEJd for ; Thu, 20 Jun 2013 09:10:15 -0700 (PDT) Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 667CE21F9DB7 for ; Thu, 20 Jun 2013 09:10:15 -0700 (PDT) Received: by mail-ee0-f47.google.com with SMTP id e49so4014381eek.34 for ; Thu, 20 Jun 2013 09:10:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=sCknXidxhUtiqiVDN/6ssfhYCcm8Q7nhjoMLoiJsYAk=; b=TAQDAmQ7J4edwDPgUr9xLZ9RV3ROuBQgKnb7+LfllYWtnQBcPXC4nC+PEY7wfKfAcf sNZhlkUzepcKJ10k99C9rRk1u1eG+tuUb43KHHdLSDXn5x9iX3ZWLBFJtI6jD8rn9zNW UXX+JHoMSeNrrxLSM6FBYanNthE854t9CaxDQuSV5GsCu3wurRk4IIU0Yvnj+wTV0Csa NvE5mIvwIp0VWb2U7P3p8UbGQdPudO3WTMDx6vstQp8e3gNKZtizBDZjuT//DNeZfXmO 6mQxxzpfm17NNYpub/KLxYL1FPRJPEgqxhDGUgXdfWN7eb3c8TTFvh6jab/KOdvr1+LI 5+Zg== MIME-Version: 1.0 X-Received: by 10.14.180.4 with SMTP id i4mr8157907eem.148.1371744614293; Thu, 20 Jun 2013 09:10:14 -0700 (PDT) Received: by 10.15.32.8 with HTTP; Thu, 20 Jun 2013 09:10:14 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Jun 2013 09:10:14 -0700 Message-ID: From: Joakim Erdfelt To: Zhong Yu Content-Type: multipart/alternative; boundary=047d7b62214a7550b204df982ef4 X-Gm-Message-State: ALoCoQnvukaiKRibECS95HCv/mYiCrA9LdPy5mcNNSj1H3m06MD0pyjCqp6NMn1LaRNkbpjAEapH Cc: "hybi@ietf.org" Subject: Re: [hybi] Fwd: Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:10:17 -0000 --047d7b62214a7550b204df982ef4 Content-Type: text/plain; charset=ISO-8859-1 an empty frame within the context of a streaming message is possible. if you have a websocket library that supports streaming of a message, it has to make some judgement calls on when to flush the outgoing data in the form of a fragment. The library however has no prior knowledge of the size of the message, so the flush could occur, then the user application determines it is done streaming data and simply closes that message stream, resulting in a need for a final 0 payload length FIN frame. -- Joakim Erdfelt webtide.com Developer advice, services and support from the Jetty & CometD experts eclipse.org/jetty - cometd.org On Thu, Jun 20, 2013 at 8:28 AM, Zhong Yu wrote: > Not all websocket applications treat messages as atoms. If > client/server are doing streaming (within a message), we need to > support tiny frames. The requirement of min payload length will > restrict how the protocol can be used. > > Empty frames are odd, and a sender should never depend on empty frames > to carry any semantics. But why would empty frames cause any trouble > for the receiver? Can't the receiver simply discard them? > > Zhong Yu > > > > On Thu, Jun 20, 2013 at 6:12 AM, William Budd wrote: > >>> This is particularly annoying when a websocket server wants to guard > >>> against denial of service attacks, because in the case of deliberately > >>> over-fragmented messages the server needs to process an excessive (or > >> > >> Guard against this kind of attack could be done by frame/sec limit, > >> fragments/message limit, idle (no new payload octet coming) timeout, > etc. > > > > Yes, careful timing can certainly catch a lot of unreasonable traffic > > (albeit at the cost of a significant processing overhead in some > > cases). I'm not sure what you mean by a fragments/message limit > > though. If a server decides to drop fragments beyond a certain > > fragment count, isn't that a violation of RFC 6455 (as the reason for > > declining would be based on the framing rather than on the contents of > > the payload)? > > > >>> infinite?) amount of framing data before it has enough payload data to > >>> determine whether the message is valid with regard to any API built on > >>> top of the websocket layer. > >> > >> With this change, we can delegate DoS detection to code after > defragment. I > >> agree that it's useful. For keep-alive we already have ping/pong, so > nobody > >> should miss empty (non-first && non-last) frames. > > > > Glad to hear that! > > > >>> This issue could be easily prevented if websocket frames that do not > >>> have the FIN bit set need to specify a payload of at least X bytes > >> > >> I'd relax it to "!FIN && !first". > > > > Alright, but could you give an example of when it would be desirable > > to make the first frame of a fragmented message (very) small? > > > >>> (where I would vote for X to be 125, but could conceivably be as small > >>> as 8 or so bytes). Any non-FIN frames smaller than X could then simply > >> > >> If we were still standardizing per-frame mux, I'd say "this could be > source > >> of head of line blocking when used for multiplexing. Though 125 sounds > small > >> enough not to clog multiplexed connection, I don't want X to be greater > than > >> 1". > >> > >> But now in the latest mux spec, we're encapsulating fragments into > messages. > >> So, it's fine wrt current mux spec. > > > > A fortunate coincidence. :) > > > >> I don't want to get bothered by minimum transmission unit when flushing > >> data, but in practice, we're always asked to consolidate small chunks if > >> possible to reduce overhead, and we do so. > > > > Agreed. Thank you for your thoughtful input! > > > > It would be good if other people chimed in with their opinions too, > > but if it turns out there are no significant drawbacks I hope said > > minimum size can be ratified in the next version of the websocket > > protocol. > > > > Best, > > Will > > _______________________________________________ > > hybi mailing list > > hybi@ietf.org > > https://www.ietf.org/mailman/listinfo/hybi > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --047d7b62214a7550b204df982ef4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
an empty frame within the context of a streaming message i= s possible.

if you have a websocket library that s= upports streaming of a message, it has to make some judgement calls on when= to flush the outgoing data in the form of a fragment. =A0
The library however has no prior knowledge of the size of the me= ssage, so the flush could occur, then the user application determines it is= done streaming data and simply closes that message stream, resulting in a = need for a final 0 payload length FIN frame.

--
J= oakim Erdfelt <j= oakim@intalio.com>
Developer advice, services and support
from the = Jetty & CometD experts


On Thu, Jun 20, 2013 at 8:28 AM, Zhong Y= u <zhong.j.yu@gmail.com> wrote:
Not all websocket applications treat messages as atoms. If
client/server are doing streaming (within a message), we need to
support tiny frames. The requirement of min payload length will
restrict how the protocol can be used.

Empty frames are odd, and a sender should never depend on empty frames
to carry any semantics. But why would empty frames cause any trouble
for the receiver? Can't the receiver simply discard them?

Zhong Yu



On Thu, Jun 20, 2013 at 6:12 AM, William Budd <wb@wbudd.com> wrote:
>>> This is particularly annoying when a websocket server wants to= guard
>>> against denial of service attacks, because in the case of deli= berately
>>> over-fragmented messages the server needs to process an excess= ive (or
>>
>> Guard against this kind of attack could be done by frame/sec limit= ,
>> fragments/message limit, idle (no new payload octet coming) timeou= t, etc.
>
> Yes, careful timing can certainly catch a lot of unreasonable traffic<= br> > (albeit at the cost of a significant processing overhead in some
> cases). I'm not sure what you mean by a fragments/message limit > though. If a server decides to drop fragments beyond a certain
> fragment count, isn't that a violation of RFC 6455 (as the reason = for
> declining would be based on the framing rather than on the contents of=
> the payload)?
>
>>> infinite?) amount of framing data before it has enough payload= data to
>>> determine whether the message is valid with regard to any API = built on
>>> top of the websocket layer.
>>
>> With this change, we can delegate DoS detection to code after defr= agment. I
>> agree that it's useful. For keep-alive we already have ping/po= ng, so nobody
>> should miss empty (non-first && non-last) frames.
>
> Glad to hear that!
>
>>> This issue could be easily prevented if websocket frames that = do not
>>> have the FIN bit set need to specify a payload of at least X b= ytes
>>
>> I'd relax it to "!FIN && !first".
>
> Alright, but could you give an example of when it would be desirable > to make the first frame of a fragmented message (very) small?
>
>>> (where I would vote for X to be 125, but could conceivably be = as small
>>> as 8 or so bytes). Any non-FIN frames smaller than X could the= n simply
>>
>> If we were still standardizing per-frame mux, I'd say "th= is could be source
>> of head of line blocking when used for multiplexing. Though 125 so= unds small
>> enough not to clog multiplexed connection, I don't want X to b= e greater than
>> 1".
>>
>> But now in the latest mux spec, we're encapsulating fragments = into messages.
>> So, it's fine wrt current mux spec.
>
> A fortunate coincidence. :)
>
>> I don't want to get bothered by minimum transmission unit when= flushing
>> data, but in practice, we're always asked to consolidate small= chunks if
>> possible to reduce overhead, and we do so.
>
> Agreed. Thank you for your thoughtful input!
>
> It would be good if other people chimed in with their opinions too, > but if it turns out there are no significant drawbacks I hope said
> minimum size can be ratified in the next version of the websocket
> protocol.
>
> Best,
> Will
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--047d7b62214a7550b204df982ef4-- From tobias.oberstein@tavendo.de Thu Jun 20 10:15:35 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87DD21F9E37 for ; Thu, 20 Jun 2013 10:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwyAL5NVmqDI for ; Thu, 20 Jun 2013 10:15:32 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id 6A93421F9E24 for ; Thu, 20 Jun 2013 10:15:31 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.90]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Thu, 20 Jun 2013 10:15:30 -0700 From: Tobias Oberstein To: Joakim Erdfelt Date: Thu, 20 Jun 2013 10:15:29 -0700 Thread-Topic: [hybi] Fwd: Proposal: require non-final websocket frames to have a minimum payload length of X bytes Thread-Index: Ac5t0KpBFbqygfyQRomGqeyAcv0njAACRkk5 Message-ID: <9l6wdsh2085s4o5gkhwrutxt.1371748490903@email.android.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_9l6wdsh2085s4o5gkhwrutxt1371748490903emailandroidcom_" MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Fwd: Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:15:35 -0000 --_000_9l6wdsh2085s4o5gkhwrutxt1371748490903emailandroidcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yep. That's exactly what Autobahn does when using it's streaming API: compl= ete the message by sending an empty FIN frame. Sent from Mobile (Google Nexus 4) Joakim Erdfelt schrieb: an empty frame within the context of a streaming message is possible. if you have a websocket library that supports streaming of a message, it ha= s to make some judgement calls on when to flush the outgoing data in the fo= rm of a fragment. The library however has no prior knowledge of the size of the message, so t= he flush could occur, then the user application determines it is done strea= ming data and simply closes that message stream, resulting in a need for a = final 0 payload length FIN frame. -- Joakim Erdfelt > webtide.com Developer advice, services and support from the Jetty & CometD experts eclipse.org/jetty - cometd.org On Thu, Jun 20, 2013 at 8:28 AM, Zhong Yu > wrote: Not all websocket applications treat messages as atoms. If client/server are doing streaming (within a message), we need to support tiny frames. The requirement of min payload length will restrict how the protocol can be used. Empty frames are odd, and a sender should never depend on empty frames to carry any semantics. But why would empty frames cause any trouble for the receiver? Can't the receiver simply discard them? Zhong Yu On Thu, Jun 20, 2013 at 6:12 AM, William Budd > wrote: >>> This is particularly annoying when a websocket server wants to guard >>> against denial of service attacks, because in the case of deliberately >>> over-fragmented messages the server needs to process an excessive (or >> >> Guard against this kind of attack could be done by frame/sec limit, >> fragments/message limit, idle (no new payload octet coming) timeout, etc= . > > Yes, careful timing can certainly catch a lot of unreasonable traffic > (albeit at the cost of a significant processing overhead in some > cases). I'm not sure what you mean by a fragments/message limit > though. If a server decides to drop fragments beyond a certain > fragment count, isn't that a violation of RFC 6455 (as the reason for > declining would be based on the framing rather than on the contents of > the payload)? > >>> infinite?) amount of framing data before it has enough payload data to >>> determine whether the message is valid with regard to any API built on >>> top of the websocket layer. >> >> With this change, we can delegate DoS detection to code after defragment= . I >> agree that it's useful. For keep-alive we already have ping/pong, so nob= ody >> should miss empty (non-first && non-last) frames. > > Glad to hear that! > >>> This issue could be easily prevented if websocket frames that do not >>> have the FIN bit set need to specify a payload of at least X bytes >> >> I'd relax it to "!FIN && !first". > > Alright, but could you give an example of when it would be desirable > to make the first frame of a fragmented message (very) small? > >>> (where I would vote for X to be 125, but could conceivably be as small >>> as 8 or so bytes). Any non-FIN frames smaller than X could then simply >> >> If we were still standardizing per-frame mux, I'd say "this could be sou= rce >> of head of line blocking when used for multiplexing. Though 125 sounds s= mall >> enough not to clog multiplexed connection, I don't want X to be greater = than >> 1". >> >> But now in the latest mux spec, we're encapsulating fragments into messa= ges. >> So, it's fine wrt current mux spec. > > A fortunate coincidence. :) > >> I don't want to get bothered by minimum transmission unit when flushing >> data, but in practice, we're always asked to consolidate small chunks if >> possible to reduce overhead, and we do so. > > Agreed. Thank you for your thoughtful input! > > It would be good if other people chimed in with their opinions too, > but if it turns out there are no significant drawbacks I hope said > minimum size can be ratified in the next version of the websocket > protocol. > > Best, > Will > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi --_000_9l6wdsh2085s4o5gkhwrutxt1371748490903emailandroidcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
Yep. That's exactly what Autobahn does when using it's streamin=
g API: complete the message by sending an empty FIN frame. =0A=
=0A=
Sent from Mobile (Google Nexus 4)=0A=
=0A=
Joakim Erdfelt <joakim@intalio.com> schrieb:=0A=
=0A=
an empty frame within the context of a streaming message i= s possible.

if you have a websocket library that supports streaming of = a message, it has to make some judgement calls on when to flush the outgoin= g data in the form of a fragment.  
The library however has no prior knowledge of the size of t= he message, so the flush could occur, then the user application determines = it is done streaming data and simply closes that message stream, resulting = in a need for a final 0 payload length FIN frame.

--
Joakim Erdfelt <joakim@intalio.com>
webtide.com<= /div>
Developer advice, services and support
from the Jetty & CometD experts


On Thu, Jun 20, 2013 at 8:28 AM, Zhong Yu <zhong.j.yu@gm= ail.com> wrote:
Not all websocket applications treat messages as atoms. If
client/server are doing streaming (within a message), we need to
support tiny frames. The requirement of min payload length will
restrict how the protocol can be used.

Empty frames are odd, and a sender should never depend on empty frames
to carry any semantics. But why would empty frames cause any trouble
for the receiver? Can't the receiver simply discard them?

Zhong Yu



On Thu, Jun 20, 2013 at 6:12 AM, William Budd <wb@wbudd.com> wrote:
>>> This is particularly annoying when a websocket server wants to= guard
>>> against denial of service attacks, because in the case of deli= berately
>>> over-fragmented messages the server needs to process an excess= ive (or
>>
>> Guard against this kind of attack could be done by frame/sec limit= ,
>> fragments/message limit, idle (no new payload octet coming) timeou= t, etc.
>
> Yes, careful timing can certainly catch a lot of unreasonable traffic<= br> > (albeit at the cost of a significant processing overhead in some
> cases). I'm not sure what you mean by a fragments/message limit
> though. If a server decides to drop fragments beyond a certain
> fragment count, isn't that a violation of RFC 6455 (as the reason for<= br> > declining would be based on the framing rather than on the contents of=
> the payload)?
>
>>> infinite?) amount of framing data before it has enough payload= data to
>>> determine whether the message is valid with regard to any API = built on
>>> top of the websocket layer.
>>
>> With this change, we can delegate DoS detection to code after defr= agment. I
>> agree that it's useful. For keep-alive we already have ping/pong, = so nobody
>> should miss empty (non-first && non-last) frames.
>
> Glad to hear that!
>
>>> This issue could be easily prevented if websocket frames that = do not
>>> have the FIN bit set need to specify a payload of at least X b= ytes
>>
>> I'd relax it to "!FIN && !first".
>
> Alright, but could you give an example of when it would be desirable > to make the first frame of a fragmented message (very) small?
>
>>> (where I would vote for X to be 125, but could conceivably be = as small
>>> as 8 or so bytes). Any non-FIN frames smaller than X could the= n simply
>>
>> If we were still standardizing per-frame mux, I'd say "this c= ould be source
>> of head of line blocking when used for multiplexing. Though 125 so= unds small
>> enough not to clog multiplexed connection, I don't want X to be gr= eater than
>> 1".
>>
>> But now in the latest mux spec, we're encapsulating fragments into= messages.
>> So, it's fine wrt current mux spec.
>
> A fortunate coincidence. :)
>
>> I don't want to get bothered by minimum transmission unit when flu= shing
>> data, but in practice, we're always asked to consolidate small chu= nks if
>> possible to reduce overhead, and we do so.
>
> Agreed. Thank you for your thoughtful input!
>
> It would be good if other people chimed in with their opinions too, > but if it turns out there are no significant drawbacks I hope said
> minimum size can be ratified in the next version of the websocket
> protocol.
>
> Best,
> Will
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--_000_9l6wdsh2085s4o5gkhwrutxt1371748490903emailandroidcom_-- From fenix@google.com Thu Jun 20 10:45:42 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3386921F9F77 for ; Thu, 20 Jun 2013 10:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57fpCd3oVzPR for ; Thu, 20 Jun 2013 10:45:38 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id C4A3A21F9F86 for ; Thu, 20 Jun 2013 10:45:37 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id z5so5920857lbh.21 for ; Thu, 20 Jun 2013 10:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K57FgD2rK9vaFJe9GczEQzPD8BaE3/MEAnsSLEFwIL0=; b=JcaiL5lQNiXWcSuTWhpGOwRU6BEKIUJngLAUEa3AISbGNcj9CTOaODFUXtBieH/muj nZbp64i/mKbcXG9B3jP/gByuEMQ1vKk5+PD+bBqRo1dngmaOWm5Xw+gdoHC/g0e6gU9B AXU3ZZq+CQjFkJ7ACxMa4UTMbJUVcgvuPbGuYYWRgKVn/OkKvfTwjgw15e7+sqbnfcOl k2PZOYRdDFLQQN4YO/ByoK5FIftVvZF09kQ4JbZD6ZAAM7DODPblmV/LVpn/l3TBpYiV Qo7G+q5C39RYShtPk0axTkZ9QtU3jcKZzPynPWOWZ/g6GkuLlZUusxFvRttc58CukyZ5 giNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=K57FgD2rK9vaFJe9GczEQzPD8BaE3/MEAnsSLEFwIL0=; b=btUkryNXSqmTtM3EndMC2pUsTK6GMcb9PehQbR/G0pkMQwbn7ewdQ77q6lb9LpAKwJ aN/ZiPssyvaN9DcuEkYIHAtd2yIWOZ4lhOJRZwKl2aEIH9n/r9gGxwouHUGTBHHSR5F8 PeiN9icQvjayQRFg562LgUGPpcxZ4w8kTZPrfiqmIBfPZBxmHV/5GT1ajqw1pGrf+Ebl tCmwsqU5hWB3SKcb+ypKynZsTFdhEc04gaoA4rKVxoLdftHHxm+c5Rd0vKtj3zWp45GG zD9hEDenK4H8oMbO9sxn4OITd7Xfe9GjPH5NQzPwwwRKrhrf3wV0EBbueE/3w/hATfnh Wp3Q== MIME-Version: 1.0 X-Received: by 10.112.140.231 with SMTP id rj7mr6142134lbb.16.1371750336632; Thu, 20 Jun 2013 10:45:36 -0700 (PDT) Received: by 10.112.52.105 with HTTP; Thu, 20 Jun 2013 10:45:36 -0700 (PDT) In-Reply-To: <9l6wdsh2085s4o5gkhwrutxt.1371748490903@email.android.com> References: <9l6wdsh2085s4o5gkhwrutxt.1371748490903@email.android.com> Date: Thu, 20 Jun 2013 10:45:36 -0700 Message-ID: From: Roberto Peon To: Tobias Oberstein Content-Type: multipart/alternative; boundary=001a11c26a3089373c04df9983e0 X-Gm-Message-State: ALoCoQk4CZzW0q/ogGskSp7gwOSBrkYUk4XV5bG8p9mGEuEQrVS/HPI33FnBaK7oYGXtPk6b7QDj3PiD3sBzG1pZoAzC3bZmmOcu3j/73ip5Fzi1w69luWzkb4IunwNKTw+Q/DYSXTcsvbQsAOoUOQXsifPlP63qE2kE/rNruK3E54D+Vz0yb945Yg9OSNq7AppPEV6/UDeu Cc: "hybi@ietf.org" Subject: Re: [hybi] Fwd: Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:45:42 -0000 --001a11c26a3089373c04df9983e0 Content-Type: text/plain; charset=ISO-8859-1 That "empty" frame carries information, namely that a FIN was sent. The presence of a zero-length frame might also indicate something, but a zero-length *fragment* without a FIN or other metadata seems pretty stupid. -=R On Thu, Jun 20, 2013 at 10:15 AM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > Yep. That's exactly what Autobahn does when using it's streaming API: complete the message by sending an empty FIN frame. > > Sent from Mobile (Google Nexus 4) > > Joakim Erdfelt schrieb: > > > an empty frame within the context of a streaming message is possible. > > if you have a websocket library that supports streaming of a message, it > has to make some judgement calls on when to flush the outgoing data in the > form of a fragment. > The library however has no prior knowledge of the size of the message, so > the flush could occur, then the user application determines it is done > streaming data and simply closes that message stream, resulting in a need > for a final 0 payload length FIN frame. > > -- > Joakim Erdfelt > webtide.com > Developer advice, services and support > from the Jetty & CometD experts > eclipse.org/jetty - cometd.org > > > On Thu, Jun 20, 2013 at 8:28 AM, Zhong Yu wrote: > >> Not all websocket applications treat messages as atoms. If >> client/server are doing streaming (within a message), we need to >> support tiny frames. The requirement of min payload length will >> restrict how the protocol can be used. >> >> Empty frames are odd, and a sender should never depend on empty frames >> to carry any semantics. But why would empty frames cause any trouble >> for the receiver? Can't the receiver simply discard them? >> >> Zhong Yu >> >> >> >> On Thu, Jun 20, 2013 at 6:12 AM, William Budd wrote: >> >>> This is particularly annoying when a websocket server wants to guard >> >>> against denial of service attacks, because in the case of deliberately >> >>> over-fragmented messages the server needs to process an excessive (or >> >> >> >> Guard against this kind of attack could be done by frame/sec limit, >> >> fragments/message limit, idle (no new payload octet coming) timeout, >> etc. >> > >> > Yes, careful timing can certainly catch a lot of unreasonable traffic >> > (albeit at the cost of a significant processing overhead in some >> > cases). I'm not sure what you mean by a fragments/message limit >> > though. If a server decides to drop fragments beyond a certain >> > fragment count, isn't that a violation of RFC 6455 (as the reason for >> > declining would be based on the framing rather than on the contents of >> > the payload)? >> > >> >>> infinite?) amount of framing data before it has enough payload data to >> >>> determine whether the message is valid with regard to any API built on >> >>> top of the websocket layer. >> >> >> >> With this change, we can delegate DoS detection to code after >> defragment. I >> >> agree that it's useful. For keep-alive we already have ping/pong, so >> nobody >> >> should miss empty (non-first && non-last) frames. >> > >> > Glad to hear that! >> > >> >>> This issue could be easily prevented if websocket frames that do not >> >>> have the FIN bit set need to specify a payload of at least X bytes >> >> >> >> I'd relax it to "!FIN && !first". >> > >> > Alright, but could you give an example of when it would be desirable >> > to make the first frame of a fragmented message (very) small? >> > >> >>> (where I would vote for X to be 125, but could conceivably be as small >> >>> as 8 or so bytes). Any non-FIN frames smaller than X could then simply >> >> >> >> If we were still standardizing per-frame mux, I'd say "this could be >> source >> >> of head of line blocking when used for multiplexing. Though 125 sounds >> small >> >> enough not to clog multiplexed connection, I don't want X to be >> greater than >> >> 1". >> >> >> >> But now in the latest mux spec, we're encapsulating fragments into >> messages. >> >> So, it's fine wrt current mux spec. >> > >> > A fortunate coincidence. :) >> > >> >> I don't want to get bothered by minimum transmission unit when flushing >> >> data, but in practice, we're always asked to consolidate small chunks >> if >> >> possible to reduce overhead, and we do so. >> > >> > Agreed. Thank you for your thoughtful input! >> > >> > It would be good if other people chimed in with their opinions too, >> > but if it turns out there are no significant drawbacks I hope said >> > minimum size can be ratified in the next version of the websocket >> > protocol. >> > >> > Best, >> > Will >> > _______________________________________________ >> > hybi mailing list >> > hybi@ietf.org >> > https://www.ietf.org/mailman/listinfo/hybi >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --001a11c26a3089373c04df9983e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
That "empty" frame carries information, namely t= hat a FIN was sent.
The presence of a zero-length frame might also indi= cate something, but a zero-length *fragment* without a FIN or other metadat= a seems pretty stupid.
-=3DR


On Thu, Jun 20, 2013 at 10:15 AM, Tobias Oberst= ein <tobias.oberstein@tavendo.de> wrote:
Yep=
. That's exactly what Autobahn does when using it's streaming API: =
complete the message by sending an empty FIN frame.=20

Sent from Mobile (Google Nexus 4)

Joakim Erdfelt <=
joakim@intalio.com> schrieb:
an empty frame within the context of a streaming message i= s possible.

if you have a websocket library that supports streaming of a message, = it has to make some judgement calls on when to flush the outgoing data in t= he form of a fragment. =A0
The library however has no prior knowledge of the size of the message,= so the flush could occur, then the user application determines it is done = streaming data and simply closes that message stream, resulting in a need f= or a final 0 payload length FIN frame.

--
Joakim Erdfelt <joakim@intalio.com>
webtide.com<= /div>
Developer advice, services and support
from the Jetty & CometD experts


On Thu, Jun 20, 2013 at 8:28 AM, Zhong Yu <zhong.j.yu@gm= ail.com> wrote:
Not all websocket applications treat messages as atoms. If
client/server are doing streaming (within a message), we need to
support tiny frames. The requirement of min payload length will
restrict how the protocol can be used.

Empty frames are odd, and a sender should never depend on empty frames
to carry any semantics. But why would empty frames cause any trouble
for the receiver? Can't the receiver simply discard them?

Zhong Yu



On Thu, Jun 20, 2013 at 6:12 AM, William Budd <wb@wbudd.com> wrote:
>>> This is particularly annoying when a websocket server wants to= guard
>>> against denial of service attacks, because in the case of deli= berately
>>> over-fragmented messages the server needs to process an excess= ive (or
>>
>> Guard against this kind of attack could be done by frame/sec limit= ,
>> fragments/message limit, idle (no new payload octet coming) timeou= t, etc.
>
> Yes, careful timing can certainly catch a lot of unreasonable traffic<= br> > (albeit at the cost of a significant processing overhead in some
> cases). I'm not sure what you mean by a fragments/message limit > though. If a server decides to drop fragments beyond a certain
> fragment count, isn't that a violation of RFC 6455 (as the reason = for
> declining would be based on the framing rather than on the contents of=
> the payload)?
>
>>> infinite?) amount of framing data before it has enough payload= data to
>>> determine whether the message is valid with regard to any API = built on
>>> top of the websocket layer.
>>
>> With this change, we can delegate DoS detection to code after defr= agment. I
>> agree that it's useful. For keep-alive we already have ping/po= ng, so nobody
>> should miss empty (non-first && non-last) frames.
>
> Glad to hear that!
>
>>> This issue could be easily prevented if websocket frames that = do not
>>> have the FIN bit set need to specify a payload of at least X b= ytes
>>
>> I'd relax it to "!FIN && !first".
>
> Alright, but could you give an example of when it would be desirable > to make the first frame of a fragmented message (very) small?
>
>>> (where I would vote for X to be 125, but could conceivably be = as small
>>> as 8 or so bytes). Any non-FIN frames smaller than X could the= n simply
>>
>> If we were still standardizing per-frame mux, I'd say "th= is could be source
>> of head of line blocking when used for multiplexing. Though 125 so= unds small
>> enough not to clog multiplexed connection, I don't want X to b= e greater than
>> 1".
>>
>> But now in the latest mux spec, we're encapsulating fragments = into messages.
>> So, it's fine wrt current mux spec.
>
> A fortunate coincidence. :)
>
>> I don't want to get bothered by minimum transmission unit when= flushing
>> data, but in practice, we're always asked to consolidate small= chunks if
>> possible to reduce overhead, and we do so.
>
> Agreed. Thank you for your thoughtful input!
>
> It would be good if other people chimed in with their opinions too, > but if it turns out there are no significant drawbacks I hope said
> minimum size can be ratified in the next version of the websocket
> protocol.
>
> Best,
> Will
> _______________________________________________
> hybi mailing list
> hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi


_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi


--001a11c26a3089373c04df9983e0-- From wb@wbudd.com Thu Jun 20 22:58:49 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16BE421F9FFB for ; Thu, 20 Jun 2013 22:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNVfkwAMRnHQ for ; Thu, 20 Jun 2013 22:58:43 -0700 (PDT) Received: from mail.wbudd.com (li327-245.members.linode.com [66.228.46.245]) by ietfa.amsl.com (Postfix) with ESMTP id 6964521F9FE0 for ; Thu, 20 Jun 2013 22:58:39 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.wbudd.com (Postfix) with ESMTPSA id A1433FD0F for ; Fri, 21 Jun 2013 14:58:38 +0900 (JST) Received: by mail-qa0-f48.google.com with SMTP id cm16so276282qab.7 for ; Thu, 20 Jun 2013 22:58:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pAoy6hZPfFAd4clI5Nd259NJqbJgHt1PCsv4alZRYrM=; b=Sj6HmmhvotaCdcbBRGHKsTjH1PH8wb7q2iLR62Jm8KiHHsw2z9hOxJLNX6BD0e8Iv1 LDKk9zZs+fLiEEfma9DafLVRf8O63uvVdZzXX1Uu1wYrz8epDZnwouD7S7eOlw80h1de 6H3sbCu4WzMfe+PlaH2MzraXMuZ5NfwKdhlu6cbI1mY5DsOPzjRtddKgNSLvapv3LbZg z7CD3o8eCBSuChE1ZxuuTkQVKqkJDESFnH+RCTkitbsx30wff3DGsVezSwSVN5xSWpB4 WDTzzy5xP/sdeLti+6fOCFgdUgRpk8bqT7yKlHgppiw36dynVN7iYAijQ3lDPykUVFv3 honA== MIME-Version: 1.0 X-Received: by 10.49.37.225 with SMTP id b1mr12991439qek.24.1371794318268; Thu, 20 Jun 2013 22:58:38 -0700 (PDT) Received: by 10.49.58.174 with HTTP; Thu, 20 Jun 2013 22:58:38 -0700 (PDT) Date: Fri, 21 Jun 2013 14:58:38 +0900 Message-ID: From: William Budd To: "hybi@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 05:58:49 -0000 Peter Thorson wrote: > I would argue that a WebSocket server that dropped connections attempting > to send excessive numbers of fragments (for some application defined value > of excessive) or fragments that were too small (for some application defined > value of small) with a private code or code 1008/Policy Violation would be > compliant with RFC6455 without any modifications. That would be nice, but I'm not sure I agree with that. Quoting the relevant section of RFC 6455: "Unless specified otherwise by an extension, frames have no semantic meaning. An intermediary might coalesce and/or split frames, if no extensions were negotiated by the client and the server or if some extensions were negotiated, but the intermediary understood all the extensions negotiated and knows how to coalesce and/or split frames in the presence of these extensions. One implication of this is that in absence of extensions, senders and receivers must not depend on the presence of specific frame boundaries." Assume a server considers a certain amount of fragments per message excessive, and documents this fact as part of the API description on its website. It's clients take note and make sure that they don't fragment beyond the documented threshold. Despite the best of intentions by both endpoints, the connections can still fail here in unpredictable ways, because any intermediaries (otherwise uninvolved 3rd parties) are free to fragment messages further as per RFC 6455. The consensus between endpoints becomes irrelevant because the intermediate didn't know about the agreement and really had no reason to care anyway. In that sense, senders and receivers are in fact "depending here on the presence of specific frame boundaries", and thus in violation of the spec quoted above. (Please correct me if my interpretation is misguided.) Zhong Yu wrote: > But why would empty frames cause any trouble for the receiver? > Can't the receiver simply discard them? Let me repeat just in case: I'm only referring to empty frames that do *not* have the FIN bit set. In other words, these are frames that specify that the message is incomplete and will continue in an upcoming continuation frame. So why can't I simply discard those? Because as long as I haven't yet received any (or enough) of the payload of said message, I can't yet determine whether the payload will turn out to be valid or not from the p.o.v. off my application. To discard the message merely on the basis of frame boundaries seems to me like a violation of the spec ("senders and receivers must not depend on the presence of specific frame boundaries."). Or at least that's how I interpreted it. Joakim Erdfelt wrote: > alternative behavior would be for the Client to state that it supports fragment > rules by simply saying > fragment >and the server responding with the rules it expects > fragment; min=0; max=1234567 > > thoughts? I think this would be an excellent idea, actually. My "min. size for non-final fragments idea" might be less work to implement, but if it turns out to be too controversial or problematic in some use cases, I'd rally behind this. Perhaps this kind of negotiation during handshake would be best to keep everyone happy. That said, I'm again not sure what the role of intermediaries would be here. What should happen if intermediaries don't like the values negotiated by the endpoints? Joakim Erdfelt wrote: > The library however has no prior knowledge of the size of the message, so the > flush could occur, then the user application determines it is done streaming data > and simply closes that message stream, resulting in a need for a final 0 payload > length FIN frame. Tobias Oberstein wrote: > Yep. That's exactly what Autobahn does when using it's streaming API: complete > the message by sending an empty FIN frame. Sorry to repeat myself again, but my proposal would explicitly allow 0 payload length FIN frames. Reread the subject line of these emails? Anyway, I appreciate you all for being open minded enough to (at least) consider changes like these at this late stage of the game. Best, Will From zhong.j.yu@gmail.com Fri Jun 21 07:00:28 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4DB21E8116 for ; Fri, 21 Jun 2013 07:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tydEHxN33KJg for ; Fri, 21 Jun 2013 07:00:27 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9806811E818C for ; Fri, 21 Jun 2013 07:00:27 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id xn12so8453260obc.20 for ; Fri, 21 Jun 2013 07:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=shfbVUoVJ8+aJO9NWenKY6BiaSd+EMMqeoxGA1sD0SE=; b=Vo6qHeI6asfxP/6fFOCVdr7T2KYwzgZICOQq8dufc91YnD3/sOUDrcNiLQKhAY0vWh F+uu0zmiAm0W/OUqaYrNTiP91Dmb+fvs67bvzs3CdAFmdeb1gIawbQm8nfnkNsm/gYyw lqkoHFbruDPUO3UrqeJFCMQnP4jDpUoM+oAXWDKk1f0QOM1XOVys4JTvymP7ov4v+xLT IbDs+B1kQLvNi6NyfdP8CYjJqAGGRftJ/lsmLX5reTZzrucMZ8xhP5atib5K088wMA1X XxTulwKmZtu8EdL053lk7fFIRXtoGW63XiRGevNRYIpQo8+k6fnd9aGER9vhzfrMo9+Z jjPA== MIME-Version: 1.0 X-Received: by 10.60.37.168 with SMTP id z8mr6643574oej.66.1371823227070; Fri, 21 Jun 2013 07:00:27 -0700 (PDT) Received: by 10.76.79.8 with HTTP; Fri, 21 Jun 2013 07:00:26 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 Jun 2013 09:00:26 -0500 Message-ID: From: Zhong Yu To: William Budd Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 14:00:28 -0000 On Fri, Jun 21, 2013 at 12:58 AM, William Budd wrote: > Peter Thorson wrote: >> I would argue that a WebSocket server that dropped connections attempting >> to send excessive numbers of fragments (for some application defined value >> of excessive) or fragments that were too small (for some application defined >> value of small) with a private code or code 1008/Policy Violation would be >> compliant with RFC6455 without any modifications. > > That would be nice, but I'm not sure I agree with that. Quoting the > relevant section of RFC 6455: > > "Unless specified otherwise by an extension, frames have no semantic > meaning. An intermediary might coalesce and/or split frames, if no > extensions were negotiated by the client and the server or if some > extensions were negotiated, but the intermediary understood all the > extensions negotiated and knows how to coalesce and/or split frames > in the presence of these extensions. One implication of this is that > in absence of extensions, senders and receivers must not depend on > the presence of specific frame boundaries." > > Assume a server considers a certain amount of fragments per message > excessive, and documents this fact as part of the API description on > its website. It's clients take note and make sure that they don't > fragment beyond the documented threshold. > > Despite the best of intentions by both endpoints, the connections can > still fail here in unpredictable ways, because any intermediaries > (otherwise uninvolved 3rd parties) are free to fragment messages > further as per RFC 6455. The consensus between endpoints becomes > irrelevant because the intermediate didn't know about the agreement > and really had no reason to care anyway. In that sense, senders and > receivers are in fact "depending here on the presence of specific > frame boundaries", and thus in violation of the spec quoted above. > (Please correct me if my interpretation is misguided.) > > > Zhong Yu wrote: >> But why would empty frames cause any trouble for the receiver? >> Can't the receiver simply discard them? > > Let me repeat just in case: I'm only referring to empty frames that do > *not* have the FIN bit set. In other words, these are frames that > specify that the message is incomplete and will continue in an > upcoming continuation frame. So why can't I simply discard those? > Because as long as I haven't yet received any (or enough) of the > payload of said message, I can't yet determine whether the payload > will turn out to be valid or not from the p.o.v. off my application. > To discard the message merely on the basis of frame boundaries seems Hi William, I meant that these empty *frames* can be discarded by server. My understanding is that you want one message correspond to one frame and vice versa in your application where all messages are tiny, this will make coding a little easier. I think that you have to bite the bullet and handle the complexity of buffering fragmented messages:) Zhong Yu > to me like a violation of the spec ("senders and receivers must not > depend on the presence of specific frame boundaries."). Or at least > that's how I interpreted it. > > > Joakim Erdfelt wrote: >> alternative behavior would be for the Client to state that it supports fragment >> rules by simply saying >> fragment >>and the server responding with the rules it expects >> fragment; min=0; max=1234567 >> >> thoughts? > > I think this would be an excellent idea, actually. My "min. size for > non-final fragments idea" might be less work to implement, but if it > turns out to be too controversial or problematic in some use cases, > I'd rally behind this. Perhaps this kind of negotiation during > handshake would be best to keep everyone happy. > > That said, I'm again not sure what the role of intermediaries would be > here. What should happen if intermediaries don't like the values > negotiated by the endpoints? > > > Joakim Erdfelt wrote: >> The library however has no prior knowledge of the size of the message, so the >> flush could occur, then the user application determines it is done streaming data >> and simply closes that message stream, resulting in a need for a final 0 payload >> length FIN frame. > Tobias Oberstein wrote: >> Yep. That's exactly what Autobahn does when using it's streaming API: complete >> the message by sending an empty FIN frame. > > Sorry to repeat myself again, but my proposal would explicitly allow 0 > payload length FIN frames. Reread the subject line of these emails? > > Anyway, I appreciate you all for being open minded enough to (at > least) consider changes like these at this late stage of the game. > > Best, > Will > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From wb@wbudd.com Fri Jun 21 08:01:41 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD21521F9993 for ; Fri, 21 Jun 2013 08:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYTgBmE--Xhq for ; Fri, 21 Jun 2013 08:01:35 -0700 (PDT) Received: from mail.wbudd.com (li327-245.members.linode.com [66.228.46.245]) by ietfa.amsl.com (Postfix) with ESMTP id 7E20821F9958 for ; Fri, 21 Jun 2013 08:01:34 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.wbudd.com (Postfix) with ESMTPSA id 5CDF0FD0F for ; Sat, 22 Jun 2013 00:01:33 +0900 (JST) Received: by mail-qc0-f175.google.com with SMTP id k14so4644558qcv.6 for ; Fri, 21 Jun 2013 08:01:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GKAwig1YPEi1ZBAW9Oz4G4m7ZtqDI01AwgrkibRHlZg=; b=AT1MyXza+1qHvnkNw8yjIT8A8E2dhE4Sjk/3Y4QBSl/rAOgK4lIc14JoL4nUQxDHIw QIX0nMETenSsMKpY8Bf3PhonXOVkpqNVz6sSuIwsUwv0xxjyE9+seEbGNUoCOkrbc36Y Z5XrXtFGgwUiQqUbUfb7bPfoSaeiCyfK0X1zN0LDdLG+6V+tq1b0ocyaB/mvENe1bFSW 7uDQQ3xcpaPZOD1d7/Y6A4XdRFJdn0TNHu2CpStyNMQaibkNKRA6kprpzAoCF/pKrCT8 Kj2YmMqzgr8ZvLy9ASLb26uwqPoP/dtZhj3gBnsl2ixMx10WXFv+MvbxZd0T2EP0hjOA aP7g== MIME-Version: 1.0 X-Received: by 10.224.2.129 with SMTP id 1mr5879062qaj.100.1371826893063; Fri, 21 Jun 2013 08:01:33 -0700 (PDT) Received: by 10.49.58.174 with HTTP; Fri, 21 Jun 2013 08:01:32 -0700 (PDT) In-Reply-To: References: Date: Sat, 22 Jun 2013 00:01:32 +0900 Message-ID: From: William Budd To: Zhong Yu Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 15:01:41 -0000 >>> But why would empty frames cause any trouble for the receiver? >>> Can't the receiver simply discard them? >> >> Let me repeat just in case: I'm only referring to empty frames that do >> *not* have the FIN bit set. In other words, these are frames that >> specify that the message is incomplete and will continue in an >> upcoming continuation frame. So why can't I simply discard those? >> Because as long as I haven't yet received any (or enough) of the >> payload of said message, I can't yet determine whether the payload >> will turn out to be valid or not from the p.o.v. off my application. >> To discard the message merely on the basis of frame boundaries seems > > Hi William, I meant that these empty *frames* can be discarded by server. > > My understanding is that you want one message correspond to one frame > and vice versa in your application where all messages are tiny, this > will make coding a little easier. I think that you have to bite the > bullet and handle the complexity of buffering fragmented messages:) Ah, sorry, I see. Right, of course I can discard those frames, but we all know that doing so isn't free. It requires a couple of CPU instructions to parse the extra frames. The likelihood of a read buffer containing partial payloads goes up. State machines become slightly larger. Code complexity increases a bit. More per-client payload buffers means more cache misses. Etcetera. None of these things are a terribly big deal if there really is a good reason to be doing so, but the thing is; it is not at all clear to me that there is such a reason. As of yet nobody has replied with a reason (as far as I can tell) why anyone would want to send any non-FIN fragment of less than 125 bytes (other than for malicious purposes). Especially so since the websocket protocol is designed to allow control frames (with arbitrary payloads of up to 125 bytes) to be inserted in between fragments whenever needed. And if there is no reason to do so, why not make that threshold official and make the job of implementers out there a little easier, and allow his or her software to run a little faster? (And I address this question not to you only, but to everyone reading this email). Apologies for the --vverbosity, Will From tobias.oberstein@tavendo.de Fri Jun 21 08:18:21 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9121B21F9E5C for ; Fri, 21 Jun 2013 08:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGBLDVVQR7yY for ; Fri, 21 Jun 2013 08:18:16 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE1821F9E04 for ; Fri, 21 Jun 2013 08:18:15 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.90]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Fri, 21 Jun 2013 08:18:14 -0700 From: Tobias Oberstein To: William Budd , Zhong Yu Date: Fri, 21 Jun 2013 08:18:13 -0700 Thread-Topic: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes Thread-Index: Ac5ukEqNschsUGPZTseePqygpV/rkwAALo8g Message-ID: <634914A010D0B943A035D226786325D4422DF4C77B@EXVMBX020-12.exch020.serverdata.net> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 15:18:21 -0000 > As of yet nobody has replied with a reason (as far as I can tell) why any= one > would want to send any non-FIN fragment of less than 125 bytes (other tha= n for > malicious purposes). Especially so since the websocket protocol is design= ed to > allow control frames (with arbitrary payloads of up to 125 bytes) to be i= nserted > in between fragments whenever needed. And if there is no reason to do so,= why Sending of control frames might not be exposed in API, but an implementatio= n exposing a frame-based API can allow apps to do app-level keep-alive by s= ending empty payload frames (I am not saying that this is a terrible good i= dea, but it shows that it restricts what can be done ..) > not make that threshold official and make the job of implementers out the= re a Because it's a) arbitrary (why 125?) or requires negotiation and b) an implementation with frame-based (or streaming) API might not want to = buffer up stuff up to 125 before it sends out a frame. > little easier, and allow his or her software to run a little faster? (And= I address > this question not to you only, but to everyone reading this email). It makes implementations more complex. It's one thing to forbid empty payload non-FIN frames and another to requir= e an arbitrary minimal payload size.=20 /Tobias From webmaster@zaphoyd.com Fri Jun 21 08:21:29 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3870B21F9458 for ; Fri, 21 Jun 2013 08:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhR2whDcKcCW for ; Fri, 21 Jun 2013 08:21:21 -0700 (PDT) Received: from sh78.surpasshosting.com (sh78.surpasshosting.com [72.29.64.142]) by ietfa.amsl.com (Postfix) with ESMTP id D671B21F90CC for ; Fri, 21 Jun 2013 08:21:17 -0700 (PDT) Received: from ranna.uchicago.edu ([128.135.45.206]:58396) by sh78.surpasshosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Uq39H-0002uR-Hw; Fri, 21 Jun 2013 11:21:16 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Peter Thorson In-Reply-To: Date: Fri, 21 Jun 2013 10:21:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: William Budd X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sh78.surpasshosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zaphoyd.com X-Get-Message-Sender-Via: sh78.surpasshosting.com: authenticated_id: webmaster@zaphoyd.com X-Source: X-Source-Args: X-Source-Dir: Cc: "hybi@ietf.org" Subject: Re: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 15:21:29 -0000 On Jun 21, 2013, at 10:01 , William Budd wrote: >>>> But why would empty frames cause any trouble for the receiver? >>>> Can't the receiver simply discard them? >>>=20 >>> Let me repeat just in case: I'm only referring to empty frames that = do >>> *not* have the FIN bit set. In other words, these are frames that >>> specify that the message is incomplete and will continue in an >>> upcoming continuation frame. So why can't I simply discard those? >>> Because as long as I haven't yet received any (or enough) of the >>> payload of said message, I can't yet determine whether the payload >>> will turn out to be valid or not from the p.o.v. off my application. >>> To discard the message merely on the basis of frame boundaries seems >>=20 >> Hi William, I meant that these empty *frames* can be discarded by = server. >>=20 >> My understanding is that you want one message correspond to one frame >> and vice versa in your application where all messages are tiny, this >> will make coding a little easier. I think that you have to bite the >> bullet and handle the complexity of buffering fragmented messages:) >=20 > Ah, sorry, I see. Right, of course I can discard those frames, but we > all know that doing so isn't free. >=20 > It requires a couple of CPU instructions to parse the extra frames. > The likelihood of a read buffer containing partial payloads goes up. > State machines become slightly larger. Code complexity increases a > bit. More per-client payload buffers means more cache misses. > Etcetera. None of these things are a terribly big deal if there really > is a good reason to be doing so, but the thing is; it is not at all > clear to me that there is such a reason. >=20 > As of yet nobody has replied with a reason (as far as I can tell) why > anyone would want to send any non-FIN fragment of less than 125 bytes > (other than for malicious purposes). Especially so since the websocket > protocol is designed to allow control frames (with arbitrary payloads > of up to 125 bytes) to be inserted in between fragments whenever > needed. And if there is no reason to do so, why not make that > threshold official and make the job of implementers out there a little > easier, and allow his or her software to run a little faster? (And I > address this question not to you only, but to everyone reading this > email). >=20 > Apologies for the --vverbosity, > Will I see two cases where framing related limitations come into play. 1. An endpoint that needs to apply limitations based on the type of = application is is running. For example a service that processed large = volumes of short text messages might want to choose a fixed message = buffer size for more efficient operation and issue a 1008 error if a = larger message came in. In this case of application specific limitations I think informal = consensus between endpoints or explicitly defined extensions detailing = the requirements and/or allowing negotiation of them are both excellent = solutions. I don't think defining these types of limitations makes sense = in the core protocol as the limitations and their reasoning is very much = time and application specific. A non-malicious reason for sending small = frames would be a case of streaming API that wanted to send character by = character "as you type" data as is commonly done in chat programs or = interactive terminals. As you have pointed out above, one limitation of informal consensus is = the ability for intermediaries to gum things up. Extensions would get = around that, as the rules stated in RFC6455 only apply when the = intermediary understands all extensions being used, perhaps not from a = technical standpoint, as the intermediary may still not be able to work = under the given constraints but the reason reported to the endpoints = about what is wrong would be more clear. 2. Security against resource exhaustion / DoS attacks. Examples: Very = large frames (i.e. frames too large for any endpoint to reasonably = buffer in memory), excessive numbers of small or zero length frames, = etc. In these cases you cannot rely on the remote endpoint or any = intermediaries to behave according to a specification. No matter what = the spec says, your server will need to unilaterally impose security = policies about the various limits that it can handle without regard to = what is officially allowed. Adding such a requirement to the official = specification would not prevent implementers from having to deal with = small frames in malicious situations.= From wb@wbudd.com Fri Jun 21 09:28:18 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0CD21F9F31 for ; Fri, 21 Jun 2013 09:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DreZ-Aplxi0h for ; Fri, 21 Jun 2013 09:28:07 -0700 (PDT) Received: from mail.wbudd.com (li327-245.members.linode.com [66.228.46.245]) by ietfa.amsl.com (Postfix) with ESMTP id DB4C021F9948 for ; Fri, 21 Jun 2013 09:28:02 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.wbudd.com (Postfix) with ESMTPSA id A347BFD12 for ; Sat, 22 Jun 2013 01:27:38 +0900 (JST) Received: by mail-qc0-f176.google.com with SMTP id z10so4699884qcx.21 for ; Fri, 21 Jun 2013 09:27:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pTSbHf3G5o8OM06tgnlMHPAaTj5ezmxRDRG8PoRV+UA=; b=odPwGrm9WudwpiwHrZai5mGlbqLObaTxh4MUKSUuGcPMHYpIf0Su5rNq/6sUWukmpB hAmXpo6MLwStgFsiO5zo5qxUEGKl5FbMgcgeBRRwXSjO2wHTCRxXbQb1Z8CCLzeUdiXe f0Pes4y6hAaTtdFmjQ+Da4EiD12Llxv9mwC++EnRd1yUx/z6XawBsYzLONGMKB1zQEX7 gAcqE5nt0OHEhz3zOsZEOfDXLJaHzuzxUh8C4JNMOU0rLk+XvrY5VDLzj3hFJqmY+hgp vsY4tp8KLXs5iTwOrqV36kt1BjYYuP7idIGpQ1JVBITond6nZG1I5oYZB702O2PbZuHt atAQ== MIME-Version: 1.0 X-Received: by 10.49.116.79 with SMTP id ju15mr15648277qeb.2.1371832058279; Fri, 21 Jun 2013 09:27:38 -0700 (PDT) Received: by 10.49.58.174 with HTTP; Fri, 21 Jun 2013 09:27:38 -0700 (PDT) In-Reply-To: References: Date: Sat, 22 Jun 2013 01:27:38 +0900 Message-ID: From: William Budd To: Peter Thorson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 16:28:18 -0000 > A non-malicious reason for sending small frames would be a case of stream= ing API that wanted to send character by character "as you type" data as is= commonly done in chat programs or interactive terminals. Any such input character frames really don't need to be fragmented though. Just set the final bit on every frame, and treat them all as separate messages, without incurring any performance penalty or other downside. (If anything, it could be speed up the implementation, because any layer unaware of the chat API might otherwise needlessly check for continuations instead of just blindly handing it over to the app.) While you might argue that on some semantical level individual characters don't make for separate messages, I don't believe such a consideration has anything to do with why websocket fragmentation was implemented in the first place, as the distinction is of no practical consequence. As RFC 6455 points out, fragmentation in websockets is merely a mechanism intended to make large blobs of data easier to handle. > As you have pointed out above, one limitation of informal consensus is th= e ability for intermediaries to gum things up. Extensions would get around = that, as the rules stated in RFC6455 only apply when the intermediary under= stands all extensions being used, perhaps not from a technical standpoint, = as the intermediary may still not be able to work under the given constrain= ts but the reason reported to the endpoints about what is wrong would be mo= re clear. True, but it seems to me that the elephant in the room with regard to websocket extensions is that you can forget about your clients using their browser of choice to connect to your server and have them understand the extension, unless you're a huge company like Google with the clout to influence said browsers to support doing so. > 2. Security against resource exhaustion / DoS attacks. Examples: Very lar= ge frames (i.e. frames too large for any endpoint to reasonably buffer in m= emory), excessive numbers of small or zero length frames, etc. In these cas= es you cannot rely on the remote endpoint or any intermediaries to behave a= ccording to a specification. No matter what the spec says, your server will= need to unilaterally impose security policies about the various limits tha= t it can handle without regard to what is officially allowed. Adding such a= requirement to the official specification would not prevent implementers f= rom having to deal with small frames in malicious situations. That's true as well, but I'd prefer to defend my server's policy by saying "you violated the spec", rather than by saying "the spec allows what you did, but it's actually still always a horrible thing to do, and might have brought down my server if I hadn't refused it". :) Will From wb@wbudd.com Fri Jun 21 09:40:57 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E53011E81A3 for ; Fri, 21 Jun 2013 09:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Lq+dRWozKbz for ; Fri, 21 Jun 2013 09:40:51 -0700 (PDT) Received: from mail.wbudd.com (li327-245.members.linode.com [66.228.46.245]) by ietfa.amsl.com (Postfix) with ESMTP id 8076611E8193 for ; Fri, 21 Jun 2013 09:40:51 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.wbudd.com (Postfix) with ESMTPSA id EFEB1FD0F for ; Sat, 22 Jun 2013 01:40:41 +0900 (JST) Received: by mail-qc0-f176.google.com with SMTP id z10so4723953qcx.7 for ; Fri, 21 Jun 2013 09:40:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6uJ9J4oa0bdtgXZA8hZYRW74STKPi3cwbzUdEK+H+FA=; b=b+56x/exw+RlrQIxGguNnrqDoSYU/7lrloWKro0s8VIuoqOiZn62RiZZu8ipV0MEQk drgc+580F0TdwHPAX3zwEYXkaVvsm9AVvCXYBCGPvZLPph5mtU/Y+XddL2xjh9mvjeq/ 25dLy9XwhSLHoVdzQwve0qU8As8fke2/eQqRhkzWFIRt59TLSImfOgQfvgy4lrX4QtIc unMYmoSaTdqJPOskgYOSFm7drzB6ge+HeuSrMj1EkF7pgJ1Z1iFRAA2uNNpkgsTUK8JW 7Hd029f4s6XHJ8QxYjEWeftvxvIbFN2+OFn1Uuly13Es/ldfL6uKwoXECtgBIgzyTU0D kQjQ== MIME-Version: 1.0 X-Received: by 10.49.37.225 with SMTP id b1mr15496005qek.24.1371832841721; Fri, 21 Jun 2013 09:40:41 -0700 (PDT) Received: by 10.49.58.174 with HTTP; Fri, 21 Jun 2013 09:40:41 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D4422DF4C77B@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D4422DF4C77B@EXVMBX020-12.exch020.serverdata.net> Date: Sat, 22 Jun 2013 01:40:41 +0900 Message-ID: From: William Budd To: Tobias Oberstein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 16:40:57 -0000 >> As of yet nobody has replied with a reason (as far as I can tell) why an= yone >> would want to send any non-FIN fragment of less than 125 bytes (other th= an for >> malicious purposes). Especially so since the websocket protocol is desig= ned to >> allow control frames (with arbitrary payloads of up to 125 bytes) to be = inserted >> in between fragments whenever needed. And if there is no reason to do so= , why > > Sending of control frames might not be exposed in API, but an implementat= ion exposing a frame-based API can allow apps to do app-level keep-alive by= sending empty payload frames (I am not saying that this is a terrible good= idea, but it shows that it restricts what can be done ..) Alright, but how would that work though? Since the empty payload frame would be part of a larger fragmented message, I would expect any response to that frame to come back no sooner than the response to the entire message it's part of, given that it technically isn't a control frame. In other words, wouldn't this "app-level keep-alive" better be sent as a separate message? >> not make that threshold official and make the job of implementers out th= ere a > > Because it's > a) arbitrary (why 125?) or requires negotiation and > b) an implementation with frame-based (or streaming) API might not want t= o buffer up stuff up to 125 before it sends out a frame. It's no more arbitrary than what's already in the spec. I'm deliberately mirroring the maximum size of control frames in my suggestion. That is, the spec says control frames can be no more than 125 bytes. I say, non-FIN fragment frames can be no less than 125 bytes. Their use cases are in many ways complimentary (and because 125 is the max value you can specify in the first pay load size byte). Just trying to be practical and pragmatic here. Will From tobias.oberstein@tavendo.de Fri Jun 21 10:50:41 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B844E21F9FA0 for ; Fri, 21 Jun 2013 10:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zdZ876d-irb for ; Fri, 21 Jun 2013 10:50:36 -0700 (PDT) Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id 517BA21F9F36 for ; Fri, 21 Jun 2013 10:50:35 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.90]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Fri, 21 Jun 2013 10:50:34 -0700 From: Tobias Oberstein To: William Budd Date: Fri, 21 Jun 2013 10:50:34 -0700 Thread-Topic: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes Thread-Index: Ac5unhJ+fBb2+NNyQoeaqv4moeqijAABvyxQ Message-ID: <634914A010D0B943A035D226786325D4422DF4C89C@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D4422DF4C77B@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 17:50:41 -0000 > > Sending of control frames might not be exposed in API, but an > > implementation exposing a frame-based API can allow apps to do > > app-level keep-alive by sending empty payload frames (I am not saying > > that this is a terrible good idea, but it shows that it restricts what > > can be done ..) >=20 > Alright, but how would that work though? Since the empty payload frame wo= uld > be part of a larger fragmented message, I would expect any response to th= at > frame to come back no sooner than the response to the entire message it's= part There is no response expected .. it's just about pushing some octets onto t= he wire to keep the endpoints (e.g. radio) or any intermediaries from sending the TCP = to sleep. > of, given that it technically isn't a control frame. In other words, woul= dn't this > "app-level keep-alive" better be sent as a separate message? An app that uses a frame-based API might not want to start a new message just to do app-level keep alive. > >> not make that threshold official and make the job of implementers out > >> there a > > > > Because it's > > a) arbitrary (why 125?) or requires negotiation and > > b) an implementation with frame-based (or streaming) API might not want= to > buffer up stuff up to 125 before it sends out a frame. >=20 > It's no more arbitrary than what's already in the spec. I'm deliberately > mirroring the maximum size of control frames in my suggestion. That is, t= he > spec says control frames can be no more than > 125 bytes. I say, non-FIN fragment frames can be no less than 125 bytes. = Their Obviously, "no more" is something different than "no less", and regarding d= ata messages, there is only 1 "arbitrary" limit in the spec: a data frame may h= ave a payload of at most 2^63 octets (which amounts to "infinity" in practice). And what about b)? At this point, my point of view is: your original worry about DoS is valid,= but better served via implementation knobs. Given that, I just fail to see value in im= posing a lower bound on non-FIN frame payload length. It seems to make implementat= ions more complex and restrict apps. =20 /Tobias From zhong.j.yu@gmail.com Fri Jun 21 13:26:07 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CD421F9CF7 for ; Fri, 21 Jun 2013 13:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiLr1q344Clg for ; Fri, 21 Jun 2013 13:26:07 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id C9F1121F9CEE for ; Fri, 21 Jun 2013 13:26:06 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id k14so9710512oag.40 for ; Fri, 21 Jun 2013 13:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MiDhue2HkS63RPRuafoEuZuuvVzrJmripdGDowX3Alo=; b=Cse6TQZEyDrfMWqTGLpWuykwdJtr9B7dWZB3CPdmqUDPKlY8BgIFBZnXDNzoFFPd/W 6qJiZqWrggrxE2COnneEREXa1xG3M+Y58QkAK+ad5pebdehhON6ry3geBmTtOU1Eq8VR JIHp85jtd9Q+Epb+lWjUazchE3+H8Bc4W7Ql8YZoP0SzqAj/vPJEnABwWjk7NHLV7jo/ dVALIWCw5J8KI3ru9fsrSXrepKbYjK9spu00NPzH14MQqtRyn1Kba4dToufMau1RPOaG Xf1IE+4PkQKTenihoM7v+Z23XutrK2eM7jD2f+QsuyBFkkbsKACjqHiLNBI3lEKzsMrc jqtg== MIME-Version: 1.0 X-Received: by 10.182.102.234 with SMTP id fr10mr4146542obb.85.1371846366183; Fri, 21 Jun 2013 13:26:06 -0700 (PDT) Received: by 10.76.79.8 with HTTP; Fri, 21 Jun 2013 13:26:06 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 Jun 2013 15:26:06 -0500 Message-ID: From: Zhong Yu To: William Budd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Peter Thorson Subject: Re: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 20:26:07 -0000 A websocket message is not necessarily an atomic thing for applications. Client and server can stream bytes within a message, and if it's important to transmit bytes as soon as available, it's necessary to support tiny frames. I fail to see why tiny frame can cause any problem for the receiver. If it's a problem, we should have heard of the same thing on other protocols, for example, 1 byte segments in TCP. It does not seems to be a very profitable attack vector. Zhong Yu On Fri, Jun 21, 2013 at 11:27 AM, William Budd wrote: >> A non-malicious reason for sending small frames would be a case of strea= ming API that wanted to send character by character "as you type" data as i= s commonly done in chat programs or interactive terminals. > > Any such input character frames really don't need to be fragmented > though. Just set the final bit on every frame, and treat them all as > separate messages, without incurring any performance penalty or other > downside. (If anything, it could be speed up the implementation, > because any layer unaware of the chat API might otherwise needlessly > check for continuations instead of just blindly handing it over to the > app.) > > While you might argue that on some semantical level individual > characters don't make for separate messages, I don't believe such a > consideration has anything to do with why websocket fragmentation was > implemented in the first place, as the distinction is of no practical > consequence. As RFC 6455 points out, fragmentation in websockets is > merely a mechanism intended to make large blobs of data easier to > handle. > > >> As you have pointed out above, one limitation of informal consensus is t= he ability for intermediaries to gum things up. Extensions would get around= that, as the rules stated in RFC6455 only apply when the intermediary unde= rstands all extensions being used, perhaps not from a technical standpoint,= as the intermediary may still not be able to work under the given constrai= nts but the reason reported to the endpoints about what is wrong would be m= ore clear. > > True, but it seems to me that the elephant in the room with regard to > websocket extensions is that you can forget about your clients using > their browser of choice to connect to your server and have them > understand the extension, unless you're a huge company like Google > with the clout to influence said browsers to support doing so. > > >> 2. Security against resource exhaustion / DoS attacks. Examples: Very la= rge frames (i.e. frames too large for any endpoint to reasonably buffer in = memory), excessive numbers of small or zero length frames, etc. In these ca= ses you cannot rely on the remote endpoint or any intermediaries to behave = according to a specification. No matter what the spec says, your server wil= l need to unilaterally impose security policies about the various limits th= at it can handle without regard to what is officially allowed. Adding such = a requirement to the official specification would not prevent implementers = from having to deal with small frames in malicious situations. > > That's true as well, but I'd prefer to defend my server's policy by > saying "you violated the spec", rather than by saying "the spec allows > what you did, but it's actually still always a horrible thing to do, > and might have brought down my server if I hadn't refused it". :) > > Will > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From jat@jaet.org Fri Jun 21 14:07:44 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1462421F9D80 for ; Fri, 21 Jun 2013 14:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6Empoz3f-lJ for ; Fri, 21 Jun 2013 14:07:20 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCC921F9D77 for ; Fri, 21 Jun 2013 14:07:20 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x12so20633253ief.12 for ; Fri, 21 Jun 2013 14:07:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=XEH4BKlE5R6NfkAmiRc8km4qp7bZenxb7k1QO0cw3lA=; b=ctvKViEpLNodJhRXw9laXqmVMsixhNnElxIwqcqsaLmfRRs+GPd898gIEB2APfnrwb hiOJ3JV37F3tqfvmzQ/jjcBpb3jgASTMh4Z5t3b9/UgWwFUJ3nqD4EhyIgZr5uQbqcuX 78NsRwJyFWW7q3/NqcgqCEXrtitBSFkNceUNnfeQ9xcd/AD9gsCiBMIJQ3xPLIJ9QZzA RuCLDVOjV9eo1sDeA2CjgiWaetUUhnVa8iMcZRxgZtiUd7XvuG4S8lQOf1uEJSHqiODc sjz+HVB5dw0YLz9DyMt1PF3pGdKrwCPn5/XxM2uqUPHYcI5uMtlKYut0hGIhQDB7fQUJ QSPQ== X-Received: by 10.50.3.103 with SMTP id b7mr3341591igb.54.1371848840025; Fri, 21 Jun 2013 14:07:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.220.167 with HTTP; Fri, 21 Jun 2013 14:06:59 -0700 (PDT) X-Originating-IP: [50.199.119.178] In-Reply-To: References: From: "John A. Tamplin" Date: Fri, 21 Jun 2013 17:06:59 -0400 Message-ID: To: William Budd Content-Type: multipart/alternative; boundary=089e013c61e0cbb1a904dfb072b1 X-Gm-Message-State: ALoCoQlcgIaG2Q+Ps1+z1WRVmQYZ9m1+SAeutkQW2s0Ft/oPTVBqdzrz0FXGBgjUzBh+lVMPjtN/ Cc: "hybi@ietf.org" Subject: Re: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 21:07:44 -0000 --089e013c61e0cbb1a904dfb072b1 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 21, 2013 at 11:01 AM, William Budd wrote: > As of yet nobody has replied with a reason (as far as I can tell) why > anyone would want to send any non-FIN fragment of less than 125 bytes > (other than for malicious purposes). Especially so since the websocket > protocol is designed to allow control frames (with arbitrary payloads > of up to 125 bytes) to be inserted in between fragments whenever > needed. And if there is no reason to do so, why not make that > threshold official and make the job of implementers out there a little > easier, and allow his or her software to run a little faster? (And I > address this question not to you only, but to everyone reading this > email). > I don't object to requiring any non-initial, non-final frame to have >0 length. However, I do object to a minimum requirement above 1. For example, let's say I have a streaming API, and 1 byte has been written since the last time the buffer was flushed and a frame sent (whether full or other reasons). The client calls flush - if I can't send a 1-byte frame, I have to ignore the client's request to flush the buffer, breaking my guarantees. -- John A. Tamplin --089e013c61e0cbb1a904dfb072b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 21, 2013 at 11:01 AM, William Budd <wb@wbudd.com= > wrote:
As of yet nobody has = replied with a reason (as far as I can tell) why
anyone would want to send any non-FIN fragment of less than 125 bytes
(other than for malicious purposes). Especially so since the websocket
protocol is designed to allow control frames (with arbitrary payloads
of up to 125 bytes) to be inserted in between fragments whenever
needed. And if there is no reason to do so, why not make that
threshold official and make the job of implementers out there a little
easier, and allow his or her software to run a little faster? (And I
address this question not to you only, but to everyone reading this
email).
=C2=A0
I don't object to requir= ing any non-initial, non-final frame to have >0 length. =C2=A0However, I= do object to a minimum requirement above 1.

For example, let's say I have a streaming AP= I, and 1 byte has been written since the last time the buffer was flushed a= nd a frame sent (whether full or other reasons). =C2=A0The client calls flu= sh - if I can't send a 1-byte frame, I have to ignore the client's = request to flush the buffer, breaking my guarantees.

--
John A. Tamplin
--089e013c61e0cbb1a904dfb072b1-- From wb@wbudd.com Fri Jun 21 21:32:51 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED2F21E8097 for ; Fri, 21 Jun 2013 21:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.955 X-Spam-Level: X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 995iw-l8sKBZ for ; Fri, 21 Jun 2013 21:32:46 -0700 (PDT) Received: from mail.wbudd.com (li327-245.members.linode.com [66.228.46.245]) by ietfa.amsl.com (Postfix) with ESMTP id D0B5D21E80AC for ; Fri, 21 Jun 2013 21:32:45 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.wbudd.com (Postfix) with ESMTPSA id 93EFBFD0B for ; Sat, 22 Jun 2013 13:32:44 +0900 (JST) Received: by mail-qc0-f178.google.com with SMTP id c11so5247525qcv.9 for ; Fri, 21 Jun 2013 21:32:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q5BjQlWV44JKqwbZUmp7uSeshyJxsljfGu6Ul3Xm4g0=; b=OFDbvritFASK4yiqd6Hmr4OfnArauwSKrpiS1qNaQ1pgeTu9dMquD0dTHudmsG3cry qDMLlwFvVEN6iy8mXdLLBqY1VlHrgEB+7G33ts5t9zj8DhvjI31UetgtpFn2enLpgxwf /L03AW3T9JY617JS0kR0kEDdDTBsVYhxIIvAId1TiGT8sknPrdYD1e1ZE+rOcz6ilyni jfMONgLAD8l9G4RSByNDoPY3hFNRhobS2C+qLcD+xiuPSWmoeKt0zW3peK/01k2DVD6x wlliHYhSHZljuA4dMYiCzT0E8sL/EWQpXE7spaSohTinmALXdJFfrHOcqipKbdL0VIHr yPLg== MIME-Version: 1.0 X-Received: by 10.224.188.74 with SMTP id cz10mr17438156qab.31.1371875564142; Fri, 21 Jun 2013 21:32:44 -0700 (PDT) Received: by 10.49.58.174 with HTTP; Fri, 21 Jun 2013 21:32:44 -0700 (PDT) In-Reply-To: References: Date: Sat, 22 Jun 2013 13:32:44 +0900 Message-ID: From: William Budd To: "John A. Tamplin" Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 04:32:51 -0000 > I don't object to requiring any non-initial, non-final frame to have >0 > length. However, I do object to a minimum requirement above 1. > > For example, let's say I have a streaming API, and 1 byte has been written > since the last time the buffer was flushed and a frame sent (whether full or > other reasons). The client calls flush - if I can't send a 1-byte frame, I > have to ignore the client's request to flush the buffer, breaking my > guarantees. Alright. Tobias, Zhong and you have convinced me that using websocket fragmentation is an established way of implementing a streaming API, and that requiring said minimum size would interfere with that. I personally think you could just as well stream by sending separate websocket messages. That is, whenever you want to flush the buffer, just send whatever you have with the FIN flag set. The presence of the FIN bit would then just indicate a flush. In that sense, new messages would continue to arrive as part of the same stream. The benefit of this approach is that anyone API handling large opaque data could use the fragmentation mechanism in the intended ways specified in RFC 6455 (note that streaming is *not* mentioned in the spec as rationale for justifying fragmentation), while my suggestion of minimum size would allow everyone who only handles small data and doesn't need fragmentation to be totally oblivious of fragmentation for their purposes. Realistically though, I realize it's way too late to convince people of how I think websocket fragmentation should be used or not be used. These emails are simply a few years too late for that... I still see potential though in what Joakim suggested earlier for a future revision of the protocol: > alternative behavior would be for the Client to state that it supports fragment > rules by simply saying > fragment >and the server responding with the rules it expects > fragment; min=0; max=1234567 Does anyone else like this idea? And if so, any thoughts on "what should happen if intermediaries don't like the values negotiated by the endpoints"? Thanks, Will From jat@jaet.org Fri Jun 21 21:40:48 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F6B11E80E6 for ; Fri, 21 Jun 2013 21:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwbBxTqUi-Td for ; Fri, 21 Jun 2013 21:40:43 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 407CB11E80CC for ; Fri, 21 Jun 2013 21:40:42 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id c10so20877541ieb.38 for ; Fri, 21 Jun 2013 21:40:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=ewR+qeyU+/9pKE8qAi3Nv1+gNMvJKWfp8Uyiw98lz+I=; b=nGIfGtHP/DfzDMEaDTRSo1fqcF+EJvTxRdf08/dfJAa5cik0CbijeLidq8AqzFUVDU 9u9VMl14XrcTDp28OsLPxveqpQwZqQfzGB0nYsy+4NkdoldHmiV1xBpCHQt/ffjjMcwM 0JV5tXIl1Zsa3UpykCmIqNvSuXFlzdvYYUq7802Hzbsymt0U6h29v29kPGzt+l0S3Gu1 Xg+62PmRXEuQGYPQrE62oZvwKX9VXfdF5zFmNt/YzSRlypPFeGDD8Hvs9YTAJpVRG4GR 1EZRkB3B4DPPy+JNkG9Ejd4JVfo+29yMAD82gxDFERfVzi1u7h9ePX2Iswa5Yvb9OnQq iZfQ== X-Received: by 10.42.76.5 with SMTP id c5mr4031865ick.91.1371876042083; Fri, 21 Jun 2013 21:40:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.220.167 with HTTP; Fri, 21 Jun 2013 21:40:22 -0700 (PDT) X-Originating-IP: [50.199.119.178] In-Reply-To: References: From: "John A. Tamplin" Date: Sat, 22 Jun 2013 00:40:22 -0400 Message-ID: To: William Budd Content-Type: multipart/alternative; boundary=90e6ba3fcee12a1b0c04dfb6c8c0 X-Gm-Message-State: ALoCoQnqdwyzQnv0HsHDIAzmbcugN4r+Cev9LMXprK+0IjtgrL84AdcH5ETMkTMSOU2IqA97s8jW Cc: "hybi@ietf.org" Subject: Re: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 04:40:48 -0000 --90e6ba3fcee12a1b0c04dfb6c8c0 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 22, 2013 at 12:32 AM, William Budd wrote: > I personally think you could just as well stream by sending separate > websocket messages. That is, whenever you want to flush the buffer, > just send whatever you have with the FIN flag set. The presence of the > FIN bit would then just indicate a flush. In that sense, new messages > would continue to arrive as part of the same stream. > Then to maintain the message-oriented WebSocket approach, you would have to have another framing level above to say whether this was the last frame of the message or not, since right now FIN means "the message is complete", signal that to the WebSocket client. If you now want FIN to mean "end of this arbitrary buffer boundry" (which btw, the client doesn't actually care to know), then you need to invent something new for the original meaning. Realistically though, I realize it's way too late to convince people > of how I think websocket fragmentation should be used or not be used. > These emails are simply a few years too late for that... > You have no idea how contentious it was to come up with the current framing approach that nobody strongly objected to. It took well over a year to get agreement. I still see potential though in what Joakim suggested earlier for a > future revision of the protocol: > > > alternative behavior would be for the Client to state that it supports > fragment > > rules by simply saying > > fragment > >and the server responding with the rules it expects > > fragment; min=0; max=1234567 > > Does anyone else like this idea? And if so, any thoughts on "what > should happen if intermediaries don't like the values > negotiated by the endpoints"? > If it is something the intermediaries need to care about, it has to be an extension -- otherwise, intermediaries are allowed to arbitrarily change fragmentation to suit their needs. If it is an extension, then it sounds reasonable, though I don't know that there is enough value for there to be enough implementations of it to be useful. -- John A. Tamplin --90e6ba3fcee12a1b0c04dfb6c8c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 22, 2013 at 12:32 AM, William Budd <wb@wbudd.com= > wrote:
I personally think yo= u could just as well stream by sending separate
websocket messages. That is, whenever you want to flush the buffer,
just send whatever you have with the FIN flag set. The presence of the
FIN bit would then just indicate a flush. In that sense, new messages
would continue to arrive as part of the same stream.
<= br>
Then to maintain the message-oriented WebSocket approac= h, you would have to have another framing level above to say whether this w= as the last frame of the message or not, since right now FIN means "th= e message is complete", signal that to the WebSocket client. =C2=A0If = you now want FIN to mean "end of this arbitrary buffer boundry" (= which btw, the client doesn't actually care to know), then you need to = invent something new for the original meaning.=C2=A0

Realistically though, I realize it's way too late to convince people of how I think websocket fragmentation should be used or not be used.
These emails are simply a few years too late for that...

You have no idea how contentious it was to come up = with the current framing approach that nobody strongly objected to. =C2=A0I= t took well over a year to get agreement.

I still see potential though in what Joakim suggested earlier for a
future revision of the protocol:

> alternative behavior would be for the Client to state that it supports= fragment
> rules by simply saying
> =C2=A0fragment
>and the server responding with the rules it expects
> =C2=A0 fragment; min=3D0; max=3D1234567

Does anyone else like this idea? And if so, any thoughts on "wha= t
should happen if intermediaries don't like the values=
negotiated by the endpoints"?

If it is something the intermediaries need to ca= re about, it has to be an extension -- otherwise, intermediaries are allowe= d to arbitrarily change fragmentation to suit their needs. =C2=A0If it is a= n extension, then it sounds reasonable, though I don't know that there = is enough value for there to be enough implementations of it to be useful.<= br clear=3D"all">

--
John A. Tamplin
--90e6ba3fcee12a1b0c04dfb6c8c0-- From wb@wbudd.com Fri Jun 21 22:28:44 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236B221F9D0E for ; Fri, 21 Jun 2013 22:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVQFf1iNj2Q9 for ; Fri, 21 Jun 2013 22:28:38 -0700 (PDT) Received: from mail.wbudd.com (li327-245.members.linode.com [66.228.46.245]) by ietfa.amsl.com (Postfix) with ESMTP id 38FE421F9D23 for ; Fri, 21 Jun 2013 22:28:38 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.wbudd.com (Postfix) with ESMTPSA id B0DC4FD0B for ; Sat, 22 Jun 2013 14:28:37 +0900 (JST) Received: by mail-qc0-f177.google.com with SMTP id n1so5191444qcx.36 for ; Fri, 21 Jun 2013 22:28:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fzseeUCwNAnFYVR+WQe5O2lmQThk7T1s40lpLKW92ig=; b=BE6B1HpSqeJViHqBxta3ynJhBOLxoeala2qCJt1RgH1wYYaNQ7YeCOGnITbNh1SMj0 CVT0IoadsoGlrJ3NYmQk9JeKTImBj4uL3We53XEG6c6e46p2PMLyRBp16zEUYFVUsD0a GOjQ3Va27kbrIBPqMegEJ9q9Z4vvQGvEpFxCmpLoSn1lo2KFjhVXeJNYmOYQjFtdtsGF qb5JGluJvKhGZTIQbK5nlBQOXSUGS0erxAZIm3sjTmI52hxkeWJq63IRxkcVLWk2Nb3q nrg76pjmH08/MYMjnZ2hyCfbziFdX8XjIIOabEtvh0TBMyFKlQUin2/Vw35bJv3b0+MJ 9TPw== MIME-Version: 1.0 X-Received: by 10.49.116.176 with SMTP id jx16mr17799679qeb.52.1371878917435; Fri, 21 Jun 2013 22:28:37 -0700 (PDT) Received: by 10.49.58.174 with HTTP; Fri, 21 Jun 2013 22:28:37 -0700 (PDT) In-Reply-To: References: Date: Sat, 22 Jun 2013 14:28:37 +0900 Message-ID: From: William Budd To: "John A. Tamplin" Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 05:28:44 -0000 On Sat, Jun 22, 2013 at 1:40 PM, John A. Tamplin wrote: > On Sat, Jun 22, 2013 at 12:32 AM, William Budd wrote: >> >> I personally think you could just as well stream by sending separate >> websocket messages. That is, whenever you want to flush the buffer, >> just send whatever you have with the FIN flag set. The presence of the >> FIN bit would then just indicate a flush. In that sense, new messages >> would continue to arrive as part of the same stream. > > > Then to maintain the message-oriented WebSocket approach, you would have to > have another framing level above to say whether this was the last frame of > the message or not, since right now FIN means "the message is complete", > signal that to the WebSocket client. If you now want FIN to mean "end of > this arbitrary buffer boundry" (which btw, the client doesn't actually care > to know), then you need to invent something new for the original meaning. I'd argue that what does or doesn't constitute the end of a message should ideally be handled on the (web)application layer anyway, since the semantics of a "message" are very much domain dependent. The websocket layer only needs to care about sending frames back and fro. In other words, I see websocket fragmentation as a traffic shaping tool for intermediaries, rather than a means for endpoints to express message semantics with (as that can be done with the API semantics of your payload). >> Realistically though, I realize it's way too late to convince people >> of how I think websocket fragmentation should be used or not be used. >> These emails are simply a few years too late for that... > > > You have no idea how contentious it was to come up with the current framing > approach that nobody strongly objected to. It took well over a year to get > agreement. Actually, Google did provide me with some glimpses of that here and there. If I had known of websockets back then I probably wouldn't have hesitated to pour some more oil on that fire. >> I still see potential though in what Joakim suggested earlier for a >> future revision of the protocol: >> >> > alternative behavior would be for the Client to state that it supports >> > fragment >> > rules by simply saying >> > fragment >> >and the server responding with the rules it expects >> > fragment; min=0; max=1234567 >> >> Does anyone else like this idea? And if so, any thoughts on "what >> should happen if intermediaries don't like the values >> negotiated by the endpoints"? > > > If it is something the intermediaries need to care about, it has to be an > extension -- otherwise, intermediaries are allowed to arbitrarily change > fragmentation to suit their needs. If it is an extension, then it sounds > reasonable, though I don't know that there is enough value for there to be > enough implementations of it to be useful. Yeah, you're probably right......... D: thanks, Will From jat@jaet.org Sat Jun 22 05:25:10 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A831411E80F7 for ; Sat, 22 Jun 2013 05:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdsvSlT5KIu9 for ; Sat, 22 Jun 2013 05:25:05 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 86C2A11E80F6 for ; Sat, 22 Jun 2013 05:25:05 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id c10so21305491ieb.38 for ; Sat, 22 Jun 2013 05:25:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=ujxebLFT9SJQ529d+ZoU+oQSCjisSCbxaZOmy4dw5jk=; b=A1N9IB8tVGM1lg47qHV/h0VwHv6pPLVt3zY6pkbxF9BVUEX7D2TwzncmEhNMKSd3yo khptbYQdwk1H6U7j/FqwlB4Q3J7hyXrQpJEhr30NTccA+Tp6YzbT5nEZKeVCYupffgXi DRF+ZJdIZ4JR9AxFLmV/E1Ry8PawTzhdSinE+bL2HD3chauKqSwSJJnu4j3YFCpObNt1 TNnqEtJU7lYjfefEC3F+Wv0KncW3GL5qOQZD80F+uRNTzuA2fxW3sNxa9Eh2SC31xzOq G+Pp+uHG5VaCbEV5AOfFWGGrcEdRStfdC8dzRIfIb607EUK99Fdo6DcqDEe88ERA4O4h IHMQ== X-Received: by 10.50.1.70 with SMTP id 6mr1276942igk.54.1371903905031; Sat, 22 Jun 2013 05:25:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.220.167 with HTTP; Sat, 22 Jun 2013 05:24:44 -0700 (PDT) X-Originating-IP: [50.199.119.178] In-Reply-To: References: From: "John A. Tamplin" Date: Sat, 22 Jun 2013 08:24:44 -0400 Message-ID: To: William Budd Content-Type: multipart/alternative; boundary=047d7bd6c730ecfc8204dfbd444b X-Gm-Message-State: ALoCoQnnQPmghSBfIiB64q1/aeJDFsJjpYcXUom4iBdgv3HAB20r6RVOopLz/rDO9rB6Mww0+AJU Cc: "hybi@ietf.org" Subject: Re: [hybi] Proposal: require non-final websocket frames to have a minimum payload length of X bytes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 12:25:10 -0000 --047d7bd6c730ecfc8204dfbd444b Content-Type: text/plain; charset=UTF-8 On Sat, Jun 22, 2013 at 1:28 AM, William Budd wrote: > I'd argue that what does or doesn't constitute the end of a message > should ideally be handled on the (web)application layer anyway, since > the semantics of a "message" are very much domain dependent. The > websocket layer only needs to care about sending frames back and fro. > In other words, I see websocket fragmentation as a traffic shaping > tool for intermediaries, rather than a means for endpoints to express > message semantics with (as that can be done with the API semantics of > your payload). So basically, you just want a streaming protocol that you can write whatever bytes you like, and then the application decides what messages are? Well, that protocol already exists, and is just plain TCP. Every app would have to implement its own framing, and then connecting to a third-party WebSocket server would require implementing that server's protocol, which is going to have the same complications as writing each protocol on top of TCP today. One of the goals was to make it easy to send messages from a simply JS client in the browser, and having to implement all your own framing in JS doesn't sound like it meets that goal. There are also security issues involved in having potentially hostile JS applications running in the browser (which itself might be behind a firewall with access to sensitive resources) having direct access to TCP, such as exploiting bugs in UTF8 decoders by sending arbitrary bytes to what is intended to be a text-based endpoint. Fragmentation is also required to support streaming without arbitrarily large buffers. Basically, it sounds like you want a different protocol from WebSockets, rather than a simple modification to prevent a DoS attack. I think you should go back and read the archives of the discussions when WebSockets was created to understand the rationale behind the decisions. In any case, it doesn't seem very likely to me that we would revisit the basic idea of what WebSockets is at this point. -- John A. Tamplin --047d7bd6c730ecfc8204dfbd444b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 22, 2013 at 1:28 AM, William Budd <wb@wbudd.com> wrote:
I'd argue that what does or do= esn't constitute the end of a message
should ideally be handled on the (web)application layer anyway, since
the semantics of a "message" are very much domain dependent. The<= br> websocket layer only needs to care about sending frames back and fro.
In other words, I see websocket fragmentation as a traffic shaping
tool for intermediaries, rather than a means for endpoints to express
message semantics with (as that can be done with the API semantics of
your payload).

So basically, you just want = a streaming protocol that you can write whatever bytes you like, and then t= he application decides what messages are? =C2=A0Well, that protocol already= exists, and is just plain TCP. =C2=A0Every app would have to implement its= own framing, and then connecting to a third-party WebSocket server would r= equire implementing that server's protocol, which is going to have the = same complications as writing each protocol on top of TCP today. =C2=A0One = of the goals was to make it easy to send messages from a simply JS client i= n the browser, and having to implement all your own framing in JS doesn'= ;t sound like it meets that goal. =C2=A0 There are also security issues inv= olved in having potentially hostile JS applications running in the browser = (which itself might be behind a firewall with access to sensitive resources= ) having direct access to TCP, such as exploiting bugs in UTF8 decoders by = sending arbitrary bytes to what is intended to be a text-based endpoint.

Fragmentation is also required to support streaming wit= hout arbitrarily large buffers.

Basically, it soun= ds like you want a different protocol from WebSockets, rather than a simple= modification to prevent a DoS attack. =C2=A0I think you should go back and= read the archives of the discussions when WebSockets was created to unders= tand the rationale behind the decisions. =C2=A0 In any case, it doesn't= seem very likely to me that we would revisit the basic idea of what WebSoc= kets is at this point.

--
John A. Tamplin
--047d7bd6c730ecfc8204dfbd444b-- From webmaster@zaphoyd.com Thu Jun 27 17:18:09 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE8011E8147 for ; Thu, 27 Jun 2013 17:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0Hhoo8aHxXu for ; Thu, 27 Jun 2013 17:18:03 -0700 (PDT) Received: from sh78.surpasshosting.com (sh78.surpasshosting.com [72.29.64.142]) by ietfa.amsl.com (Postfix) with ESMTP id 8789721F9246 for ; Thu, 27 Jun 2013 17:18:03 -0700 (PDT) Received: from c-68-51-76-178.hsd1.il.comcast.net ([68.51.76.178]:45514 helo=[10.0.1.88]) by sh78.surpasshosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UsMNp-0007uy-4Z for hybi@ietf.org; Thu, 27 Jun 2013 20:17:50 -0400 From: Peter Thorson Content-Type: multipart/alternative; boundary="Apple-Mail=_521023F4-2ADA-46E3-937F-913E1391AF5B" Message-Id: Date: Thu, 27 Jun 2013 19:17:46 -0500 To: "hybi@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sh78.surpasshosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zaphoyd.com X-Get-Message-Sender-Via: sh78.surpasshosting.com: authenticated_id: webmaster@zaphoyd.com X-Source: X-Source-Args: X-Source-Dir: Subject: [hybi] permessage-deflate "client is not likely to reuse" X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 00:18:09 -0000 --Apple-Mail=_521023F4-2ADA-46E3-937F-913E1391AF5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Section 8.1.1.2 of permessage-deflate draft 10: ... Using this parameter, a client tells the peer server a hint that the = client is not likely to use the same LZ77 sliding window it used to = build frames of the last sent message to build frames of the next = message. ... -> "hint that client is not likely to reuse the sliding window" In order for this to be useful there needs to be a stronger guarantee = than "not likely to use".=20 I would like to see this strengthened such that if a client sends = c2s_no_context_takeover and the server acknowledges then the client must = not reuse the previous sliding window. If the client *won't* reuse then = I can skip reserving memory. If the client "likely won't" then I can't.= --Apple-Mail=_521023F4-2ADA-46E3-937F-913E1391AF5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Section = 8.1.1.2 of permessage-deflate draft 10:
...
Using this parameter, a = client tells the peer server a hint that the client is not likely to use = the same LZ77 sliding window it used to build frames of the last sent = message to build frames of the next message.

-> "hint that client is not = likely to reuse the sliding window"
In order for this to be useful = there needs to be a stronger guarantee than "not likely to = use". 

I would like to see this = strengthened such that if a client sends c2s_no_context_takeover and the = server acknowledges then the client must not reuse the previous sliding = window. If the client *won't* reuse then I can skip reserving memory. If = the client "likely won't" then I can't.
= --Apple-Mail=_521023F4-2ADA-46E3-937F-913E1391AF5B-- From webmaster@zaphoyd.com Thu Jun 27 18:17:13 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089A321F9DC9 for ; Thu, 27 Jun 2013 18:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFHOBm6i+YGu for ; Thu, 27 Jun 2013 18:17:04 -0700 (PDT) Received: from sh78.surpasshosting.com (sh78.surpasshosting.com [72.29.64.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1BA21F9DB8 for ; Thu, 27 Jun 2013 18:17:04 -0700 (PDT) Received: from c-68-51-76-178.hsd1.il.comcast.net ([68.51.76.178]:42410 helo=[10.0.1.88]) by sh78.surpasshosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UsNIu-0005nd-Vc for hybi@ietf.org; Thu, 27 Jun 2013 21:16:54 -0400 From: Peter Thorson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <39A7ABA3-0579-40EA-804A-DCA19B35E3ED@zaphoyd.com> Date: Thu, 27 Jun 2013 20:16:46 -0500 To: "hybi@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sh78.surpasshosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zaphoyd.com X-Get-Message-Sender-Via: sh78.surpasshosting.com: authenticated_id: webmaster@zaphoyd.com X-Source: X-Source-Args: X-Source-Dir: Subject: [hybi] More minor permessage-deflate notes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 01:17:13 -0000 8.1.2.1. s2c_max_window_bits Using this parameter, a client limits the LZ77 sliding window size that = the server uses to compress messages. If the peer server doesn't use = small LZ77 sliding window to compress messages, the client can reduce = the memory for the LZ77 sliding window. -> Is this right? Shouldn't it be... if the server *does* use a smaller = sliding window then the client can save memory? The description of the = reverse later on (for the server) appears correct: Using this server-to-client parameter, a server limits the LZ77 sliding = window size that the client uses to compress messages. This reduces the = amount of memory that the server has to reserve for the connection, in = the same way the "s2c_max_window_bits" extension parameter does for the = client. -------------------- 8.1.2.2. c2s_max_window_bits If the parameter has a value, the parameter also tells the peer server a = hint that the client is not likely to use LZ77 sliding window size = greater than the size specified by the value to compress messages. -> As with the previous mail. What does "not likely" mean? Announcing = only seems useful if it is announcing something more definitive.=20 -------------------- Minor grammar issue: 8.1.2.1. s2c_max_window_bits A client MAY include the "s2c_no_context_takeover" extension parameter = to an offer. Corrected: A client MAY attach the "s2c_no_context_takeover" extension parameter to = an offer. OR A client MAY include the "s2c_no_context_takeover" extension parameter = in an offer. ... same error occurs in a few other places ... - A server MAY include the "s2c_no_context_takeover" extension parameter = to a response - A client MAY include the "c2s_no_context_takeover" extension parameter = to an offer. - A server MAY include the "c2s_no_context_takeover" extension parameter = to a response. - A client MAY include the "s2c_max_window_bits" extension parameter to = an offer. - A server MAY include the "s2c_max_window_bits" extension parameter to = a response - A client MAY include the "c2s_max_window_bits" extension parameter to = an offer.= From tyoshino@google.com Thu Jun 27 20:49:31 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82ABF11E80F8 for ; Thu, 27 Jun 2013 20:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAMySWlGmTGS for ; Thu, 27 Jun 2013 20:49:31 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6194F11E816B for ; Thu, 27 Jun 2013 20:49:30 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id m6so312325wiv.3 for ; Thu, 27 Jun 2013 20:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TApwGxY/9y6baxobwrAyrGlEzVYlG+ILWsLTccyT8io=; b=OvIfcTp0oN6Ezj0p1P3Wvh87DhAoORHZCDT0uRsCgNKqrgCBiGXZ1Mn6yZHzPwTCjO NJCdLtQ07N50QM6mKsOFwHtvPxgkYEWd2VMgZ0KHmbqoPEqKqsFyLZf4yjpOxa8bdqQk ngxK7j2gzVQs9hjGKTDgjdJHxcFPgCprV1fCuaAhu8DAkknNiGpsBAAhRjoig2puGqna IviqDvCoVKAudzVaCIakGD87n8/3FD5idm/h9yiQRHhqsdjBOQ6ca4COp2zDoFcIFw1k KulflBOwePeoIgGhNEmO/ymvYpn1dzOQFevkKq6kJ6Zz1LetDcPKbxkRO+WtiNzPX0D1 s3gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=TApwGxY/9y6baxobwrAyrGlEzVYlG+ILWsLTccyT8io=; b=PabH76IDGWwb9wRdCJU/lrqBn4+MR2/gLXhskltj/s7yaiPqZxvkqZAUaqPv58XL7Y Knn39naVEeUvthOgT2DGW5p2SO0Ti9L6nS1r13jyow+FwIIl563HaG9JyqqEZEicrMXh I+X31gmThKG1zqjmB7jyUfmgCQXFPjlNCkBnM3ZpyVkqPTW2Jn0Q1WKTf9DzMUzrnT3l LVp0JI7kMrGrw4D6Usd9Rg0ECI65hxrtFV4eKYz0/abqOi5LmzRiqqr9FkL/SG7fN7fn OQkF4qxPb0eGV+1QTM/dWmxOVxshmFY+NbkespB+aJmSUF1+g2H8IpOtiD1zuXPZ0Bes SibA== X-Received: by 10.194.21.231 with SMTP id y7mr8115799wje.94.1372391369374; Thu, 27 Jun 2013 20:49:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.175.161 with HTTP; Thu, 27 Jun 2013 20:49:09 -0700 (PDT) In-Reply-To: <39A7ABA3-0579-40EA-804A-DCA19B35E3ED@zaphoyd.com> References: <39A7ABA3-0579-40EA-804A-DCA19B35E3ED@zaphoyd.com> From: Takeshi Yoshino Date: Fri, 28 Jun 2013 12:49:09 +0900 Message-ID: To: Peter Thorson Content-Type: multipart/alternative; boundary=047d7b5d27fc109a5404e02ec420 X-Gm-Message-State: ALoCoQkb8QBxHs/mJEPJGsbuKTOF0nwVHJunD67c7442dHYUgbEq9MiX6O0gSKXir8IQX3BDY0AGWuSlVjxBt+KDCtFcaVYP5+7aOn/GwofQwaY3laOtgJd2m2n2PCnEsRECRuEJbBu9BFp8gZzAaXjOe3lbq+9RzbcHeOAMg51R0AcO7zbiVP3xOH+upXDyfhhX2oL0QRjE Cc: "hybi@ietf.org" Subject: Re: [hybi] More minor permessage-deflate notes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 03:49:31 -0000 --047d7b5d27fc109a5404e02ec420 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 28, 2013 at 10:16 AM, Peter Thorson wrote: > 8.1.2.1. s2c_max_window_bits > Using this parameter, a client limits the LZ77 sliding window size that > the server uses to compress messages. If the peer server doesn't use small > LZ77 sliding window to compress messages, the client can reduce the memory > for the LZ77 sliding window. > > -> Is this right? Shouldn't it be... if the server *does* use a smaller > sliding window then the client can save memory? The description of the > reverse later on (for the server) appears correct: > Right. Thanks for reporting. > 8.1.2.2. c2s_max_window_bits > If the parameter has a value, the parameter also tells the peer server a > hint that the client is not likely to use LZ77 sliding window size greater > than the size specified by the value to compress messages. > > -> As with the previous mail. What does "not likely" mean? Announcing only > seems useful if it is announcing something more definitive. > Now the response from the server represents all the configuration about permessage-deflate on the session. If we give some definitive meaning to client-to-server c2s_max_window_bits, configuration will depend on that too. We can avoid this by requiring the peer server to acknowledge c2s_max_window_bits by sending back server-to-client c2s_max_window_bits equal to or smaller than this value. Then, the client-to-server c2s_max_window_bits will have a definitive meaning "request c2s_max_window_bits". I'm not sure if this is meaningful. > Minor grammar issue: > Thanks. I'll fix them. --047d7b5d27fc109a5404e02ec420 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 28, 2013 at 10:16 AM, Peter Thorson <web= master@zaphoyd.com> wrote:
8.1.2.1. =A0s2c_max_window_bits
Using this parameter, a client limits the LZ77 sliding window size that the= server uses to compress messages. If the peer server doesn't use small= LZ77 sliding window to compress messages, the client can reduce the memory= for the LZ77 sliding window.

-> Is this right? Shouldn't it be... if the server *does* use a smal= ler sliding window then the client can save memory? The description of the = reverse later on (for the server) appears correct:

Right. Thanks for reporting.
=A0
8.1.2.2. =A0c2s_max_window_bits
If the parameter has a value, the parameter also tells the peer server a hi= nt that the client is not likely to use LZ77 sliding window size greater th= an the size specified by the value to compress messages.

-> As with the previous mail. What does "not likely" mean? Ann= ouncing only seems useful if it is announcing something more definitive.

Now the response from the server re= presents all the configuration about permessage-deflate on the session. If = we give some definitive meaning to client-to-server c2s_max_window_bits, co= nfiguration will depend on that too.

We can avoid this by requiring the peer ser= ver to acknowledge c2s_max_window_bits by sending back server-to-client c2s= _max_window_bits equal to or smaller than this value. Then, the client-to-s= erver c2s_max_window_bits will have a definitive meaning "request c2s_= max_window_bits". I'm not sure if this is meaningful.
=A0
Minor grammar issue:

Thanks. I'll fix them.=A0
<= /div>
--047d7b5d27fc109a5404e02ec420-- From webmaster@zaphoyd.com Fri Jun 28 04:20:00 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4178E21F9F1B for ; Fri, 28 Jun 2013 04:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFlX8GwIIZIJ for ; Fri, 28 Jun 2013 04:19:50 -0700 (PDT) Received: from sh78.surpasshosting.com (sh78.surpasshosting.com [72.29.64.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4424121F9EFB for ; Fri, 28 Jun 2013 04:19:49 -0700 (PDT) Received: from c-68-51-76-178.hsd1.il.comcast.net ([68.51.76.178]:44266 helo=[10.0.1.88]) by sh78.surpasshosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UsWiL-00019b-MU; Fri, 28 Jun 2013 07:19:42 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_4237138E-D552-4230-8710-F62030D5F13F" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Peter Thorson In-Reply-To: Date: Fri, 28 Jun 2013 06:19:40 -0500 Message-Id: <8A9626A2-1124-49D4-9424-EA69C18C4559@zaphoyd.com> References: <39A7ABA3-0579-40EA-804A-DCA19B35E3ED@zaphoyd.com> To: Takeshi Yoshino X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sh78.surpasshosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zaphoyd.com X-Get-Message-Sender-Via: sh78.surpasshosting.com: authenticated_id: webmaster@zaphoyd.com X-Source: X-Source-Args: X-Source-Dir: Cc: "hybi@ietf.org" Subject: Re: [hybi] More minor permessage-deflate notes X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 11:20:00 -0000 --Apple-Mail=_4237138E-D552-4230-8710-F62030D5F13F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jun 27, 2013, at 22:49 , Takeshi Yoshino wrote: > On Fri, Jun 28, 2013 at 10:16 AM, Peter Thorson = wrote: > 8.1.2.1. s2c_max_window_bits > Using this parameter, a client limits the LZ77 sliding window size = that the server uses to compress messages. If the peer server doesn't = use small LZ77 sliding window to compress messages, the client can = reduce the memory for the LZ77 sliding window. >=20 > -> Is this right? Shouldn't it be... if the server *does* use a = smaller sliding window then the client can save memory? The description = of the reverse later on (for the server) appears correct: >=20 > Right. Thanks for reporting. > =20 > 8.1.2.2. c2s_max_window_bits > If the parameter has a value, the parameter also tells the peer server = a hint that the client is not likely to use LZ77 sliding window size = greater than the size specified by the value to compress messages. >=20 > -> As with the previous mail. What does "not likely" mean? Announcing = only seems useful if it is announcing something more definitive. >=20 > Now the response from the server represents all the configuration = about permessage-deflate on the session. If we give some definitive = meaning to client-to-server c2s_max_window_bits, configuration will = depend on that too. >=20 > We can avoid this by requiring the peer server to acknowledge = c2s_max_window_bits by sending back server-to-client c2s_max_window_bits = equal to or smaller than this value. Then, the client-to-server = c2s_max_window_bits will have a definitive meaning "request = c2s_max_window_bits". I'm not sure if this is meaningful.=20 So the idea would be..=20 1. client sends c2s_max_window_bits=3D10.=20 2a. If the server doesn't care (perhaps it only supports the default 15 = window) then it can omit that parameter from the negotiation. Client is = still free to (but not strictly required to) stay under 10 bits. 2b. If the server understands this and acknowledges by returning = c2s_max_window_bits=3D10, client is now bound by this value and server = can reduce memory usage accordingly. This interpretation wasn't clear to me from the text of the spec. Given = your explanation here I think this is a good way to do it. > Minor grammar issue: >=20 > Thanks. I'll fix them.=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --Apple-Mail=_4237138E-D552-4230-8710-F62030D5F13F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 tyoshino@google.com> = wrote:

On Fri, Jun 28, 2013 at 10:16 AM, Peter = Thorson <webmaster@zaphoyd.com> wrote:
8.1.2.1. =  s2c_max_window_bits
Using this parameter, a client limits the LZ77 sliding window size that = the server uses to compress messages. If the peer server doesn't use = small LZ77 sliding window to compress messages, the client can reduce = the memory for the LZ77 sliding window.

-> Is this right? Shouldn't it be... if the server *does* use a = smaller sliding window then the client can save memory? The description = of the reverse later on (for the server) appears = correct:

Right. Thanks for = reporting.
 
8.1.2.2.  c2s_max_window_bits
If the parameter has a value, the parameter also tells the peer server a = hint that the client is not likely to use LZ77 sliding window size = greater than the size specified by the value to compress messages.

-> As with the previous mail. What does "not likely" mean? Announcing = only seems useful if it is announcing something more = definitive.

Now the = response from the server represents all the configuration about = permessage-deflate on the session. If we give some definitive meaning to = client-to-server c2s_max_window_bits, configuration will depend on that = too.

We can avoid this by requiring = the peer server to acknowledge c2s_max_window_bits by sending back = server-to-client c2s_max_window_bits equal to or smaller than this = value. Then, the client-to-server c2s_max_window_bits will have a = definitive meaning "request c2s_max_window_bits". I'm not sure if this = is = meaningful. 

= So the idea would be.. 

1. client = sends c2s_max_window_bits=3D10. 
2a. If the server = doesn't care (perhaps it only supports the default 15 window) then it = can omit that parameter from the negotiation. Client is still free to = (but not strictly required to) stay under 10 bits.
2b. If the = server understands this and acknowledges by = returning c2s_max_window_bits=3D10, client is now bound by this = value and server can reduce memory usage = accordingly.

This interpretation wasn't clear = to me from the text of the spec. Given your explanation here I think = this is a good way to do it.

Minor grammar = issue:

Thanks. I'll fix = them. 
_______________________________________________
hybi mailing = list
hybi@ietf.org
https://www.ietf.org/ma= ilman/listinfo/hybi

= --Apple-Mail=_4237138E-D552-4230-8710-F62030D5F13F--